Three parts, one agent: Phil Schmid's 2026 stack

In 22 days, Phil Schmid has published three deep dives that, without him setting out to, form the unwritten manual for building a serious agent in 2026. Skills, on April 13. MCP servers, on April 27. Subagents, on May 5. Three technical pieces three weeks apart that, read as a single document, answer the three questions you have to address every time you build a production agent: what does the agent know about the task, which external systems can it reach, and how does it scale when one call isn’t enough.

Phil didn’t write a guide. He wrote three independent posts. What follows is the synthesis of the three, and it’s worth more than most of the guides that show up as such this spring.

Skills: recipes for the agent, not procedures

On April 13, Phil published 8 tips for writing skills. The definition is brutally simple: a skill is a folder with a SKILL.md file and, optionally, scripts/, references/, and assets/.

my-skill/
├── SKILL.md          ← the only required file
├── scripts/          ← reusable code the agent runs
├── references/       ← docs the agent reads when needed
└── assets/           ← templates, images, output files

The three tips that will change how you write your next skill most:

Nail the description. The field that triggers skill activation isn’t secondary, it’s the whole thing. Anti-pattern: “Helps with documents”. Done right: “Create, edit, and analyze .docx files, use for tracked changes, comments, formatting, or text extraction”. The difference between the skill activating when it should or never.

Instructions, not step-by-step procedures. “When you dictate every step, you take away their ability to adapt, recover from errors, or find better approaches.” Describe the outcome, not the sequence. Anti-pattern: “Step 1: Read file. Step 2: Parse JSON. Step 3…”. Right: “Update the database port in the config file to the value specified by the user.”

Negative cases are mandatory. Explicitly define when the skill should NOT activate. “Use when working with PDF files. Do NOT use for general document editing, spreadsheets, or plain text files.” Without the negative clause, the skill gets into places it shouldn’t and degrades the rest of the system.

And the closing line that frames the others: “If exact steps matter, write a script. If the task is fragile, that’s not a skill problem, it’s a scripting problem.” Your skill is not an imperative program. If you need exact steps, that’s code, not instructions.

Audit every skill you already have. Does the description distinguish when to fire and when not? Are the instructions outcomes or sequences? If you find yourself spelling out “Step 1, Step 2…”, that’s a script, not a skill.

MCP servers: external tooling with brakes

On April 27, Phil publishes his piece on MCP servers. MCP (Model Context Protocol) is the standard for wiring external tools to an agent — databases, internal APIs, ticket systems — and its public narrative has implicitly been “the more MCPs you have active, the more capable your agent”. Phil breaks the frame directly: “MCP servers are not dead. But blindly enabling them bloats your context, which leads to higher cost and worse performance.”

The operational problem: loading 30 MCPs as global tools injects 30 tool definitions into every request. Each definition is context that takes space, distracts the model from the real task, and gets paid for per token. Most of those tools won’t get called in 95% of requests.

The two patterns he proposes to avoid this:

Explicit injection. MCPs don’t load by default. The user mentions them with @server and only then they’re resolved, listTools() runs on the specific server, and its tools are injected into the array. Outside that mention, they don’t exist in context.

Subagent-scoped MCP. Declare MCPs in the subagent definition with allowed_tools for least privilege:

mcp_servers:
  - url: https://github-mcp.example
    allowed_tools: [list_pulls, list_reviews, get_diff]

The subagent sees only those 3 tools. Not 30. Not 100.

Audit the MCPs you have active globally. For each one, look at the last 50 sessions and count how many times one of its tools was called. If it’s under 5%, it shouldn’t be global — it should be explicit injection or live inside a subagent.

Subagents: the 4 orchestration patterns

On May 5, Phil publishes the densest piece: 4 patterns for orchestrating subagents — the secondary agents a main agent invokes to isolate tasks and scale. The thesis is that “isolating tasks into focused agents with their own context, tools, and instructions improves reliability” — but how you isolate them comes in 4 flavors with different tradeoffs.

Pattern 1 — Inline Tool. The subagent is a function call. The main agent invokes call_agent(task, agent, tools), waits for the response as a tool response, and moves on. Fire-and-forget. No lifecycle management. Works on any model with tool use.

{
  "name": "call_agent",
  "arguments": {
    "task": "Review PR #42 for security issues",
    "agent": "security-reviewer",
    "tools": ["read_file", "search_code"]
  }
}

Pattern 2 — Fan-Out. The main spawns N agents and gets back IDs immediately, then calls wait_agent to collect results. Useful for genuinely independent parallel tasks. Phil’s concrete example: a test-writer that updates 12 tests in parallel. The model has to reason correctly about when to call wait_agent — if it calls too early, it blocks; if it calls too late, it loses sync.

Pattern 3 — Agent Pool. Persistent subagents with messaging. The main keeps 2–4 agents alive, sends them follow-up instructions, coordinates work. Phil puts the ceiling concretely at “2–4 agents okayish” with frontier models. Beyond that, non-frontier models lose track of multi-agent state. The minimum tool surface: spawn_agent, send_message, wait_agent, list_agents, kill_agent.

Pattern 4 — Teams. Agents talk to each other directly without going through the main. The main sets up the roles and steps back. Only works if every agent is frontier-capable; debugging chains of inter-agent messages is hard.

The migration rule Phil makes explicit: “Start with Pattern 1. Move to Pattern 2 for genuinely independent parallel work. Move to Pattern 3 when agents need to collaborate. Pattern 4 is for when coordination logic exceeds what a single agent can manage.” And the reminder that changes the investment calculus: “A task that takes 4 coordinated agents today may be solvable by a single agent with a better model tomorrow.”

Audit the agent you have in production. Which pattern does it live in? If it’s in Pattern 3 without needing it (multi-agent state a single agent would handle), you’re paying complexity without ROI. If it’s in Pattern 1 when it should be 2 (independent parallelizable tasks forced to serial), you’re leaving latency and cost on the table.

The synthesis: three levers, one agent

Phil didn’t write a guide. But the three posts together compose a clear model of what a practitioner has to decide when building a serious agent in 2026:

• Skills — what the agent knows about the task. Defines the recipe. Anti-pattern: forgetting the negative cases.
• MCP — what external systems the agent reaches. Defines the scope. Anti-pattern: enable everything.
• Subagents — how it scales when one call isn’t enough. Defines the orchestration. Anti-pattern: starting at Pattern 4 when 1 would do.

And the Phil line that ties the three together: “The framework provides the tools. The model controls the orchestration.” Your job as a practitioner isn’t to train the model (you can’t) or pick the model (frontiers converge). Your job is to decide well the three levers you do control — skill, MCP, subagent pattern — so the model orchestrates over the substrate you design.

The three pieces evolve at different speeds, and that tells you where to invest. Skills are highly stable: a well-written skill today works tomorrow. Invest deep. MCP is maturing as a protocol: invest with discipline, not in quantity. Subagents are still experimental: the winning pattern of 2026 may not be 2027’s. Invest light, without coupling too tightly to the specific pattern.

When did you last redesign your agent’s three layers

If the last time you redesigned your agent layer by layer was “when I built it initially”, chances are you’re running a setup that today’s Phil would already call legacy. When was the last time you questioned it like that, with the three questions in hand?