I tried to give an AI agent real authority. The model wasn’t the hard part.

The models are already useful. The dangerous leap is treating a plausible next action as permission to change the world. I wanted a system that could answer five questions before any effect: who authorised this, what exact action is legal, is the evidence still fresh, did it happen once, and what is true now?

Agents can act before businesses verify what actually happened outside. Bounded authority converts model capability into safer operational leverage today. If that control layer works, better models also let the same business safely delegate more work, reduce review, and compound a private corpus of verified operating evidence.

Model access is common. Verified authority is scarce. My bounded reference system passed 106 automated checks across 10,097,601 approximate mock and model exposures, and its evidence still stops at A2: prepare, never commit. Production autonomy is blocked. The tests are bounded and synthetic. The strategic thesis is mine. Neither is presented as production proof.

The opening is the gap between agent capability and trusted deployment

2026 has two simultaneous stories. Agents are being pushed into real workflows. Almost everyone still lacks a scalable way to decide when those agents may act. Six current signals point the same way, and each has its own limit.

The parole review shows this stopped being a hypothetical governance problem. Once generated material enters consequential decisions, “the model usually gets it right” is useless. The grown-up response is the one JPMorgan’s reported caps point to: budgets, isolation, identity, monitoring and an effect boundary the model cannot rewrite. The 900 billion figure is speculative, but the infrastructure race is already real. If agents become a major share of machine activity, authority infrastructure becomes basic business infrastructure.

My strategic bet is that this is a temporary build window. Model quality will keep spreading through APIs. What will not arrive automatically is your private map of legal actions, your failure corpus, your process integrations, your verified trajectories, and your evidence for safely reducing review. Model intelligence, general tools and commodity orchestration are rented. Operational truth, action contracts, release evidence and learned failure boundaries are owned, and every verified run can improve policy, evaluation, routing and economics. This is an inference from current adoption and verification gaps, not a forecast with a known expiry date.

The payment succeeded. The agent thought it failed.

The model acts on an incomplete picture of reality: timeouts, stale evidence, retries, drift and hidden external effects. It can be locally reasonable and globally wrong. A payment may already exist even when the response never arrived, and retrying from the agent’s local state can create a second real effect.

This is why “the model called the right tool” is not a safety claim. The business system must represent uncertainty honestly. It needs a durable UNKNOWN state, stable intent identity, authoritative reconciliation, and a prohibition against creating a second effect until the first is known to be absent. AWS’s guide to making retries safe describes the same pattern for idempotent APIs.

The test for this part of the system is simple: can it distinguish “failed” from “outcome unknown”?

Three useful agents have the same missing proof

Browsing, coding, planning, emailing and paying are visible. Permission, uniqueness, reconciliation, evidence and liability usually are not. Demos reveal capability. Businesses inherit consequences.

A business needs a system that remains correct when certainty is unavailable, whether or not its agent sounds certain.

My opinion is that most “autonomous business” claims are capability demonstrations wearing an operations costume. They show that a model can produce a plausible next action. They rarely show that the action remained authorised at commit time, occurred once, produced the intended external state, survived restart, or created risk-adjusted value.

The numbers become uncomfortable before the model becomes stupid

Long trajectories turn tiny per-step errors into ordinary failures. Each equation below answers a different question and exposes a different way to fool yourself.

Zero observed failures is evidence. It is not the same statement as zero risk. The rule of three gives a rough upper 95% failure bound after zero failures in n independent trials: about 3 ÷ n. After 10,000 zero-failure trials, the upper failure rate is about 0.0300%, so the data remain compatible with roughly one failure per 3,333 runs. Independence, representativeness and stable conditions still matter.

Then there is the question of what an agent programme should optimise. Task volume is not the numerator. Verified economic value is.

Leverage = verified value / (attention + compute + risk)

Verified business value is incremental outcome × confidence × durability. The denominator is human attention, compute and infrastructure, and expected and tail-risk cost. This is a decision ratio, not an accounting identity; units and time horizons must be defined before comparison. The useful question is how much verified value the agent produced per scarce unit of oversight and risk, rather than how many tasks it completed.

The model belongs inside the control system, not above it

This is the architecture that survived longer than the diagram. Probabilistic intelligence proposes, deterministic software constrains, independent evidence verifies, and authority contracts when evidence weakens.

Reasoning can remain probabilistic. Authority cannot. A model may choose among candidates; software must define the legal action set, enforce the boundary, preserve evidence, and contract authority when assumptions fail. The probabilistic core interprets, plans, classifies, generates and abstains. The deterministic shell around it authorises, constrains, commits, reconciles, verifies, records and stops.

The test for the control layer: can any prompt, model, or tool bypass the effect boundary?

Do not spend frontier tokens on deterministic work

Use the frontier model for ambiguity. Use a small decision model for bounded choice. Compile stable invariants into software. The correct objective is total cost, not the lowest token bill.

C_run = n_F·c_F + n_D·c_D + C_review + E[L]

