OCapN and Structural Authority in Agentic AI
How capability-based architectures help reason about authority, delegation, and safety in autonomous systems
Agentic AI systems are evolving rapidly. What started as experimental patterns only a short time ago are now increasingly being discussed as production-grade architectural approaches, with real implications for cost, risk, and organizational responsibility. Looking toward 2026, it is becoming increasingly clear that agentic AI will not remain a niche topic, but a core concern for teams building complex, autonomous systems.
Over the past months, I have been spending time exploring different architectural approaches for agentic AI systems, both in theory and in practice. One recurring theme across these explorations is that autonomy changes the nature of architectural responsibility. As systems gain the ability to plan, decide, delegate, and act with limited human oversight, architectural decisions begin to shape not only system behavior, but also authority, control, and accountability.
In traditional software systems, architecture typically focuses on scalability, availability, performance, and perimeter-oriented security concerns. Authority and permission are usually handled through external mechanisms such as identity, roles, centralized policies, and runtime checks. These approaches have proven effective for systems with well-defined boundaries and predictable execution paths.
Agentic AI systems operate under different assumptions. Agents are long-lived, operate asynchronously, interact with multiple internal and external systems, and may delegate work to other agents or tools. In such environments, authority is no longer a static configuration detail. Architectural decisions increasingly influence how authority is granted, transferred, limited, and contained across the system.
This raises a fundamental question: if agents are expected to act autonomously, coordinate with other agents, and operate safely over time, how should authority be modeled and enforced at the architectural level?
Why Agentic AI Requires Structural Authority
Agentic AI systems differ from traditional software not only in how they execute tasks, but in how authority is exercised over time. An agent may initiate actions, invoke tools, coordinate with other agents, or delegate responsibilities without a direct request-response cycle or immediate human supervision. In such systems, authority is exercised continuously, often implicitly, and across asynchronous boundaries.
When authority is not modeled explicitly at the architectural level, it tends to emerge indirectly through configuration, shared context, or accumulated permissions. This implicit authority is difficult to reason about, hard to audit, and even harder to revoke safely. Over time, basic questions, such as what an agent is allowed to do, on whose behalf it acts, and how far its authority extends become increasingly difficult to answer with confidence.
For agentic systems that are expected to operate reliably, safely, and at scale, authority cannot remain an accidental byproduct of implementation details. It needs to be constrained, delegated, and enforced through structure rather than convention.
Object-Capability Networking (OCapN)
Object-Capability Networking (OCapN) is an architectural approach that treats authority as a first-class concern. Instead of relying on global identities, roles, or ambient permissions, OCapN represents authority explicitly through capabilities. A capability is both a reference and an authorization: possessing a reference to an object implies the authority to invoke the operations it exposes.
In OCapN-based systems, there is no implicit authority. An entity can only act if it holds the specific capability required to do so. Authority is transferred explicitly by passing capabilities, and it can be limited by passing attenuated capabilities that expose only a subset of functionality.
OCapN also assumes asynchronous, message-oriented communication. Interactions between parties occur through eventual message delivery and promise-based results, rather than synchronous blocking calls. This communication model aligns naturally with distributed and autonomous systems.
Modeling Agents as Vats
In the OCapN model, a vat represents an isolated unit of computation with its own event loop and object graph. Objects within a vat can communicate synchronously, while communication across vats is asynchronous and capability-based.
In the context of agentic AI, mapping one vat to one agent emerges as a natural and effective design choice. Each agent operates within its own isolated vat, maintaining internal state, reasoning processes, and workflows. Objects inside the vat represent internal components of the agent, such as planners, memory modules, or tool adapters, connected through explicit internal workflows.
Isolation between agents is enforced structurally. An agent cannot access another agent’s internal state unless it has been explicitly granted a capability to do so. This containment model limits blast radius and makes inter-agent interactions explicit and auditable.
Capabilities as the Basis of Agent Authority
In OCapN-based systems, authority tends to shift from configuration and policy into the architecture itself. Capabilities define not only what an agent can do, but also the boundaries within which it can operate.
An agent’s external capabilities are defined at creation time. These capabilities represent the actions the agent is allowed to perform in the broader system, such as accessing specific services, invoking tools, or interacting with other agents. Internally, the agent may further delegate or attenuate these capabilities as part of its workflows.
Because capabilities must be explicitly passed, there is no hidden or ambient permission. Every action can be traced back to a specific capability, making authority explicit and inspectable.
Delegation and Authority Transfer
Delegation is a core requirement in agentic systems. Agents often need to offload tasks, coordinate work, or request assistance from other agents. In OCapN, delegation is performed by passing capabilities.
This model makes delegation explicit and intentional. An agent cannot delegate more authority than it possesses, and it can choose to delegate a restricted form of its authority by passing an attenuated capability. This ensures that delegation does not unintentionally expand the overall authority surface of the system.
Delegation paths are visible in the system’s structure, making it easier to reason about trust relationships and responsibility boundaries.
Asynchronous Communication and Promises
OCapN relies on asynchronous message passing and promises for handling results. When an agent sends a message, it does not block waiting for a response. Instead, it receives a promise that will eventually be resolved.
This model aligns well with AI-driven reasoning and execution loops, where actions may involve long-running computations, external API calls, or human-in-the-loop interactions. Asynchronous communication allows agents to remain responsive while managing complex workflows.
It also avoids tight coupling between agents, reducing failure propagation and improving system resilience.
Security Characteristics
OCapN-based architectures provide several security properties by construction. Authority is explicit, least privilege can be enforced through capability attenuation, and isolation boundaries are structural rather than policy-driven.
This can reduce reliance on some classes of runtime checks and external policy engines by embedding authority constraints directly into system structure. However, OCapN does not eliminate the need for broader security controls such as monitoring, auditing, and organizational governance.
Security in this model is not centralized but distributed across the system’s topology of capabilities.
Developer Experience and Operational Impact
OCapN prioritizes correctness and clarity, often at the expense of short-term convenience. Developers must think explicitly about authority, delegation, and isolation when designing systems.
This explicitness can increase initial development effort and requires a shift in mindset, particularly for teams accustomed to identity-centric or policy-heavy security models. Tooling and ecosystem support are also less mature compared to mainstream cloud-native approaches.
Operationally, OCapN requires architectural commitment and a long-term perspective. Debugging, observability, and incident response practices must adapt to a capability-based mental model.
Pros and Cons of Using OCapN for Agentic AI
Advantages
Explicit authority modeling improves reasoning about agent behavior
Structural isolation limits blast radius
Delegation is intentional and auditable
Aligns well with asynchronous and autonomous execution models
Limitations
Steep learning curve for most engineering teams
Limited industry adoption and tooling maturity
Requires architectural buy-in rather than incremental adoption
I was introduced to OCapN through the work of the Spritely Institute’s Goblins project.
https://spritely.institute/goblins/
The project provided valuable insights into object-capability systems and their practical implications.
you can also refer here: https://ocapn.org
Conclusion
OCapN offers a clear and principled foundation for teams that choose to model authority explicitly in agentic AI architectures. It is not a universal solution, nor is it a lightweight addition to existing systems. Adopting OCapN requires deliberate architectural choices, a shift in how authority is reasoned about, and a willingness to accept trade-offs in tooling maturity and developer experience.
At the same time, OCapN does not address all challenges of agentic AI architectures equally well. Concerns such as performance characteristics, operational complexity, observability, and ecosystem maturity remain significant and require careful consideration. In practice, adopting OCapN often shifts complexity rather than eliminating it, moving certain concerns from runtime policy and infrastructure into architectural design and developer responsibility.
From my perspective, the value of OCapN lies less in any single technical mechanism and more in the discipline it enforces. By treating authority as a structural concern, it provides a way to reason about autonomy, delegation, and containment in systems where traditional assumptions no longer hold.
In a follow-up article, I plan to explore how OCapN principles might be interpreted and applied within cloud-native environments. In particular, I want to look at how ideas such as structural authority and explicit delegation can be expressed using existing infrastructure, tooling, and operational practices. That exploration is less about replacing current platforms, and more about understanding how these principles can inform the next generation of agentic system design.