“The enterprise agent stack” can mean almost anything: models, orchestration, tools, data, observability, identity, policy, and the application around them. The Agent Control Points series maps a narrower stack inside that system: the control path that makes an agent’s consequential work attributable, bounded, terminable, and reviewable.
That control path exists because the useful property of an agent is also the property conventional authorization handles poorly. Goal-seeking software can assemble unfamiliar context, discover tools, and complete work its designer did not enumerate step by step. It operates in an open world. The architecture therefore cannot depend on predicting every path or trusting every intermediate decision. It has to preserve containment when the reasoning is wrong, the context is hostile, a credential is stolen, or a supplier fails.
That path is not one product and it is not a call stack. It is a sequence of answers supplied by different kinds of things: runtime evidence, an enterprise binding, an approved-task record, a projected credential, a provider interface, a resource decision, and an evidence feed. The architecture works when those answers join. It fails when one is allowed to substitute for another.
This capstone assembles the three essays and five companions into one model, then adds the practical test implicit in all of them: which facts must survive when each replaceable component changes?
Six Rules for Reading the Stack
1. Position creates the default. It does not confer authority. The runtime sees the instance first. The harness sees the work first. The credential provider sits in the access path. The model provider sees the assembled context. Those positions make it cheap to create private state and hard for a later layer to displace it. They do not decide which records the enterprise should treat as authoritative.
2. A standard seam makes a default contestable, not inevitable. A portable interface or artifact gives a buyer a choice only if something can deploy it. The MCP lesson supplies the clock: the first useful loop needs a small enough coordination radius, immediate utility, and a path from one controlled deployment to multilateral interoperability. Cross App Access shows how that layered play ships when a launch coalition pre-assembles the parties the loop cannot avoid.
3. The predicates are conjunctive. Runtime evidence, enterprise identity, approved work, credential validity, and resource policy answer different questions. Strong proof for one cannot compensate for a missing answer somewhere else. A perfectly attested instance can still belong to an ineligible deployment. A valid credential can still serve terminated work. A live approved task can still request an action the resource forbids. This is survival correctness expressed as architecture: failure in one layer must not silently erase the ceilings enforced by the others.
4. Durable records and projections are different objects. The Agent and Agent Deployment records should survive a runtime. The approved-task record should survive a session and credential. Canonical institutional memory should survive a model, harness, and storage implementation. Credentials and compiled contexts carry bounded views of those records. They do not become the records merely because they travel.
5. The resource retains the final decision. No identity, task record, issuer, or approval can command a resource to act. A resource may narrow, deny, require step-up, or defer under current policy. A blocked agent is a captive client adds the recovery discipline: some denials can expose a governed path to remediation and re-evaluation without surrendering the enforcement point’s final word.
6. Heterogeneity creates pressure for portability, not a law of market structure. Vendors that run consequential, long-lived work keep building the same governance responsibilities because their own operations require approval, lifecycle, revocation, delegation, and evidence. Convergence is not coordination. The customer’s second vendor turns private identifiers and state into a join problem, but a strong bundle can still win where buyers value one operating boundary more than replaceability.
The couplet underneath all six is unchanged:
Distribution determines the default. Standard seams determine whether the default can be challenged.
The Control Path on One Page
The stack becomes clearer when every position states both its answer and its limit.
| Position | Question it answers | Governing evidence, record, interface, or decision | What it does not prove |
|---|---|---|---|
| Runtime evidence | Which running instance controls this key, and what execution environment produced the evidence? | Key-bound attestation or workload evidence | Whose enterprise Agent it is, whether its deployment is eligible, or why it is acting |
| Identity binding | Whose Agent is this, and which approved deployment is running? | Enterprise Agent and Agent Deployment records bound to accepted runtime evidence | Whether the current undertaking is approved or this action is permitted |
| Approved work | Why does authority exist, what bounds it, and is the undertaking still active? | Approved-task record with owner, purpose, bounds, derivation, lifecycle, and expiry | That a particular credential is valid or a resource must accept the action |
| Credential projection | Which eligible subset may travel to this audience for this interval? | Issuance decision and audience-bound, short-lived credential | Ownership of the identity or approved-task records it projects |
| Provider seam | How does the agent acquire, hold, and present the right credential? | Mechanism-hiding interface, key custody, provider selection, and downgrade policy | That the credential’s claims are true or sufficient for the resource |
| Resource decision | May this concrete action proceed now? | Current local policy and an allow, deny, step-up, or defer decision | Permission for any later action or authority to expand the upstream records |
| Evidence plane | What happened, under which records and decisions? | Stable identifiers and events joining instance, Agent, deployment, task, credential, decision, and effect | That a joined decision remains valid going forward, independent of the records it evidences |
These are not seven independent systems a buyer must purchase. They are seven responsibilities that may be bundled in one platform or divided among several. Logical separation is the requirement. Product separation is a deployment choice.
Three Upstream Contests, Not Seven Markets
The series focuses on three upstream control points because those are the places where a product can turn distribution into a durable enterprise dependency.
- The provider seam controls the default path through which credentials are acquired and presented, including key custody and mechanism policy.
- The binding layer controls the durable Agent inventory, approved deployments, runtime mappings, and identity incident joins.
- The approved-task record controls the approval surface, authority derivation, lifecycle, termination, and task-level evidence.
Control accumulates through the four powers the series names, and a layered market exists when those powers split among parties without breaking the path.
The other positions matter without becoming additional upstream systems of record. The runtime originates evidence and gains distribution at deployment. The issuer chooses which evidence it accepts and what it projects, so it is a real chokepoint. In this architecture it reads the Agent and approved-task records rather than silently absorbing them. If an issuer becomes authoritative for either, it has bundled an existing control point rather than discovered a new one. The resource decision is absolutely a control point, contested by resource vendors, gateways, and policy engines, but it stays outside the upstream contest because its final decision cannot be delegated away. Audit crosses all of them.
One Trace, Forward and Backward
The forward path shows how bounded authority reaches an action. The reverse path shows whether termination actually works.
The series hub draws that trace once for the whole set. Read in both directions it works as follows.
Run forward, the runtime supplies proof, the binding layer resolves the enterprise Agent and Deployment, the approved task supplies the live purpose and ceiling, the issuer projects only the eligible subset, the provider seam acquires and presents it, and the resource evaluates the concrete action under current policy.
Run backward from termination, a non-active task stops new projection at the task authority, and issuers must observe that state within a declared propagation bound. Outstanding credentials remain usable only inside their declared freshness bound. Higher-consequence actions can require a current-state check and fail closed. Completed effects are not undone. The evidence plane preserves which state and credential the resource evaluated when they occurred.
The invariant is the series’ conjunctive Permit rule, stated in full on the hub.
This is a decomposition of assurance, not an instruction to make every resource synchronously call five services. Evidence can be verified upstream, decisions can be cached within explicit bounds, and records can be projected into short-lived artifacts. The rule says only that optimization may change how a predicate is established, never erase the predicate.
Context and Memory Cross the Path. They Do Not Merge with It.
The company’s memory must be an enterprise record, but memory is not a fourth identity or authority record. The approved task and enterprise memory meet at a context compiler:
- The approved-task record states the undertaking’s exposure ceiling and durable-memory write rights.
- Enterprise memory, current documents, and live sources supply candidate context inside that ceiling.
- The context compiler produces a temporary, model-specific view and records why each source was exposed.
- Model and tool outcomes become candidate memory writes, not enterprise truth.
- A validation gate may accept, reject, supersede, or expire those candidates under memory policy.
The lifecycles stay separate. Ending a task should terminate its authority and future context access. It should not delete a canonical procedure that predated the task. Correcting institutional memory should change future contexts and invalidate derived indexes. It should not rewrite the historical record of what an earlier task saw.
The model router belongs on this adjacent plane too. It selects an execution supplier under cost, capability, latency, residency, and risk policy. It does not decide whose Agent is running, whether the undertaking remains approved, or whether a resource permits an effect. Supplier-neutral task state and canonical memory make re-compilation possible. The approved-task record makes the resulting exposure legitimate.
The Replacement Tests
Portability becomes concrete when the architecture names what survives a component change and what may be regenerated.
| Component replaced | State that must survive | State that may change or be regenerated |
|---|---|---|
| Runtime | Agent and Deployment records, approved-task state, canonical memory, and their evidence relationships | Instance identity, attestation, keys, and the mapping from new runtime evidence |
| Harness | Enterprise Agent records, approved work that outlives the session, canonical institutional memory, and action-to-task joins | Session identifiers, checkpoints, local plans, tool caches, and working context according to migration policy |
| Model supplier | Every governance record, canonical task state, source records, and accepted institutional memory | Model-specific prompts, compiled context, response caches, and routing decisions |
| Issuer or credential provider | Agent, Deployment, and approved-task records with their identifiers and lifecycle | Credentials, key material, audience projections, and provider-specific handles |
| Memory backend | Canonical memory identifiers, content, provenance, relationships, versions, status, and policy metadata | Embeddings, summaries, retrieval indexes, and caches |
Passing does not require exporting every byte or preserving every ephemeral representation. It requires semantic continuity: after the replacement, the enterprise can still say what each durable record meant, who governed it, what superseded it, and which actions relied on it.
Use the Stack in an Architecture Review
The series’ Buyer’s Floor is the procurement baseline. This capstone turns it into a review sequence:
- Name the authority for every durable object. Identify the system authoritative for Agent, Deployment, approved task, canonical memory, resource policy, and evidence retention. “The platform” is not a sufficient answer.
- Trace one consequential action in both directions. Starting from the effect, recover the resource decision, credential, approved task, Agent and Deployment, runtime evidence, and relevant context sources. Starting from task termination, show where new projection and execution stop.
- State every freshness bound. Token lifetime, status caching, policy propagation, retry behavior, and fail-closed rules determine the real revocation window.
- Test admission, not only export. Can the runtime, issuer, harness, and resource accept evidence or records they did not mint? Export lets a product explain its past. Admission lets an enterprise change its future control path.
- Exercise a denial. Distinguish terminal denial, requestable denial, step-up, and defer. Verify that remediation causes a fresh resource evaluation rather than converting an approval into a bypass.
- Run one replacement from the table. A migration document is weaker evidence than a working cutover that preserves identifiers, lifecycle, provenance, policy, and audit joins.
- Guard the memory write path. No unmarked route should exist from model output to canonical enterprise truth.
This review will expose a bundle as well as a layered design. A bundle is not a failure if its internal predicates remain explicit, its lifecycle behavior is sound, and the buyer accepts its replacement cost. A layered architecture is not a success if adapters export state while the incumbent remains the only party whose evidence, identity, or authority anyone will accept.
Where the Contest Remains Open
The provider seam has useful fragments but no general interface that composes credential mechanisms, custody, provider choice, and policy across agent environments. The identity-binding market has runtime-shaped, directory-shaped, and provider-shaped positions, but the decisive test remains whether an Agent record can survive a runtime migration. Approved work has transport ingredients and many private implementations, but no general system of record for the undertaking whose lifecycle governs authority. Memory has customer-controlled storage options, but semantic portability is much harder than moving documents or embeddings.
Those gaps need not close as one standard or one database. Interfaces, lifecycle APIs, event relationships, task-bound credentials, and portable records may standardize separately. Heterogeneity supplies pressure for a stable contract among them. It does not guarantee the market will choose one.
One disclosure belongs beside that claim. Where the series names a candidate form for the approved-task record, the Mission draft, it is my proposal. The stack does not depend on that form winning. It depends on the responsibilities being explicit and on some authoritative representation of approved work surviving the session, credential, and vendor that first touched it.
The Stack Is the Set of Non-Substitutions
The enterprise agent control stack is not a new monolithic control plane to buy. It is an agreement about which facts survive, who may change them, which projections can carry them, and where each action still stops for a local decision.
Runtime evidence identifies the instance. Binding names the Agent. Approved work limits the purpose. Credentials carry a projection. The resource decides. Audit proves the joins. Memory survives the suppliers.