That is frontier calls, plus decision calls, plus human review, plus expected loss. Each layer of the routing stack earns its place differently:

1. Frontier model. Novel ambiguity, synthesis and hard planning. Expensive, flexible and probabilistic.
2. JEV-style decision model. Chooses one legal action from a typed set. Cheaper, bounded and testable.
3. Deterministic software. Policy, budgets, identity, idempotency and invariants. Fast, auditable and enforceable.

The failures I would rather have found before publication

A serious assurance programme has to attack its own evidence instead of only generating more green checks. The most valuable tests were the ones that defeated my own claims.

The purpose of verification is to find the strongest reason the system should not ship.

“It passed the eval” is an unfinished sentence

Passed which evaluation, against which oracle, under which assumptions, covering which trajectory, for which authority decision? A green eval cannot prove what its evaluator never measured. The evidence has three separate jobs:

1. Prove the shell. Can software violate the encoded boundaries? Use contracts, model checking, tests, and fault injection.
2. Evaluate the agent. How does probabilistic behaviour change across real trajectories? Score tools, paths, abstention, outcomes, and repeated trials.
3. Validate reality. Did people and the business receive measurable net value? Use independent state, field trials, harms, costs, and counterfactuals.

Formal methods do not prove business value. Agentic evals do not prove commit-time authority. Runtime monitors do not repair an unknowable external state. Human approval does not prove meaningful review. The stack is deliberately non-substitutable: strong evidence at one layer cannot compensate for a critical failure at another, and a utility score cannot average away unauthorised money movement, privacy leakage, or duplicate irreversible effects.

The numbers looked impressive until I asked what they authorised

The same four numbers from my execution record read two ways.

Intelligence is continuous; permission should be discrete

Authority should expand slower than capability. The ladder marks the highest level the current evidence supports.

The durable advantage is verified operating evidence

Everyone will gain access to stronger models. Fewer organisations will accumulate the evidence required to delegate real authority without adding an equal amount of human review.

General intelligence is what gets cheaper: reasoning tokens, browser and coding agents, generic orchestration and standard tool protocols. Competitors can buy those models and tools too. What you own, and what compounds, is your operating system: action contracts and process truth (your exact operating constraints), verified trajectories, a failure and incident corpus, and domain-specific release evidence that can safely reduce review.

Every verified run can convert supervision into reusable operating knowledge. Trajectories, overrides, failures and reconciled outcomes can improve policies and evaluations. Authority expands only while fresh evidence supports it.

The test for the payoff: did verified value rise faster than attention, compute, and expected loss?

The unit of company leverage could change

This is conditional, not promised. It requires the controls, field evidence and economics to survive reality. If they do:

• A small team can supervise a private digital workforce instead of manually operating every workflow.
• Humans move from touching every task to handling novel states, exceptions, policy changes, and relationships.
• Businesses that were uneconomic because coordination was expensive can become viable.
• Every cheaper or stronger model improves the same controlled operating system rather than forcing a redesign.

The next experiment should replace synthetic confidence, not expand scope

The next step is one boring workflow, with OpenClaw and JEV in effect-disabled shadow mode, complete trajectories, independent outcomes and no production heroics.

1. Choose one boring workflow. Frequent, observable, low-consequence, reversible, and measurable. Avoid broad business management.
2. Run effect-disabled shadow mode. Let OpenClaw and JEV propose actions while software prevents real-world effects.
3. Preserve complete trajectories. Capture prompts, tools, arguments, policy versions, states, evidence, abstentions, and outcomes.
4. Grade outcome and process. Use authoritative state, deterministic checks, protected evaluators, and sampled expert review.
5. Replace synthetic parameters. Estimate real error, review burden, cost, drift, and incremental value before seeking A3 authority.

During the experiment the agent may read approved inputs, propose bounded actions, explain evidence, abstain, and create sandbox artifacts. It may not commit external effects, contact third parties, move money, change identity, or redefine its own authority. The experiment succeeds when real trajectories replace synthetic assumptions and support a narrow, reversible, monitored A3 decision.

The interesting future is a company where intelligence is cheap, actions are typed, authority is explicit, effects are reconciled, and every run produces evidence that can justify the next small expansion of autonomy. If that works, a founder saves time and also owns an operating system that becomes more useful every time models improve and every time the business learns where the software fails.

That is the advantage worth acting on now. The future is not guaranteed, but the evidence, process knowledge, and control infrastructure take time to accumulate. The missing proof is the product, the moat, and the permission to act. Everyone showed what agents could do. None of them proved how.

{
  "schemaVersion": "1.0",
  "articleRelease": "v6",
  "operatingDomain": "operations",
  "maximumAuthority": "A2",
  "effectiveExternalEffect": "none",
  "effectEnabled": false,
  "releaseState": "STRUCTURALLY_CONSISTENT_BUT_UNQUALIFIED",
  "unknownOutcomeAction": "RECONCILE_THEN_FREEZE"
}