Building AI Agents That Actually Work: A Beginner’s Full Course

AI is confusing. There, I said it.

Skills. MCPs. Agent harnesses. Context engineering. There are a lot of terms floating around, and somehow every new product introduces three more.

But underneath the terminology, the setup is surprisingly straightforward: give an AI a goal, explain your business, connect the tools it needs, and teach it the processes you repeat.

That is how you move from asking AI questions to building an executive assistant, a content team, or a marketing agent that can actually get work done.

The useful thing about learning these concepts is that they travel. Claude Code, Codex, Cowork, Antigravity, Manus, and OpenClaw have different interfaces and capabilities, but the underlying ideas are similar. Think of it as learning to drive rather than memorizing the dashboard of one particular car.

Chat Is Question to Answer. An Agent Is Goal to Result.

A chat interaction is usually a back-and-forth exchange. You ask something, the model replies, and then you do the work. It is a bit like ping-pong.

An agent takes a different approach. You give it a task, it works out the next steps, uses available tools, and keeps going toward a result.

• Chat: Explain how to build a portfolio website.
• Agent: Build the portfolio website and start a preview so I can inspect it.

The difference is not simply that the second response is longer. The agent can perform actions between responses, inspect what happened, and decide what to do next.

That does not mean it is guaranteed to succeed, or that you should hand it your entire business on day one. It means the unit of work changes from an answer to a task.

The observe, think, act loop

Inside an agent is a repeating cycle:

1. Observe: Read the request, available files, tool results, and relevant context.
2. Think: Decide what should happen next.
3. Act: Use a tool, create a file, run a command, or take another permitted action.

The result of that action feeds back into the next observation. The agent repeats the cycle until it considers the task complete or needs something from you.

Suppose the task is to build a minimalist portfolio site for Greg Isenberg. Starting with an empty workspace, the agent might:

1. Inspect the folder to see whether a project already exists.
2. Research Greg to understand who the site is about.
3. Use that research to plan the page.
4. Write the website code.
5. Start a local preview.
6. Open the page and inspect the result.

The goal also needs a finish line. For a research assignment, “find 10 sources and produce a PowerPoint report” gives the agent a much clearer completion condition than “research this topic.”

Good delegation includes a deliverable and a definition of done.

The four pieces of an agent

A useful way to organize all of this is into four components:

• The model: The LLM doing the reasoning.
• The loop: The mechanism that lets it continue beyond one response.
• The tools: The capabilities it can use to take action.
• The context: The information it needs to work intelligently.

The application that brings these pieces together is often called an agent harness. That is the intimidating term for the environment facilitating the work.

Different harnesses offer different features, permissions, scheduling options, and ways to inspect progress. But once you understand the model, loop, tools, and context, switching platforms becomes much less mysterious.

What Happens When Three Agents Get the Same Website Task?

We gave Claude Code, Codex, and Antigravity essentially the same assignment: build a minimalist portfolio website for Greg and make it available in a local preview.

Each worked in a separate folder. That folder is the project workspace, much like a project in a chat application, except the working files are on the computer rather than only inside a cloud interface.

All three produced a usable-looking site. The interfaces made their progress visible in different ways, but the work followed the same general pattern: inspect, gather information, create the site, and start the preview.

In the Claude Code run, a connected Perplexity tool helped with research. Later, the agent opened the site and used screenshots to check the output. That is the loop in a concrete form: it did not simply write code and stop.

Here is the important catch: one site had the wrong email address and outdated location information.

The design looked good. The facts were not all right.

That is a useful distinction for beginners. A polished result is not the same as a verified result. You still need to review factual details, especially when the agent has researched them rather than received them directly from you.

A small business idea hiding in the demo

This immediately suggests a possible service: build a clean website for a business before pitching it.

Instead of sending an abstract offer to redesign someone’s site, you could show them a finished starting point and offer to sell it for something like $250.

That was a business idea prompted by the demonstration, not a validated business model. But it illustrates the shift nicely: an agent can help you create the thing you are selling, not just write an email describing it.

Security Starts With What the Agent Can Access

Before connecting an agent to your business, ask a simple question: What is the worst thing it could do with the permissions I am giving it?

An agent that can read an inbox has a different risk profile from one that can send messages. An agent that can analyze ad performance is different from one that can change ad budgets.

The practical approach is to scope access around the task:

• Use read-only permissions where reading is sufficient.
• Limit which files and services the agent can access.
• Be deliberate about permissions that allow spending, sending, or modifying important information.
• Keep review steps around consequential actions while you learn how the workflow behaves.

A familiar company name is not a substitute for sensible permissions. The goal is to make the possible downside manageable if the agent makes a mistake or the setup is compromised.

You can expand responsibility as a workflow becomes more reliable. You do not need maximum autonomy to get meaningful value.

