The parts of an agent, and why each one matters to governance.
An agent is more than a model.
Through a chat window it looks like a model with a personality, which is a comfortable view and a misleading one. The governance view is a loop: information is assembled, the model chooses an action, the action reaches the world, and the result of that action becomes part of the next assembly.
Everything in that loop is something you can inspect, bound, or record. Taken one at a time, here is what the parts are and why each of them shows up later in a release conversation.
The reasoning engine, at a specific version, with specific decoding settings.
Providers update models on their own schedule, which means behavior can change while your repository does not. That makes the version number a governance fact rather than a footnote, and it is why the version belongs in the composition record.
The system prompt, the policy prompt, the role and scope.
Instructions shape behavior strongly and enforce nothing. They are the right place to express intent and the wrong place to put a limit that must hold. Prompts can guide behavior; where a restriction matters operationally, enforce it through permissions, tools, or an approval path outside the model.
Everything assembled into the model’s input on a given turn: the instructions, the user’s message, retrieved documents, tool results, memory, policies, and sometimes another agent’s output.
Context is where trusted and untrusted material meet, and it is the most common origin of agent failure. Chapter 7 is devoted to it.
What persists across turns and across sessions.
Memory is useful and quietly risky, because a wrong fact learned on Monday still shapes behavior on Thursday, where nobody is looking for it. The governance question is not whether memory exists but what may be written to it, by whom, for how long, and how it gets corrected.
Named functions with typed arguments and real side effects.
Tools are where language becomes action. A model can recommend changing a payment record. A tool can actually change it. That makes tool scope, parameters, permissions, and declared side effects governance concerns rather than implementation details.
Tool providers connected over the Model Context Protocol belong in the same category, with one addition: each one is also a supply-chain relationship.
The corpora the agent searches, and the rule that decides what may ground a claim.
Weak grounding does not announce itself. It produces a fluent answer with nothing behind it, which is considerably harder to notice than an error message.
The credentials the agent can assume.
This is the outer limit of what the agent can do at all, regardless of what any prompt says, which makes it the strongest control available. It is also the one most often inherited by accident, because agents tend to be deployed with credentials that already existed.
Planning, control flow, handoffs.
A sub-agent is another agent with its own authority. When one agent’s output becomes another’s input, an error stops being an error and becomes a premise, so inter-agent messages need provenance for the same reason retrieved documents do.
Systems of record, files, the public web, other agents, and people.
Everything the agent touches on the outside is where consequence lives, and it is the reason the loop matters more than any single part of it.
It helps to have a concrete example, so most of what follows refers to one.
Meridian Group is a fictional mid-size enterprise. Its Finance Operations team runs the Vendor Payment Exception Agent: when an invoice does not match a purchase order, the agent works out why, recommends an action, and prepares the change.
Its parts are unremarkable. A frontier model. A system prompt describing the exception policy. Four tools — read the vendor master, parse an attached document, look up a payment record, submit a payment change. A retrieval corpus of accounts-payable policy. Session memory. A service identity with write access to the payment queue.
That ordinary list eventually produced a blocked release, a critical finding traced to a single turn, and a remediation that touched three parts of the assembly and none of the model. The case is worked through in full in Chapter 16.
One property of the loop deserves emphasis before moving on. Whatever a tool returns becomes context on the next turn, as does a retrieved document, a sub-agent’s conclusion, and a summary of the conversation so far. The prompt template in your repository is not the thing that runs; what runs is the context assembled at inference time, which is why any claim about the agent’s instructions has to be a claim about the assembly.
You are governing the complete system around the model, not the model in isolation.
Draw the agent rather than describing it. A diagram of one turn makes the parts that carry risk visible in a way that an architecture document rarely does, and it takes about twenty minutes.