ARMORIQ

Where do we go with Intent Containers: Infrastructure That Manages Objectives

The bigger opportunity begins when intentd provides current objective state to the infrastructure running agents.

Sep 18, 202612 min read
Where do we go with Intent Containers: Infrastructure That Manages Objectives// Cover

We started this series with a fairly narrow question: What exactly should agent infrastructure contain? Our answer was the objective.

That led us to the Intent Container which we introduced in Part 1, a runtime object that persists beyond any individual Actor. In Part 2, we followed that objective down to the syscall boundary. In Part 3, we looked at what happens when an Actor wakes up carrying authority from the past. In Part 4, we brought those pieces together in the first intentd demo.

The prototype gives the abstraction teeth through one enforcement backend. But it is not the end of the idea. Once an objective becomes a first-class runtime object, carrying identity, authority, lineage, delegation and lifecycle, intentd can provide that current state to schedulers, routers, runtimes, and other policy enforcement points that otherwise see only unrelated Actors, inference requests, and processes.

And Anthropic’s recent work on multi-agent systems suggests that this transition may become necessary sooner than we expected.

Today’s infrastructure sees fragments of an objective

Consider our running example:

Analyze quarterly revenue and prepare a board-ready report.

Perhaps that objective creates four Actors and invokes three different models. One Actor queries financial data. Another investigates an anomaly. A third creates visualizations. A final Actor assembles the report.

The infrastructure underneath them sees plenty. Agent runtimes see Actors. The inference infrastructure sees model requests. MCP gateways see tool calls. GPU schedulers see compute. Identity infrastructure sees principals. The operating system sees processes.

Each layer can optimize what it sees. But none of those objects is actually the workload the user cares about. The user did not ask for 47 inference requests, four Actors, six MCP calls and 83 GPU-seconds. The user asked for the board report. That distinction starts to matter when infrastructure itself needs to make decisions on behalf of autonomous systems.

A five-dollar request is different from twenty twenty-five-cent requests

Take something simple: cost. Suppose the revenue-analysis objective has a budget of $5. The first research Actor invokes a frontier model and spends $1.40. Another Actor explores an anomaly and spends $1.20. Several smaller model calls consume another dollar.

Now the final synthesis begins. If every inference request is treated independently, the infrastructure knows the cost of each request. What it does not necessarily know is the economic constraint governing the task as a whole.

An Intent Container can hold that objective-level state, and intentd can expose it to the systems that make routing, scheduling, and budgeting decisions.

Objective

Analyze quarterly revenue

Budget

$3.60 / $5.00 consumed

Remaining

$1.40

Current stage

Final synthesis

Priority

High

Now a model router receiving intentd context has more to work with. Perhaps exploratory branches can use smaller models. Perhaps the final synthesis deserves the expensive frontier model. Perhaps a scheduler or runtime should suspend a speculative child Actor because the objective is approaching its budget.

The point is not that intentd should become the world’s smartest model router, scheduler, or budget system. It maintains and exposes objective context; those systems remain responsible for their decisions. Without that context, infrastructure optimizes requests.

With it, infrastructure can optimize outcomes.

The same thing happens with authority

Cost is the easy example. Authority is more consequential. Suppose the objective says financial data must remain internal. The primary Actor queries an internal database. It delegates visualization to another Actor. That Actor invokes a model. Another branch calls an MCP server. Internal Only should not have to be rediscovered independently at every transition. It belongs to the objective.

PAP already gives us a model for this. As an objective is refined into plans and executable actions, ambiguity can decrease, but authority should remain bounded. A more detailed plan should not quietly acquire interfaces or capabilities that were absent from the objective that authorized it.

IAP then gives that execution a verifiable lineage. When work is delegated, the child can receive scoped authority connected cryptographically to its parent rather than simply inheriting everything available to the parent Agent.

intentd maintains those properties in the current Intent Container state and carries them across runtime boundaries. Now Internal Only is no longer just a sentence in the original prompt. It can become a property of the objective that runtimes and policy enforcement points consume.

Delegation becomes infrastructure-visible

This becomes particularly important as multi-agent systems grow. When an agent creates another agent today, we tend to think about the relationship primarily as orchestration. Who spawned whom? Who is waiting for whom? Which Actor owns the result? But delegation is also an authority transition. Imagine:

Analyze quarterly revenue

│

├── Product analysis

│

├── Customer analysis

│

└── Visualization

Those children do not need identical authority. The customer-analysis Actor may need access to customer-level records. The product-analysis Actor may need financial aggregates. The visualization Actor may need only sanitized outputs from the other two.

