Tres piezas, un agente: el stack 2026 según Phil Schmid

En 22 días, Phil Schmid ha publicado tres deep-dives que sin proponérselo forman el manual no escrito de cómo se monta un agente serio en 2026. Skills, el 13 de abril. MCP servers, el 27 de abril. Subagents, el 5 de mayo. Tres piezas técnicas separadas por tres semanas que, leídas como una sola, responden las tres preguntas que te tienes que hacer siempre que construyes un agente en producción: qué sabe el agente sobre la tarea, a qué sistemas externos llega, cómo escala cuando una sola llamada no basta.

Phil no ha escrito una guía. Ha escrito tres posts independientes. La síntesis de los tres es lo que sigue, y vale más que la mayoría de las guías que aparecen como tales esta primavera.

Skills: recetas del agente, no procedimientos

El 13 de abril Phil publica 8 tips para escribir skills. La definición es brutalmente sencilla: una skill es una carpeta con un fichero SKILL.md y, opcionalmente, scripts/, references/ y assets/.

my-skill/
├── SKILL.md          ← único fichero obligatorio
├── scripts/          ← código reutilizable que el agente ejecuta
├── references/       ← docs que el agente lee cuando hace falta
└── assets/           ← templates, imágenes, ficheros del output

Los tres tips que más van a cambiar cómo escribes tu próxima skill:

Acertar la description. El campo que dispara la activación de la skill no es secundario, es el todo. Anti-patrón: “Helps with documents”. Bien escrito: “Create, edit, and analyze .docx files, use for tracked changes, comments, formatting, or text extraction”. La diferencia entre que tu skill se active cuando toca o nunca.

Instrucciones, no procedimientos paso a paso. “When you dictate every step, you take away their ability to adapt, recover from errors, or find better approaches.” Describe el outcome, no la secuencia. Anti-patrón: “Step 1: Read file. Step 2: Parse JSON. Step 3…”. Bien: “Update the database port in the config file to the value specified by the user.”

Negative cases obligatorios. Define explícitamente cuándo la skill NO debe activarse. “Use when working with PDF files. Do NOT use for general document editing, spreadsheets, or plain text files.” Sin la cláusula negativa, la skill se mete en sitios que no le corresponden y degrada el resto del sistema.

Y la frase que cierra y que enmarca las otras: “If exact steps matter, write a script. If the task is fragile, that’s not a skill problem, it’s a scripting problem.” Tu skill no es un programa imperativo. Si necesitas pasos exactos, eso es código, no instrucciones.

Audita cada skill que ya tienes. ¿La description distingue cuándo SÍ y cuándo NO? ¿Las instrucciones son outcomes o son secuencias? Si te encuentras detallando “Step 1, Step 2…”, eso es script, no skill.

MCP servers: tooling externo con frenos

El 27 de abril Phil publica su análisis de los MCP servers. MCP (Model Context Protocol) es el estándar para conectar herramientas externas a un agente — bases de datos, APIs internas, sistemas de tickets — y su narrativa pública ha sido implícitamente “cuantos más MCPs activos, más capaz tu agente”. Phil rompe el marco directamente: “MCP servers are not dead. But blindly enabling them bloats your context, which leads to higher cost and worse performance.”

El problema operativo: cargar 30 MCPs como tools globales mete 30 tool definitions en cada request. Cada definition es contexto que ocupa sitio, distrae al modelo del task real, y se paga por token. La mayoría de esas tools no se llaman en el 95% de los requests.

Los dos patrones que propone para evitarlo:

Explicit injection. Los MCPs no se cargan por default. El usuario los menciona con @servidor y solo entonces se resuelven, se hace listTools() del servidor concreto, y sus tools se inyectan en el array. Fuera de esa mención, no existen en el contexto.

Subagent-scoped MCP. Declarar los MCPs en la definición del subagent con allowed_tools para least-privilege:

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

El subagent solo ve esas 3 herramientas. No 30. No 100.

Audita los MCPs que tienes activos como globales. Para cada uno, mira en las últimas 50 sesiones cuántas veces se llamó una de sus tools. Si es menos del 5%, no debería ser global — debería ser explicit injection o vivir dentro de un subagent.

