TL;DR
The components of an AI agent are well understood. The machinery for managing their lifecycle, governing their behaviour, and auditing their actions is not. This is the gap that will define enterprise AI adoption and it needs a standard before it needs more frameworks.
The Promise and the Operational Reality
When organisations talk about deploying AI agents, they typically focus on two things: what the agent can do, and how accurate it is. These are reasonable concerns in a proof-of-concept setting. They are insufficient concerns in a production setting.
The operational questions that actually matter (who authorized this capability, which version of this skill ran, what data did this hook touch, who can revoke this plugin, how do I roll back this behaviour without redeploying the whole system) have no satisfying answers in any major agent framework today. Not because the frameworks are bad. Because no one has yet built the layer those answers require.
That layer does not exist. This essay argues that it must, that we can describe its architecture with reasonable precision, and that the history of software infrastructure gives us a clear map of how it will emerge, if we are deliberate about building it.
What an Agent Actually Is
An AI agent is not an LLM. It is a system built around an LLM, composed of at least five distinct categories of components that the current discourse regularly collapses into one.
- The LLM is the reasoning core: a model that reads token sequences and generates continuations. On its own it has no memory, no agency, no side effects. It is stateless and passive.
- The prompt is the instruction layer: a system-level text fragment injected at the start of every inference call that defines persona, constraints, output format, and operational rules. It is the agent’s constitution.
- The context window is working memory. Everything the model can attend to in a single inference (system prompt, conversation history, retrieved documents, tool results) lives here. It is finite, and what gets loaded into it is a consequential engineering decision.
- Tools and plugins are the agent’s actuators. A tool is a typed function the LLM can invoke — web search, code execution, database query, API call. A plugin is a curated bundle of related tools distributed as a unit. When the model outputs a tool call, the framework executes it and feeds results back into the context.
- Hooks are event-driven interceptors. They fire at specific moments in the agent’s execution cycle — before an LLM call, after a tool result, when a content policy condition is met — and can inspect, modify, log, or abort the flow. Guardrails live here. Observability lives here. Compliance controls live here.
- Skills sit above all of this: reusable, composed capabilities that bundle prompt fragments, tool definitions, and hook registrations into a single callable unit. A “research” skill might orchestrate three web searches, a summarisation pass, and a structured extraction step. A “data analysis” skill might spin up a code interpreter, execute transformations, and return a typed result.
The insight that current practice has not caught up with is this: a prompt fragment, a tool definition, and a hook registration are not three things. They are one thing — a capability — and they need to be managed together.
The Gap
In today’s agent implementations, these components are distributed across whatever happens to be convenient. System prompts live in database rows or environment variables. Tool definitions are Python class methods decorated with metadata. Hooks are registered imperatively in initialisation code. Skills are documented in README files, if at all.
The result is that there is no unit (no package, no artifact, no manifest) that represents “this capability as deployed.” There is nothing to version. There is nothing to sign. There is nothing to revoke. There is nothing to audit at the capability level rather than the log line level.
This has three compounding consequences.
1. Lifecycle Management Is Impossible in Any Coherent Sense
You cannot upgrade a skill independently of the agent that uses it, because the skill has no independent existence. You cannot canary-deploy a new version of a plugin, because the plugin is not a deployable artifact. You cannot roll back a hook registration without redeploying the service it lives in. The capability bundle has no seam along which you can apply operational control.
2. Governance Has No Surface to Attach To
Governance requires objects, things that can be approved, version-pinned, audited, and revoked. In current agent architectures, the closest object is the entire agent deployment. That is far too coarse. A compliance team that wants to approve the addition of an email-sending capability to an agent currently has no choice but to review a pull request.
There is no capability manifest to sign off on, no registry entry to approve, no permission scope to grant. The governance surface is the source code. That is not a governance surface; it is an absence of one.
3. Accountability Chains Break at Inference Time
When an agent takes an action (sends a message, executes a query, modifies a record) the audit trail typically records what happened at the tool-call level.
What it does not record, in any structured and queryable form, is: which skill triggered this tool call, which version of that skill was active, which hook had the opportunity to veto it and did not, who authorised this capability to exist in this agent, and against which data classification policy it was evaluated.
Without this chain, post-incident accountability is archaeology. You reconstruct what happened from log fragments rather than reading from a structured provenance record.
A Technology Lifecycle in Three Phases
This situation is not novel. Software infrastructure has passed through this exact pattern (abundant capability, absent governance) at least three times in recent memory. Locating agent capability management in that history is clarifying.
Phase One: The Library Era (npm, pip, Maven)
When package managers emerged, the central problem was dependency resolution and reuse. npm (2009), pip, and Maven solved the question of “how do I use code someone else wrote without copying it into my project?” They introduced the package as a first-class artifact: versioned, declared, resolvable.
The governance they offered was minimal (a package.json is a statement of intent, not an enforcement mechanism) but that was appropriate to the problem. The primary risk of a bad npm package was a broken build, not a compliance violation.
The agent ecosystem has not yet reached this phase for capabilities. There is no canonical artifact format. There is no registry. There are no semantic version contracts. Most skills are not packages at all; they are patterns in a codebase.
Phase Two: The Container Era (Docker, OCI)
Docker (2013) changed the unit of deployment. The image became a versioned, signed, immutable artifact that bundled runtime, dependencies, and configuration. Critically, it separated the lifecycle of what you deploy from the lifecycle of the infrastructure it runs on. You could now version your application independently of the operating system, promote the same artifact through environments, and roll it back with surgical precision.
The governance story improved substantially: image signing, vulnerability scanning on the artifact, and content trust gave operators a hook before deployment rather than after the fact. The OCI specification turned what Docker pioneered into a vendor-neutral standard.
Agent capability bundles need exactly this: an immutable, signed artifact that can be promoted through environments, scanned for policy compliance before activation, and rolled back without touching the broader system. The analogy is direct. A capability bundle is to an agent what a container image is to a service, the deployable unit that carries its own identity and version.
Phase Three: The Operator Era (Kubernetes, OPA, service mesh)
Kubernetes did not just orchestrate containers. Through the operator pattern and the admission controller mechanism, it introduced policy as a first-class runtime concern. An admission controller can veto a deployment before it reaches the scheduler. Open Policy Agent (OPA) can evaluate arbitrary policy against any Kubernetes resource at admission time. The service mesh (Istio, Linkerd) extended this to the request level: every service-to-service call could be evaluated against policy, authenticated, and traced.
This is the phase that matters most to the governance and accountability problem. The operator era established that runtime policy enforcement is infrastructure, not application code. You do not ask every application developer to implement their own authorisation logic; you enforce it at the platform level, consistently, before the call is made.
Agent capability governance requires the same architectural move. The policy layer cannot live inside individual agent implementations. It must be infrastructure that every agent runs against, enforced at the moment a capability is activated or a tool is invoked, not logged after the fact.
Where Are AI Agents on This Curve?
Where Are AI Agents on This Curve?
They have not yet reached Phase One. There is no canonical artifact format for a capability bundle. A skill is not a package you can reference by name and version from a registry. A hook registration is not something you can pin, sign, or revoke. A prompt fragment is not versioned independently of the agent that uses it. The components exist (in abundance) but they have no unified identity as a deployable, addressable thing. That is precisely what Phase One gives you, and it is absent.
This is worth stating plainly, because the ecosystem contains gestures across all three phases that can be mistaken for the real thing, and the gap between a gesture and a standard is precisely what this section needs to establish.
The artifact gesture
Toward Phase One, LangChain Hub is a gesture at a registry, and the early OpenAI plugin manifest was a rough analog to a package descriptor. Some teams version prompt templates in git with semantic tags. The idea of a capability as a nameable, versioned, shareable thing exists in the discourse. It has not congealed into an artifact format.
The versioning gesture
Toward Phase Two, tools like LangSmith and LangFuse offer prompt versioning and deployment tracking. These are genuinely useful. You can store named versions of a prompt, compare outputs across versions, and promote a version to production. But prompt versioning is not capability versioning. A prompt string is one component of a capability bundle. The tool definitions, hook registrations, and permission scopes that travel with that prompt are not part of the versioned artifact, they remain scattered across application code.
More critically, the version lives inside the observability tool’s data model, not inside a deployable artifact that carries its own provenance at runtime. When the agent executes, it has no way to assert “I am running capability bundle v1.4.2, signed by this key, approved by this person.” The version is a label in a dashboard, not a property of the executing system.
The governance gesture
Toward Phase Three, a cluster of tools addresses runtime safety: Guardrails AI, NVIDIA NeMo Guardrails, Azure AI Content Safety, and AWS Bedrock Guardrails all provide mechanisms for intercepting and filtering agent behaviour. LangSmith and LangFuse provide tracing. These are the most mature gestures in the ecosystem. But they share a structural limitation: they are per-application integrations, not platform-level enforcement. They live inside your agent’s code, or are called by it, which means every team that builds an agent must integrate them independently. Coverage is a function of developer discipline rather than architectural constraint. There is no central policy authority, no shared schema, and no mechanism by which a compliance team can verify that a given agent is actually running the guardrails it is supposed to be running without inspecting the source code.
The deepest problem, however, is not any individual tool’s limitations. It is that none of these systems share a common object. The prompt version in LangSmith has no formal relationship to the guardrail configuration in Guardrails AI, which has no relationship to the tool definition in the agent code. There is no capability bundle that ties them together.
Each tool gives you a fragment of an answer. The fragment cannot be assembled into a whole because the whole (the capability as a unified, versioned artifact) does not exist.
The practical consequence is that skipping or poorly resolving Phase One makes Phase Three significantly harder to build. Kubernetes works because OCI images were a solid, vendor-neutral artifact format first. If the container image format had fragmented across incompatible implementations, orchestration and policy enforcement would have had nothing stable to operate on.
The same dependency holds here: a registry, a runtime enforcer, and an audit bus can only be built around a capability artifact that has a stable, agreed-upon shape. The standard must be established at Phase One before the governance infrastructure of Phase Three can be built on top of it.
The frameworks that dominate today (LangChain, LlamaIndex, CrewAI, AutoGen) have solved real composition problems, but without resolving this dependency, each one is an island. Governance built on top of any single framework is not infrastructure; it is a vendor relationship.
What the Architecture Needs to Look Like
The solution is not a new framework. Frameworks have proliferated; the problem has not diminished. The solution is a standard, a set of specifications that any framework can implement and any enterprise can require. That standard needs five components.
1. A Capability Manifest
A structured, declarative document that specifies, for a given capability bundle: the prompt fragments it injects and their scope, the tool signatures it exposes and the permissions they require, the hooks it registers and the lifecycle events they fire on, the data classifications it is permitted to access, and its compatibility constraints against agent runtime versions. The manifest is the unit of governance. You approve a manifest. You sign a manifest.
2. A Registry With Cryptographic Provenance
A content-addressed store where capability bundles are published, versioned, and signed — analogous to a container registry, but with an additional provenance chain that records who published this version, who approved it, and against which policy it was evaluated. Revocation must be a first-class operation: when a capability is found to be unsafe or non-compliant, the registry must be able to mark it unacceptable and propagate that signal to every runtime that has loaded it.
3. A Capability Runtime With Manifest Enforcement
The component that loads capability bundles into a running agent must enforce that the bundle can only do what its manifest declares. A capability that declares read access to a document store must not be able to write to it. A hook registration must be bounded by the lifecycle events the manifest names. This is not about trust — it is about the difference between stated intent and runtime behaviour being the same thing, verifiably. Without enforcement, the manifest is documentation. With enforcement, it is a contract.
4. A Structured Audit Bus
Every significant event in the agent’s execution cycle (LLM call, tool invocation, hook firing, context injection) must emit a structured event that includes: the capability bundle version responsible, the authorising identity, the data classification of inputs and outputs, and the policy evaluation result.
This is not logging. Logging is for debugging. An audit bus is for accountability: it must be queryable, tamper-evident, and structured enough that a compliance query (“show me every time capability X accessed data classified Y in the last 30 days”) returns a precise answer rather than requiring log archaeology.
5. A Policy Sidecar
A runtime component, decoupled from the agent’s application code, that evaluates whether a capability is permitted to run given the current execution context. The policy language should be capable of expressing: who is the end user, what is their authorisation level, what data classification is in context, what is the risk tier of the requested tool, and is the capability version still on the approved list. This is the admission controller for agents. It runs before the tool executes, not after.
Why This Matters Now
The argument for deferring this problem is always the same: it is early, the ecosystem is moving fast, standards imposed too soon calcify the wrong abstractions. This argument was correct in 2013 for containers. It is less obviously correct today for agent capabilities, for two reasons.
First, the risk profile of agents is qualitatively different from the risk profile of earlier infrastructure primitives. A misconfigured container crashes a service. A misconfigured agent capability — a hook that fails to apply a content filter, a tool that operates outside its intended scope, a skill that exposes data to an LLM context it was never meant to reach — can produce consequential real-world actions before anyone notices. The asymmetry between the speed of deployment and the speed of detection is larger, and the harm is less reversible.
Second, enterprise adoption is happening now, not in three years. Organisations are deploying agents into workflows that touch customer data, financial records, and internal communications. They are doing this without a capability governance layer because none exists. The absence of a standard does not delay enterprise adoption; it means enterprise adoption happens without the accountability infrastructure that should accompany it. That is a worse outcome than a standard that gets some abstractions slightly wrong.
An Invitation
The components of this architecture are not speculative. The manifest format, the registry protocol, the runtime enforcement model, the audit schema — each of these has clear analogues in existing, battle-tested infrastructure. The intellectual work is not inventing new primitives. It is carefully composing existing ones for a new execution model, then socialising that composition as a standard that framework authors and enterprises can both implement.
That work requires people who understand both the operational requirements of enterprise AI governance and the architectural constraints of agent runtimes. It requires framework maintainers, platform engineers, compliance architects, and the researchers who understand what agent execution models actually need.
The question is not whether this standard will exist. The question is whether it will be designed deliberately, in the open, with input from the communities that will live with it — or whether it will be defined implicitly, by the choices of whichever vendor achieves sufficient market share first.
The moment to have that conversation is before the second outcome becomes inevitable.
Bottom Line
- What are the governance requirements your organisation is currently trying to solve without the right tools?
- What should a capability manifest actually contain?
- Where does this architectural sketch need revision? This is a conversation that needs more voices in it.
