The Agent Stack

The Model Context Protocol is one of the better ideas in AI infrastructure right now, and it is also one of the worst implementations. Not because the engineering is bad, though some of it is, but because the entire thing shipped without a clear separation of concerns. The result is a protocol that works in demos and falls apart the moment you try to build something modular, auditable, and deployable at the scale an enterprise actually requires.

The problem is not technical complexity. The problem is taxonomic. Nobody can tell you with precision where a connector ends and a tool begins, what a skill is versus a server, or what exactly constitutes an agent in this system versus a prompt with ambition. The naming is muddy, the hierarchy is flat, and the boundaries between layers are implicit rather than enforced. That is not a documentation gap. It is an architecture gap, and it is the kind of gap that calcifies fast if you do not address it before the ecosystem builds load-bearing assumptions on top of it.

What the Stack Should Look Like

The right framing is four layers, each with a distinct job, clear ownership, and defined interfaces to the layers above and below it — plus a fifth dimension that runs alongside all of them.

Connectors are the bottom of the stack. A connector does one thing: it authenticates and provides raw access to an external system. Slack, Google Calendar, Salesforce, a database, whatever the integration target is. The connector knows how to get in and how to move data. It does not know why. It has no opinion about workflows, no business logic, no domain judgment. It is plumbing, and it should be treated as plumbing: standardized, certified, and boring.

Skills sit on top of connectors and carry the domain judgment. A skill is a scoped instruction set that tells an agent how to actually accomplish a task using one or more connectors. It includes the sequencing, the edge cases, the things that break, the things to confirm before acting, and the things to never try. If the connector is the API, the skill is the senior colleague who already learned the hard way which endpoints lie to you and which workflows require a specific order of operations that nothing in the documentation mentions.

This is the layer that compresses apprenticeship. A well-written skill file means the model does not have to rediscover through trial and error that a calendar API technically accepts four timezone formats and silently mangles three of them. The skill is institutional knowledge made portable — and it is the most underleveraged layer in the current architecture, because most MCP implementations skip it entirely, dumping raw connector access into the model's context and hoping inference handles the rest.

Skills should be composable, versionable, and ownable. An enterprise should be able to write its own skills on top of standard connectors, version them like code, share them across teams, and audit what each skill is authorized to do. The skill layer is where organizational context enters the stack, and if you do not give people a clean way to own it, they will embed it in system prompts and lose it when someone changes the model.

Agents are deployable orchestrations of skills with a defined role, scope, and set of guardrails. An agent is the unit that an enterprise IT team can actually reason about. It has a name, a purpose, a permission boundary, and a set of skills it is authorized to use. It is the thing you hand to a team and say "this handles your weekly reporting" or "this triages incoming support tickets."

The distinction between an agent and a skill matters enormously for governance. A skill is a capability. An agent is an actor. Skills do not make decisions about when to run or what to prioritize. Agents do. That means agents are where you enforce policy, logging, approval gates, and escalation paths. Conflate the two — which is what happens when you have no taxonomy — and you cannot scope permissions, cannot audit behavior, and cannot give a compliance team anything coherent to review.

Orchestrators are the top of the stack. An orchestrator coordinates multiple agents toward a higher-order goal, deciding which agents to invoke, in what order, with what context, and how to handle conflicts between them. This is the layer where genuine strategic logic lives — where the system decides not just how to do something but whether to do it at all, and what to prioritize.

Most implementations today collapse the orchestrator into the model itself, treating the LLM as orchestrator and agent at once. That works for simple tasks and breaks immediately when you need predictable, repeatable, governable behavior across complex workflows. The orchestrator should be its own layer with its own logic, not an emergent property of whatever the model decides to do with a long context window.

Guides: The Missing Dimension

The four layers describe what the stack does. The fifth dimension describes what the stack knows about itself — and its absence is the biggest reason MCP fails in practice today.

Call it a Guide. It is the structured, LLM-native documentation layer that runs alongside every level of the stack, giving the model the context it needs to operate without flooding it with everything the system technically contains. If the stack is the architecture, the Guide is the institutional memory that makes the architecture usable.

