The Single-Agent Era Is Over

Something happened this past week that deserves more attention than it is getting. In the span of roughly 72 hours, three of the most prominent agent frameworks in the industry made the same architectural decision independently. Microsoft moved AutoGen to maintenance mode, directing users to the new Microsoft Agent Framework. GitHub launched Squad, a multi-agent coding system. And Block’s Goose — once the poster child for single-agent simplicity — pivoted its entire architecture toward multi-agent orchestration with MCP as the coordination backbone.

Any one of these in isolation could be dismissed as a product pivot. All three at once is a signal.

The single-agent era is over. What comes next is more interesting, more complex, and more consequential for how we build software with AI.

What Actually Happened

Let’s start with the facts, because the details matter more than the headlines.

Microsoft AutoGen: From Flagship to Maintenance Mode

AutoGen was Microsoft Research’s multi-agent conversation framework, originally released in late 2023. It allowed developers to define multiple agents that could converse with each other to solve problems. It was one of the earliest popular multi-agent frameworks, accumulating over 40,000 GitHub stars.

This week, Microsoft formally moved AutoGen to maintenance mode. The successor is the Microsoft Agent Framework, which takes a fundamentally different approach. Where AutoGen was built around conversational patterns between agents, the new framework is built around structured orchestration — agents with defined roles, explicit handoff protocols, and centralized coordination. The shift is not just a rebrand. It reflects a hard-won lesson: unstructured multi-agent conversation does not scale. What you need is disciplined multi-agent coordination.

GitHub Squad: Multi-Agent Coding Goes Mainstream

GitHub’s launch of Squad is perhaps the most visible signal. Squad is not a research project or a framework. It is a product, integrated directly into GitHub’s platform, that assigns multiple specialized agents to work on different aspects of a codebase simultaneously.

The architecture is straightforward: a planning agent breaks down tasks, specialized coding agents handle implementation across different files and languages, a review agent checks the output, and a coordination layer manages conflicts and dependencies. Each agent has a focused context window and a defined role. The days of a single Copilot agent trying to hold an entire repository in context are officially numbered.

What makes Squad notable is not the architecture itself — researchers have proposed similar patterns for years. It is that GitHub is shipping it as a default workflow for millions of developers. Multi-agent is no longer a research pattern. It is a product feature.

Block’s Goose: The Pivot That Tells the Whole Story

Goose is the most instructive case. Block (formerly Square) released Goose as an open-source AI coding assistant built around a single-agent model. One agent, one conversation, one context window. It was deliberately simple, and that simplicity was a selling point.

The pivot to multi-agent is significant because it was driven by practical limitations that every team building with agents has encountered. A single agent trying to code, test, browse documentation, manage deployments, and reason about architecture hits context window limits quickly. It loses track of earlier instructions. It makes inconsistent decisions because it is juggling too many concerns in one reasoning chain.

Goose’s new architecture uses MCP as the coordination backbone. Specialized agents communicate through MCP tool calls, share context through a common protocol, and hand off work through defined interfaces. The agent that writes code does not also need to understand the deployment pipeline. The agent that reviews code does not need the full history of the implementation conversation.

This is not “more agents for the sake of more agents.” It is an architectural response to a fundamental constraint: single-agent systems collapse under the weight of real-world complexity.

What Multi-Agent Actually Means

The term “multi-agent” gets thrown around loosely. Some people use it to mean “I have two chat windows open.” That is not what we are talking about. The architecture that is emerging across these three projects shares specific structural properties that distinguish it from simply running multiple independent agents.

Specialized Roles, Not General-Purpose Clones

In a well-designed multi-agent system, each agent has a narrow, well-defined role. A coding agent only codes. A review agent only reviews. A planning agent only plans. This is not a limitation — it is the point. Narrow roles mean smaller context windows, more focused prompts, and more predictable behavior.

The shift from single-agent to multi-agent mirrors a pattern that software engineering adopted decades ago: the move from monoliths to microservices. A single-agent system is a monolith. Everything happens in one process, one context, one reasoning chain. Multi-agent systems decompose that monolith into specialized services with defined interfaces.

Shared Context Through Protocol, Not Conversation

The early multi-agent frameworks — AutoGen included — used conversation as the coordination mechanism. Agents would literally talk to each other in natural language, passing messages back and forth. This works for demos. It falls apart in production because natural language is ambiguous, conversations are expensive (every message costs tokens), and there is no structured way to verify that agents actually understood each other.

The emerging pattern replaces conversation with protocol. MCP provides a structured way for agents to expose capabilities, share state, and invoke each other’s tools. When a coding agent finishes implementation and needs a review, it does not write a message saying “please review my code.” It makes a structured tool call with defined parameters, passing the exact files, the diff, and the review criteria. The review agent receives structured input and returns structured output.

This is why MCP keeps appearing in these announcements. It is not because MCP is trendy. It is because multi-agent systems need a standard way for agents to interact, and MCP provides the tool-calling and capability-discovery primitives that make structured coordination possible.

Coordination Primitives, Not Just Communication

Communication is necessary but not sufficient. Multi-agent systems also need coordination — the ability to manage concurrent work, resolve conflicts, handle failures, and maintain consistency. This is where the infrastructure gap is widest.

Consider a scenario where two coding agents are working on the same file. Without coordination, they will produce conflicting changes. With coordination, you need: locking (or optimistic concurrency), conflict detection, merge strategies, and rollback capabilities. These are distributed systems problems, and they require distributed systems solutions.

GitHub Squad handles this through a centralized planning agent that assigns non-overlapping work. Goose handles it through MCP-based handoff protocols. The Microsoft Agent Framework provides explicit orchestration patterns. All three have arrived at the same conclusion: multi-agent without coordination is just chaos with extra steps.

