Over the first days of October 2026 we shipped the first set of AEAP Composition Boundary Adapters — one for each of the major agent frameworks developers are using in production today. Thirteen packages across npm and PyPI, all Apache 2.0, all built around the same single architectural shape.
This post explains what a Composition Boundary Adapter is, why we built each one as a thin wrapper around a single underlying primitive instead of as a feature-rich standalone product, which framework each adapter is designed for, who it's ideal for, and how to install it.
What a Composition Boundary Adapter is
The AEAP specification defines the Composition Boundary (§9) as the specific point in a system where the Runtime Decision Point is invoked — the moment between an autonomous Intent being formed and a Consequential Action executing. The Composition Boundary looks different in every framework:
- In an agent framework like LangChain, the Composition Boundary is the tool invocation point
- In a graph-based framework like LangGraph, it's the node transition
- In a middleware-based framework like Microsoft Agent Framework, it's a middleware hook before the action executes
- In the Model Context Protocol, it's the server-side tool call before dispatch
A Composition Boundary Adapter is the specific way AEAP attaches to that framework's native primitive. The adapter is not a product. It is not adding Aiyo features to someone else's framework. It is a thin shape that translates the framework's native tool/node/middleware abstraction into an AEAP Intent, calls the Runtime Decision Point, and composes the ternary verdict — ALLOW, ESCALATE, or BLOCK — back into the framework's native control flow.
Why we chose thin wrappers over per-framework products
The alternative we deliberately did not take was shipping a feature-rich "AEAP for [Framework]" integration product per framework. We considered that path and rejected it for three reasons.
Feature backlogs multiply. Every feature we would add to a per-framework product would be a feature we needed to maintain in that framework's idiom indefinitely. Framework-specific feature backlogs tend to grow. We did not want seven feature backlogs. We wanted one.
Architectural honesty. The whole point of AEAP is that the Runtime Decision Point is a protocol primitive. If we built seven different RDPs — one per framework — we would be undermining our own claim that AEAP is a specification rather than a collection of framework-specific products. One RDP implementation (@aiyoplane/mcp-authz, aiyoplane-mcp-authz), seven adapters, is the architecturally honest shape.
Audit surface. Thin wrappers are easier to read. Every adapter in this release is a few hundred lines of code at most. A developer evaluating whether to install an AEAP adapter can read the entire source in ten minutes and see exactly what the adapter does: build an Intent from framework-native arguments, call the RDP, compose the verdict into the framework's native control flow, fail closed on every ambiguous condition. That transparency is a feature of the shape itself, not something we have to document.
Don't build ten different Aiyo authorization systems. Build ten tiny doors into the same AEAP boundary.
The adapters are category (d) distribution under our internal Build Discipline rule: they distribute an existing implementation into developer ecosystems where that implementation already works. They do not add new behavior at the adapter layer. All the work happens in mcp-authz.
The adapters
Thirteen packages shipped across seven frameworks, listed in the order a reader is most likely to want them. Each entry explains why we chose that framework, who the adapter is ideal for, and how to install it.
MCP — the foundation (@aiyoplane/mcp-authz, aiyoplane-mcp-authz)
Why MCP first. The Model Context Protocol is becoming the lingua franca of agent-tool interoperability. An MCP server exposes tools; any MCP-compatible client (Claude Desktop, agent frameworks, IDE integrations) can invoke them. If AEAP's authorization decision attaches at the MCP tool-invocation boundary, every downstream client inherits it without framework-specific adapter code.
And: mcp-authz is the foundational package — the one that carries the actual AiyoAuthz middleware, the LocalRdp and HostedRdp providers, Intent and Policy evaluation, and receipt signing. Every other adapter in this release depends on it. That dependency pattern is deliberate: it keeps the RDP primitive singular and ensures that improvements to the primitive flow outward to every framework adapter in one step.
Ideal for: anyone operating an MCP server who wants to attach authorization decisions to specific tool invocations. If you're building MCP servers for internal use, publishing them to the MCP community, or integrating MCP into your product's agent surface, this is the adapter you compose with directly.
npm install @aiyoplane/mcp-authz
pip install aiyoplane-mcp-authzLangChain (@aiyoplane/langchain, aiyoplane-langchain)
Why we chose LangChain. It remains the most-installed agent framework by a wide margin, and its Tool abstraction is explicit and well-documented. LangChain's tool-invocation point is the canonical Composition Boundary for the chain-style agent pattern. If someone comes to AEAP for the first time looking for "how do I attach authorization to my agent's tools," LangChain is the framework they're most likely bringing with them.
Ideal for: developers building agents in LangChain where tool calls have real consequences — payments, data writes, deploys, external API calls — and the decision of whether to execute needs to depend on current Policy and current Evidence, not just whether the LLM decided to call the tool.
npm install @aiyoplane/langchain
pip install aiyoplane-langchainLangGraph (@aiyoplane/langgraph, aiyoplane-langgraph)
Why we chose LangGraph as a separate adapter from LangChain. LangGraph is architecturally the strongest fit for AEAP in the LangChain ecosystem. The Composition Boundary sits at the graph node — the exact point where state transitions into a consequential action. For long-running agents, stateful workflows, multi-step execution with branches, and human-in-the-loop checkpoints, LangGraph is where the Runtime Decision Point most naturally lives.
The aiyo_gate decorator and wrapNode / wrap_node function make the attachment one-line and idiomatic. On ALLOW, the verified Execution Receipt attaches to graph state so downstream nodes can inspect it and audit pipelines can collect it.
Ideal for: developers already using LangGraph for stateful or branching agent workflows, especially those where human approval or escalation is an explicit graph edge rather than a surprise exception.
npm install @aiyoplane/langgraph
pip install aiyoplane-langgraphOpenAI Agents SDK (@aiyoplane/openai-agents, aiyoplane-openai-agents)
Why we chose the OpenAI Agents SDK. It is deliberately lightweight, well-shaped around agents / tools / handoffs / guardrails / sessions, and growing fast. The function-tool invocation point is almost comically clean as a Composition Boundary. OpenAI's push into more autonomous agents makes AEAP's thesis sharper every month: the more autonomous the agent, the more important independent authorization at the point of consequential execution becomes.
The adapter composes with the Agents SDK's own guardrails — guardrails run on input shape, AEAP runs on policy evaluation at the tool-invocation moment. Different layers, both valuable, both staying in their own lane.
Ideal for: developers building on OpenAI's Agents SDK whose agents call tools with real-world consequences and who want authorization decisions to be independently verifiable rather than trusting the model's own "I decided to call this tool" implicit decision.
npm install @aiyoplane/openai-agents
pip install aiyoplane-openai-agentsCrewAI (aiyoplane-crewai)
Why we chose CrewAI (Python-native). Multi-agent crew composition is a textbook case where "may this crew member perform this class of action" and "should this specific action execute right now" are two different questions requiring two different authorization layers. Role assignment is identity and delegation. AEAP is the question at the tool-invocation moment, under the Protected Party's current Policy, against the specific Intent being formed by the specific crew member calling the specific tool.
CrewAI's community is particularly developer-first and open to protocol-level thinking, which fits the AEAP posture.
Ideal for: developers building multi-agent workflows in CrewAI where different crew members have different authority levels, where the same tool might be ALLOW for one crew member and ESCALATE for another, or where consequential actions in a crew need independent audit beyond the LLM's own tool-call reasoning.
pip install aiyoplane-crewaiMicrosoft Agent Framework (@aiyoplane/microsoft-agent-framework, aiyoplane-microsoft-agent-framework)
Why we chose Microsoft Agent Framework. It is Microsoft's current agent framework — the successor to AutoGen and Semantic Kernel — and its explicit "middleware for intercepting agent actions" is architecturally adjacent to AEAP's Composition Boundary. Enterprise developers already using Semantic Kernel or AutoGen are migrating to Agent Framework, and the migration path brings workflow and middleware abstractions that are a natural fit for AEAP's attachment pattern.
The adapter provides two integration surfaces: an AiyoAgentMiddleware class for the middleware chain, and a wrapAction / wrap_action function for workflow nodes defined as plain callables.
Ideal for: enterprise developers building on Microsoft Agent Framework whose agents interact with internal systems where policy, approval, and audit are non-negotiable requirements. If "the LLM decided to call this tool" isn't a complete answer in your compliance context, this adapter closes the gap.
npm install @aiyoplane/microsoft-agent-framework
pip install aiyoplane-microsoft-agent-frameworkGoogle ADK (aiyoplane-google-adk)
Why we chose Google ADK. It is Google's agent development kit for the GCP + Gemini ecosystem, and it already reaches into runtime code execution and sandboxed environments. Those are prime AEAP territory — code execution, external API calls, cloud resource mutations, and economic actions are all consequential and benefit from the "before this crosses the boundary, authorize it" property AEAP provides.
The adapter wraps a Python callable before Google ADK tool registration via @aiyo_tool decorator or wrap_tool_function. Fail-closed on every ambiguous condition.
Ideal for: developers building on Google ADK, especially those running agents against GCP resources or using ADK's code-execution and sandboxed-environment features, where the "the agent decided to run this code" decision needs to be independently authorizable at the point of execution.
pip install aiyoplane-google-adkClaude Agent SDK (@aiyoplane/claude-agent-sdk, aiyoplane-claude-agent-sdk)
Why we chose the Claude Agent SDK. Coding-agent surfaces produce some of the clearest consequential execution boundaries in all of software. File write → modify file → run command → install dependency → git push → deploy → production. Each arrow crosses a Composition Boundary. The Claude Agent SDK is the SDK Anthropic ships for building these agents, and coding agents in particular benefit from the "the agent can decide what it wants to do; AEAP provides the independently verifiable authorization decision at the point where consequential execution occurs" separation.
Ideal for: developers building coding agents, autonomous software engineering tools, or any agent whose tool calls touch files, commands, dependencies, or deployment surfaces. The adapter positions perfectly for the "the model decides the plan; the authorization layer gates the plan's execution" architecture.
npm install @aiyoplane/claude-agent-sdk
pip install aiyoplane-claude-agent-sdkThe common install shape
Every adapter in this release follows the same shape — three parts: a Policy, an Intent builder, and the adapter attaching the two to the framework's native primitive. In Python:
from aiyoplane_mcp_authz import create_aiyo_mcp_authz, create_local_rdp
from aiyoplane_<framework> import <adapter_entry_point>
authz = create_aiyo_mcp_authz(
rdp=create_local_rdp(policy=my_policy),
tool_config={
"my_consequential_tool": {"aiyo_gated": True, "action": {...}},
},
)
guarded = <adapter_entry_point>(
<framework_native_tool_or_node>,
authz=authz,
intent_builder=lambda args: {"type": "...", ...},
)The adapter is the thin layer. The RDP, the receipt signing, the verdict logic — all in mcp-authz, same primitive every adapter uses. Swap the policy, swap the Intent builder, swap the framework; the shape stays the same.
Verdict composition in every adapter
Every adapter composes the AEAP ternary verdict into the host framework's native control flow:
- ALLOW → the inner tool/node/handler runs with the original arguments; the verified Execution Receipt is attached to the host framework's native context so downstream code and audit pipelines can inspect it
- ESCALATE →
EscalationRequiredis raised with a stableescalation_idso the host framework's error handling or an explicit conditional edge can route to a human-approval branch - BLOCK →
BlockedByPolicyis raised; the inner tool/node/handler never executes
And every adapter fails closed on every ambiguous condition — missing Intent builder, non-dict Intent, unreachable RDP, misconfigured tool_config — all surface as BlockedByPolicy rather than silently passing through. This matches AEAP §2.2 invariant 5: in any indeterminate condition, the RDP produces BLOCK.
Where this goes next
Independent framework adapter development is explicitly welcomed under the same architectural contract: thin wrappers around mcp-authz, Intent builder user-supplied, ternary verdict composed into the host framework's native control flow, fail-closed on every ambiguous condition. We will continue to ship adapters where ecosystem demand surfaces them.
If you build an adapter for a framework we haven't covered, we'd like to hear about it. The repository catalog is public at github.com/aiyoplane and the Trust surface tracks every live adapter at aiyoplane.com/trust.
How to engage
- Install the adapter for the framework you're already using (list above)
- Read the specification: github.com/aiyoplane/aeap
- Browse the public source for any adapter in the aiyoplane GitHub organization
- File issues on the adapter repository or open a feature request on the AEAP specification repository
- Email info@aiyoplane.com for partnership, security concerns, or private discussion
- Trust surface: aiyoplane.com/trust
Seven framework ecosystems. Thirteen packages. One architectural shape. All live, all Apache 2.0, all built around the same single primitive.
Verify First. Execute Second.