Prashant AkhawatBuilding AI-Native Enterprises
CXO Intelligence Series · Enterprise AI SeriesEdition 15 · October 2026

The Agent Is Not the System

Harness engineering makes AI agents reliable. Only the enterprise can make them accountable.

Prashant Akhawat · akhawat.com

Enterprise AI Series · CXO Intelligence Series · All writing

The six proofs drawn as nested rooms, with the agent's route passing through each doorway to an accepted outcome

Context

Enterprises are moving from AI that answers to AI that acts. Harness engineering, the discipline of building the system around a model, has made agents far more reliable. Reliability is not the same as accountability, and most agent architectures were never designed to answer the questions a board, a regulator or a risk committee will ask.

The argument

An agent's reasoning is only one of five properties that make it safe to deploy. Authority, bounded execution, independent verification and accountability are properties of the enterprise, not the model. The Six Proofs of Accountable Autonomy give leaders a test for all six, and a rule for how much autonomy to grant.

The takeaway

Intelligence can be delegated to a model. Accountability cannot. Grant autonomy at the level of your weakest proof, scale the burden of proof to the consequence of the action, and treat the inventory of irreversible actions as the most important governance artifact you own.

The next advantage in AI will not belong to the companies whose agents can do the most. It will belong to the companies that can prove what their agents did, stop what they should not do, and stand behind the outcomes.

The most dangerous agent in your enterprise will not be the one that fails. It will be the one that succeeds at the wrong thing.

Consider a scenario that is hypothetical but entirely plausible. A finance agent receives a supplier invoice. It matches the invoice to the purchase order and the goods receipt, confirms the amount is within its limit, schedules the payment and calls the banking API. The API returns success. Every log line is green. Four days earlier, the supplier's bank details had been changed after an email request that nobody verified by callback. The money has gone to the wrong account.

Nothing in that sequence was a model failure. The agent reasoned correctly about the task it was given. The tools worked. The workflow completed. And the business outcome was unacceptable.

That gap, between a task completed and an outcome that is correct, permitted and defensible, is where enterprise AI will be won or lost. It is also the gap most agent architectures are least equipped to close, because they were designed to answer a different question.

Five things that look like one

When an executive watches an agent demo, five distinct properties blur into a single impression of competence. They are not the same thing, and they fail independently.

Intelligence is whether the agent can interpret the goal and reason toward a plausible action. Authority is whether it is permitted to take that action, for this data, at this value, at this moment. Execution is whether the action runs inside controlled boundaries rather than with whatever access the agent happens to hold. Verification is whether something other than the agent confirmed that the result is correct by the rules of the business. Accountability is whether the enterprise can later establish what happened, why, under whose authority, and who owns the consequence.

Model progress improves the first property. It does almost nothing for the other four. A more capable model reasons better. It does not thereby acquire a mandate, a boundary, an independent auditor or an owner. Those are properties of the system the enterprise builds around the model, and of the institution that operates it.

A more capable model reasons better. It does not thereby acquire a mandate, a boundary, an independent auditor or an owner.

The missing layer, and what it does not cover

The engineering community has a name for the system around the model. Viv Trivedy, credited with coining the term, reduced it to an equation: an agent is a model plus a harness, and anything that is not the model is the harness (Osmani). Harness engineering is the discipline of designing that surround: the context the model receives, the tools it may call, the gates its proposals pass through, the checks its outputs face and the traces it leaves.

The idea earned attention for good reason. In February 2026, OpenAI described building an internal product of roughly a million lines with no manually written code, and concluded that its engineers' real work had become designing environments, specifying intent and building feedback loops (OpenAI). In March, Anthropic showed the same model producing a broken application on its own and a working one inside a planner, generator and evaluator harness (Anthropic).

What happens without that surround is no longer hypothetical. In July 2025, an AI coding agent on Replit's platform ran destructive commands against a live database during an explicit code freeze, erasing records on roughly 1,200 executives and 1,200 companies, and then told the user that a rollback was not possible. The user recovered the data himself, and Replit's chief executive acknowledged the failure publicly (eWeek). Read against the five properties above, three failed at once. The agent acted against its instructions. It held credentials that reached production. And its own account of what could be recovered was wrong.

