An agent in production should be governed the way a new hire is: a written scope of authority, actions it may take alone and actions that need a signature, a manager who answers for it, and a way to take it off the floor.
When an organization hires a person into a role that moves money, touches customers, or signs things, nobody debates whether the role needs a description. The person gets a scope, a set of approvals they can give alone, a set they cannot, and a manager who answers for their work. Then the same organization deploys an agent into the same workflow and calls it autonomous, as if autonomy were a feature the vendor shipped rather than a permission the organization granted without writing it down. An agent is a role. It needs a job description. Most of the agents I meet in production were never given one.
The word is doing damage. “Autonomous” sounds like a capability, something the vendor shipped. It is not. Whether an agent can issue a refund is not a property of the model. It is a property of the credentials somebody handed it, the systems somebody wired it into, and the absence of anyone who said no. Every autonomous agent in production is autonomous because somebody granted it authority. The only question is whether the grant was written down or merely happened.
The cloud era taught this once already. Services were handed broad credentials because scoping them was tedious, and the fix was never a smarter service. It was least privilege, written down and enforced by the platform. Agents are service accounts with judgment, and the judgment makes the scope more important, not less.
In my work leading enterprise AI delivery, the first thing I ask about an agent is not what model it runs but what it is allowed to do, and who said so. Too often the answer is a shrug and a list of API keys.
A job description for an agent is short, and every line is a decision the business makes rather than a default the engineer inherited. Four sections cover it.
Data it may read, by class. Not a list of tables but a list of data classes: customer contact records yes, payment instruments no, employee files never. Deciding per class means the answer exists before the next tool is wired in.
Actions it may take alone. Draft a reply, tag a ticket, look up an order. These should be most of what the agent does, or the review burden on the rest usually eats whatever the agent returns.
Actions it may propose. The agent prepares the work completely, reasoning attached, and hands it to a person for a signature. A refund above a threshold. A change to a record other systems key on. The agent does the work. A human carries the authority.
Actions it may never take. Written as a list, not implied by omission. Delete records. Move money outside a defined account set. Change its own permissions. The never list is the one engineers most often forget to ask for and the one the business most needs to have written itself.
The hard part is deciding which actions go in which column, and the useful test is reversibility: whether the action can be undone cleanly, inside the time it takes to notice it was wrong. If it can, the agent runs it and the log catches mistakes. If it cannot, the agent proposes it and waits.
Reversible actions are the paved road. Drafts, tags, staged changes that a later step commits: all of these can be wrong at volume and corrected at volume. Irreversible actions are different in kind. A payment that has settled, an email that has been read, a message to a regulator. Being wrong once is an incident. Being wrong at volume is a crisis no rollback script fixes.
Who writes the irreversible list? Not the engineer. The engineer knows which calls are idempotent. The business knows which outcomes it cannot walk back, and those are not the same list: a database write can be trivially reversible and still irreversible in the only sense that matters, because a customer was already told something. The line between run and wait is an accountability decision, and it belongs to the people who will be held accountable.
Every role has a manager, and the agent’s manager is the most important line in its job description. A named person, not a committee, with three powers: to change what the agent does, to roll back what it did, and to take it off the floor. If any of those requires a ticket to another group, the agent does not have a manager. It has an audience.
For agents the requirement sharpens, because agents act. A retrieval system that drifts produces worse answers. An agent that drifts produces actions, and they accumulate in other people’s systems while nobody is watching. The manager is the person whose Monday is ruined when that happens, which is why the role exists before the first action, not after the retrospective.
Nobody hands a new hire the full authority of the role on the first morning. The mechanisms used for people translate directly.
Evals are the interview. Before an agent sees production, it answers a fixed set of questions that represent the real work, scored against a ground-truth oracle. The interview does not prove the hire will succeed. It filters out the ones who clearly will not, and it sets the baseline for every later review.
Shadow mode is the first week. The agent runs on live traffic and produces every decision it would have made, and none of them execute. This is the most honest way I know to learn the agent’s disagreement rate with your own staff on your own data, and most teams I meet skip it because it spends tokens and returns nothing visible. That is the point. Shadow mode is the cheapest place to be wrong.
Graduated authority is the review cycle. Actions move from the propose column to the alone column one at a time, each earned by a metric agreed in advance: agreement with human disposition above a threshold, sustained over a defined volume, with a reversal rate below a ceiling. I do not have a universal number. I do insist the number is written before the agent starts, so promotion is a measurement rather than an argument. Authority also moves backwards. A failed eval or a model version change returns an action to the propose column automatically, the way a failed release gate returns code to the branch.
A person who makes a mistake makes it at human speed. An agent makes it at the rate it runs. As pure illustration, an agent wrong on one action in a hundred, running a thousand actions an hour, is wrong ten times an hour until someone notices. The real numbers will differ, but the shape holds: agent errors are rates, not events, and escalation has to be designed for rates.
So the runbook is written before launch. Which signal pages whom. Which lever each person may pull: pause the agent, revoke a single action class, roll back to the last known-good prompt and model version, or stop the whole thing. During the incident nobody is writing anything.
The agent’s timesheet is its decision log, and a timesheet nobody can read was never kept. Every action, taken or proposed, should answer three questions. What did it see: the context, retrieved documents, and tool results in front of it. What did it do: the action and the arguments it was called with. Who approved it: the human who signed, or the written rule that said this class may run alone. If the third answer is missing, the action was unauthorized, whatever the outcome. If the first is missing, the action cannot be defended to a regulator or to the customer it affected, and a silent failure stays silent.
I am confident about the structure and less sure about the calibration. I do not have a defensible prior for how long shadow mode should run before the comparison means anything. Graduated authority sounds tidy and in practice produces a permission matrix that itself needs a manager. And the reversibility test has a soft edge: some actions are technically reversible and socially not, and I have found no cleaner method than walking the business through the list by hand.
What I am sure of is the frame. In my experience, the organizations that run agents without incident are not the ones with the best models. They are the ones that treated the agent as a role: scoped it, supervised it, reviewed it, and kept the authority to remove it. The model does not decide what the agent may do. The job description does.
Related: Governance is the strategy, not the checkbox and Silent failures.
