The advice you hear everywhere is: give your LLM tools. Wire up an MCP server, expose your API, watch the model get smarter. It works, too — the first time you hand an agent a tool it couldn’t reach before, it does feel like leveling up.

Then the session ends, and the intelligence evaporates.

The next agent you spin up starts from zero. It has the same tool, and none of the knowing. It’ll call the endpoint that costs real money without checking a balance first, pick the wrong script for the wrong prospect, and cheerfully do the thing you spent an hour last week teaching a different agent never to do. The tool survived. Everything you learned about using it didn’t.

That’s the trap. A tool adds a capability to one agent for one conversation. What you actually want is to teach every agent you’ll ever connect — at once, permanently. That isn’t a tool. That’s a system.

What a tool actually buys you

We built a sales system called Pipe — prospect research, call scripts, outbound dialing, campaign metrics, the whole revenue loop. The obvious first move was to expose it to our agents: we wrapped its real actions as MCP tools. Dozens of them. Discover prospects, qualify a lead, place a call, pull the campaign metrics, check the balance before you spend.

It worked, in the narrow way tools work. The agent could do things now. It could also do them badly, because a list of callable actions tells a model what it can do and says nothing about when, in what order, or what will get you in trouble. place_call is one function signature. “Never batch-dial a list of real people blind — place one call, profile it to completion, evaluate it against what you expected, and only then dial the next” is not something a function signature can carry.

That second sentence is the actual expertise — and on the tools-only path, it lives nowhere. It lives in your head, and you re-type it into every new session until you die.

The layer that turns a tool into a teammate

We wrote it down instead — next to the tools, not in a chat window. Pipe got an AGENTS.md: the operating manual an agent reads before it touches anything. The calling protocol became a skill file. The recurring plays became runbooks. The one-call-at-a-time rule stopped being a thing I remembered and became a thing the system remembered.

That’s the shift. The tool is the verb. The documentation is everything that makes the verb safe to conjugate.

Here’s the test I use now, and it’s cheap: a capability an agent can invoke but doesn’t know how to use isn’t a capability — it’s a liability with an API. A glossary the agent doesn’t read is a diary. A tool the agent doesn’t understand is a loaded footgun you handed a very confident intern. Writing the AGENTS.md, the skills, the runbooks is what turns “dozens of callable endpoints” into “an agent that knows how to sell responsibly.” Same tools. Completely different colleague.

Documenting one system once still isn’t the win, though. It’s the setup for the win.

The move that compounds: centralize the knowing

Here’s where it stops being about Pipe.

We don’t keep Pipe’s operating knowledge locked inside Pipe. We pull it up into a central context vault — the second brain, the nexus, whatever you want to call the one directory that every agent reads on the way in. Agent definitions live there. Skills live there. Runbooks, the memory system, and context slices that load only when the work matches — all there, in one place, version-controlled, synced.

That vault is the launchpad — and the reason it matters is dumb-simple and easy to miss: any LLM we connect to it inherits all of it, instantly. New model drops on a Tuesday? Point it at the vault. It doesn’t relearn how to run Pipe. It doesn’t rediscover the one-call-at-a-time rule the hard way. It walks in already knowing everything every previous agent knew, because the knowing was never in the agent. It was in the vault the whole time.

That’s the word this whole post rests on.

Tools are verbs. The harness is the world they act in. Get the world right once and every agent you drop into it — this model, the next one, the one Anthropic ships next quarter — starts fluent instead of feral.

It’s a pattern, not a one-off

If it were just Pipe, it’d be a nice story and not a principle. It’s a principle.

We built a second system, Optimus — a markdown-first, hyperscaler-independent agentic runtime that centralizes context, governs token spend, and stands up virtual agent teams to run the whole software-delivery lifecycle. Think an agentic Trello: it plugs into any hyperscaler, spins up virtual agent teams, builds your projects on autopilot, and curates the context they run on. Same exact shape. Expose its real actions as tools: projects, goals, docs, daily planning, checkpoints, memory. Then document what those actions are for and when to reach for them. Then fold that documentation back into the vault as first-class context, so every agent inherits it alongside everything else.

Expose → document → centralize. Tool, then system, then launchpad. Do it once and you’ve got a capability. Do it every time and you’ve got a compounding asset — a second brain that gets smarter every time you teach any part of it anything, and hands that intelligence to every model you’ll ever plug in. The context doesn’t reset per session anymore. It accrues.

The Claude Code team made the same bet

Here’s the part that made me stop treating this as a personal quirk and start treating it as the shape of the thing.

Boris Cherny built Claude Code, and the origin story he tells isn’t “I gave a model a big toolbox.” It’s the opposite. (Paraphrasing his account on Lenny’s Podcast:) the first version was barely more than a model in a terminal that could reason with code. He gave it a single Bash tool — no instructions on how to use it — and asked it what music he was listening to. It figured out, on its own, how to write code to answer. The shocking part wasn’t the tool. It was that the model, given a runtime it could reason inside, worked out the rest itself. The design philosophy he describes is “the product is the model itself” — expose it, wrap it in minimal scaffolding, give it a minimal toolset, and let its reasoning do the work.

Read that again with the argument of this post in your ear. They didn’t start with a hundred tools. They started with the runtime — the shell, the ability to reason with code — the substrate an intelligence could stand on. The tools came after, and stayed deliberately few. The system was the product; the tools were the thin layer on top.

That’s the same lesson from the other end. Building Claude Code, they invested in the ground the model stands on. Building on top of Claude Code, we invest in the vault every agent reads. Different altitude, identical bet: the durable thing is the harness, not the tool count.

So here’s the question

Go look at what you’ve wired up for your agents. Be honest about the split: how much of it is tools — raw capabilities, bolted on, session-scoped — and how much is system — documentation, memory, rules, sitting in one place every agent inherits on the way in?

For most setups I’ve seen, it’s almost all tools and almost no harness — which means every new agent, every new model, starts over.

So: if a brand-new model connected to your setup tomorrow morning, what would it already know — and what would it have to learn the hard way, again, that you already taught something last week?

---

This is part of the Agentic Foundations series. If you haven’t read Context Is King, start there — the harness is just context that refuses to reset.