What an agent needs that a model does not.
A model answers a question. An agent takes an action, and taking an action requires permission that nobody has thought to grant.
The refused cases are the ones that decide it.
An agent that cannot say no is dangerous. One that says no into nowhere gets switched off.
The difference between a model and an agent is that an agent acts. Acting requires four things a model never needs: a stated boundary on what it may do alone, a destination for what it cannot, a record of what it did, and a named person answerable for the result. Capability is rarely the constraint.
Everyone building agents this year has solved the same problem twice. The first solve is technical and it works. The second is organisational and it usually does not get attempted until the first has been running for a month with nothing to show.
A model is asked a question and returns an answer. Whatever happens next is somebody else’s decision. That is a comfortable arrangement, and it is why models went into production so quickly.
An agent does the next thing. It sends the email, updates the record, approves the case, books the slot. The moment it does that, a set of questions arrives that nobody had to answer before.
A model can be wrong and nothing happens. An agent can be wrong and something has already happened.
The four things
Across the agent deployments we have worked on or reviewed, four things separate the ones running a year later from the ones quietly switched off. None is about the model.
A stated boundary
What can this agent do without asking anyone?
The answer has to be specific enough to be checked. Not “handle routine cases” — a value limit, a category, a confidence threshold, a list. Something a person could read and say yes or no to.
Where this is absent, one of two things happens. Either the agent is given broad permissions because narrowing them requires a decision nobody wants to make, or it is given almost none and every action queues for approval, which makes it a slower version of the manual process.
Both outcomes are common and neither is a technical failure.
A destination for what it cannot do
Every agent will encounter a case it should not handle. The question is where that case goes.
“Escalate” is not a destination. A destination is a named person or a named queue, with a stated time by which somebody looks at it, and a rule for what happens if nobody does.
The agents that survive have this written down before they run. The ones that do not accumulate a queue of exceptions that nobody owns, and that queue becomes the reason the agent is switched off — not because it made mistakes, but because the cases it correctly refused had nowhere to go.
A record of what it did
Somebody will ask what the agent did on a particular date and why. Not immediately. Around month nine.
The record has to be written at the time of the action, carrying the inputs the agent saw, the version that ran, what it decided, and what followed. Reconstructing this later from application logs is possible, expensive, and unconvincing to the person asking — which is covered in more depth in the evidence question.
A named person answerable for the result
Not a sponsor. Not a team. The person who, if the agent does something wrong on a Tuesday, is the one who answers for it.
This is the item most often missing and the hardest to add later, because by then the agent is running and naming somebody looks like assigning blame retrospectively.
Why the technical work does not surface these
The build is a coherent, well-understood engineering problem. Prompt design, tool definitions, retries, evaluation. There is a clear right answer to most of it and a body of practice forming quickly.
None of that work requires you to decide who is answerable. It is entirely possible to build a correct agent while never having the conversation, and the sequencing of most projects means the conversation happens at handover, when the answer determines whether the thing goes live.
Observation from agent work across regulated operations, not a counted study. The pattern is consistent enough to write down; the sample is engagements rather than a survey, and it skews toward organisations that asked for outside help.
What to do before the build
Four questions, answerable in a room, in under an hour.
- What can it do alone? Write the limit. If nobody will write one, that is the finding.
- Where does a refused case go? A named queue with a stated response time.
- What gets written when it acts? The five fields, specified before anything is built.
- Who answers for it? A person, who knows they have been named.
The organisations that do this before building end up with a different agent — narrower, with a clearer refusal path, and considerably more likely to still be running in a year.
The readiness instrument asks eleven statements about one deployment and names where it will stop. What follows from that answer is the work itself.
Limits
Not a measured study
This is engagement observation. The four items are consistent across the deployments we have seen and we have not counted them systematically.
It describes agents that act
Agents that draft suggestions for a person to review have a lower bar and different failure modes.
Model choice is not the variable
Nothing here is about model selection, and we did not find model choice separating outcomes in the cases we reviewed.
Questions
Is this not just permissions management?
Permissions are the mechanism; the boundary is the decision. Most systems can enforce whatever limit you set. Almost nobody has set one, and the enforcement layer will happily enforce "everything."
What if the agent only makes recommendations?
Then it is closer to a model and the bar is lower. The questions still apply the moment somebody starts acting on the recommendations without checking, which happens sooner than teams expect.
How narrow should the initial boundary be?
Narrow enough that the first month is boring. Widening a boundary after it has run cleanly is a small conversation; narrowing one after an incident is a large one.
Who should be the named person?
Whoever would be asked to explain it. That is usually the person accountable for the process the agent sits inside, not the person who commissioned the project.
What if nobody will be named?
That is the most useful possible outcome of asking. It means the accountability has not been resolved, and building first does not resolve it — it just moves the conversation to a worse moment.
Does this apply to multi-agent systems?
More so. Each agent needs its own boundary and destination, and the system needs one more thing: a record of which agent did what, because "the system decided" is not an answer anybody accepts.
Govil, A. (2026). What an agent needs that a model does not. The Field Report, XONIK.