This is not documentation in the traditional sense. Human documentation is written for people who read linearly, search selectively, and bring their own context to fill in the gaps. An LLM has none of those affordances. The Guide is documentation rebuilt from first principles for a consumer that is fast, literal, and has no prior relationship with the system it is about to use.

At the connector level, the Guide is a resource index: a structured manifest of everything the connector exposes — data types, operations, rate limits, permissions, relationships between entities — with plain-language descriptions of what each tool does and when to choose it over its neighbors. Today a connector like Gmail ships tool names like gmail_search_messages and terse descriptions that assume you already understand the API; the Guide would make explicit that search returns metadata and snippets while reading a thread returns the full conversation. The model should never have to guess which tool to call. The Guide makes the choice obvious before a single token gets spent reasoning about it.

At the skill level, the Guide becomes a playbook — not just what to do but how to decide what to do. When someone asks to "find that conversation about the Q3 budget," the playbook supplies the decision tree: determine whether this is a search by content, by person, or by time range; execute the connector calls in a specific order; validate before presenting; fall back if the results are empty, narrow if they flood. The playbook compresses trial-and-error into directed action, and it is the single biggest lever for reducing both latency and token waste.

At the agent level, the Guide becomes a role brief: purpose, boundaries, escalation paths, relationships to other agents. An orchestrator deciding which agent to invoke should not have to introspect its full skill set and reason about capabilities from first principles. It should read a brief that says: this agent handles support triage, it can access these systems, it escalates to a human under these conditions, and it does not have permission for these others. The role brief makes agents discoverable and composable without requiring the orchestrator to understand their internals.

At the orchestrator level, the Guide becomes a system map. It is the high-level view of what agents are available, what domains they cover, where their boundaries overlap, and how conflicts between them should be resolved. This is the layer where an enterprise's organizational logic gets encoded: which team owns which agent, which workflows cross agent boundaries, and what the approval chain looks like when an orchestration involves sensitive operations.

The common thread across all four levels is one principle: give the model exactly what it needs to make the right call, and nothing more. The Guide is the opposite of a context dump — a structured, scoped, layered system of self-knowledge, queried at the right moment for the right level of detail. Each level answers a different question, and the model should only need to consult the one that matches the question in front of it.

This is the piece that makes the whole stack work in practice rather than in theory. Without Guides, every layer of the stack is a cold start. The model has to reason from raw tool signatures every time, reconstructing context that should have been pre-computed. With Guides, the stack carries its own institutional knowledge, and the model can operate the way a competent employee operates in their second month: not by knowing everything, but by knowing where to look and what questions to ask before acting.

Why Naming Matters More Than It Looks

The instinct will be to treat this as a naming convention problem, a cleanup that can happen later once the protocol matures. That instinct is wrong for the same reason that leaving organizational debt unaddressed is wrong: the longer you wait, the more load-bearing the current confusion becomes.

Every MCP server built today that conflates connector logic with skill logic with agent behavior is a server that will need to be refactored or replaced when the taxonomy finally lands. Every enterprise that builds workflows on top of the current flat structure is building on assumptions that will not survive the introduction of real governance requirements. The cost of not having a clear hierarchy is not paid at build time. It is paid at scale, when you need to audit, permission, swap, or govern what you have already deployed and discover that the boundaries you need do not exist.

A clean stack also solves the composability problem. If connectors are standardized, any skill can use any connector. If skills are portable, any agent can be assembled from any combination of skills. If agents are self-contained, any orchestrator can coordinate any set of agents. The modularity compounds at every layer, and the absence of it creates friction at every layer. That is the difference between a protocol that enables an ecosystem and a protocol that accidentally prevents one.

Where This Lands

The Model Context Protocol has the right instinct. Give models structured access to the outside world. Let them act, not just think. But the current implementation treats that access as a flat surface when it needs to be a stack, and it ships without the self-knowledge layer that makes any of it usable at speed.

Connectors should connect. Skills should carry judgment. Agents should be deployable units with clear boundaries. Orchestrators should coordinate. And Guides should run alongside all of it, giving the model exactly the context it needs at every layer, and no more.

The protocol that gets this right will not just be a better version of MCP. It will be the infrastructure layer that makes AI-native organizations actually possible, because it solves the same problem at the system level that those organizations are solving at the human level: compressing the connective tissue so that judgment, not routing, is where all the time gets spent.