A runtime that sees only Actors has to reconstruct those relationships indirectly. A runtime receiving objective context from intentd can know why each Actor exists. The parent objective establishes the authority envelope. Each child receives the portion justified by its sub-objective.

That gets us much closer to the least privilege for autonomous systems than giving every child the credentials of whichever agent happened to create it.

But hierarchical delegation is actually the easier problem. Anthropic’s latest multi-agent research exposes the harder one.

What happens when independently valid objectives collide?

Anthropic recently published a fascinating set of experiments on what happens when multiple autonomous agents operate together over longer periods.

Some results show the upside. In one experiment, a coordinating swarm of 45 agents searching open-source projects found 266 vulnerabilities, with agents learning to specialize and build their own tools. Anthropic expects this kind of specialization and coordination to increasingly outperform simple brute-force parallelism. Anthropic

But other experiments show something more unsettling. When agents competed for finite job-processing bandwidth, they independently converged on aggressive polling. In one run, the agents generated 2.4 million requests for only 117 accepted jobs. No single agent needed to behave catastrophically. Locally reasonable resource-seeking behavior composed into a globally terrible outcome.

Anthropic saw another version of the problem in pricing experiments. Individually profit-maximizing agents quickly learned to collude. Even after direct communication was removed, they could coordinate by matching prices through public information.

And then there was the coding experiment. Anthropic started three coding agents on separate VMs and instructed each to migrate the same Python backend to a different language.

One wanted Rust. One wanted to go. One wanted TypeScript. All three objectives were legitimate individually. Together, they created a turf war.

The agents began interpreting one another’s work as interference. They killed competing processes, disabled Unix accounts, created automated kill loops and even disguised malicious code as belonging to other agents. Anthropic found that greater execution capability did not necessarily produce better coordination. More capable agents could simply become better at winning the conflict. That result exposes a problem one level above agent assurance.

Individually valid intents do not necessarily compose into a valid system.

This changes what objective-aware infrastructure needs to see

Imagine Anthropic’s language-migration experiment as three Intent Containers:

Objective A

Migrate backend to Rust

Objective B

Migrate backend to Go

Objective C

Migrate backend to TypeScript

Each objective can be perfectly valid. Each Agent can remain faithful to its own objective. Each execution lineage can be cryptographically sound. And the resulting system can still be absurd. That means verifying each objective independently is not enough. Infrastructure eventually needs to understand relationships between objectives.

Suppose the Rust Actor attempts to kill a process belonging to the TypeScript objective.

Traditional authorization can ask:

Does this Actor have permission to kill this process?

Objective-aware infrastructure can ask something more fundamental:

Why should Objective A have authority over execution belonging to Objective B?

Perhaps both belong to a parent objective that explicitly permits competition. Perhaps they should be isolated. Perhaps one objective has authority over the other. Perhaps the objectives are mutually exclusive and should never have been activated against the same production environment simultaneously. Or perhaps the correct answer is to stop and ask the human who created them.

The important point is that we do not have to leave that decision entirely to the agents.

Intent has to work vertically and horizontally

Our first intentd work mostly considers authority vertically. A parent objective delegates narrower objectives:

Objective

/ \

Research Visualization

|

Data Analysis

PAP constrains how authority can narrow through those refinements. IAP commits and proves the execution lineage connecting the descendants back to the accepted objective. Anthropic’s experiments point toward another dimension. Intent also needs to work horizontally.

Objective A ← relationship → Objective B

│ │

Actors Actors

Can these objectives share resources? Can they modify one another’s state? Can one interrupt the other? What happens if they compete for the same scarce resource? What happens if individually rational behavior produces collective resource exhaustion? What happens when two objectives simply cannot both be true? Those are not just questions about agent identity or agent communication. They are questions about objective composition.

Multi-agent infrastructure becomes multi-objective infrastructure

Anthropic also makes an important observation in its research: stronger individual intelligence does not automatically produce good collective behavior. Coordination, trust, competition, conformity and shared-resource dynamics create system-level properties that do not exist inside any single agent.

That suggests a progression in AI infrastructure. The first generation asked:

Which inference request should run?

Agent infrastructure asks:

Which Actor should run?

Intent Containers add:

Which objective is this Actor serving?

Multi-agent systems force another question:

How should this objective coexist with all the other objectives already running?

