Subagents, MCP and skills: fitting tools into C²

If you're past the basics of building with agents, you've hit the toolbox: subagents, MCP servers, slash commands, skills, hooks. Powerful, and easy to get lost in. People wire up six tools and end up with a setup nobody understands, context scattered across all of them.

Here's how to think about these tools clearly — what each is for, and how they fit a C² contextbase without fragmenting it.

The harness toolbox

These tools all live in the harness — the machinery around the model that turns it into a working agent. They extend what the agent can reach and do. The four you'll meet most:

• MCP servers — the plumbing that connects your agent to outside tools and data (GitHub, a database, a browser, your design tool).
• Skills — reusable instructions that teach the agent how to perform a task, applied automatically when relevant.
• Slash commands — explicit triggers you invoke by hand for a repeatable action.
• Subagents — separate agent instances with their own context window, spun up for a scoped task.

Martin Fowler's team groups all of this under harness engineering for good reason: it's the machine layer, sitting above your prompts and your context.

What each is actually for

The clean way to keep them straight is by job:

• MCP is the plumbing. Reach for it when the agent needs something outside your repo — live data, an external service, a tool the model can't reach on its own.
• Skills are the know-how. Reach for them when you want the agent to apply a richer workflow automatically when the situation calls for it.
• Slash commands are the trigger you control. Reach for them when you want an explicit, repeatable entry point — you decide when it runs.
• Subagents are the scoped worker. Reach for one when a task deserves its own clean context window — an independent review, a focused, repeatable check — so it doesn't clutter the main session.

Stuart Leo

MCP is the plumbing. Skills are the know-how. Slash commands are the trigger. Subagents are the scoped worker. Pick by the job, not the novelty.

Where the contextbase sits under them

Here's the part people miss. These tools extend the agent's reach. None of them is the agent's memory. A subagent with its own window still forgets when it's done. An MCP server fetches data but doesn't remember decisions. Skills encode how to do a task, not the decisions behind it and why.

The contextbase is the layer underneath all of them — the durable, version-controlled knowledge every tool and every agent reads. A subagent doing a review should read the same contextbase as the lead agent, so its judgement is anchored to the same decisions and gotchas. The tools give reach — the contextbase keeps that reach pointed at one source of truth.

Keeping tools from fragmenting context

The risk with a big toolbox is fragmentation — context scattered across six tools, no single place that's true. The discipline that prevents it:

• One source of truth. Decisions, patterns and gotchas live in the contextbase, in git — not buried in a skill file or an MCP server's config.
• Subagents read, they don't own. A subagent reads from the contextbase and writes its findings back to it. It doesn't keep private knowledge the lead agent can't see.
• The Router points to the tools too. Your Router can note which tools the project uses and when, so the setup is documented, not folklore.

The aim is one place that's true, with tools hanging off it — not knowledge smeared across the toolbox.

A simple decision rule

When you're tempted to add a tool, ask: does the agent need more reach, or does it need to remember better? If it's reach — connect to something, run a repeatable task — a harness tool is right. If it's memory — stop re-explaining, stop repeating mistakes — the answer is the contextbase, not another tool.

Tools give the agent reach. The contextbase keeps that reach pointed at the same source of truth.

Start here: see what an agent harness is, the Router file line by line, or read the method.