AG2 0.13.4 Turns AutoGen’s Successor Into an MCP Endpoint, Not Just an MCP Client

AG2’s latest release is not trying to win the demo war. Good. The demo war has produced enough terminal windows where five agents roleplay as a startup and somehow nobody asks who is allowed to call whom, how the bill gets counted, or what happens when the “agent” becomes an endpoint other systems can invoke.

AG2 0.13.4, published June 12, is more interesting because it moves in the opposite direction: less theater, more runtime surface. The release adds a Beta wrapper that can serve an AG2 Agent as an MCP server, introduces a spec-aligned SkillPlugin, adds decoupled usage events, ships an Amazon Bedrock Beta client, and includes a TealTiger governance example. That combination says the quiet part plainly: the AutoGen successor is preparing to become infrastructure, not just a Python API for choreographing agents in-process.

The headline is bidirectional MCP. AG2 already had client-side MCP support; now an AG2 Beta agent can be exposed to MCP clients as a conversational ask(message, context?) tool through autogen.beta.mcp.MCPServer. Locally, it can run over stdio. Remotely, build_streamable_http() returns a Starlette ASGI app. PR #2937 was not a toy patch either: 2,742 additions across 41 files.

Consuming MCP is table stakes. Serving MCP is the platform move.

Most agent frameworks have been asking the same first-order question: how does my agent call tools? That matters, but it is only half of the protocol story. If MCP becomes a common adapter layer for tools, clients, IDEs, and agent runtimes, then frameworks need to answer the inverse question too: how does another system call this agent as a capability?

That distinction changes the architecture. A framework that only consumes MCP is a client in someone else’s graph. A framework that can expose agents over MCP becomes a node other systems can compose. That is what makes AG2 0.13.4 worth watching. It is not just adding another integration checkbox. It is turning an agent into a network-addressable component.

That also raises the security bar immediately. There is a bad version of this future where every team wraps an internal agent as a friendly tool endpoint, hands it a schema, and forgets that the endpoint can read tickets, query databases, trigger workflows, or write code. AG2’s implementation at least starts with the right shape: the remote MCP path supports OAuth Resource Server authentication, serves RFC 9728 Protected Resource Metadata at /.well-known/oauth-protected-resource, enforces bearer tokens on /mcp, returns 401 with a WWW-Authenticate metadata hint for missing or invalid tokens, and returns 403 when scope is insufficient. Token issuance is explicitly left to an external authorization server.

That is not the whole enterprise story. You still need issuer configuration, scopes that mean something, audit logs, rate limits, tenant isolation, replay protection, and policy enforcement around which tools the served agent may call on behalf of the requester. But the important point is that AG2 is not pretending “MCP server” means “just bind a port and hope.” In agent systems, authentication is not paperwork. It is the line between composition and lateral movement with JSON.

Skills are a supply chain, not prompt garnish

The other architectural tell is SkillPlugin, added in PR #2957 with 1,049 additions across 19 files. It implements the agentskills.io progressive-disclosure pattern: publish a startup catalog of available skills, load full instructions only when needed, and fetch bundled resources on demand. That is the correct direction. Dumping every instruction into the context window at startup is not architecture; it is prompt landfill with latency.

The details matter more than the feature name. AG2 constrains load_skill(name) to a Literal enum of discovered skills, XML-escapes catalog values, warns and skips shadowed name collisions, strips frontmatter from loaded skill bodies, adds path-traversal guards for resources, and caps output. None of that will make a launch video. All of it matters if skills become portable agent capabilities rather than local snippets copied between repos.

Practitioners should treat skills the way they treat plugins, CI actions, editor extensions, and package dependencies: as a supply chain. A skill can carry instructions, scripts, resources, and behavioral assumptions. If an agent can discover and load skills dynamically, the runtime needs provenance, collision rules, sandboxing, resource limits, and review workflows. Otherwise “skill ecosystem” becomes a polite phrase for “untrusted prompt execution with file access.”

Usage accounting finally moves closer to where cost happens

AG2 also adds decoupled UsageEvent accounting in PR #2952, a 661-line change across 17 files. This is the kind of runtime plumbing that separates serious multi-agent systems from impressive notebooks. Costs in multi-agent runs do not happen only at the final response. They happen inside model calls, live sessions, compaction, aggregation, and sub-agent rollups. If the parent agent reads the last response and pretends that is the bill, the accounting is already wrong.

Decoupled usage events are a better primitive because they let token spend be emitted where it actually occurs. A sub-agent can keep private call-level events and emit a rolled-up event to its parent without double-counting. Platform teams can aggregate across nested runs. Finance can compare framework telemetry against provider invoices. SRE can correlate cost spikes with compaction, retries, tool-heavy runs, or specific orchestration patterns. This is not glamorous. It is exactly what teams ask for after the first surprisingly expensive month.

The Amazon Bedrock Beta client rounds out the enterprise posture. Bedrock support is not just another provider logo. For many organizations, Bedrock is the approved path for model access because it fits existing AWS controls, procurement, and data-governance expectations. If AG2 wants to compete with LangGraph, CrewAI, Microsoft Agent Framework, Google ADK, and Pydantic AI in real deployments, it needs provider support, protocol surfaces, runtime governance, migration stability, and cost telemetry — not just pleasant abstractions.

The roadmap context makes this release sharper. AG2 says the current autogen.agentchat framework will be tidied through deprecations and prepared for maintenance mode, while the Beta framework under autogen.beta becomes official at v1.0. Version 0.13 is the transition period; 0.14 is framed as the final current-line release; v1.0 is where Beta takes over main and the original AG2 moves to an ag2-original branch. In other words, these Beta surfaces are not side quests. They are the future contract.

That means builders should evaluate this release like a migration signal, not a drop-in production rewrite. If you use AG2 today, decide whether new work belongs behind adapters that can move toward Beta. If you expose an AG2 agent over MCP, test missing tokens, invalid tokens, insufficient scopes, multi-turn semantics, progress and log notifications, and structured outputs from real MCP clients — not just the happy path. If you adopt SkillPlugin, threat-model installed skills as plugins: review scripts, resources, instructions, collisions, and path behavior. If cost matters, start aggregating UsageEvents now and compare them with provider-side bills.

The bigger point is that the agent-framework race is changing. The early comparison was “which framework has the nicest multi-agent abstraction?” That was always going to be temporary. The durable question is which runtimes can expose agents, secure them, meter them, compose them across protocols, and make the operational behavior inspectable enough that a team can trust it. AG2 0.13.4 is not v1.0 yet. But this is the shape v1.0 needs: less orchestration poetry, more runtime contract.

Sources: AG2 0.13.4 release, MCP server PR, SkillPlugin PR, UsageEvent PR, AG2 MCP docs, AG2 roadmap