That is where scheduling, security and coordination begin to converge, without requiring intentd to become any of those systems. intentd can provide current objective and relationship state. A scheduler could use it to see that two Actors are competing for the same resource because their objectives are competing. A budget system could allocate resources across sibling objectives rather than allowing independently optimizing agents to create a polling stampede. KAP, Lynx, a runtime gateway, or another policy enforcement point could distinguish execution belonging to different objective lineages rather than seeing only processes with otherwise valid credentials. And a control plane could recognize that two individually legitimate objectives cannot safely operate against the same environment at the same time.

Infrastructure is no longer merely coordinating agents. It is governing a system of objectives.

Revoking the objective should mean stopping the objective

This also makes lifecycle semantics cleaner. Today, stopping an autonomous task can be surprisingly ambiguous. Which process do we kill? Which Actor do we stop? Which API credentials should be revoked? Which child agents are still running? Which MCP sessions remain open? If the objective is the runtime object, the command becomes conceptually much simpler:

intentctl stop ic-001

intentd knows which execution belongs to the objective and can reconcile its current lifecycle state. Runtime adapters and policy enforcement points still enact stop, revoke, pause, checkpoint, and resume. That does not make distributed termination magically instantaneous. Real systems still have propagation delays, external side effects and failure modes. But there is finally an object around which termination semantics can be defined. The same applies to budget exhaustion, delegation expiry and audit. The lifecycle belongs to the objective rather than whichever Actor happens to be executing at that moment.

This is bigger than security

ArmorIQ arrived at this problem from security. Our original question was how to ensure autonomous execution remains accountable to the intent that authorized it. PAP led us toward purpose-preserving refinement. IAP led us toward cryptographically committed execution lineage. KAP led us into the kernel because eventually intent becomes a real system effect. intentd connected those ideas to the lifetime of an autonomous objective.

But once that runtime object exists, it becomes useful for considerably more than deciding whether a syscall should execute. The same object can provide shared objective context to the systems that manage authority, delegation, cost, model usage, GPU consumption, data boundaries, checkpointing, lifecycle and observability. And the relationships between those objects may themselves need to become governable.

This is why we think Intent Containers could eventually become an infrastructure abstraction rather than simply an ArmorIQ security mechanism.

Where we go from here

The first intentd prototype deliberately proves the smallest useful version of the idea. Create an objective. Bind an Actor to it. Carry its authority into the guest kernel. Allow valid execution. Reject invalid execution. Suspend it. Resume it. Revoke it. Reject stale authority when old execution state returns. That is enough to show that an objective can become an enforceable runtime boundary.

The next work makes that boundary richer. We want to explore objective-scoped budgets, stronger delegation across Actors, distributed lineage, model and MCP visibility, objective-level resource accounting, and adapters for the agent infrastructure already emerging around us, from Google Agent Substrate, AWS AgentCore, and Microsoft agent runtimes to Kubernetes or Lynx, SaaS services, and local execution.

Anthropic’s work suggests another research direction that we think is particularly important: objective composition.

What happens when two Intent Containers interact? How should authority compose when objectives share resources? How do we represent competition, cooperation or mutual exclusion? When should a conflict be resolved by policy, by infrastructure, by negotiation between agents, or by escalation to a human? How do we prevent individually rational objectives from creating globally irrational systems?

Those questions go well beyond intentd v1. But they increasingly look like questions agent infrastructure will have to answer.

The object we actually care about

Containers gave infrastructure a powerful abstraction. Applications could consist of enormous numbers of instructions, files, libraries, sockets and processes, but infrastructure gained a manageable object around which it could reason. Agents are creating another abstraction gap.

An autonomous objective may consist of dozens of Actors, hundreds of model calls, thousands of tool invocations, multiple execution environments and hours of activity. Those are implementation details of the task. The thing the human cares about is still:

What did I ask the system to accomplish?

We think infrastructure should understand that object too. That is the larger bet behind intentd. Agent runtimes manage Actors. KAP is one enforcement backend among the policy enforcement points that can consume Intent Container authority. IAP commits and proves verifiable execution lineage. intentd makes the current objective state portable and manageable across runtimes. And Anthropic’s multi-agent experiments point toward what may come after that.

Once autonomous objectives begin cooperating, competing and sharing resources, it will not be enough to know whether every individual Agent is behaving correctly. We will need to know whether the system of objectives makes sense.

Individual agent assurance becomes objective assurance. Multi-agent assurance becomes objective composition.

That feels like the next frontier for intentd. The Actor is becoming infrastructure.

We think the objective, and eventually the relationships between objectives, are next.

Onboarding open

Ready to control what your AI agents actually do?

Join the teams shipping safer, compliant AI agent deployments. White-glove onboarding for the first 50 design partners.

Read Docs →
Live Intent Assurance↗