Accountability in Autonomous Systems: Who Owns the Agent’s Decision
The agent makes a wrong decision, and the organisation discovers it has no clear answer to a simple question: who is responsible? The engineer who built it points to the model. The business owner points to the engineer. The compliance function points to whoever approved the deployment. Everyone can explain why it is not their fault, and no one owns the decision, which means the organisation has deployed a system that takes consequential actions with the accountability left undefined. Accountability in autonomous systems is the question that determines whether an agent can operate in a regulated setting at all, and most deployments answer it only after something goes wrong.
If you are accountable for an autonomous system, this is the gap that turns a technical failure into an organizational crisis. A deterministic system that errs has a clear chain: someone specified it, someone built it, someone approved it, and the error traces to a decision a person made. An autonomous system blurs that chain, because the agent made a choice no human directly made, and the instinct to treat the agent as the decision-maker is exactly the instinct a regulator, a court, or an auditor will reject. Accountability cannot rest with the agent, and defining where it does rest is the work most programs skip.
Why the agent cannot be the accountable party

The tempting framing is that the agent decided, so the agent is responsible, and that framing collapses under any real scrutiny. An agent is not a legal or moral actor. It cannot be held accountable in any sense that matters, cannot answer to a regulator, cannot bear consequences, cannot be the entity a harmed party seeks redress from. Treating the agent as the accountable party is a category error that functions, in practice, as a way for every human in the chain to avoid ownership, and an organisation that lets accountability rest with the software has effectively deployed a consequential decision-maker that answers to no one.
The reason this matters operationally is that regulated environments require an accountable human or organisation behind every consequential decision, and the presence of an agent does not remove that requirement. It relocates it. Someone remains accountable for what the agent does, whether that is defined deliberately in advance or discovered painfully after an incident. The choice is not whether a human is accountable. It is whether the organisation decides who, before deployment, or lets the question resolve itself in the worst possible circumstances. This is why we treat accountability as a governance property engineered into the system rather than a matter to settle later.
Defining accountability before deployment
Assigning accountability means deciding, in advance, who owns the agent’s decisions and under what conditions, which is an organizational design problem as much as a technical one. The accountable party is a human or a function that answers for what the agent does within a defined scope: this agent, operating within these bounds, on these kinds of decisions, is owned by this role. That ownership has to be explicit, because implicit accountability is the diffusion that leaves everyone pointing elsewhere when something fails.
The accountability also has to be paired with the means to exercise it, which is where many assignments fail. Holding someone accountable for an agent’s decisions while giving them no visibility into what the agent does, no ability to set its bounds, and no power to intervene is assigning blame without control, which is both unfair and ineffective. Real accountability requires that the accountable party can see what the agent is doing, through the trajectory tracing that makes decisions reconstructable, can set and adjust the bounds within which it operates, and can intervene when needed. Accountability without control is a scapegoat arrangement. Accountability with control is a functioning oversight structure, and building the latter is the actual work.
The trade-off, and the tiers of accountability
Defining accountability rigorously has a cost, and it is not primarily technical. It forces the organisation to make ownership explicit, which surfaces uncomfortable questions about who is willing to own an autonomous system’s decisions, and those questions slow deployment because they should. An organisation that rushes an agent into production without settling accountability has not avoided the cost. It has deferred it to the moment of an incident, when it is paid at far higher interest and in public.
The nuance worth naming is that accountability is tiered by consequence, mirroring how oversight is placed by consequence. Low-consequence, reversible decisions the agent makes autonomously can carry lighter accountability, because the cost of an error is a correction and the ownership can sit at the level of the system as a whole. High-consequence, irreversible decisions require a specific accountable human, often in the loop at the moment of the decision, because the cost of an error demands a person who owned that specific choice. Designing the accountability structure means mapping decisions to the level of ownership their consequences warrant, rather than applying a single blanket answer that is either too heavy for routine decisions or too light for grave ones. The structure has to match the risk, and building that map is the deliberate work that makes the system defensible.

Where it almost broke
We worked with an organisation operating an autonomous system that made a consequential wrong decision, and the response revealed the deeper problem. There was no defined owner of that decision. The technical team, the business owner, and the compliance function each had a reasonable case that accountability lay elsewhere, and while they debated it, the organisation had no coherent answer for the regulator asking who was responsible. The incident was recoverable. The absence of any accountability structure was the real exposure, because it meant every future decision the agent made carried the same undefined ownership.
The correction was organizational before it was technical. We defined, explicitly, which role owned the agent’s decisions within which scope, and tiered that ownership by consequence, so routine decisions sat with the system while high-consequence ones had a named accountable human in the loop. We paired the accountability with control, ensuring the accountable parties had visibility through tracing, authority over the agent’s bounds, and the ability to intervene. The organisation moved from an autonomous system nobody owned to one where every decision had a defined, empowered owner matched to its consequence. The lesson was that the accountability question does not wait for you to answer it, and answering it after an incident is answering it too late.
Decide who owns it before it decides for you
The reframe that makes autonomous systems deployable is accepting that accountability in autonomous systems is an organizational decision to be made before deployment, not a question to resolve after an incident. The agent takes actions, and someone answers for them, and the only choice the organisation controls is whether that someone is defined deliberately in advance or discovered chaotically in the aftermath of a failure.
The organisations that operate autonomous systems responsibly are the ones that settled the accountability question first, assigned explicit ownership matched to consequence, and gave the accountable parties the visibility and control that make ownership real rather than nominal. An autonomous system that nobody owns is not an efficiency. It is an unbounded liability wearing the appearance of one. Deciding who owns the agent’s decisions, before the agent makes one that matters, is what turns autonomy from an exposure into something an enterprise can actually stand behind.
Related: Agentic AI
Tell us the number you need to move.
…outcomes that survive scrutiny.