Build Your First Agent Like You Are Onboarding an Employee

If you hired an executive assistant, you would not sit them down and say, “Write me a cold email,” without explaining what your company does.

You would tell them about your customers, your tools, your preferences, and the kind of work you want them to handle.

An AI assistant needs the same onboarding.

Remy organizes his workspaces with a folder for each company or client, then separate folders for roles such as executive assistant, head of marketing, and content team. More elaborate setups can include an overarching agent that coordinates those roles.

For a beginner, one folder called “executive assistant” is enough. Open it in your chosen harness and start there.

Do not try to create an entire AI company before you have one assistant doing one useful job.

Create the always-available context file

In the empty-folder example, asking the assistant to write a cold email led to obvious questions: What do you sell? Who are you targeting? What tone should it use?

The fix is a persistent instruction file in the workspace. Depending on the platform, you will encounter names such as AGENTS.md, CLAUDE.md, or GEMINI.md. Use the exact filename and placement your harness expects.

These are plain-text Markdown files. You can think of them as the workspace’s standing instructions, similar in purpose to custom instructions in a project or custom GPT. The AGENTS.md documentation provides a useful reference for that convention.

Your first context file should explain:

• The role: What this assistant is responsible for.
• You and your business: What you do and what you sell.
• Your customers: Who you serve and what they need.
• Your working preferences: Tone, communication style, and relevant constraints.
• Your tools: Which applications you use and what each is for.

You do not have to write the whole thing from scratch. Ask your preferred AI to interview you, one question at a time, and use the answers to build the context file.

That is often easier than staring at a blank document and trying to remember everything an assistant should know.

Context engineering beats hunting for the perfect prompt

When the assistant knows nothing, the prompt has to explain everything.

When it already understands your business, the prompt can be simple. “Write me a cold email” still leaves room for a clarifying question, but now that question can be specific: Is this for a sponsor, a partner, or a consulting prospect?

That is the practical shift from prompt engineering to context engineering. You spend less time crafting a magical instruction and more time making sure the right information is available.

As the setup grows, split supporting information into a context folder. You might have separate documents for your background, brand voice, and ideal customer profile.

Then tell the agent, in its standing instruction file, where to find that context and when to read it. Simply putting documents in a folder does not guarantee every harness will load them into every session.

The same approach can point an agent toward an Obsidian vault or another collection of business notes. The key is making the route to the information explicit.

A small input shortcut

Voice-to-text can make this onboarding much faster. Remy uses Monologue to dictate instructions, and Wispr Flow is another option mentioned in the discussion.

The point is not which dictation app you choose. It is that explaining your business out loud can be easier than typing a perfectly organized brief. Let the AI help turn that explanation into a useful document.

Add Memory So Corrections Survive the Next Session

Context answers “Who are we, and how do we work?” Memory answers “What have we learned along the way?”

Do not assume your agent remembers a previous conversation just because a chat product sometimes does. Memory behavior varies by product and configuration. In a local, file-based workflow, you should be explicit about what persists.

Here is the simplest test: tell the assistant your favorite color is lavender. Then start a fresh session in the same folder and ask what your favorite color is.

Without a persistence mechanism, the assistant may have no idea. Saying “Got it” in one conversation does not necessarily mean it saved anything.

The business version is more frustrating: you correct an email sign-off today, then tomorrow it uses the same wrong sign-off again.

Create a memory.md file and a rule for updating it

Add a file called memory.md. Then update the standing instructions so the assistant knows to:

1. Read the relevant context files at the start of work.
2. Read memory.md for preferences and lessons from previous sessions.
3. Save meaningful corrections and new durable preferences in the relevant memory section.
4. Replace outdated information rather than accumulating contradictory rules.

Once that behavior is in place, the lavender example changes. The agent can write the preference to the memory file, making it available to a future session that reads it.

More useful examples include:

• Use “warm regards” rather than “cheers” in client emails.
• Keep client communication in email rather than Slack.
• Use a casual tone instead of overly formal language.
• Avoid dark mode in this particular website project.
• Follow a preferred structure when organizing Facebook ads.

This creates a feedback loop. You correct the assistant, it records the correction, and subsequent work can use that preference.

It is not retraining the underlying model. It is improving the instructions and information available to it. That distinction matters, because the saved preference still has to be read and followed.

Keep memory useful, not enormous

Remy’s rule of thumb is to keep the primary instruction file around 200 lines or fewer. That is a working guideline, not a universal limit for every memory file.

If the assistant saves every tiny remark, narrow the rule to substantial corrections and durable preferences. If old rules conflict with new ones, update or remove the outdated information.

Some harnesses provide built-in memory features. You may not need to build this manually in every product, but understanding the mechanism helps you diagnose why an assistant keeps repeating a mistake.

Connect Your Tools With MCP

