Software Has Become an Actor
The governance built for it has not caught up
Abstract. Software has become an actor. The governance that worked when software was a tool cannot govern software that acts. This manifesto names the categorical shift, walks through how existing controls fall short of governing autonomous AI action, articulates what governance must become, and traces the historical pattern that makes an independent authorisation layer structurally inevitable.
For most of computing history, software produced outputs and humans decided what to do with them. The boundary between what software produced and what happened in the world ran through the human in the chair. Identity systems, role-based access control, audit logs, content filters — the entire apparatus of software governance was designed for that era and continues to solve real problems within it.
Autonomous AI systems remove the human from the chair. They observe a situation, reason over it, and execute an action — directly, without anyone reviewing the action between the decision and its consequence. The actions are not specified in advance by a human; they emerge from inference. The result is a categorical change in what software is. Software was a producer of outputs. It is becoming a producer of consequences. The two are not the same thing. An output is a value a human interprets. A consequence is a state change in the world — a fact, not an artefact. Outputs can be reviewed before they take effect. Consequences are facts the moment they happen. They cannot be uncomputed.
None of the controls built for the previous era governs the question that the new era requires: was the specific action this system is about to commit authorised — by whom, under what constraint, and can you prove it? That question lives at the action boundary.
Action boundary. The point in a system where intent becomes consequence. Everything before it is intent; everything after, fact. Governance of autonomous AI action can exist only exactly there.
The governance that fits this era has to live there.
The Three Phases of Software
The change in what software is happens in three identifiable phases. The boundary between what software produces and what happens in the world moves each time.
Software computed. For the first several decades, software did one thing: accepted inputs, ran a calculation, produced an output. A spreadsheet computed totals; a person looked at the total and decided whether to send the invoice. A database returned query results; a person decided who to email. A compiler produced an executable; an engineer decided when to deploy it. The software was a tool. The person was the actor. The boundary between what the software produced and what happened in the world ran straight through the person sitting at the keyboard. Software-side governance was modest — file permissions, who could log into which system, basic audit logs. The human in the chair was the load-bearing governance mechanism.
Software automated. Then software started doing things humans had been doing manually. A cron job ran a nightly batch import. A pipeline moved data between systems on schedule. A deployment script provisioned servers. The actions were no longer triggered by a person hitting return; they were triggered by time, by events, by predefined conditions. But the actions themselves were still designed by humans in advance. The cron job did exactly what the engineer who wrote it intended. If an action produced an unexpected consequence, you could trace it to a human design choice, find the line of code, and fix it. Governance moved to design time — change control, code review, deployment gates, compliance reviews. The human moved from the moment of consequence to the moment of design, but the model still held: every consequence the system would produce was downstream of a human choice that could be reviewed before the system was ever turned on.
Software acts. Autonomous AI systems break that model. They observe a situation, reason over it, and execute an action — and the action they take is not a thing a human designed in advance. The system was deployed with a goal, a set of tools, and access to a context, but the specific tool invocations emerge from inference at runtime.
The engineer who built the system can still point to the dispatcher that fires a tool call — that plumbing is real, hand-written, deterministic code. What no one wrote in advance is the selection: which tool fires, with which arguments, against which target. That binding of action to intent was never reviewed before the system ran. The action is a product of the model’s reasoning over a context the model was given, and that reasoning produces sequences no one designed and no one reviewed.
The pattern is visible across domains: coding agents committing to production repositories, customer-service agents posting account changes, research agents executing cloud queries against datasets they were given access to, scheduling agents sending messages that bind the organisation. In each case, the action lands in the world before any human checkpoint exists.
The boundary between intent and consequence has no human checkpoint left to land on. In the compute phase, it lived in the human at the keyboard. In the automate phase, it lived in the engineer at design time. In the act phase, neither point exists by default. Teams can reinstate one — gating destructive tools behind a human approval click — but a manual gate is ad-hoc, per-tool, applied at human discretion, and produces no durable record; it slows the loop without governing it. Absent a deliberate checkpoint, the system observes, decides, and executes within a single continuous loop, and by the time anyone outside that loop could look at the action, the consequence has already happened.
The distinction this exposes is categorical, not incremental. An output is a value a human interprets. A consequence is a state change in the world. Outputs can be reviewed before they take effect; the entire model of software governance assumed they would be. Consequences are facts the moment they happen — a refund posted, a message transmitted, a record modified, a deployment triggered. They cannot be reviewed before taking effect because they have already taken effect.
This is why the controls built for the previous two phases do not transfer cleanly to the third. They were not wrong; they solved real problems for software that produced outputs. They are insufficient for software that produces consequences. To see why, it helps to look at exactly what each one does, and exactly where it stops.
What Existing Controls Actually Do (and Don’t)
Every organisation deploying autonomous AI systems already has governance tooling. Identity systems, role-based access control, audit logs, guardrails, observability platforms, network controls — collectively the apparatus that came out of decades of enterprise software security. Each one solves a real problem within its own domain. None of them governs the action boundary, because none of them was designed to.
Identity systems answer who the actor is. Okta, Auth0, Azure AD — mature, federated, standards-based, and load-bearing for human access. They tell you that the entity making a request is who it claims to be. They do not tell you that the specific action this entity is about to commit is authorised. Identity is a necessary input to an authorisation decision; it is not the decision itself. For autonomous systems this matters more, not less, because the entity making the request is not the principal whose intent the action represents — it is a delegate acting on behalf of someone else, often at the end of a chain of such hand-offs. That chain is not a label to be recorded but a structured object with a rule: each link can only narrow the authority the link above it granted, never widen it — authority attenuates monotonically from principal to acting delegate, and the question that needs answering is whether what survives that narrowing covers this specific action under this specific delegation (with all the edge cases a chain brings — a link revoked mid-flight, an intermediate grant expired, conflicting constraints accumulated along the way). Identity systems are silent on that question.
Role-based access control maps identities to static permission sets. The user has the database-write role, so the user can write to the database. This worked when users were humans whose intent matched the operations they triggered. Autonomous systems break the model: they hold all the roles their job ever requires, all the time, with no equivalent of a user choosing not to invoke a permission they hold. And the question that matters has nothing to do with role membership. A role check answers “could this entity ever do this kind of thing?” Governance has to answer “should this entity do this exact thing, right now?”
Guardrails and content filters evaluate what the model says: input and output classifiers that catch prohibited content, prompt injections, sensitive-data leakage in generated text. They are useful, and any serious deployment should include them. They are also categorically misplaced for action governance, because text production and action execution are different operations at different boundaries. A model can produce text the guardrail accepts: “I’ll help you process that refund.” Meanwhile the tool invocation it generates issues a refund that exceeds the delegation scope. The guardrail evaluated the language. Nobody evaluated the action.
Audit logs and observability platforms record what happened. They are essential for incident response, debugging, and operational improvement. They are not governance. A log reconstructs history. Governance writes history. The two work in opposite temporal directions, and no enhancement to logging closes the gap. “We have detailed audit trails of everything the system did” is a different claim from “we have evidence that every action was authorised before it executed.”
Network controls like service meshes, perimeter firewalls, and mutual TLS govern transport. The action flowing across the connection is invisible to them. Transport governance and action governance are different problems.
Tool-calling interfaces and agent protocols — function calling, the Model Context Protocol, and the orchestration frameworks built on them — are the closest existing thing to action governance, and a practitioner will reasonably ask whether they already are the layer described here. They standardise how an action is invoked and let a host scope what each tool or server may do. That is real and necessary, but the host still evaluates one tool call at one boundary against a static per-tool scope. It does not see the delegation chain behind the caller, it produces no decision record an auditor can replay, and — the decisive gap — it cannot see the action that emerges from how separate tool calls compose. The retrieval-then-messaging case below slips through precisely because each call is in scope at its own boundary. Per-tool scoping is a component of the answer; it is not the boundary at which composed authority is decided.
None of the controls is wrong. Each was designed for a real problem and solves it. The issue is that no combination of them produces a pre-execution record binding the proposed action, the delegation chain, the policy in force, and the resulting decision into a single tamper-evident artefact that proves the action was authorised before it executed. That artefact is what governance of autonomous AI action requires, and it does not fall out of stacking existing controls on top of each other.
There is also a deeper failure mode that even the right per-action check would miss.
The Composition Argument
Each of the controls above evaluates one entity at one boundary — identity at the session, RBAC at the call site, guardrails at the model output, audit at the log line, network at the connection. Even controls that did evaluate each action one by one would still miss the class of failure that emerges from how components compose.
Autonomous AI systems are built out of multiple components that share state. A retrieval component is authorised to read customer records into a shared workspace. A messaging component is authorised to send outbound email. Each holds an individually well-bounded permission, and each step, taken on its own, is in scope: reading the records is allowed, and sending an email is allowed. The breach is that this email carries data the messaging delegation was never granted to send outside the system. A per-step check sees a permitted read and a permitted send; neither step crosses a boundary it was forbidden to cross. The exfiltration is visible only to a check that knows where the email’s payload came from — and that origin is exactly the cross-component fact a single-action policy cannot see unless the data carries its provenance with it.
Locally authorised does not imply globally authorised.
This is the strongest reason no governance plane assembled from existing controls can do the work. The action that breaches authority is the composition of authorised steps, not any single step. Governance has to evaluate the composed action — what the system is collectively about to do — not just each step it takes to get there.
This is harder than a per-step check, and it is worth being honest about how much harder. It does not mean enumerating every reachable composition before each action; the space of reachable compositions is combinatorially large and, in full generality, undecidable. It means a bounded check at the action boundary against what has already flowed into this action — the accumulated delegation context and the provenance of the data the action would act on. The example above is governable only if that provenance is visible: the email step has to carry the fact that its payload originated in a customer record the messaging delegation was never granted egress over. A plane that mediates discrete tool calls but cannot see what flowed between them inherits the same blindness one level up. Evaluating the composed action therefore presumes the canonical action carries attested provenance, not merely a well-formed shape — a schema-valid artefact asserting false context is exactly the case a shape check passes and a provenance check catches.
The two-tool case is the simplest instance, not the limit of it. The same structure holds across actors and across time: a planning agent that delegates to an executor, a multi-agent system whose members each stay in scope while the joint effect does not, a session that writes shared memory a later session reads back and acts on. The cleanest no-attacker version is the confused deputy — a component induced, with no adversary present, to act outside the intent its authority was granted under. That floor matters because it makes the load-bearing property explicit: authority verified at the action boundary is source-independent. It governs the action regardless of what produced it — a bug, a prompt injection arriving through retrieved content, a hijacked tool, a colluding peer. The plane does not detect the attacker or diagnose the confusion; it does not need to. It bounds what the action can do to whatever the presented delegation authorises, and a proposal that exceeds that scope is denied on the same basis whether it was benign, buggy, or hostile. The corollary is the discipline this imposes: governance is only as tight as the delegation. An over-broad delegation re-opens the gap from the inside, which is why narrowing scope to what the task actually requires — not the model’s behaviour — is the real control.
The Distinction That Changes Everything
The distinction is categorical, and naming it clarifies almost everything that follows.
Safety is a property of the model. Governance is a property of the system the model is wired into.
Safety asks: is this model well-behaved? Does it refuse harmful requests? Does it produce accurate answers? Does it generalise to inputs it was not trained on? These are questions about the model’s internal disposition, addressed by training, evaluation, red-teaming, alignment work, interpretability research. AI safety is a real and important discipline, and the work being done there matters.
Governance asks a different question. Was this specific action — this tool invocation, with these parameters, against this target, under this delegation, at this moment — authorised? The question is about the action, not the disposition. It is answered at the boundary where the model’s reasoning crosses into the world’s state. And it has to be answered by something outside the model, because a system that decides whether its own actions are authorised has no external accountability.
Here is what makes the distinction load-bearing rather than rhetorical. A perfectly safe model — one that refuses every harmful prompt, never hallucinates, generalises flawlessly — wired into a delegation it should not be exercising will still take an unauthorised action, because the model has no way to know it should not. A less well-behaved model wired through a governance plane on the only path to consequence cannot commit an action the plane refuses — because denial does not depend on the model’s cooperation, and the model has no route to the world that skips the plane. The claim is precise, and the precision is the point: the plane refuses what its policy classifies as unauthorised, so the guarantee holds insofar as the policy is sound and the mediation complete. That is not a retreat. It relocates the failure mode from the opaque interior of model weights to an explicit, externally auditable policy — a gap you can inspect, test, and close, rather than a property of the model you can only hope for. The two layers solve different problems and neither subsumes the other.
This is also why “identity for AI agents” is not the right framing for what is needed. For human users, identity is presented once at login and authority is inferred from it for the session — the identity-once, authority-many model that decades of enterprise infrastructure are built on. For software actors, that model fails. Actors do not authenticate; they compose. Their identity is what they are composed of — model version, system prompts, tools, policy bindings, retrieval configuration — and that composition can shift between the moment authority is granted and the moment an action is forwarded. Their authority has to be verified at every action they propose, not once at the start of a session — and verified against a composition the plane measures, not one the actor declares about itself. If the actor is the source of truth about what it is, a hijacked or swapped component can re-present a stale, still-authorised fingerprint while running an injected prompt or an added tool; the same independence that forbids a system from judging its own actions forbids it from attesting its own identity. The primitive that fits autonomous AI action is not actor identity, taken alone. It is actor identity, freshly measured, bound to action-level authority and evaluated at every consequence.
Once the safety/governance distinction is named and the actor-identity formulation follows, the architectural question simplifies. If governance has to be its own layer — outside the model, at the action boundary, evaluating delegation per-action — what does that layer have to look like?
What Governance Has to Be
Five properties. Each one is forced by the structure of the problem; none is a design preference.
In-path. Pre-execution. Deterministic. Evidenced. Independent.
The action must have no route to consequence except through the plane. This is the precondition every other property rests on, and it is the one most easily left silent. “Denial does not depend on the model’s cooperation” is true only if the action physically cannot reach the world without passing the plane first. Any capability the actor holds outside that path — a credential it can use directly, a tool that calls out of band, a network channel no one is mediating — is ungoverned by construction, and a determined reader will find it. This is not a property the layer confers for free; it is an assumption the deploying architecture has to guarantee, by routing every consequence-producing operation through the plane and granting the actor no means to act around it. Stated this way, every bypass a hostile reviewer can name — the out-of-band credential, the unmediated side channel, the action mutated after the check, the decision token replayed against new state — stops being a refutation and becomes a case the architecture must foreclose. The plane can only govern what it sees; complete mediation is what makes sure it sees everything.
A second clause follows directly: when the plane cannot decide, the action must not proceed. The absence of an authorisation decision — on any error, timeout, unreachable policy, or unresolvable input — has to resolve to denial, not to default-allow. A plane that lets the action through when it cannot evaluate it has not closed the unaccountable loop; it has relocated it. This fail-closed default is what makes the irreversibility argument bite: it is no defence that consequences cannot be uncomputed if the gate waves the action through the moment it falters.
Governance has to precede consequence. This is the asymmetry that defines the action boundary. Consequences cannot be uncomputed; the database row is modified, the message is sent, the transfer is posted. A control that evaluates the action after it executes is doing investigation, not governance. Investigation is valuable (it diagnoses, it improves the system, it informs the next decision), but it cannot prevent the consequence it observes. Governance has to live before commit, or it is not governance.
The decision has to be deterministic. Given the same canonical action, the same delegation context, and the same policy, the governance plane returns the same decision — always, everywhere, regardless of load, model version, or operational conditions. The reason is verifiability. A decision that is non-deterministic cannot be replayed by a third party, checked by an auditor, or reproduced after the fact. Non-deterministic governance is governance taken on faith — which is to say, not governance at all.
This rests on two things being pinned, and they carry the whole property. The first is the canonical action: a normal form — the operation, its target, its parameters, and the delegation context it is proposed under — produced by a fixed procedure that strips ordering, encoding, and transport variation so that equivalent runtime behaviour maps to one representation. That procedure has to be deterministic and external to the model; reducing a free-form, model-emitted invocation to canonical form must not put a model back in the loop, or the non-determinism the property excludes simply hides inside canonicalisation. The second is the policy: pinned to a stable version or hash, so any party can reconstruct the exact inputs the decision was computed over and arrive at the same output. (Determinism also presumes a fixed conflict-resolution order — first-match, most-specific, deny-overrides each yield a different decision from the same inputs — so that the decision is a genuine function of its inputs and two compliant implementations cannot disagree.) Because policy, revocation, and freshness can change, determinism is sameness of output for the same frozen inputs, not sameness across wall-clock time: the version-pinned policy, the revocation epoch, and the time source are themselves members of the input set, snapshotted at the boundary and bound into the evidence so replay reproduces the decision and the inputs it was computed over.
There is a gap this does not close on its own, and it has to be named: a sound, deterministic decision over a canonical action is worthless if the action that executes is not the one that was authorised. The authorised artefact has to be the exact artefact that runs — bound at the boundary so that parameters changed after the check, a reference resolved to a different target at use time, or an authorisation replayed against different live state either invalidates the decision or counts as a new action requiring its own. Replayability for audit and replay-resistance of execution are different properties; the first is what determinism buys, the second is a binding the architecture has to add.
Every decision has to produce evidence. Authorisation that occurred without a verifiable record of having occurred is indistinguishable, from any external position, from authorisation that did not occur. The auditor’s question is not “do you have a governance system?” but “can you prove that policy was evaluated against this specific action under this specific delegation before this action executed?” The evidence required is concrete: the action that was proposed, the policy that was applied, the delegation under which it was authorised, the decision that resulted — bound together cryptographically so that the record cannot be silently edited, deleted, or backdated.
It is worth separating what that record does and does not establish, because the guarantee is easy to overstate. Cryptographic chaining buys tamper-evidence: a record cannot be quietly altered after the fact. It does not, by itself, buy two further things the word “verifiable” tends to smuggle in. One is completeness — that no action executed without a record at all — which is not a property of the record but of the in-path plane: only mediation on the execution path can guarantee there is a receipt for every consequence. The other is faithful production — that the record reflects the action that actually executed — which depends on the receipt being produced at the independent in-path chokepoint, not by the runtime it governs; a compromised producer can emit a cryptographically intact but false receipt, so verifiability of the record is not verifiability of the world. (And verification is a designed capability, not a free one: a naive walk of an append-only chain costs time linear in its length, so at infrastructure scale the evidence structure has to make the auditor’s check efficient, not merely possible — a concern the infrastructure layer answers, but one the claim should not pretend away.) Within those bounds, governance moves from a claim to a verifiable system property; outside them, the record is necessary but not sufficient.
Governance has to be independent of the system it governs. A reasoning system that decides whether its own actions are authorised is a system with no external accountability. The pattern of independence appears in every regulated domain — financial auditors must be independent of the firms they audit; payment authorisation networks are operated separately from the merchants whose transactions they evaluate; in distributed systems, the routing controller is independent of the switches that execute its decisions. The same structural requirement applies. The governance layer for autonomous AI action has to be outside the model, outside the orchestration framework, outside the runtime — separable in mechanism and operated under different organisational control than the systems whose actions it evaluates. Those are two conditions, and both are required: a plane can be technically separable yet still captured by being run by the party whose actions it judges and whose fate it shares. If swapping the model changes what is allowed, the planes are not separated; you do not have governance, you have a feature of the model vendor’s product. That test is a reliable symptom of independence — a plane that fails it is certainly not independent — but passing it is necessary, not sufficient; the organisational condition is the part the swap test cannot see.
The difficulty is not any one of these properties. It is satisfying them at once. In-path yet not a bottleneck; independent yet inline; complete yet cheap — each pair is a real tension, and presenting the list as frictionless is the one place a manifesto-grade reader rightly senses hand-waving. The independent-yet-inline tension is the sharpest, because “operated under different organisational control” and “synchronously on every action’s path” read as a remote call on every tool invocation unless two axes are pulled apart: who owns the policy and holds the evidence (which must be organisationally independent) is not the same question as where the enforcement point runs (which can be a co-located library or sidecar inside the runtime, for speed). This is exactly the payments split — the terminal sits at the merchant, while the rules and the settlement record belong to the network — and it is what keeps the hot path a local evaluation over cached, freshness-bounded inputs rather than a round-trip per action, so the synchronous gate is mandatory without being a chokepoint.
None of these five properties is novel, and none of these tensions is unprecedented. They are the structural shape — and the structural strain — that every previous infrastructure layer eventually arrived at and resolved when its domain crossed the action threshold. The pattern section that follows is offered precisely as the evidence that joint satisfaction is achievable: prior layers achieved it. The pattern is worth tracing.
The Pattern
Every major infrastructure layer in modern computing went through the same trajectory: a capability begins embedded in applications, separates into a standalone service, converges on a platform standard, and becomes infrastructure so foundational that serious systems cannot operate without it. The trajectory is observable, and the structural forces driving it are the same in every case.
Identity. In the early days, every application managed its own user database, its own authentication, its own session model. Each one reinvented the same wheel with slightly different security holes. LDAP and Active Directory externalised user stores into shared services in the 1990s. OAuth and OpenID Connect transformed authentication into a federated platform standard in the 2010s. Today, no serious application is built without an identity provider, and “do you have identity infrastructure?” is a rhetorical question — the answer is always yes.
Networking. Network behaviour was originally embedded in application logic; early networked applications managed their own routing, connection handling, and protocol negotiation. BGP and standardised routing protocols externalised network decisions into dedicated infrastructure. Software-defined networking made the network control plane structurally independent of the data path — the controller decides, the switches execute, and a routing decision is the same decision regardless of which switch happens to be forwarding the packet.
Container orchestration. Deployment began as bespoke shell scripts encoding operational knowledge in imperative procedures. Configuration management tools (Chef, Puppet, Ansible) externalised it into standalone products. Kubernetes turned it into declarative infrastructure: applications declare desired state, the orchestration layer converges actual state toward it, and Kubernetes is the layer underneath every serious cloud-native deployment today.
Payments. Each merchant once managed its own payment logic, fraud detection, and settlement. Payment gateways externalised processing into standalone products. Visa, Mastercard, and the card network infrastructure converged transaction authorisation onto a platform. Today, every transaction flows through an authorisation network that evaluates the transaction before it executes and produces a record that proves it was authorised. The merchant cannot execute the transaction without the network’s decision, and the receipt is the artefact that establishes the merchant’s authority to have taken the customer’s money.
Four transitions, four different domains, one shape. In every case the forces driving separation were the same. Heterogeneity demanded neutrality — the capability had to work across diverse systems, not be coupled to one. Audit demanded evidence — decisions had to be provable, not asserted. Scale demanded automation — manual processes could not keep pace. Trust demanded independence — the control mechanism had to be operated separately from the systems it controlled. Each transition happened when the cost of ungoverned action became structurally unacceptable.
Governance of autonomous AI action is currently in this trajectory. Today, governance is embedded in applications — guardrails inside the model orchestrator, ad-hoc checks in the agent loop, framework-specific permission systems. Three of the four forces press on it visibly: heterogeneity as enterprises deploy autonomous systems from multiple vendors, audit pressure as regulators and counterparties demand proof rather than assertion, scale that makes manual review impossible. The fourth force is doing the most structural work. A model vendor that also operates the governance mechanism controls both the actor and the rules that judge it — the kind of concentration that prior layers eventually pushed out to separate operators, because trust in the layer required independence from the systems being governed.
The pattern does not predict whether the layer will emerge. It predicts that it will be the same structural shape as every prior layer when it does.
Who Builds It
The structural requirement is settled. The shape of the layer is determined by the same forces that produced identity infrastructure, network control planes, container orchestration, and payment networks — neutrality across vendors, evidence as the basis of trust, deterministic evaluation, independence from the systems it governs. There is no path to “autonomous AI systems at enterprise scale, governed and accountable” that does not pass through this layer. The question is not whether it will exist. It is who builds it, and whether the organisations that need it recognise the requirement in time.
There is an honest objection to confront before the close: a mandatory inline authority is itself a new single point of failure and a new concentration of power — the very concentration this argument warns against in the model-vendor case. The answer is not that the cost is zero; it is that the same properties that make the layer work are what bound the cost. Because the authority is deterministic and evidenced, it cannot silently abuse its position — its every decision is replayable and auditable, so the governor is the one component in the system whose conduct is itself provable. Because it is independent and replaceable, the concentration is structural, not proprietary: it is a position any compliant operator can hold, not a lock-in to one vendor. And because the gate fails closed, its failure mode is a halt, not a silent grant — a denial of governance is a different and more recoverable failure than a false authorisation. A new chokepoint that is small, auditable, and swappable is a better trade than diffuse controls no one can inspect, but it is a trade, and naming both sides is the price of asking anyone to take it seriously.
Software has become an actor. The next decade of computing will be defined by whether we govern that fact at the structural level it requires, or pretend the actor is still a tool and govern accordingly. The first path produces autonomous systems that organisations can deploy in consequential domains. The second produces incidents.
Ambit Systems exists to build this layer.
The argument made here continues in the rest of this programme. The Governance of Autonomous AI Action develops the conceptual foundations — the formal definition of consequential action, the Authority Composition Law that explains why composed systems exceed the authority of their parts, and the principles any execution-governance architecture must satisfy. From Confused Deputies to Execution Governance gives the architecture itself — the deterministic evaluation function, the delegation model, the evidence shape. The Ambit Infrastructure Thesis makes the convergence case in detail.