Subagents: los 4 patrones de orquestación

El 5 de mayo Phil publica la pieza más densa: 4 patrones de orquestación de subagents, los agentes secundarios que un agente principal invoca para aislar tareas y escalar. La tesis es que “isolating tasks into focused agents with their own context, tools, and instructions improves reliability” — pero el cómo lo aíslas tiene 4 sabores con tradeoffs distintos.

Patrón 1 — Inline Tool. El subagent es una function call. El main agent invoca call_agent(task, agent, tools), espera la respuesta como tool response, y sigue. Fire-and-forget. Sin lifecycle management. Funciona en cualquier modelo con tool use.

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

Patrón 2 — Fan-Out. El main spawna N agents y recibe los IDs inmediatamente, después llama wait_agent para colectar. Sirve para tasks paralelos genuinamente independientes. El ejemplo concreto de Phil: un test-writer que actualiza 12 tests en paralelo. El modelo tiene que razonar correctamente cuándo llamar wait_agent — si lo llama antes de tiempo, bloquea; si lo llama tarde, pierde sincronía.

Patrón 3 — Agent Pool. Subagents persistentes con mensajería. El main mantiene 2-4 agents vivos, les envía instrucciones de seguimiento, coordina trabajo. Phil pone el techo concreto en “2-4 agents okayish” con frontier models. Más allá, modelos no-frontier pierden el rastro del estado multi-agent. La tool surface mínima: spawn_agent, send_message, wait_agent, list_agents, kill_agent.

Patrón 4 — Teams. Los agentes se hablan entre sí directamente sin pasar por el main. El main setea los roles y se aparta. Solo funciona si cada agent es de capacidad frontier; el debugging de cadenas de mensajes inter-agent es duro.

La regla de migración que Phil deja explícita: “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.” Y el recordatorio que cambia la inversión: “A task that takes 4 coordinated agents today may be solvable by a single agent with a better model tomorrow.”

Audita el agente que tienes en producción. ¿En qué patrón vive? Si está en Patrón 3 sin necesitarlo (multi-agent state que un solo agent llevaría), estás pagando complejidad sin ROI. Si está en Patrón 1 cuando debería ser 2 (tasks independientes paralelizables forzados a serie), estás dejando latencia y coste en la mesa.

La síntesis: tres palancas, un agente

Phil no ha escrito una guía. Pero los tres posts juntos componen un modelo claro de qué tiene que decidir un practitioner cuando construye un agente serio en 2026:

• Skills — qué sabe el agente sobre la tarea. Define la receta. Anti-patrón: olvidarte de los negative cases.
• MCP — a qué sistemas externos llega el agente. Define el alcance. Anti-patrón: enable everything.
• Subagents — cómo escala cuando una sola llamada no basta. Define la orquestación. Anti-patrón: empezar en Patrón 4 cuando el 1 sobraría.

Y la frase de Phil que enlaza los tres: “The framework provides the tools. The model controls the orchestration.” Tu trabajo como practitioner no es entrenar el modelo (no puedes) ni elegir el modelo (los frontiers convergen). Tu trabajo es decidir bien las tres palancas que sí controlas — skill, MCP, subagent pattern — para que el modelo orqueste sobre el sustrato que tú diseñas.

Las tres piezas evolucionan con velocidades distintas, y eso te dice dónde invertir. Skills son altamente estables: una skill bien escrita hoy funciona mañana. Invierte profundo. MCP está madurando como protocolo: invierte con disciplina, no en cantidad. Subagents siguen siendo experimentales: el patrón ganador del 2026 quizá no sea el del 2027. Invierte ligero, sin acoplarte demasiado al patrón concreto.

Cuándo rediseñaste por última vez las tres capas de tu agente

Si la última vez que rediseñaste tu agente capa por capa fue “cuando lo monté inicialmente”, lo más probable es que vayas con un setup que el Phil de hoy ya consideraría legacy. ¿Cuándo fue la última vez que lo cuestionaste así, con las tres preguntas en la mano?