Something important is changing underneath AI agents. For the first few years of generative AI, infrastructure was mostly organized around models and inference. Which GPU should serve a request? Which model should handle it? How should requests be batched and routed? Agents create a different kind of workload.
Give an agent an objective and it may reason for an hour, call several models, invoke MCP servers, create processes, delegate work to other agents, suspend while waiting for results, and resume later. What begins as one user request can quickly become an entire tree of autonomous execution.
Infrastructure is beginning to adapt. Docker is building dedicated sandboxes for agents. Google’s Agent Substrate is designed around actors that can be created, suspended, resumed, and moved across ready compute, with secure runtimes such as Kata providing strong isolation underneath them. These are important developments. They give agents safe places to run. But they also expose the next question:
What exactly are we trying to contain?
We think the answer is increasingly not the process, or even the agent. It is the objective.
One objective can become many agents
Imagine asking an enterprise agent to investigate why quarterly revenue missed the forecast and prepare a board-ready report.
The primary agent might query financial data through MCP, delegate product analysis to a research agent, ask another agent to generate visualizations, use several models along the way, and execute code inside isolated environments. Some agents may exist for seconds. Others may suspend and resume hours later.
Every infrastructure layer sees its piece correctly. Agent Substrate sees actors. Kata sees isolated workloads. The inference layer sees model requests. MCP gateways see tool calls. GPU infrastructure sees compute. The operating system sees processes and sockets.
But the actual workload is still the objective the user started with:
Investigate why quarterly revenue missed the forecast and prepare a board-ready report.
That objective has properties that survive every individual agent. It has a budget. It has an authority boundary. It has data restrictions. It has a delegation lineage. It has a lifetime.
Today, those properties are scattered across the stack. The path we use is: human purpose becomes an operational objective, or intent; the Intent Container represents that objective at runtime; plans, Actors, and actions realize it.
We think the objective itself should become a runtime object.
Introducing the Intent Container
We call that object an Intent Container. An Intent Container is the runtime representation of an autonomous objective, including its current authority, constraints, execution lineage, delegation state, and lifecycle. It is not another VM or Linux container, and it does not replace an agent runtime, Docker Sandboxes, or Kata. Those technologies isolate execution. An Intent Container isolates the objective and its authority.
When an agent begins working, the objective creates the container. Actors, model sessions, delegated agents, MCP connections, and eventually processes created on its behalf remain connected to the same objective lineage even when physical execution moves between Google Agent Substrate, AWS AgentCore, Microsoft agent runtimes, Kubernetes or Lynx, SaaS services, and local environments.
That changes a surprisingly basic question. Instead of asking which agents are running, infrastructure can ask:
Which objectives are running, and what are they currently authorized to do?
This becomes particularly important during delegation. A visualization agent created by our revenue-analysis agent should not automatically inherit access to raw financial records merely because its parent had that access. Its authority should derive from the narrower objective it was created to perform.
That is already a core principle in our Purpose Assurance Plane work: agents should be free to refine their plans, but refinement should not silently expand authority. Our Intent Assurance Plane then cryptographically commits the accepted plan and maintains its lineage as execution evolves, delegates, re-anchors, or is revoked.
The Intent Container gives those guarantees a runtime home.
Agent Substrate gives us the first runtime on which to demonstrate it
This is where the idea gets practical. Google’s Agent Substrate gives our first reference implementation much of the Actor lifecycle machinery it needs. It manages where and when Actors execute, while Kata and microVMs provide isolation underneath them. That makes it the first intentd runtime adapter, not an assumption built into the Intent Container architecture. That lets intentd, the Intent Container runtime we are building, focus on a different question:
Why does this actor exist, and what authority follows from that objective?
But maintaining objective lineage in a control plane only gets us so far. Eventually an agent’s decisions become real execution. A process starts. A file is opened. A network connection is made. A subprocess is created. At that point, the objective needs an enforcement mechanism at the same layer where those effects actually occur.
In our first implementation, that is the role of the Kernel Assurance Plane, or KAP. KAP is our reference intent-aware Linux enforcement backend. intentd carries the current Intent Container authority to it, and KAP binds that authority to the processes executing on the objective’s behalf. Instead of relying on the agent to decide whether an operation remains appropriate, KAP can enforce the boundary when execution reaches files, sockets, processes, descriptors, and other kernel-visible resources. Other runtimes and policy enforcement points can consume the same Intent Container authority at their own boundaries. We provided a sneak preview in one of our previous posts.
Our first intentd reference implementation brings these pieces together using Google Agent Substrate with a Kata microVM running a KAP-enabled Linux guest kernel. Before an Actor begins executing, it is bound to the objective lineage and authority committed through ArmorIQ.
The agent remains free to reason probabilistically. It can change its approach, delegate work, and create subprocesses. But when those decisions become execution, KAP provides a deterministic boundary. An action inside the committed authority succeeds. An execution outside it is denied at the kernel. That is where intent stops being metadata and becomes an execution boundary.
The strange case of an agent waking up with yesterday’s authority
Suspend and resume revealed why this abstraction matters more than we initially expected. Suppose an agent is running under an authorized objective and is checkpointed. While it sleeps, the user revokes that authority. Later, someone restores the old checkpoint. The Actor is legitimate. The VM is legitimate. The snapshot is legitimate. But the authority inside the snapshot is stale.
Because a microVM snapshot can restore kernel memory, blindly restoring it could also restore the authority that existed when the checkpoint was created. An Intent Container gives us a different source of truth. Before the Actor resumes, intentd reasserts the current objective state. If the restored Actor carries authority older than the current objective, it cannot resume with that authority. The old snapshot cannot resurrect a revoked objective. We like the resulting invariant:
Execution state can travel backward in time. Authority cannot.
This is difficult to express if authority belongs only to a process, workload identity, or VM. It becomes natural once authority belongs to the objective lineage. We are putting the Google Agent Substrate, Kata, IAP, intentd, and KAP pieces together now as our first reference implementation. The upcoming demo will walk through the complete lifecycle:
Objective → Actor → intent binding → kernel enforcement → suspend → resume → revoke → stale restore rejection.
This post is the first in a series on Intent Containers and intentd. In the next few posts, we will go underneath the abstraction: how an objective becomes cryptographically committed authority, how that authority is carried into an Agent Substrate Actor, how KAP enforces it inside the guest kernel, and why checkpoint and restore creates a surprisingly difficult problem for revocation. We will also publish the end-to-end demo as the prototype comes together.
We gave an early preview of the kernel side in our earlier Kernel Assurance Plane post. KAP asks how intent-derived authority can survive all the way to operating-system execution, where an agent’s decisions finally become processes, files, network connections, descriptors, and syscalls. intentd extends that work in an important direction.
KAP binds execution to authority. The Intent Container gives that authority an objective-level identity and lifecycle.
There is considerably more underneath that statement than we have covered here. That is intentional. We’ll unpack objective-to-Actor binding, IAP lineage, authority epochs, the KAP guest kernel, delegation, suspend and resume semantics, stale-snapshot protection, and the Agent Substrate integration individually rather than compressing them into one giant architecture post. For now, the idea we want to put into the world is simpler:
The sandbox should contain the Actor. The Intent Container should contain why the Actor exists.
Great read! Containers will be key in safeguarding.