The contract is signed, the schedules are agreed, and somebody from the vendor has asked for a technical contact and an implementation kick-off. Your operations lead forwarded the thread with a single line on top: happy to be the point of contact on this. That was four days ago and you have not replied, because the honest answer is that you do not know what you would be appointing her to.
You know roughly what the thing does. You sat through the demonstrations, you asked about the record and the sending rules, and you got answers you could write down. What nobody in that process described is the job that starts the week it arrives: what it consists of, how many hours it takes, and which of your people is qualified to do it. Your board will ask. Whoever asks first will get a name, and the name will be whoever said yes in an email.
A name is not an answer
The question “who looks after it” sounds like a staffing question and behaves like a governance one. Answered with a name, it hides that three separate jobs have just been handed to one person, and the three want different qualifications, different seniority, and different accountability.
The first is authority. Somebody has to decide what each specialist may do without asking a person. In the Cabinet, ArkOne’s reference design for an executive agent, that decision lives in the Mandate, the standing charter each of the ten specialists works under. It carries one word: act on its own, propose and wait, or escalate to a person. Every specialist ships at propose and wait, and a person writes act, and the change lands on the Record, the ledger of every action with its reason beside it, where nothing is ever edited and a correction is a new entry. Those values sit on the Register, the standing page of every setting in the design, and the nineteenth paper walks the setting itself. Granting an agent the right to act is the same kind of decision as granting a new hire a spending limit, and you would not let an engineer make that one either.
The second is editorial. The instructions a specialist works from are prose your company can edit, and they go stale the way a briefing note goes stale: a price changes, a product is retired, a policy tightens, and the written instruction still describes last quarter. Keeping it current is the work of whoever owns the function, because the person who can tell that the Finance instruction has drifted is the person who runs finance.
The third is measurement. Somebody has to know whether a change made the thing better or worse, which nobody can answer by reading the change. That is what the Rehearsal is for: the standing examination the reference design puts every change through before it reaches a company, a bank of written scenarios scored on five dimensions by a judge model that is not the model being examined. Its limits belong in the same sentence as its use. A judge model is a model, so its scores are opinions made consistent rather than facts. And the scenarios are the ones somebody thought to write, so a situation nobody imagined has not been examined at all.
The accident is that all three arrive together in one inbox. The person who can edit an instruction tonight is usually the person technical enough to have set up the connection, and once they are editing instructions they are also the only person who can say whether the edit helped, and by the second month they are quietly deciding which specialists may act on their own. Nobody granted them that. It was the shape of the work.
Three jobs inside one role
Suppose a company of roughly three hundred people, invented for this exercise, which runs a professional services business with a renewals book and a procurement function. It has signed for an executive agent and it has nobody named. Here is the role broken into its three parts, with the person in a company that size who is actually qualified for each.
| The job | What it decides | Who holds it | What it is not |
|---|---|---|---|
| Authority | Which specialists may act alone, which must propose, who approves what | The chief executive, for the approval scopes; the functional director for their own area | A configuration task, and not the vendor’s to advise on |
| Editorial | Whether each specialist’s written instructions still describe the business | The director who owns that function, reading their own specialist’s text | Content work, and not a quarterly review anybody enjoys |
| Measurement | Whether a change helped, held, or quietly cost something | One named person who can read a score and refuse a change | The person who wrote the change |
Exhibit 2. Illustrative. Three jobs inside one role, who holds each, and what one person holding all three costs you.
The right-hand column is where the argument lives. Each of the three looks like administration and none of them is. Authority is a signing decision wearing a settings screen: approval rights in the reference design are named per person, with spend bands, hiring, vendor onboarding and legal signature kept apart, and exactly one scope approves anything at all, which belongs to the chief executive and cannot be delegated into a field. That is a governance fact rather than a technical one, and the twentieth paper sets out the roster it sits in.
Editorial is the job most often mistaken for the technical one, because the editing happens in the same screen. The skill it needs is knowing that the business has moved, and no engineer has that skill about your renewals. The seventh paper makes the case that you should be able to change a specialist’s instructions tonight without anybody releasing anything, which is a strength and also the reason this job cannot sit where it is convenient.
Measurement is the one that must not sit with the author of the change. The examination has a pass mark, an average of three and a half out of five before anything ships, and a second rule that carries more weight: any single dimension slipping by more than a tenth of a point fails the change, whatever the average says. Somebody has to be willing to apply that rule to a change they would prefer to ship, and the author of a change is the worst person to ask. The whole marking scheme is in the twenty-sixth paper.
Where one person holds all three, the failure is not incompetence. It is that a change they wrote, scored by a process they run, is deployed under an authority they granted, and there is nobody in the sequence whose job is to say no. Your Record will show every step of it, correctly, with a name and a date against each. It will show a policy your company never debated.
Ninety days in an invented company
Suppose the same invented company goes live in the first week of a quarter. Nothing below is a schedule anybody has run; it is the order the three jobs have to be settled in, set against a calendar so the sequence is visible.
| By when | What is settled | Who settles it |
|---|---|---|
| The first fortnight | Every specialist stays at propose and wait; approval scopes written against named people, with a named deputy for leave | The chief executive, in one meeting |
| The end of the first month | A handful of goals chosen and a reporting cadence set, so the room starts writing states rather than answering questions | Each functional director, for their own area |
| The second month | The first instruction edits land, each read against the examination before it ships; the first change is refused | The functional director writes, the measurement holder scores |
| The ninetieth day | One specialist moves from propose to act, deliberately, with the reason on the Record | The chief executive, on the evidence of the first two months |
Exhibit 3.
The shape of that table is the argument. Authority comes first and costs one meeting. Goals come second, because a goal carrying one of three written states, on track, at risk or off track, reported on a cadence without being asked, is the thing that tells you in month two whether any of this is working. The twenty-fifth paper walks a goal through those states.
The third row is the one companies skip, and it is the load-bearing one. A change refused in the second month is worth more than four changes shipped, because it is the only evidence that the measurement job is being done by somebody rather than performed. A process that has never failed anything has never been run.
The fourth row is deliberately late and deliberately small. One specialist, one move, one reason written down. The reference design ships everything at propose and wait so that granting the right to act is an event with a date on it rather than a condition you find yourself in. Nothing forces the move at ninety days, and a company that arrives there with every specialist still proposing has lost nothing except the reviewing a person was doing anyway.
What the quarter does not produce is a verdict on the technology. It tells you whether the output is worth reviewing, whether somebody is keeping the instructions current, and whether your goals moved. It tells you nothing about the first time the thing acts unsupervised on something that matters, because that has not happened yet.
What to write down before it arrives
Four things, each written before the implementation call rather than during it, and each phrased so you can say it in the room.
Every specialist starts at propose and wait, and I will name the person who may change that. Say it to the vendor and say it to your own team. It costs nothing in week one because a system nobody trusts yet is being reviewed anyway, and it converts the authority question from a default into a decision with your name against it.
Approvals are named against people, and each name has a deputy for leave. This is the one that gets skipped and the one that breaks first. An approval scope with a single name attached stops working the week that person takes a holiday, and what happens next is that somebody urgent gets given the credentials. Write the deputy down at the same time as the principal.
Each director owns the instructions for their own specialist, and I want to know when they last read them. Put a date on it rather than a process. The useful question at your next management meeting is not whether the instructions are being maintained, it is when each director last opened the text their specialist works from.
No change ships without a score, and I want to see the first one that failed. Ask for the refusal rather than the process. The examination is a bank of scenarios somebody wrote, so it can only catch what it was taught to look for, and a refused change is the only proof that anybody is reading the result.
One thing not to write down. Do not name a single owner for all of it in order to have an answer for the board. The tidy answer costs you the separation between the person who grants authority, the person who changes the thing, and the person who says whether the change was good, and that separation is the whole of what “looking after it” means. Three named people doing a few hours a month each is a smaller commitment than one person doing it properly, and it is the only version that survives that person leaving.
An hour, a room, three chairs
Before the implementation call, get the three people into one room for an hour with the vendor’s own screens open in front of them, and have each of them do their job once, out loud, while the other two watch.
The functional director edits one instruction, a real one, something they know is out of date. The measurement holder runs the examination against that edit and reads the five scores aloud. Then you decide, in front of both of them, whether that change ships. An hour, one edit, one score, one decision, with all three jobs performed by the three different people who will hold them.
Watch for the moment somebody says they would need to ask the other two. That is the sound of the separation working. If instead the hour collapses into one person doing all three while the others read email, you have learned the real answer to who looks after it, and you have learned it before go-live rather than in month five.
What that hour buys you is not a rehearsal of a process. It is the only arrangement of this that survives whichever of the three people leaves first, because each of the other two already knows what the missing job was and can say who should now hold it. A single owner takes the whole answer with them. The quiet way these arrangements come apart instead is set out in why the pilot failed.
component: null
Asked plainly
Who should own an AI agent inside a company?
Nobody owns all of it, because the role is three jobs with three different qualifications. Deciding what the agent may do without asking a person is an authority question, and it belongs to whoever already signs for that class of risk. Keeping its written instructions current belongs to whoever owns the function it works in, because a sales instruction going stale is a sales problem. Proving a change helped is a measurement job, and it needs somebody who can read a score and refuse a change. Handing all three to one engineer makes that engineer your policy setter.
Do I need to hire someone to run an AI agent?
Usually not a new full-time post in the first quarter, and usually yes to naming the three parts of the job against people you already employ. The work is small and irregular at first: a handful of authority decisions, an instruction edited when the business changes, and a scored examination read before each change ships. What makes it a hire later is volume rather than novelty. What makes it a disaster early is nobody being named, so the first urgent decision is made by whoever happens to be nearest.
What should a CEO decide before an AI agent goes live?
Four things, all of them yours rather than your vendor's. Which actions the agent may take on its own and which must wait for a person. Which named person holds approval for each class of decision, and what happens when that person is on leave. Which handful of goals it reports against, and on what cadence. And who may edit the instructions each specialist works from, with the requirement that every edit carries a name and a date. Write them down before go-live, because each one gets decided by default otherwise.