TECHThe Smallest Agent That Works, Part 3: The Three Agents With StateTECHThe Smallest Agent That Works, Part 2: The Three Reach-Out AgentsTECHThe Smallest Agent That Works, Part 1: The Three Cheap AgentsTECHWhat MLX Got to Throw Away (That PyTorch Can't)TECHThe Unified-Memory Bet: Why On-Device Inference Stopped Being a ToyTECHEvery Useful Skill Is One of Five ShapesTECHMCP Gives You the Kitchen. Skills Are the Recipe.TECHThe Three-Level Skill, and Why Yours Is Probably One Level Too ManyTECHThe Smallest Agent That Works, Part 3: The Three Agents With StateTECHThe Smallest Agent That Works, Part 2: The Three Reach-Out AgentsTECHThe Smallest Agent That Works, Part 1: The Three Cheap AgentsTECHWhat MLX Got to Throw Away (That PyTorch Can't)TECHThe Unified-Memory Bet: Why On-Device Inference Stopped Being a ToyTECHEvery Useful Skill Is One of Five ShapesTECHMCP Gives You the Kitchen. Skills Are the Recipe.TECHThe Three-Level Skill, and Why Yours Is Probably One Level Too Many
AI × Forward
Subscribe
Tech

MCP Gives You the Kitchen. Skills Are the Recipe.

Most teams ship one of these and call the job done. MCP gives the agent tools. Skills tell it which to use, in what order, with which fallbacks. Without skills, your MCP integration ends with users asking 'okay, what now?'

Initial Editor·2026-05-13·4min read·737 words

You can connect an MCP server in five minutes and watch the agent fail to use it. Connection isn't competence. The agent has tools and no plan — like a kitchen with no recipes. Skills are the part most integrations forget to ship.

What each layer actually does

Layer Provides Without it When it stands alone
MCP Connection to external services — tools, data, real-time access Agent can't reach your service at all Demos. Power users who already know the system.
Skills Workflows, order, best practices, error recovery Agent can reach the service but doesn't know what to do Document creation, internal workflows, anything that doesn't need external connectivity.

MCP answers what can the agent do? Skills answer what should it do, and when? Most production setups need both, and the split tells you which problems each one solves.

The failure mode of MCP without skills

Ship a Linear MCP server. Connect it to a hundred users. Watch what happens.

  • "How do I create a sprint in Linear?"
  • "What labels should I use?"
  • "Which fields are required?"
  • "Why did it fail when I asked for X?"

Each ticket is the same shape: the user can reach the system but doesn't know the workflow. The MCP server isn't broken — it's doing exactly what it advertised. But the integration feels broken because the agent has no opinion about how to use it well.

That gap is the case for a skill. Not "another MCP feature." A separate layer that captures the workflow: "for sprint planning, fetch the active cycle, check team capacity, then create issues with these required fields." The skill loads when the user says "sprint planning" and hands the agent the playbook your support team has been writing one ticket at a time.

The failure mode of skills without MCP

The opposite shape. A skill exists, the workflow is documented, but the agent can't execute because the connectivity isn't there. Useful for skills that work against the model's built-in tools (document creation, code, design) and useless for anything that needs an external system.

If your skill says "fetch the project from Linear" and there's no Linear MCP wired up, the skill is a runbook with no hands. Both layers, or neither — half is the trap.

How to decide which layer a problem belongs in

The split is usually obvious if you ask the right question. Does this require reaching an external system?

  • Yes → MCP. Connectivity belongs there. Auth, tool schemas, real-time data, write actions against third-party state.
  • No → Skill. Workflow belongs here. Order of operations, decision trees, error handling logic, output formatting, "what to do when the user asks X."

Where it gets blurry: workflow that uses connectivity. A skill that orchestrates four MCP calls in sequence is doing skill-layer work (deciding the order, validating between steps, handling failures) on top of MCP-layer capabilities. The skill doesn't replace the MCP server; it composes calls to it.

Two layers, one user experience

The user doesn't see the split. They type "set up a new customer in PayFlow" and they expect the agent to (a) know how, (b) actually do it. The skill provides the how. The MCP provides the do. Either one alone breaks the experience.

A diagnostic: read your last twenty support tickets. If most of them are "how do I" questions, you're missing skills. If most are "it failed" questions, you're missing MCP robustness. The mix tells you which layer is underbuilt.

When this two-layer model doesn't apply

Two cases where the split isn't worth enforcing:

  • The agent's built-in tools cover the use case. Document creation, code editing, spreadsheet manipulation — these run on capabilities the agent already has. Skills here stand alone with no MCP layer at all. The kitchen is already stocked.
  • You're shipping a power-user feature. If your users are technical and want raw tool access, skipping the skills layer is a deliberate choice. The trade-off is documentation overhead — every user has to learn the workflow themselves — but for some audiences that's fine.

A connector without workflows is a feature waiting to become a support ticket. A workflow without connectivity is a recipe with no ingredients. Ship both, or ship neither and admit you're building demoware.

// more in tech

see all →
Tech· 2026-05-29· 5min

The Smallest Agent That Works, Part 3: The Three Agents With State

Stateless agents fit most tasks. State is the most expensive capability you can add — it doubles your operational surface, breaks your debugging, and rewards exactly the use cases that can't survive without it. Memory, environment control, self-learning. Part 3 of three.

#agent-architecture#ai-engineering#ai-agents#system-design
Tech· 2026-05-27· 5min

The Smallest Agent That Works, Part 2: The Three Reach-Out Agents

When the cheap tiers run out, the agent has to reach beyond the model itself — into knowledge it doesn't have, tools it can't natively use, or its own previous answer. RAG, tool use, and self-critique: three patterns, three failure modes worth pricing in. Part 2 of three.

#llm#rag#agent-architecture#ai-engineering
Tech· 2026-05-26· 5min

The Smallest Agent That Works, Part 1: The Three Cheap Agents

Most agent stacks are built one tier too capable for the job. Three of the cheapest architectures — a fixed pipeline, an LLM with rule constraints, and a reasoning loop — solve more problems than the architecture diagrams admit. Part 1 of three.

#llm#agent-architecture#ai-engineering#ai-agents
Tech· 2026-05-15· 5min

What MLX Got to Throw Away (That PyTorch Can't)

Every mature framework is a museum of decisions you can't take back. MLX is interesting mostly because it started after the decisions that matter for Apple Silicon were already mistakes — and the things it threw away are the things that were quietly costing the rest of us the most.

#ai-engineering#apple-silicon#mlx#ml-frameworks
Tech· 2026-05-15· 5min

The Unified-Memory Bet: Why On-Device Inference Stopped Being a Toy

For two years the industry's default answer to every inference question has been "bigger cluster." A different hardware topology is quietly making that the wrong default for a non-trivial slice of workloads — and the framework layer that earns it is the buzzword most decks haven't caught up with yet.

#hardware#ai-infrastructure#inference#edge-ai
Tech· 2026-05-14· 5min

Every Useful Skill Is One of Five Shapes

Skills aren't a freeform format. The useful ones fit one of five shapes — sequential workflow, multi-MCP coordination, iterative refinement, context-aware selection, domain-specific intelligence. Picking the right shape is most of the design work. Picking the wrong one is most of the bugs.

#claude-code#workflow#agents#skills