What can it touch, and what should it never be able to touch?
Giving it real access to what it needs — files, commands, external services — and setting explicit limits on what it does not.
The idea that outlives the tools
Give it exactly the hands it needs, and put in writing what it must never touch.
A model can only talk. Everything an agent does — reading a file, running a test, calling an API — is a tool somebody handed it. That is the difference between asking for an answer and asking for work.
The problem is not having few tools: it is not knowing which ones it has. If the one it needs is missing, it often will not tell you — it produces a plausible result as though it had used it. And if it has too many it picks badly: twenty connected servers occupy the window before the work starts, and raise the odds of reaching for the wrong one.
The other half of this discipline is limits. The model cannot tell deleting a scratch file from deleting your branch; that distinction belongs to the environment, and if nobody declared it, it does not exist. Permissions declared in a file hold every time. Warnings written into a prompt hold almost every time, which on something irreversible is the same as never.
The protocol matters here too: when a standard exists for connecting agents to services, you write the integration once and every agent uses it — including the one you use next year. Without a standard, every agent-and-service pair is a bespoke adapter.
How it works, stage by stage
That was the why. This is the machine: what happens at each stage and, above all, which decision is yours at each one. If there is a stage where you decide nothing, that stage is being decided for you by the tool.
01
Inventory
What happens
At startup the agent receives a list of tools: read a file, run a command, call a service. Each one is a name, a description, and the shape of its arguments. That is everything it knows about them.
What you decide
Which ones you connect. That is the difference between asking for an answer and asking for work, and there is no middle ground: the one that is not there does not exist.
02
Description
What happens
The tool's description is the contract. The model picks which tool to use by reading that text, not by trying: an ambiguous description produces wrong choices consistently.
What you decide
How they are written. Two tools with similar descriptions get confused with each other forever.
03
Selection
What happens
Given a request it picks a tool and builds the arguments. If none fits, it often does not say so: it produces a plausible result as though it had used one.
What you decide
Noticing the silence. An agent missing the tool it needs does not fail loudly, it fails convincingly.
04
Permission
What happens
Before anything runs, the environment decides: this runs on its own, this asks first, this never runs. The model does not grade how much damage a command does; that grading is a configuration decision, taken in advance.
What you decide
Where the boundary sits. Permissions declared in a file hold always; warnings written in a prompt hold almost always, which on something irreversible is the same as never.
05
Result
What happens
Whatever the tool returns comes back into the window as text. A command that prints two thousand lines leaves two thousand lines inside the context, and from there on everything else thinks worse.
What you decide
What comes back whole and what comes back summarised. This is the most common context leak and the least visible.
06
Cost of having them
What happens
Every connected tool takes up window before the work starts, and adds one more option to choose wrongly between.
What you decide
Disconnecting. Twenty tools connected just in case perform worse than the five you actually use.
Signs you are missing it
It hands you instructions for what to do instead of doing it.
It claims it ran the tests and it did not.
It did something irreversible without asking.
You have so many servers connected that the window starts half full.
Common mistakes covering it
Connecting everything that exists “just in case”. Every connection costs context and precision.
Setting permissions wide open to stop seeing confirmations.
Trusting the agent to ask before something serious. Ask for it yourself, with a permission.
None of them is mandatory. Covering the discipline is mandatory; these are known ways of doing it.
Claude Code
AnthropicHarness
Terminal agent with declared permissions, hooks, subagents and skills; also on desktop, web and IDEs.
Problem, mechanism & fit
The actual pain
The model alone cannot read your repository or run your tests. Something has to build the loop and decide what it is allowed to touch.
How it works
Runs a loop over your project: reads, edits, executes and evaluates the result. Permissions are declared in a config file, hooks intercept actions deterministically, and subagents keep heavy work out of the main thread.
When it fits
When you want the loop in the terminal with fine control over permissions and automation. If you want assisted editing inside your editor, an IDE-integrated agent fits better.
Cursor
AnysphereHarness
An editor with the agent built into the editing surface.
Problem, mechanism & fit
The actual pain
Switching between terminal and editor breaks the thread when the work is mostly local editing.
How it works
An editor pairing repository indexing with an agent that edits in the same place you are reading the code, showing changes inline.
When it fits
When the work is mostly editing files and you want the diff where you are. For long multi-step tasks with many commands, a terminal agent gives more control.
Codex CLI
OpenAIHarness
OpenAI's terminal agent, with support for procedures and external services.
Problem, mechanism & fit
The actual pain
The same as any agent: the model needs hands.
How it works
A terminal agent loop over OpenAI models, with configurable approval modes and the ability to consume procedures and connected services.
When it fits
When you live in the OpenAI ecosystem. Worth knowing even if you do not use it: running two agents on the same task is the fastest way to see what the environment contributes and what the model contributes.
OpenCode
Open source communityHarness
An open source, provider-agnostic terminal agent.
Problem, mechanism & fit
The actual pain
Tying your whole workflow to one vendor's agent is a bet that the vendor stays ahead forever.
How it works
An open source agent loop that connects to multiple model providers, with agent and tool configuration held in the repository.
When it fits
When you want to swap models without swapping workflow, or you need to read and modify the environment itself.
Pi
EarendilHarness
A minimal harness: it runs agents in the terminal and brings nothing else. Whatever you need, you add.
Problem, mechanism & fit
The actual pain
Harnesses ship with opinions inside them — which permissions to ask for, how to split the work, which services to connect — and those opinions are not always yours.
How it works
A terminal with an interactive mode, scriptable output, an RPC protocol and an SDK to embed it. It extends through extensions, skills and prompt templates installed from npm or git. It routes to fifteen-plus providers and lets you switch model mid-session. Sessions stay in local files.
When it fits
When you already know which disciplines you want to cover and would rather build them than inherit somebody else's. If you are still working out what you are missing, a harness that brings nothing will not tell you either.
MCP
Anthropic, open standardProtocol
An open protocol connecting any agent to external tools, data and services.
Problem, mechanism & fit
The actual pain
Without a standard, every agent-to-service integration is a bespoke adapter, and every agent needs its own.
How it works
A server exposes tools and resources over a common protocol; any compatible agent consumes them. Write the integration once and every agent uses it, including the one you pick up next year.
When it fits
It is the reason your memory and your code index can survive a change of tool. Resist greed: every connected server occupies the window before the work starts.
Also helps with
Hooks
Ecosystem patternPattern
Control
Deterministic commands that run at defined moments, without passing through the model.