The Infrastructure Implications

If you accept that multi-agent is the direction the industry is heading, the infrastructure requirements follow logically. And they are significant.

The Tool Explosion Problem

A single agent might connect to five or ten MCP servers, providing a manageable set of tools. A multi-agent system with four specialized agents might connect to twenty or thirty MCP servers. Each agent needs tools appropriate to its role, and those tools need to be discoverable, versioned, and governed.

This is where tool governance becomes critical. You need a layer that controls which agents can access which tools, validates tool calls against security policies, and maintains an audit trail. MCP gateways — like MCPProxy, Acuvity, or the gateway features emerging in cloud platforms — provide this governance layer. Without it, you have a multi-agent system where any agent can call any tool with any parameters, which is approximately as secure as a microservice architecture where every service has root access to every database.

Tool discovery also becomes more complex. BM25-based discovery (matching agent intent to tool descriptions), registry-based lookup, and dynamic capability negotiation all become more important when the number of available tools scales with the number of agents.

The Coordination Layer

Multi-agent systems need a messaging and coordination layer that goes beyond simple request-response. Agents need to be able to publish events, subscribe to channels, send direct messages, and maintain shared state. This is a messaging infrastructure problem, and existing solutions from the microservices world — message queues, event buses, pub/sub systems — are directly applicable.

Projects like SynapBus, Apache Kafka with agent-specific adapters, and even Redis Streams are being used as coordination backbones. The key requirement is that the coordination layer speaks MCP natively, so agents can interact with it using the same protocol they use for everything else.

Observability Is No Longer Optional

When a single agent produces a wrong answer, you can read the conversation history and trace the reasoning. When a multi-agent system produces a wrong answer, the failure might have originated in any of four agents, in the coordination between them, in a tool call that returned unexpected data, or in a planning decision three steps back.

Multi-agent observability requires distributed tracing (which agent called which tool, in what order, with what parameters), aggregate metrics (throughput, latency, error rates per agent), and the ability to replay and debug multi-agent interactions. The OpenTelemetry ecosystem is extending to cover agent-specific spans and traces, and several startups are building agent-native observability platforms.

This is not nice-to-have infrastructure. Without it, debugging a multi-agent system is like debugging a distributed microservice architecture with nothing but printf statements. Technically possible. Practically nightmarish.

Protocol Standards: MCP and A2A

The protocol layer is perhaps the most consequential infrastructure decision. Two standards are emerging as the coordination primitives for multi-agent systems.

MCP (Model Context Protocol) provides tool access, resource sharing, and capability discovery. It is the protocol agents use to interact with the outside world — databases, APIs, file systems, and other services. Its adoption across all three announcements this week is not coincidental. MCP has become the de facto standard for agent-to-tool communication.

A2A (Agent-to-Agent Protocol), introduced by Google and now gaining adoption, provides the primitives specifically for agent-to-agent interaction: task delegation, status reporting, capability advertising, and result aggregation. Where MCP is the protocol for “agent talks to tool,” A2A is the protocol for “agent talks to agent.”

These are complementary, not competing. A well-architected multi-agent system uses MCP for tool access and A2A for agent coordination. Together, they provide the full communication stack that multi-agent systems need.

What Practitioners Should Prepare For

If you are building with agents today, the multi-agent shift has practical implications that you should start planning for now.

Design for decomposition from the start. Even if you are building a single-agent system today, structure it so that capabilities can be split into separate agents later. Use MCP servers to encapsulate tool access. Keep prompts focused. Define clear boundaries between different types of work.

Invest in tool governance early. The number of tools in your system will grow faster than you expect, especially as each specialized agent brings its own tool requirements. Establish policies for tool access, parameter validation, and audit logging before the tool count makes it painful.

Build coordination infrastructure before you need it. Adding a coordination layer to a running multi-agent system is like adding a message queue to a running microservice architecture — possible but painful. Start with a lightweight messaging layer and grow it as your agent count increases.

Treat observability as a first-class concern. Instrument your agents from day one. Record tool calls, agent decisions, coordination events, and outcomes. When (not if) something goes wrong in a multi-agent interaction, you will need this data to debug it.

Expect the ecosystem to move fast. The announcements this week are not the end of the transition. They are the beginning. Expect more frameworks, more tools, more patterns, and more breaking changes over the next 6-12 months. Build for flexibility.

The Architecture That Is Emerging

Stepping back from the individual announcements, a coherent architecture is taking shape across the industry. It has four layers:

Agent Layer: Specialized agents with narrow roles, focused context windows, and defined capabilities. Each agent is optimized for a specific type of work.

Protocol Layer: MCP for tool access and capability discovery. A2A for agent-to-agent coordination and task delegation. These provide the standard interfaces that make the system composable.

Governance Layer: Gateways that control tool access, validate requests, enforce policies, and maintain audit trails. This is the security and compliance boundary for the entire system.

Coordination Layer: Messaging infrastructure that enables asynchronous communication, event-driven workflows, and shared state management between agents.

This is not a theoretical architecture. It is what GitHub Squad, the Microsoft Agent Framework, and the new Goose are all building toward, with different implementations but remarkably similar structures.

The single-agent era was a necessary starting point. It proved that AI agents could do useful work, established the tool-calling patterns that MCP standardized, and built the developer intuition for what agents are good at. But just as web applications outgrew single-server architectures, agent applications are outgrowing single-agent architectures.

The transition will be messy. Multi-agent systems are harder to build, harder to debug, and harder to secure than single-agent systems. But the complexity is not optional — it is the price of building systems that can handle real-world work at production scale.

The 72-hour signal this week was not three companies independently deciding to complicate their architectures. It was three companies independently discovering the same constraint and arriving at the same solution. That kind of convergence is not a trend. It is an inevitability catching up.