The five pieces of a real agent: harness, MCP, skills, sandbox, production layer

Step-by-Step Breakdown

1. The harness — the loop, and the part that is ordinary software

   The harness is not the AI; it is code. It sends prompts to the model, executes the actions the model asks for, manages the context window so the model does not drown in its own history, and keeps state so a long task survives a restart. If you have used Claude Code, Codex or Cursor, you have used a harness — you may just not have had a name for it. A model-agnostic harness is what lets you swap providers or drop in an open-weights model without rebuilding everything above it.

2. MCP — one protocol instead of N custom integrations

   Model Context Protocol is a standard way to expose tools to an agent. Before it, web search, calendar access and database queries were each a bespoke integration you wrote and maintained. MCP turns each into a server speaking one common language: the agent connects, asks what tools are offered, and uses them. The analogy used is USB — you do not write a driver per keyboard.

3. Skills — markdown that loads only when relevant

   A skill is a markdown file of instructions for one kind of task — the format to follow, the steps, the tool to use, the gotchas. The important mechanic is lazy loading: the agent knows a skill exists but only reads the whole file when it decides it needs it. That is what keeps a large skill library from consuming the context window. (Worth pairing with /skill-doctor, which reports what your loaded skills actually cost — see our September 6 changelog.)

4. The sandbox — a disposable computer for code execution

   Real tasks need to run code, and the honest question is whether you want an agent running arbitrary code on your actual machine with access to your files and credentials. The answer is a disposable isolated environment spun up per task and thrown away after, with scoped access. The agent gets full capability; your machine takes no risk. This is the piece most explanations skip entirely.

5. The production layer — subagents, approvals, observability

   Three things separate a demo from something you can run for real. Subagents split a large task across parallel workers instead of one context window doing everything. Approvals force the agent to stop and ask a human before anything sensitive. Observability is a full record of every step, tool call and result — so when something goes wrong you can read what happened instead of guessing, and so you can see which tool calls are failing.

6. The build: one command, then configure providers

   The harness starts with a single npx command and no paid account. On Windows it needs WSL; on Linux and macOS it runs directly in the terminal, assuming Node.js is installed. It prints a localhost URL, which opens a graphical interface where you create agents and attach tools, skills and resources. Models are configured under settings — add a hosted provider with an API key, or add a custom provider pointing at a locally served model. Because it is a self-hosted harness, it can be deployed on your own server or Kubernetes rather than living inside a vendor's runtime.

Gotchas & Caveats

• Sponsored video. The specific harness used in the build is the sponsor's product, open-sourced at the time of recording. The five-piece anatomy is vendor-neutral and applies to any agent stack; the build steps are specific to that tool.
• Cost-saving claims for running the same model through a different harness depend heavily on how that harness handles context and caching — treat any specific percentage as a vendor figure until you measure it on your own workload.
• Windows users need WSL for the one-command install; Node.js is assumed.

Key Takeaways

• The model is about 20% of an agent. Harness, MCP, skills, sandbox and the production layer are the rest, and they are ordinary software.
• A harness manages the context window and keeps state across restarts. Those two jobs are why a long task can survive at all.
• Skills load lazily — the agent knows they exist and reads them only when relevant, which is what makes a large library affordable.
• Sandboxes are the piece most people never think about, and the argument for them is simple: one bad command with root access reaches your files and credentials.
• Observability is not optional in production. Without a record of every tool call you are guessing at failures rather than reading them.
• A model-agnostic, self-hostable harness avoids provider lock-in and can be cheaper for the same model depending on how the harness manages context and caching.