In my line of work the same meeting keeps coming round. A leadership team is shown an “agent” by a vendor and comes away thinking they have seen a very clever chatbot. What they are about to sign off on will run on its own, decide its own next steps, reach into their systems, and keep going until it judges the job finished. Nobody has drawn them the parts.
That gap is why the agent projects I see stall, or quietly frighten the people accountable for them. The word “agent” hides what is being deployed: an agent harness built around a model. The model is the part everyone talks about. The harness (everything that is not the model) is where the value and the risk both sit.
This piece is the parts list. Building an analysis agent is a different job. Read this one so that when a vendor or your own team shows you an agent, you can see its anatomy, and know which parts to ask about, which to take on trust, and which to put a rule around. There are five parts, and none of them is magic.
The engine and the agent harness
Start with the distinction that clears most of the fog: the model is not the agent.
The model (Claude, GPT, Gemini, whichever you use) is a text engine. Give it some text, and it predicts the most useful text to come next. On its own it cannot open a file, send an email, or check yesterday’s numbers, and it has no memory of your last conversation. Left alone, it is a very well-read colleague locked in a room with no phone and no memory between meetings.
The harness is everything you build around that engine to let it work. It is the loop that keeps it going, the tools that let it act, the memory that lets it carry the task forward, and the record of what it did. Thorsten Ball, who helped build the coding agent Amp, put it in one line in his public “How to Build an Agent” write-up: an agent is “an LLM, a loop, and enough tokens.” An LLM (a large language model) is the text engine just described; tokens are the units of text it reads and writes, which is why there is a budget at all. He showed it by building one in the open, and the working agent came to fewer than 400 lines of code, most of it plumbing.
That line is reassuring and slightly alarming at once. Reassuring, because the mystique falls away: there is no hidden intelligence in the box, just a loop you can understand. Alarming, because if an agent comes down to a loop and some tools, then whoever wrote the harness, not the company that made the model, decided what your agent may touch, how far it may go unattended, and whether anyone can see what it did afterwards. That is your governance surface, and it sits entirely in the harness.
The five parts. Only the middle one comes from your model vendor; the other four are decisions somebody has already made on your behalf.
The loop that does the work
Every agent, underneath, is the same short cycle. The harness sends the model the goal and everything known so far. The model replies with either an answer or a request to use a tool. If it asked for a tool, the harness runs the tool, adds the result to what the model can see, and sends it all back. The model reads the result and decides the next step. Round and round, until the model judges the task done or a stopping rule cuts it off.
That is the whole architecture: the actual one, not a drawing simplified for your benefit. The people who build these systems document it in the same terms. Anthropic’s own documentation for Claude Code puts the loop in a sentence: the model “evaluates your prompt, calls tools to take action, receives the results, and repeats until the task is complete.” OpenAI’s agent toolkit describes the same cycle: call the model, run whichever tools it asks for, add the results to what it can see, and go round again. The loop is the heartbeat of an agent.
The control loop. The stopping rule and the human gate are the dials you set — and leaving them where you found them is also a setting.
Three things about this loop matter more to you than they do to whoever writes it.
The model chooses its own next step each time round. There is no fixed script you could read from start to finish. Between “received the goal” and “declared done” it may take twenty steps you never specified, and it picks each one.
The loop is also where autonomy is set. How many times may it go round before it has to stop and ask a person? Which steps run untouched, and which need a human to approve before they execute? Those limits are dials in the harness, and they are the most consequential governance decision you will make about an agent. They also start switched off: the same Anthropic documentation notes plainly that without limits the loop simply runs until the model decides it has finished. An agent with no stopping rule and no approval step is not more powerful. It is just less governed.
And the loop is what lets an agent recover. When a step fails, the failure comes back into the loop as one more observation, and the model gets to try again: a different command, another route. That self-correcting behaviour is what looks like intelligence from the outside. It is really the loop feeding errors back in.
The tools: how it reaches out of the box
On its own the model can only produce text. Tools are what let it act, and they are the part to look at hardest, because every tool is a door out of the sandbox (the walled-off space the agent runs in, where nothing it does touches anything real) into a live system.
Mechanically, a tool is mundane. You hand the model a list of things it may do, each with a name, a plain description of when to use it, and the shape of the inputs it needs. The model never runs anything itself. It asks, in effect, “please run send_invoice with these values,” and the harness runs it and hands the result back. The Amp write-up puts the handshake plainly: “When the model wants to execute the tool, it tells you, you execute the tool and send the response up.” A read-a-file tool, a send-the-invoice tool: each is a small piece of code the harness owns, and the model can only ask.
The handshake. Which door the model reaches for is settled by the plain-English description someone wrote beside it — so ask to read those descriptions.
Two things follow from that, and both are yours to decide.
The wiring is becoming standardised. Rather than hand-build every connection between an agent and a system, teams increasingly use the Model Context Protocol (MCP), a common socket that lets one agent reach many tools and data sources through a single standard interface. If you want the mechanics of that, the MCP explainer is its own field guide. For now the point is narrow: “tools” is where your agent touches your world, and MCP is the common way that connection now gets made.
And a common way tool use goes wrong is having too many tools, poorly described. Every tool description, and every result a tool hands back, sits in the pool of text the model reads on each pass, and once the list grows that is where the room goes. Anthropic’s engineering team names the problem in as many words, tool definitions overload the context window, and describes agents wired to thousands of tools working through all of them before they ever reach the request itself. That is a vendor writing about a problem in its own protocol: a practitioner’s account, not an independent measurement. The direction is what matters: the instructions you carefully wrote can shrink to a rounding error beside the tools.
Crowding is only half the cost. Give an agent forty overlapping tools and it hesitates, or burns steps deciding which door to open. Well-built harnesses expose few, sharply-scoped tools; the failure signature of an amateur one is a long, vague tool list. When you review an agent, ask how many tools it can reach, and who decided that each one earned its place.
That covers what an agent can touch. What it can see is a separate question, and a stranger one.
What it can see: the working memory
This is the part that surprises people most. The model remembers nothing. Each time the harness calls it, the model sees only the text handed to it in that one call, and it forgets everything the moment it answers. As the Amp write-up puts it, the model provider’s server “is stateless. It only sees what’s in the conversation… It’s up to us to maintain that.” The impression of an agent that “remembers” your task across a dozen steps is produced by the harness re-sending the whole story every single time.
The context window. It is assembled again every turn, so a rule about what may never enter it has to hold every turn, not once at setup.
That re-sent bundle (the goal, the steps so far, the tool results, the relevant documents) is called the context window, and it is the agent’s entire working memory. Everything the agent knows at any moment is inside it. Anything not inside it, the agent does not know. That makes the context window the single biggest determinant of whether an agent is useful or dangerous: not the model, not the tools. An agent handed clean, relevant, correctly-scoped context behaves like an expert who has read the file. The same agent handed too much, or the wrong data, or a stale fact that quietly contradicts a fresh one, behaves like someone confidently working from the wrong brief, and it will not warn you, because from inside the window everything looks consistent.
There is real craft to filling that window well: what to include and what to keep out of it. That craft is what separates a reliable agent from a flaky one, and it is a subject of its own; I have written separately about mastering the agentic techniques it takes. The anatomical point is narrower. Your agent’s judgement is only ever as good as what is in its window this turn, and a stale or contaminated window is invisible from the outside. The window is also the exact place your data rules have to bite. When a document class must never reach the model, or a customer field cannot leave the building, that is where the boundary is either honoured or breached.
And because the model forgets everything the moment each turn ends, the only lasting evidence of what the agent knew is whatever the harness wrote down.
The flight recorder: traces and recovery
The last part is the one most demos never show you, and the one that separates a system you can run a business on from one you merely hope works. An agent is non-deterministic: give it the same task twice and it may take two different routes, because the model chooses each step afresh. A fixed program you can read line by line. An agent you can only watch. So the harness has to record what it watched: every step the model took, every tool it called, every result it got back, every point where it changed its mind. That record is called a trace, and a whole layer of tooling now exists to capture it. There is even work under way at OpenTelemetry, the open standard behind much of modern monitoring, to agree a common format for agent traces. That work is explicitly unfinished; the document’s own status line still reads “Development”. Worth knowing before a supplier tells you their traces are standard.
One run, written down. A failure you can read, rather than a failure you can only be told about.
Without a trace, an agent is a black box. It did something to your systems, it produced an outcome, and if the outcome was wrong you have no way to see where it went off the rails. With a trace, the same failure becomes a readable story: it called this tool, got this error, tried that instead, and here is the step that was actually wrong. That is the difference between an agent you can govern and one you can only trust and hope.
Traces also feed recovery, which is where the loop and the record meet. A well-built harness fails legibly: it retries deliberately, and it stops to call a person at the boundary you set. A poorly-built one fails silently and carries on. So when a team walks you through an agent, ask them to open the trace of a run that went wrong. A readable trace gets walked, and it sounds like a sequence: this call, this error, this second attempt, this step that was wrong. Its absence sounds like a description of how the system is meant to behave.
The parts list, and what to do with it
Put the five parts back together and the whole thing is legible. A model that predicts text. A loop that lets it keep going and choose its own next step. Tools that let it act on your systems. A context window that is its entire working memory, re-sent every turn. And a trace that records what it did. That is what an agent is made of, and you can now see all of it.
Governing one asks far less of you than building one. It asks you to put a question to each part of the harness, and to notice whether the answer is a real design decision or a hand-wave:
- The loop: how far can it go on its own before it must stop and ask a person, and which actions need approval before they run?
- The tools: how many can it reach, who decided each one belongs, and which of them can change or send something rather than only read?
- The context: what data is allowed into its window and what is kept out, especially anything that must never reach the model at all?
- The trace: can someone replay exactly what it did last Tuesday, and can they open the record of a run that failed and read it back to you?
None of these needs a data-science background. They are governance questions, and anyone who built the thing can answer them in plain language. A stalled agent project usually has the same history: someone deployed the model and nobody owned the harness. Treat the harness as the real product, because it is.
The engine improves on its own: every few months the models get better and you get that for free. The harness does not. Working out what yours should be, for your own systems and your own risk, is where my Fractional CAIO work usually starts. The harness is either designed, or inherited by accident, and that is the choice you are accountable for.
