A DI-style container for AI agent capabilities

I’ve recently been working on decoupling MCP-style agent tool calling from application code into a control plane. The goal was to make agent tooling infrastructure-managed rather than hardcoded into agent logic.

That part worked — but it exposed the next bottleneck.

Once tools live in a control plane, the real question becomes how agents receive the right capabilities at the right time, in a way that aligns with existing enterprise permissions.

Software has already solved an analogous problem.

Dependency Injection (DI) became standard because components shouldn’t construct their own dependencies. They declare what they need, and a container resolves and injects them. The result was looser coupling, testability, and composability. Today it’s invisible infrastructure.

AI agents still feel pre-DI.

Most agents operate with static permissions, hardcoded tools, or broad service accounts. Capabilities are embedded in the agent or environment rather than granted dynamically. This works for demos but breaks down in enterprise settings where governance and auditability matter.

The core insight is simple: authority should be injected the same way dependencies are injected.

Instead of treating an agent as an app with built-in permissions, treat it like a DI-managed component whose container is a runtime connected to an enterprise directory. The container doesn’t just wire objects — it wires capabilities derived from identity and policy.

I’ve been calling this pattern Capability Injection (CI).

In CI, agents don’t possess permissions. They declare the capabilities they need for a specific purpose. A governing layer — a realm — evaluates the request, resolves the human principal, checks policy, and injects a scoped, time-bound delegation token. The agent runs strictly within that scope and never holds standing privileges.

The earlier MCP decoupling moved tool execution into a control plane. CI completes the picture by injecting capabilities at runtime rather than baking them into code or environments.

This only works if grounded in human identity. In practice, that means integrating with systems like LDAP or Active Directory. Every injected capability must be traceable to a person, for a purpose, for a duration.

One rule matters most: authority must be requested, not assumed. Guardrails can be injected automatically, but capabilities that expand external power should never appear implicitly.

Dependency Injection made software composable. Capability Injection makes AI composable.