The Agentic Stack

You know how every few months there’s a new AI buzzword that sounds like it changes everything? Right now it’s “agents” and “multi-agent systems” and something called MCP. I’ve been building with this stuff daily, and I keep running into the same confusion — not in my own head, but in how everyone talks about it. So I sat down and tried to draw myself a map.

What I came up with is embarrassingly simple. It’s basically an org chart.

The thing that clicked

Think about how a company works. You’ve got four layers:

Individual capabilities. Someone knows how to use a specific tool — a spreadsheet, a phone, a drafting program. They do one thing when asked. No opinions about the bigger picture.

Professional skills. Now that person can combine those capabilities toward a goal. A good project manager doesn’t just know how to use a calendar app. They know how to sequence a timeline, anticipate bottlenecks, adjust when things slip. The skill is the strategy, not the tool.

Roles. A project manager and an engineer might look at the same information and reach completely different conclusions — not because one is wrong, but because they bring different judgment. The PM thinks about stakeholders and deadlines. The engineer thinks about what’s actually buildable. The role is the lens.

Teams. Multiple roles working together toward something none of them could deliver alone. The PM gathers requirements, hands them to engineering, engineering builds it, QA checks it, operations ships it. Each person passes an artifact to the next.

AI agents work exactly the same way. Four layers, same logic, same reasons for existing.

The four layers, concretely

Layer 1: Tools

The primitives. CLI commands, API calls, SDKs, MCP servers, file I/O, browser automation. A tool does one thing when asked. No opinion on why.

MCP belongs here. It’s a standardized protocol for exposing capabilities — important plumbing, but plumbing. The industry treats it like a higher-level concept than it is, which leads to the belief that connecting more tools automatically produces more capable agents. It doesn’t.

Layer 2: Skills

Goal-oriented compositions of tools with embedded strategy. A skill knows what to achieve and how to get there. It selects tools, sequences operations, handles edge cases, carries domain knowledge.

“Capture a knowledge note from a URL” involves fetching, extracting, formatting, writing, and triggering an embedding pipeline. “Deploy a static site” means build, sync to storage, invalidate CDN, verify. The skill decides which tools and in what order.

The litmus test: does it make decisions, or does it just forward a request? A skill that wraps a single API call with no branching logic is just a tool with a name. The decision-making is where the value lives. Strip that out and you’ve added abstraction without adding capability.

Layer 3: Agents

Role-oriented assemblies of skills. An agent has identity, capabilities, and the judgment to decide which skill to apply in context. It’s a person in a role — not just “can do X” but “understands when and why to do X.”

A PM agent does requirements gathering, spec writing, stakeholder communication. An engineer agent does architecture, implementation, code review. Same information, interpreted differently depending on role. That perspective is what agents add.

An agent with one skill is just a skill with a system prompt. Agents earn their abstraction when they genuinely choose between capabilities based on context.

Layer 4: Teams / Workflows

Multiple agents coordinated to deliver end-to-end outcomes. PM collects requirements, architect breaks down the system, engineers build, QA validates, DevOps deploys. Each agent hands off artifacts to the next.

The key property: the team defines handoff protocols — what artifact passes between agents, what “done” looks like at each stage, how failures propagate back.

Where most teams get it wrong

Almost everyone in the AI world is mixing up the layers.

MCP gets treated as a paradigm shift when it’s layer 1 plumbing. “Skills” are single API calls with a bow on top. “Agents” never actually choose between capabilities. “Multi-agent systems” are one agent doing everything sequentially with extra overhead.

This isn’t pedantry. When you conflate layers of abstraction, you invest engineering effort at the wrong altitude. I keep seeing teams pour weeks into another MCP integration while their agent has no coherent strategy for the goal that integration was supposed to serve. The tool works. The outcome doesn’t. That’s like hiring someone who knows how to use every app on earth but has no idea how to manage a project.

Where things actually break

The hardest problems aren’t at the bottom of this stack. Individual tools work well. Skills can be solid. Even single agents can be impressive.

The whole thing falls apart at the team level. And it falls apart for exactly the same reasons human teams fall apart:

• Handoff protocols are vague. What exactly does the PM hand to engineering? A spec? What schema? What level of detail?
• “Done” isn’t defined at each stage. Without explicit completion criteria, agents either over-produce or under-deliver.
• Iteration loops aren’t handled. QA finds a bug, sends it back to engineering, engineering fixes, QA re-tests. This cycle needs explicit modeling.
• Error propagation is undefined. When step 3 fails, does step 1 need to know?

I find that both humbling and kind of funny. We built these sophisticated AI systems, and they struggle with meetings and handoffs. The most human problems imaginable.

Design principles that fall out

Each layer earns its complexity. Don’t introduce an abstraction that doesn’t add genuine composition or decision-making. If your “agent” never switches between skills, delete the agent wrapper.

Boundaries are defined by handoff artifacts, not shared state. This is the microservices lesson all over again. Shared mutable state between agents is a coordination nightmare. Define the contract.

Judgment lives in agents, strategy lives in skills, capability lives in tools. When judgment leaks into your tool layer or strategy lives in your orchestrator, the boundaries are wrong.

Multi-agent coordination is expensive. Earn it. A single capable agent often beats a team of narrow agents. The coordination overhead is real and frequently exceeds the specialization benefit.

Invest in interfaces, not just agents. The handoff protocol between PM and engineering is higher-leverage work than making either agent 10% better in isolation.

Where to actually spend your time

Most teams over-invest in Layer 1 (another integration!) and under-invest in Layers 2 and 4. The highest-leverage work right now:

Better skills. Give agents real strategies for accomplishing goals, not just access to more tools. The difference between a junior and senior engineer isn’t the number of tools they know. It’s the strategies they bring to problems.

Better coordination. Define explicit handoff artifacts. Model iteration loops. Make “done” concrete at every stage. This is unsexy infrastructure work, which is exactly why it’s underinvested.

The abstractions we need for AI aren’t new. They’re the ones humans invented for organizing ourselves. Capabilities, skills, roles, teams. The hard part was never the technology at each layer. It was always the coordination between them. The people who’ll be best at building AI teams might not be the best programmers. They might be the best managers.