Harness engineering answers a crucial question: will the agent behave as designed? Enterprises need answers to three more. Should this action happen at all? Was the outcome right by the rules of the business? Who answers for it if it was not? A harness can host the controls that answer those questions. It cannot supply their content. The approval threshold, the acceptance criteria, the definition of an irreversible action and the name of the accountable owner are business decisions, and engineers should not be left to invent them inside a configuration file.

A harness can host the controls that answer the board's questions. It cannot supply their content.
Exhibit 1. From intelligence to controlled execution. A business objective becomes an accepted outcome only after authorization, bounded execution and independent verification. A failed check triggers a correction within a retry limit, then escalation to a named owner.
Exhibit 1. From intelligence to controlled execution. A business objective becomes an accepted outcome only after authorization, bounded execution and independent verification. A failed check triggers a correction within a retry limit, then escalation to a named owner.

Why an agent cannot mark its own homework

The most tempting shortcut in agent design is to ask the agent to check its own work. It is cheap, it is fast, and it is structurally unsound.

Anthropic's engineers reported that agents asked to grade their own output tend to praise it, even when the quality is plainly mediocre, and that tuning a separate, skeptical evaluator proved far more tractable than making the generator self-critical. That finding should not surprise anyone who has run a finance or quality function. Separation of duties exists because the person who prepares a transaction is the person least able to see its flaw.

Verification performed by the author is not verification. Most of us learned that about humans long ago.

There is a deeper reason as well. When an agent verifies itself, the check inherits the same context, the same assumptions and the same blind spots that produced the error. The failure is correlated. OWASP's guidance on excessive agency makes the adjacent point that damaging actions can follow from unexpected, ambiguous or manipulated model output, whatever the cause of the malfunction (OWASP). A gate that relies on the model's own judgment can be argued past by the very output it is meant to stop.

Useful verification is independent in three ways: in its information, drawing on authoritative records rather than the agent's account; in its logic, applying business rules rather than restating the plan; and in its authority, able to block acceptance rather than merely annotate it.

The Six Proofs of Accountable Autonomy

I propose a simple test for any agent that acts on enterprise systems. Before it is granted autonomy, the enterprise should be able to produce six proofs. The framework is my own, offered for leaders to challenge and adapt, not an industry standard.

ProofThe question it answersFailure mode when it is missing
1. Proof of UnderstandingDid the agent interpret the objective, context and constraints correctly?Faithful error. Flawless execution of a misread goal
2. Proof of AuthorityWas this action permitted for this identity, data, value and time?Overreach. The agent does what it can, not what it may
3. Proof of ContainmentDid the action run with least privilege and within limits on scope, spend and rate?Blast radius. One bad decision propagates at machine speed
4. Proof of CorrectnessDid an independent check confirm the outcome against business rules?Silent wrongness. The task is done and the result is wrong
5. Proof of RecordCan we reconstruct what happened, why, under whose authority, and who owns it?Indefensible success. A right outcome nobody can evidence
6. Proof of ReversalCan the action be halted, reversed or remediated?Permanent error. A mistake the enterprise must simply absorb

Three properties make the framework more than a list.

The proofs are a chain, not a menu. Autonomy should be granted at the level of the weakest proof, not the strongest. An agent with brilliant reasoning and a weak record of authority deserves less freedom than a modest agent operating inside strong controls.

Reversibility decides where verification sits. When an action can be cheaply undone, it can be checked after the fact. When it cannot, such as a payment, a regulatory submission or a message to a customer, correctness must be proven before commit. This single relationship explains more about sound agent design than any other.

Records explain; they do not prevent. Observability is essential for Proof of Record and useless as a substitute for Proofs 2 to 4. A perfect trace of an unauthorized payment is still an unauthorized payment.

Grant autonomy at the level of your weakest proof, not your strongest.
Exhibit 2. The enterprise accountability architecture. The agent proposes from outside the control boundary. Identity, policy, conditional human approval, a least-privilege tool gateway and independent verification sit between proposal and systems of record. Every step writes evidence. Containment and recovery stand ready when a check fails.
Exhibit 2. The enterprise accountability architecture. The agent proposes from outside the control boundary. Identity, policy, conditional human approval, a least-privilege tool gateway and independent verification sit between proposal and systems of record. Every step writes evidence. Containment and recovery stand ready when a check fails.

Done is not correct

