For the last couple of years, the only question we really asked about these systems was whether the answer was any good. You typed something in, it came back with text, and you decided what to do with it. The accountability question barely came up, because a human was still the one who acted. The model advised. A person pressed the button, and that person owned what happened next.

That arrangement is quietly ending. The systems are moving from answering questions to taking actions on the business's behalf. The agent does not tell you the order is ready to be placed. It places it. It does not suggest the service might need a restart. It restarts it. The interesting question is no longer how good the answer is. It is the one who owns the action.

I started thinking about this again, watching the agentic-future framing land at Meta's Conversations event, where the pitch was agents that do not just reply to a customer but carry out the transaction for them. The platform numbers in a keynote like that are a marketing slide, not evidence, and consumer messaging is not my field. But the shape underneath it is one I keep running into in operations, and the shape is what matters.

It is easy to read "agents that act" as a convenience story. The work that used to take three clicks now takes none. That framing misses where the change actually lands.

When a system only advises, the risk sits with the human who chooses to act on the advice. The decision, and the ownership of the decision, never leaves the room. When the system acts, the decision leaves the room. Something now happens in the world (an order placed, a refund issued, a production service bounced) without a person in the loop at the moment it happens. The convenience is real. So is the transfer. You have moved the action out of human hands, and unless you were deliberate about it, you have moved the ownership of the outcome to nobody in particular.

That is the part most rollouts skip. We get excited about what the agent can now do, and we forget to say who is responsible when it does the wrong thing at the wrong time.

Here is the question. The moment an agent takes an action, someone owns the outcome. Who is it.

Most organisations cannot answer cleanly. They can tell you who built the agent, who pays for it, and who was in the demo. Ask who owns the decision the agent makes at two in the morning, and you get the answer that should worry you most: the team. "The team" owns it. Which is to say no single named person does, because an outcome owned by everyone is owned by no one, and that becomes obvious at exactly the worst time.

This is not a new failure. It is the oldest failure in operations wearing new clothes. We have always had automations that act: the script that scales the cluster, the rule that reroutes traffic, the job that clears the queue. The good ones had an owner, a person who understood what the automation did, who got the call when it misfired, and who could be asked, afterwards, why it did what it did. The bad ones were inherited, undocumented, and owned by whoever happened to be holding the rota when they went wrong. Agents make this question louder because they act across more of the business and with more apparent independence. They do not change the question.

Picture two rooms. In one, an agent is booking a customer's order over a messaging app. In the other, an agent is restarting a production service in the middle of a degraded night.

These feel like completely different problems. One is commerce; one is ops. One has a customer on the other end; one has an on-call rota. But the accountability question is word-for-word identical. When the booking is wrong, when the restart takes down the thing it was meant to protect, who owns that outcome? And in both rooms, the failure mode is identical too: if the honest answer is "the team", you have an accountability gap, and the gap does not announce itself until the action has already gone wrong.

The reason this matters is that the commerce version and the ops version are converging. The same pattern (an agent empowered to act on the business's behalf) is arriving in the customer channel and in the control plane at the same time. If you only ever reasoned about it as a customer-experience feature, you will import the same unowned-automation problem straight into production, where the blast radius is your own estate.

So what does owning it actually look like. The model I trust is approval by blast radius, and it is not complicated.

You sort the actions an agent can take by what happens if they are wrong. Low blast radius (the action is cheap to reverse and contained if it misfires) and the gate can be open: let the agent act, log it, review the pattern later. High blast radius (the action is expensive, customer-facing, or hard to undo) and the gate stays human: the agent prepares the action, a named person approves it, and the act and the approval are both recorded. The dial is not "automated or not". It is "how much can this break, and has someone agreed to own it at that level".

The rule that holds the whole thing together is this. You can automate the action. You must never automate the accountability. Every autonomous action an agent is allowed to take needs a named human owner attached to it before it is switched on. Not a team. A person, who understands what the agent does in their area, who gets the call when it goes wrong, and who can answer for it afterwards. The agent does the work. The named owner keeps the responsibility, because responsibility is the one thing you are not allowed to hand to a process.

This is also what makes the system improvable. When an action has an owner, a bad outcome has a person who notices, investigates, and tightens the gate. When it does not, the same bad outcome just happens again, a little more expensively each time, until it is big enough to become everyone's problem and therefore still no one's.

None of this is an argument against agents that act. The capability is genuine and a lot of it is worth having. Buy the agent if it earns its place.

But buy the other thing first. Before you let a system act on the business's behalf, decide who owns each thing it is allowed to do, and write the name down. The technology question (can it do this) is mostly solved and getting cheaper by the month. The question that decides whether this goes well for you is the one nobody is selling: when the agent is wrong, and at some point it will be, who answers for it. Assign that owner before the agent ever takes its first action, or you will be assigning it mid-incident, which is the most expensive moment to discover you never did.