An assistant that knows your business can write more relevant answers. An assistant that can use your tools can start doing the work.

This is where MCP, the Model Context Protocol, comes in.

The beginner-friendly analogy is a translator. Your agent and your applications need a consistent way to communicate. MCP provides a standardized interface for exposing tools and context to an AI application, rather than requiring a completely bespoke connection for every combination.

Anthropic introduced the protocol. The official MCP introduction explains the underlying architecture in more detail.

The analogy has a limit: MCP does not magically make every application available. You still need a compatible connection and the right authorization.

In a friendly interface, that might mean opening a connectors menu, choosing an app, signing in, and granting permissions. Other harnesses use different setup flows.

For the executive assistant, useful connections include Gmail, Google Calendar, Granola for meeting notes, Notion for project management, and Stripe for payments.

You can also connect research tools. That is how Claude Code had access to Perplexity during the website example: the capability had already been connected, and the agent selected it when research was needed.

The Real Value Is Stacking Tasks Across Applications

“Summarize my inbox” is a reasonable starting point. But on its own, it does not explain why this way of working is so interesting.

The value becomes clearer when the assistant can move from the email to the work behind it.

For the demonstration, Remy created a fictional prospect email and a matching set of meeting notes. The prospect wanted next steps after a call.

Instead of manually jumping between applications, the assignment became:

1. Read the prospect’s email.
2. Review the meeting notes in Granola.
3. Draft the follow-up and proposal details using that context.
4. Create the appropriate Stripe payment link.
5. Set up the project in Notion.
6. Prepare the email for review.

That is a much more meaningful workflow than summarization. It joins information and actions across several tools.

The draft incorporated details from the meeting and included a payment link. It could then be reviewed in Gmail, with sending treated as a separate action.

The leverage comes from removing the handoffs. You are not copying meeting notes into one application, moving payment details into another, and explaining the same prospect three times.

This is what Remy means by an “AI operating system”: a central working environment that combines your context, tools, preferences, and processes.

His preferred environment is Claude Code inside Visual Studio Code, but the idea matters more than the interface. Plain Markdown files also give you a portable foundation. Moving to another harness may require adjusting filenames, skill locations, and tool connections, but your business knowledge is not trapped inside one conversation.

Skills Are Standard Operating Procedures for AI

A skill is a reusable process. The easiest definition is an SOP for AI.

Imagine creating a client proposal. You spend 20 minutes adjusting it:

• Move the price to the bottom.
• Use a particular blue.
• Change the section order.
• Fix the formatting.

Eventually, you get a proposal you like. Without a reusable process, you may have to explain those details again the next time.

A skill captures how to do the job so the assistant can follow that process repeatedly.

Context, memory, and skills have different jobs

• Context: Your business, customers, role, and background.
• Memory: Durable preferences and lessons learned while working.
• Skills: Instructions for completing particular recurring tasks.
• Tools: The capabilities needed to carry out those instructions.

A general preference such as “keep my emails casual” belongs in memory. A detailed procedure for producing a specific kind of proposal belongs in a skill.

Skills commonly use a Markdown instruction file, often called SKILL.md, alongside references or other supporting resources. Some platforms can package them into an importable skill file. The exact format and installation location depend on the harness.

That supporting material is useful. A viral-hook skill, for example, can include both the writing procedure and a reference folder of hook formulas.

Two practical ways to create a skill

First, start with an existing process or body of knowledge. Remy used course material about viral hooks and asked a skill-creation capability to turn it into a reusable workflow for his content team. The resulting skill included instructions and supporting references.

Second, complete a task together, then package what worked. Work through the process with the assistant. Make corrections until the result is right. Then ask it to create a skill from the workflow you just completed.

The second approach is especially useful because you are capturing a process you have actually tested, not just writing an idealized SOP.

Start with tiny skills

One example was referring a prospect to Sebastian, a friend who runs an AI automation agency.

The assistant already had access to the prospect’s meeting notes. Remy supplied Sebastian’s contact information and asked for an introduction email connecting the two.

Once the draft was right, he asked the assistant to create a referral skill that remembered the process and the relevant contact details.

It is a small workflow. Maybe it saves 15 minutes when it comes up. But if it recurs several times, and you build similar skills for other recurring tasks, those savings add up.

A useful habit is to add three to five small skills a week as you encounter repeated work. You do not have to design them all in advance.

A Bigger Skill: Competitor Ad Analysis

The same idea scales beyond administrative tasks.

Remy built an ads analyst skill for reviewing a competitor’s Meta ad library and landing pages. In an example involving The Oodie, the workflow gathered roughly 220 ads, captured landing-page screenshots, and produced detailed analysis.

The outputs covered:

• Visual creative analysis.
• Advertising copy analysis.
• Hypotheses about why particular approaches might work.
• Possible improvements.
• Landing-page breakdowns and a master report.

