The question underneath every multi-agent architecture is deceptively simple: where should the reasoning happen? A recent proposal from Microsoft’s Agent Framework team pushes that question into the open, arguing that the Model Context Protocol (MCP) should become not just a connectivity layer but a distribution rail for agent capabilities – and that many specialist agents do not need their own reasoning loop at all.
In a September 16 blog post, Tommaso Stocchi detailed a pattern for migrating from Agent-to-Agent (A2A) specialist architectures to what he calls distributed skills over MCP. The core move: instead of each specialist running its own model to interpret requests, select tools, and write responses, the specialist publishes a description, a SKILL.md procedure document, and typed MCP tools. The parent agent – Stocchi calls it the advisor – loads those instructions on demand and invokes the tools directly in its own model context. The domain services stay distributed. The reasoning moves.
This is not a theoretical exercise. Stocchi built a ski resort advisor demo with four specialists – weather, safety, ski coaching, and lift traffic – and ran both architectures side by side on the same application. The A2A path used six to seven model calls per request across the advisor and its specialists. The skills path used three. Mean elapsed time dropped from 15.48 seconds to 6.35 seconds – roughly 60% faster.
The tradeoff shows up in the token count. Across three paired runs, the skills path consumed 13,533 observed tokens versus 11,134 for A2A – about 22% more. Fewer model calls did not mean less cumulative context. As instructions, provider-group schemas, and results accumulated, the parent agent’s context window grew even as the specialist reasoning loops disappeared. Stocchi is careful to note this is a controlled demo, not a production benchmark: processes were reused, prompt-cache hits varied, and live telemetry changed between runs.
The architectural question is where this pattern fits alongside A2A. The answer Microsoft offers is complementary, not competitive. A2A handles the collaboration layer between autonomous agents – delegation across trust and ownership boundaries. MCP handles the tool and data layer beneath an agent. When a specialist needs its own model, private context, or independent lifecycle, it stays an agent via A2A. When it is a bounded competence – a procedure plus typed operations – it becomes a skill over MCP. The same application can use both, and the ski resort demo does exactly that: a web-research agent remains a standard A2A tool in both advisor paths.
Formal standardization arrived on September 13 when SEP-2640, the MCP Skills Extension, reached final status in the protocol’s extensions track. Maintained by the Skills Over MCP Working Group under the Agentic AI Foundation, the extension standardizes how skills are discovered, distributed, and consumed through MCP’s existing Resources primitive. Skills are addressed via a skill:// URI scheme, with an optional skill://index.json discovery document for lightweight catalog browsing before loading full content. Microsoft’s Agent Skills documentation describes a progressive disclosure pattern – advertise at roughly 100 tokens per skill, load under 5,000 tokens, read resources and run scripts on demand – designed to keep the parent agent’s context window lean.
This sits directly on the governance stack Forkast has been tracking. Our coverage of the MCP Governance Surface showed three enterprise vendors embedding policy enforcement at the protocol layer in a single week. The MCP Platform Battleground mapped five vendors converging on MCP with different governance implementations. The Google Managed Agent Harness added a hyperscaler runtime tier. Now Microsoft is proposing MCP as the distribution mechanism for agent capabilities themselves – not just the policy layer or the connectivity layer, but the rail that carries domain knowledge from where it is authored to where it is consumed.
The enterprise value proposition is straightforward: author once, serve everywhere. A platform team publishes skills to an MCP server; every agent across the organization picks them up without redeployment. When the server’s content changes, connected agents get the new version on their next discovery cycle. Microsoft’s companion post from July describes this as the difference between maintaining copies and maintaining a source – a shift from deployment-centric to distribution-centric capability management.
Several open questions remain. Microsoft explicitly labels the MCP-based skills API as experimental and subject to change. The skill://index.json discovery mechanism in the demo follows a pinned, historical draft revision of SEP-2640, not the final specification. Security around remote skill execution is handled by defaulting to tool approval requirements and refusing to execute scripts bundled in archive-type skills downloaded from MCP servers, but the broader trust model for distributed skills at enterprise scale is still developing. And the token cost tradeoff – faster execution but larger context – will need production-scale validation before it becomes a reliable architectural heuristic.
For builders, the practical takeaway is directional rather than prescriptive. Not every specialist needs to become a skill. Research agents, long-running workflows, and components with specialized models may still warrant their own reasoning loops via A2A. The question to ask is whether a given capability is a bounded competence – a procedure plus typed operations – or an autonomous reasoner. That distinction, more than any protocol choice, determines where the intelligence should live.