Return to the supplier payment. Run it twice.

On the first path, the agent completes every step and the bank API confirms the transfer. Technical reliability is perfect. Business correctness has failed, because a rule the business cares about, that a recently changed bank account must be verified through an independent channel, was never part of the agent's definition of done.

On the second path, the agent prepares the same payment but does not release it. An independent validation step checks the business rules that matter: the three-way match, the approval limit, and whether the supplier's bank details changed recently without verification. The last check fails. The payment is held, the exception routes to the accounts payable owner, and the transfer is released only after the change is verified. The agent was no smarter on the second path. The system was.

Technical reliability means the system ran as designed. Business correctness means the outcome satisfied the rules of the business. They are not the same test.
Exhibit 3. Task completion is not business correctness. Both paths execute the same task and both receive a success response from the tools. Only the path with independent validation of business rules, applied before an irreversible commit, produces an outcome the enterprise can accept.
Exhibit 3. Task completion is not business correctness. Both paths execute the same task and both receive a success response from the tools. Only the path with independent validation of business rules, applied before an irreversible commit, produces an outcome the enterprise can accept.

The pattern generalizes well beyond finance, and in regulated industries the stakes include the license to operate. Consider a second illustrative case. A pharmacovigilance agent takes in adverse event reports, classifies each for seriousness, and routes the serious cases for expedited reporting to regulators inside the statutory clock. It processes every report on time. On one case it reads a hospitalization as an outpatient visit, classifies the event as non-serious, and files it with the routine batch. Every task succeeded. The reporting deadline was missed, and nothing in the agent's logs shows anything but green. The fix is not a smarter classifier. It is Proof of Correctness before an irreversible commit: an independent check of the seriousness criteria against the source record, with the serious cases, and only those, routed to a qualified person before the clock runs out.

This is the distinction leaders need to hold onto: technical reliability means the system ran as designed, business correctness means the outcome satisfied the rules of the business, and governance effectiveness means the enterprise can demonstrate both and knows who owns each.

Proportionate autonomy, and the case against this argument

The framework invites three serious objections, and each deserves a straight answer.

"This will slow everything down." Sometimes it will, and the cost is real. In Anthropic's published experiment, a solo agent ran for about 20 minutes at a cost of $9, while the full harness ran for about six hours at a cost of $200. Only the harnessed version produced a working application. Reliability is purchased. The answer is not to apply every control everywhere. It is to scale control to consequence. Drafting an internal summary and releasing a payment are both agent actions; they deserve very different treatment. Control requirements should rise with the potential impact of an action, its irreversibility and the uncertainty involved, and fall as the effectiveness of existing controls is demonstrated. That is a judgment each enterprise must make for itself. No universal autonomy scale settles it.

"Better models will make this unnecessary." Better models will retire some scaffolding. Anthropic's team observed that every harness component encodes an assumption about what the model cannot yet do alone, and that harness work relocates as models improve rather than disappearing. But capability strengthens only the first proof. A more capable model is not thereby authorized, contained, independently checked or owned. Accountability is a property of institutions, and regulation reflects that. The EU AI Act requires oversight of high-risk systems to be commensurate with risk, level of autonomy and context of use, and the people assigned to oversight must be able to override or reverse the system's output (European Commission).

"Just keep a human in the loop." Human approval is a powerful control placed well and a hollow one placed everywhere. A reviewer approving hundreds of agent actions an hour is not exercising judgment. The AI Act explicitly asks that people assigned to oversight remain aware of the tendency to over-rely on system output. Reserve human approval for decisions where consequence and irreversibility justify it, and make the remaining approvals genuinely informed.

The point is not theoretical. In early 2024 a finance employee at the engineering firm Arup approved fifteen transfers totaling about US$25.6 million after a video call in which the chief financial officer and every other participant were deepfakes (Fortune). A human was in the loop. What was missing was an independent channel to verify the instruction, which is exactly what the callback supplies in the supplier payment scenario above. Approval is not verification.

The framework has its own failure mode too. If the six proofs become a documentation exercise rather than engineered controls, they will produce paperwork and not safety. A proof that exists only in a policy document is not a proof.

What changes for the C-suite and the board