Building the skill involved working through the process once: visit the ad library, gather the material, inspect the pages, and refine the analysis. After that, the process was packaged for reuse.

Remy estimated the manual work would previously have taken three or four hours. The important lesson is not a guaranteed time saving for every ad account. It is that a multi-step research workflow can become a repeatable capability rather than a fresh project every time.

It also shows why skills are more than saved prompts. They can organize a sequence of tool calls, reference material, analysis, and deliverables.

Chain Skills Together, Then Put Them on a Schedule

Once individual skills work, they can call on one another.

A morning briefing skill might review your inbox, calendar, and projects. If it finds a podcast recording on the calendar, it can invoke a separate guest-research skill to prepare talking points.

That gives you a useful chain:

1. Review the day’s schedule.
2. Identify meetings that need preparation.
3. Run the appropriate research skill.
4. Include that preparation in the daily brief.
5. Deliver the brief through a connected channel, such as email.

With scheduling support, you can run that workflow every morning at 9 a.m. rather than remembering to request it.

Availability and setup vary by harness, but the pattern is simple: a schedule decides when the work starts, and a skill defines how to do it.

Scheduled work is useful outside your company, too

I have been using a similar approach while looking for a car with a very specific color and feature set.

Instead of repeatedly checking CarMax, Cars.com, Autotrader, and other marketplaces, the search runs every three hours and notifies me when a matching option appears.

That replaces a habit of constantly refreshing listings with a recurring task.

Remy also uses a scheduled research skill for his newsletter team. Every Thursday morning, it gathers new developments in AI from sources including X and Reddit.

The distinction is useful: a personal car-search workflow belongs with an executive assistant, while a recurring industry-research workflow belongs with the newsletter team. The underlying machinery is the same.

Start Simple Before Moving to OpenClaw

OpenClaw uses the same broad building blocks: context files, memory, tools, skills, and scheduled work.

Its workspace can include additional files describing personality and identity, but those are extensions of the same idea. You are still giving an agent information about who it is, what it should do, and how it should work.

Remy’s OpenClaw Meta ads setup combined roughly 15 skills with tool access and scheduled tasks. Those skills covered jobs such as creating ad assets from a Dropbox folder and writing business-specific copy.

That is a more elaborate version of the executive assistant, not a completely different category of magic.

For a beginner, though, OpenClaw is a harder starting point. A more approachable environment such as Cowork, Claude Code, Manus, or Perplexity Computer lets you get comfortable with the concepts first. Your best choice depends on which interface feels manageable and supports the tools you need.

The sensible progression is:

1. Build the assistant in an environment you can understand and supervise.
2. Develop and test skills through daily use.
3. Confirm that its context, memory, and tool permissions behave as expected.
4. Consider a more autonomous setup only when you have reliable processes worth migrating.

You might spend a couple of weeks building a daily brief, meeting preparation, and referral workflows before considering that move.

More autonomy is useful when it runs a good process. It is not a substitute for creating one.

Keep Global and Project-Level Instructions Separate

One final concept makes these setups much cleaner: not everything belongs everywhere.

Global resources are available across your projects. Project-level resources apply to a particular workspace.

Remy has a general editing skill that shortens writing by removing unnecessary sentences rather than squeezing every sentence into denser language. That is useful across many roles, so it makes sense globally.

A Sebastian referral skill is different. It is useful for the executive assistant, but it does not need to sit in the marketing workspace.

The same distinction can apply to standing instructions and MCP connections:

• Global: Broad preferences and capabilities that genuinely apply across your work.
• Project-level: Role-specific context, business-specific procedures, and connections needed for that workspace.

Keeping those scopes separate reduces irrelevant context and helps prevent different companies, clients, and roles from bleeding into one another.

The right structure is the one that fits your work. You do not need to reproduce someone else’s entire folder system.

Your First Useful AI Agent

You do not need a complicated multi-agent organization to start. You need one role, enough context, a few appropriate tools, and a process worth repeating.

Here is the practical starting sequence:

1. Choose a role. An executive assistant is a useful first project.
2. Create its workspace. Keep the relevant files together.
3. Build the context file. Have the AI interview you about your business and preferences.
4. Set up persistence. Make sure important corrections can survive a new session.
5. Connect the necessary tools. Grant only the permissions the work requires.
6. Do a real task together. Review and correct the output.
7. Turn the successful process into a skill. Reuse it before expanding it.
8. Add scheduling when appropriate. Automate a process you already trust.

The question to keep asking is not “What is the ultimate AI prompt?” It is “What job do I keep doing, and what would the assistant need to do it properly?”

Answer that question a few times each week, and the setup gets more useful. The context becomes clearer. The preferences become more accurate. The library of repeatable processes grows.

That is how you build AI agents that actually work: not by finding one perfect product, but by steadily teaching a system how your work gets done.