En diciembre de 2024, Anthropic publicó Building Effective Agents — una guía que define cinco patrones de workflow para sistemas con LLMs: prompt chaining, routing, parallelization, orchestrator-workers y evaluator-optimizer.
Si trabajas con Claude Code, ya usas varios sin saberlo. Cada vez que Claude delega una búsqueda a un sub-agente Explore o distribuye tareas entre workers paralelos, estás dentro de un patrón orchestrator-workers. Claude Code ofrece 6 mecanismos de extensión — skills, hooks, sub-agentes, MCP, plugins, agent teams — cada uno diseñado para escenarios distintos. La pregunta es cuál encaja con cada patrón.
Llevo meses aplicando estos patrones como parte de mi práctica profesional en Agentic AI. La mayoría se mapean de forma natural a la arquitectura de Claude Code. Pero hubo uno que no encajaba: el evaluator-optimizer.
El patrón que siempre encuentra algo
La definición de Anthropic es directa:
"One LLM call generates a response while another provides evaluation and feedback in a loop."
Un LLM genera, otro evalúa y da feedback. En bucle.
El problema es que en herramientas conversacionales como Claude Code no existe ese bucle automático. No hay un segundo LLM evaluando lo que produce el primero. Hay una conversación. Y en esa conversación, el único bucle eres tú.
Así que empecé a usarlo de forma manual. Después de una planificación extensa, o de investigar una base de código y producir un informe, o tras implementar una feature compleja, le pedía a Claude que evaluara su propio output. Cada afirmación, cada decisión, contrastada contra la realidad: código fuente, documentación oficial, archivos de configuración, hechos verificables.
El resultado fue consistente: siempre encontraba algo. No errores graves — matices. Una asunción parcialmente correcta. Una referencia de API basada en la memoria del modelo en lugar del código actual. Una decisión que se sostenía pero cuya justificación no era exacta.
Para tareas medianas o grandes, el patrón demostró su valor de forma empírica. Así que decidí formalizarlo.
La pregunta de implementación: skill o sub-agente
Claude Code ofrece dos primitivas principales para encapsular comportamiento reutilizable: skills y sub-agentes. La decisión entre ambas no es estética — depende de un factor técnico concreto.
Si no conoces las skills en detalle, la guía de skills de Claude Code cubre la anatomía. Para esta decisión, lo que importa es dónde se ejecuta cada una.
Una skill inline (sin context: fork) se ejecuta dentro de la conversación principal. Ve todo: el plan, el informe, los cambios de código. La documentación oficial lo confirma:
"This content runs inline so Claude can use it alongside your conversation context."
Un sub-agente se ejecuta en su propio contexto aislado:
"Each subagent runs in its own context window with a custom system prompt, specific tool access, and independent permissions."
Una skill con context: fork también pierde el acceso:
"It won't have access to your conversation history."
Para el evaluator-optimizer, esto lo decide todo. El evaluador necesita ver lo que se acaba de producir. Sin el contexto de la conversación, tendría que redescubrir todo desde cero — perdiendo exactamente lo que hace valioso al patrón.
flowchart TD
A["¿El evaluador necesita ver\nel output previo?"] -->|Sí| B["Skill inline"]
A -->|No| C["¿Necesita aislamiento?"]
C -->|Sí| D[Sub-agente]
C -->|No| E["Skill con context: fork"]
La respuesta fue clara: una skill inline. No un sub-agente. No una skill forkeada. La documentación oficial de Claude Code lo respalda directamente:
"Consider Skills instead when you want reusable prompts or workflows that run in the main conversation context rather than isolated subagent context."
Construyendo la skill
El archivo SKILL.md completo:
---
name: evaluate
description: Evaluator-Optimizer pattern. Critically evaluates every claim,
decision, and assertion from the previous output against verifiable evidence
from code, documentation, configuration, and other sources.
disable-model-invocation: true
argument-hint: [passes]
allowed-tools: Read, Grep, Glob, Bash, WebFetch, WebSearch
---
Decisiones de diseño que importan:
disable-model-invocation: true
El usuario decide cuándo evaluar, no Claude. No quieres que el evaluador se active automáticamente después de cada respuesta — solo cuando el output lo merece. Con este flag, la skill solo responde a /evaluate.
allowed-tools
El evaluador necesita poder buscar y leer para contrastar claims. Read, Grep, Glob para el código local. Bash para comandos de verificación. WebFetch y WebSearch para documentación externa. Puedes profundizar en cómo funciona este campo en allowed-tools en skills.
$ARGUMENTS para pasadas múltiples
Las skills soportan argumentos vía $ARGUMENTS. /evaluate 2 ejecuta dos pasadas; /evaluate sin argumentos ejecuta una. No hay valores por defecto nativos — se maneja en las instrucciones de la skill.
El sistema de veredictos
Cada claim del output anterior se clasifica en:
| Veredicto | Significado |
|---|---|
VERIFIED |
Evidencia directa lo respalda |
PARTIALLY CORRECT |
La idea central es correcta pero los detalles no |
UNVERIFIED |
No se encontró evidencia para confirmar ni negar |
INCORRECT |
La evidencia lo contradice directamente |
OUTDATED |
Fue correcto en algún momento pero ya no |
La regla clave: todo veredicto debe citar una fuente específica — ruta de archivo con línea, URL, output de un comando. "Creo que" no es evidencia. Si no hay fuente, el veredicto es UNVERIFIED.
Pasadas múltiples
La pasada 1 evalúa el output original. La pasada 2 evalúa la propia evaluación: ¿se leyó bien la evidencia? ¿Se omitieron claims? ¿Se verificó superficialmente? Es el patrón aplicado sobre sí mismo.
Esto no es un bucle automático — es el mismo principio aplicado con intención. Para automatización determinista (pre-commit checks, linting), los hooks son la herramienta correcta. Para evaluación basada en juicio, una skill.
El momento meta: evaluando al evaluador
Usé /evaluate sobre el propio análisis que produjo la skill — la comparativa skill vs sub-agente, las afirmaciones sobre argumentos, la recomendación final.
El resultado: 21 claims identificados. 18 verificados. 3 parcialmente correctos.
Los hallazgos interesantes:
| Claim | Veredicto | Problema |
|---|---|---|
| "Sub-agente recibe un resumen de la conversación" | PARTIALLY CORRECT |
No es un "resumen" — es un delegation message que Claude construye activamente. La distinción importa: Claude elige qué incluir |
WebSearch en allowed-tools es válido |
PARTIALLY CORRECT |
La herramienta existe y funciona, pero no aparece en ningún ejemplo de la documentación oficial. Funciona, pero sin respaldo documental |
| Skills forkeadas no soportan pasadas múltiples naturales | PARTIALLY CORRECT |
Cada invocación es aislada, pero los resultados vuelven al main conversation — la segunda invocación podría recibir los hallazgos previos vía delegation message |
Ningún claim resultó INCORRECT. Pero tres asunciones que parecían sólidas tenían matices que no habría detectado sin el patrón. Ese es exactamente el punto: no busca errores graves, busca las grietas que se abren bajo presión.
Lo que viene
El evaluator-optimizer fue el patrón más difícil de ubicar porque no se mapea a una feature de Claude Code — se mapea a una práctica. No es un hook que se ejecuta automáticamente ni un sub-agente que Claude invoca solo. Es una decisión deliberada de parar y verificar.
Este es el primero de varios patrones agenticos que estoy convirtiendo en workflows de Claude Code. Los otros — prompt chaining, orchestrator-workers — se mapean de forma más directa a la arquitectura nativa. Pero el evaluator-optimizer requería pensamiento lateral: entender que el mejor lugar para un evaluador no es un proceso aislado, sino el centro de la conversación.
Si estás construyendo workflows serios con Claude Code — la guía profesional de Claude Code cubre el ecosistema completo — estos patrones son los que te llevan de prompts ad-hoc a procesos repetibles y verificables.
Referencia: Building Effective Agents — Anthropic | Claude Code Skills — Documentación oficial