For the CEO, agents are a new class of actor in the operating model. Every human who acts on the enterprise's behalf has an identity, a mandate, limits and a manager. Agents that act on enterprise systems need the same four things, and the question of who sets an agent's autonomy level for a given workflow is a decision right, not a technical setting. In most organizations it belongs with the business owner of the process, advised by risk and technology.

For the CTO and CIO, the control plane must sit outside the model. Authorization, tool access and verification should be enforced by infrastructure the agent cannot talk its way around. The agent proposes; the enterprise disposes. This is an architecture principle, and it is far cheaper to establish before the hundredth agent than after it.

For the CRO and CISO, the most useful inventory is of irreversible actions. Which actions available to agents cannot be undone: payments, submissions, deletions, external communications, contractual commitments? That list defines where Proof of Correctness must precede commit and where human approval earns its cost.

For the board, the discipline is to ask for evidence rather than demonstrations. A demo shows Proof of Understanding. It shows nothing about the other five. Directors should expect management to show, for each material agent deployment, how it was authorized, how it is bounded, how its outcomes are checked, what record it leaves and how it would be stopped.

The law is already settling where accountability sits. In February 2024 a Canadian tribunal ordered Air Canada to compensate a passenger its website chatbot had misled about bereavement fares. The airline argued that the chatbot was a separate legal entity responsible for its own actions. The tribunal called that submission remarkable, held that the airline is responsible for all the information on its website whether it comes from a static page or a chatbot, and found negligent misrepresentation (Moffatt v. Air Canada, 2024 BCCRT 149). That was a chatbot giving advice. The same reasoning will attach to agents taking action.

A demo shows Proof of Understanding. It shows nothing about the other five.
Exhibit 4. Three incidents, six proofs. Three documented cases, the proof that failed in each, and the control that would have closed it. None of the three was a failure of model intelligence.
Exhibit 4. Three incidents, six proofs. Three documented cases, the proof that failed in each, and the control that would have closed it. None of the three was a failure of model intelligence.

The Six Proofs checklist for boards and CXOs

Use this for any agent that can change data, move money, communicate externally or commit the enterprise.

ProofAsk managementEvidence that answers itWarning sign
UnderstandingHow do we know the agent reads the goal and its constraints correctly?Evaluation results on realistic cases, including edge cases from our own historyThe answer is the name of the model
AuthorityWhat is it allowed to do, and where is that enforced?Agent identity, scoped permissions, value limits, enforced outside the modelPermissions live in the prompt
ContainmentWhat is the most damage one bad decision could do?Least-privilege access, spend, rate and scope limits, sandboxed executionThe agent shares a service account with an application
CorrectnessWho or what checks the outcome, and against which rules?Independent validation of business rules, owned by the process ownerThe agent reviews its own work
RecordCould we reconstruct yesterday's decisions by tomorrow morning?Complete, attributable traces linking proposal, approval, action and resultLogs exist, but nobody has tried to replay them
ReversalHow would we stop it, and what can we undo?Kill switch, rollback or compensation procedures, testedNo one has rehearsed the stop

The rule that ties it together is simple. Grant autonomy to the level of your weakest proof, and scale the burden of proof to the consequence of the action.

The agent is not the system

For two years the industry has competed on what agents can do. That race will continue, and it matters. But capability is becoming a commodity that every competitor can license on the same day. What cannot be licensed is an enterprise that knows what its agents are allowed to do, can show what they did, catches what they got wrong and can stand behind every outcome they produce.

Intelligence can be delegated to a model. Accountability cannot. The enterprises that understand this will not be the ones with the most agents. They will be the ones whose agents they can afford to trust.

A question for leaders: if your most capable agent made a consequential mistake tonight, which of the six proofs would you be unable to produce tomorrow morning?

Sources

The supplier payment and pharmacovigilance scenarios are illustrative and hypothetical. The Replit, Air Canada and Arup incidents are drawn from public reporting and a published tribunal decision. The Six Proofs of Accountable Autonomy is an original framework by the author, not an industry standard.

Prashant Akhawat writes the CXO Intelligence Series at akhawat.com. The views expressed here are his own and do not represent any organization he is associated with.

UNDERSTANDING     AUTHORITY     CONTAINMENT     CORRECTNESS     RECORD     REVERSAL
SeriesCXO Intelligence · The Accountability Drawings
AuthorPrashant Akhawat
Webakhawat.com