El gran problema económico de los agentes de IA no está solo en el precio por millón de tokens. Está en usar el modelo equivocado para cada parte del trabajo. Un agente que programa, navega por la web, lee documentación, llama herramientas, prueba cambios y corrige errores no necesita la misma inteligencia en todos sus pasos. La mayor parte del tiempo ejecuta tareas mecánicas. Solo en algunos momentos necesita criterio de alto nivel.
Anthropic ha formalizado esa idea con dos patrones que apuntan a una arquitectura más eficiente: el modelo asesor y el modelo orquestador. La idea de fondo es sencilla: separar quién hace el trabajo de quien toma las decisiones difíciles.
En el primer patrón, un modelo más barato actúa como executor. Lee, usa herramientas, escribe, prueba, corrige y avanza. Cuando se atasca, llama a un modelo más potente como advisor. Ese asesor no ejecuta herramientas ni toma el control del agente. Solo lee el contexto y devuelve una orientación breve: un plan, una corrección, una advertencia o una recomendación de parada. Anthropic describe el advisor como una herramienta beta que permite a un modelo executor más rápido y económico consultar a un modelo de mayor capacidad durante la generación para recibir orientación estratégica.
La tesis es potente porque cambia una costumbre muy extendida: usar siempre el mejor modelo para todo. En agentes reales, esa estrategia suele disparar costes. La alternativa tampoco es ideal: usar solo un modelo barato reduce la factura, pero aumenta vueltas, errores y bloqueos. La estrategia del asesor intenta quedarse en un punto intermedio: el modelo económico hace casi todo; el modelo caro aparece solo cuando aporta criterio.
El asesor no manda: aconseja
El detalle técnico más interesante es el reparto de poder. El advisor no tiene herramientas. No ejecuta comandos, no abre archivos, no llama APIs, no modifica código. El executor decide cuándo consultarlo y continúa después con la tarea. En la documentación de Anthropic, el advisor recibe el historial completo de la conversación, produce un plan o una corrección de rumbo y devuelve el resultado al executor, que sigue trabajando.
Esto evita un problema habitual en sistemas multiagente: que el modelo potente acabe haciendo todo. Si el advisor tuviera control completo, la arquitectura se parecería demasiado a usar el modelo caro en cada turno. Al limitarlo a texto, su coste se concentra en los momentos de más valor.
| Rol | Qué hace | Qué no hace |
|---|---|---|
| Executor | Usa herramientas, lee resultados, escribe, prueba y avanza | No necesita resolver solo todas las decisiones difíciles |
| Advisor | Lee el contexto y devuelve consejo estratégico | No ejecuta herramientas ni controla el bucle |
| Orchestrator | Planifica y reparte tareas entre subagentes | No tiene por qué leer todo el material bruto |
| Worker | Ejecuta trabajo pesado y repetitivo | No decide la estrategia global |
Anthropic señala que este patrón encaja especialmente en cargas agentic largas: agentes de programación, uso de ordenador, investigación en varios pasos o cualquier flujo donde muchas acciones sean mecánicas, pero un buen plan tenga mucho impacto. También advierte de que no sirve igual para preguntas simples de un solo turno o tareas donde cada paso requiera la capacidad plena del modelo asesor.
Menos vueltas también es menos coste
La economía del advisor no depende solo de que el modelo barato tenga menor tarifa. Depende de que el asesor reduzca vueltas innecesarias. Un agente que se equivoca menos, prueba menos caminos inútiles y recibe una corrección temprana puede gastar menos aunque haga alguna llamada puntual a un modelo más caro.
En la documentación, Anthropic explica que los tokens del executor y del advisor se facturan por separado. Los campos principales de uso reflejan los tokens del executor, mientras que las llamadas al advisor aparecen como entradas propias en usage.iterations, facturadas a la tarifa del modelo asesor. La compañía también indica que la salida típica del advisor suele rondar entre 400 y 700 tokens de texto, o entre 1.400 y 1.800 tokens si se incluye pensamiento en cargas más exigentes.
Ese punto es esencial. El modelo caro no genera toda la respuesta final, ni todos los logs, ni todos los cambios de código. Solo aporta dirección. La salida larga y el trabajo con herramientas los asume el executor.
| Patrón | Cuándo encaja mejor | Riesgo principal |
|---|---|---|
| Executor + advisor | Coding, agentes largos, tareas con bloqueos puntuales | Llamar demasiado tarde o demasiado a menudo |
| Orquestador + workers | Investigación, lectura masiva, análisis de muchos documentos | Delegar mal y perder información importante |
| Modelo fuerte solo | Tareas críticas donde cada paso exige máximo razonamiento | Coste elevado |
| Modelo barato solo | Volumen alto y tareas mecánicas | Atascos y más prueba-error |
Los resultados compartidos por la cuenta ClaudeDevs van en esa dirección. Según esa publicación, Sonnet 5 con Fable 5 como advisor alcanza alrededor del 92 % de la puntuación de Fable 5 en SWE-bench Pro con cerca del 63 % del precio, llamando a Fable de forma poco frecuente, aproximadamente una vez por tarea.
Conviene leer estas cifras con cautela. Son evaluaciones de Anthropic, no una reproducción independiente en cada caso de uso. Pero el patrón sí resulta coherente con la estructura de costes de los agentes: reservar el modelo fuerte para decisiones de alto impacto puede reducir el coste total si evita caminos fallidos.
El segundo patrón: planificar con el grande, ejecutar con pequeños
El advisor resuelve una parte del problema, pero Anthropic también propone el patrón inverso: usar el modelo potente como orquestador. En vez de consultarlo dentro del bucle de un executor, el modelo grande planifica, divide el trabajo y delega en subagentes más baratos.
Este patrón encaja bien cuando la tarea consume muchos tokens leyendo o buscando información. En una investigación web, por ejemplo, no siempre hace falta que el modelo más caro lea todas las páginas. Puede diseñar el plan, repartir subpreguntas y pedir a workers más baratos que hagan la lectura. Cada worker trabaja en su propio contexto, resume hallazgos y devuelve resultados filtrados.
El cookbook de Anthropic sobre Claude Managed Agents describe precisamente este enfoque como “big models for planning, small models for execution”: un coordinador de mayor capacidad planifica y sintetiza, mientras trabajadores más económicos hacen la lectura pesada en paralelo. El ejemplo está orientado a investigación web con verificación de hechos, pero la misma lógica se puede aplicar a revisión documental, análisis de logs, exploración de repositorios o barridos de código.
La diferencia con el advisor es sutil, pero importante. En el patrón advisor, el modelo pequeño lleva la tarea y consulta al fuerte cuando necesita criterio. En el patrón orquestador, el modelo fuerte lleva el plan y reparte trabajo a modelos más baratos.
| Estrategia | Modelo caro | Modelo barato |
|---|---|---|
| Advisor | Aconseja bajo demanda | Ejecuta la mayor parte del flujo |
| Orquestador | Planifica, delega y sintetiza | Lee, busca, extrae y reporta |
| Todo con modelo caro | Hace todo | No participa |
| Todo con modelo barato | No participa | Hace todo, incluso decisiones difíciles |
Según publicaciones que recogen la comunicación de Anthropic, el patrón con Fable 5 como orquestador y workers Sonnet 5 en BrowseComp logró en sus pruebas cerca del 96 % del rendimiento de Fable 5 en solitario con alrededor del 46 % del coste. La propia documentación de Managed Agents permite crear equipos con subagentes y roles separados, lo que hace posible este tipo de reparto.
Por qué esto importa para los equipos que construyen agentes
La discusión no es solo de Anthropic ni de Claude. Es una pista de hacia dónde se está moviendo el diseño de agentes. El siguiente salto no vendrá únicamente de modelos más grandes, sino de arquitecturas que usen bien modelos distintos.
Un agente empresarial no debería ser una llamada monolítica a “el mejor modelo disponible”. Debería parecerse más a un sistema operativo pequeño: roles, permisos, cachés, límites, presupuestos, herramientas y decisiones de encaminamiento. Qué modelo lee. Qué modelo decide. Qué modelo ejecuta. Qué modelo revisa. Qué información entra en cada contexto. Qué se cachea. Qué se descarta.
Anthropic también insiste en varios controles prácticos. El advisor está en beta y requiere el encabezado advisor-tool-2026-03-01; no está disponible en todos los entornos, y la documentación indica disponibilidad en Claude API y Claude Platform en AWS, pero no en Amazon Bedrock, Google Cloud o Microsoft Foundry. Además, el modelo advisor debe ser al menos tan capaz como el executor.
Hay más detalles de coste. El advisor puede usar max_tokens propio para limitar su salida. Anthropic recomienda empezar con 2.048 tokens como límite en algunos escenarios, y afirma que en una prueba interna de razonamiento difícil redujo la salida media del advisor alrededor de siete veces frente a no poner límite, sin degradación detectable en esa muestra. También recomienda activar caché del advisor solo cuando se esperan tres o más llamadas en la conversación, porque con menos llamadas el coste de escritura de caché puede no compensar.
La arquitectura gana al modelo único
La lección práctica es clara: el modelo más inteligente no siempre debe ejecutar todo. Muchas tareas agentic tienen una pequeña parte de juicio y una parte enorme de trabajo repetitivo. Si se mezclan ambas cosas en un único modelo caro, la factura crece demasiado. Si se delega todo en un modelo barato, baja la calidad.
Separar ejecución y criterio permite una tercera vía. El modelo económico mantiene el ritmo, usa herramientas y consume la mayoría de tokens. El modelo fuerte entra como consultor, arquitecto o revisor cuando hace falta. Y, cuando la tarea exige leer mucho, el orquestador puede repartir trabajo a subagentes más baratos para no arrastrar todo el material bruto al contexto más caro.
Esto no elimina la necesidad de medir. Cada equipo tendrá que probar sus propios flujos, porque los resultados dependen del tipo de tarea, del número de llamadas, de la longitud del contexto, del coste de los errores y de la calidad mínima aceptable. Un agente de soporte interno no tiene las mismas exigencias que un agente que modifica código en producción o uno que toma decisiones financieras.
Pero el mensaje de diseño sí parece general: la pregunta ya no es “qué modelo uso”, sino “qué papel cumple cada modelo dentro del sistema”.
Esa puede ser la arquitectura que haga viables más agentes en producción. No agentes más espectaculares, sino agentes más baratos, medibles y gobernables.
Preguntas frecuentes
¿Qué es el patrón advisor de Anthropic?
Es una arquitectura en la que un modelo executor más barato hace la mayor parte del trabajo y consulta a un modelo más potente solo cuando necesita orientación estratégica.
¿El advisor puede ejecutar herramientas?
No en este patrón. El advisor lee el contexto y devuelve consejo como texto. El control y las herramientas permanecen en el executor.
¿Qué ventaja tiene frente a usar siempre el mejor modelo?
Puede reducir coste total porque el modelo caro no genera toda la salida ni ejecuta todos los pasos. Solo interviene en decisiones donde aporta más valor.
¿Qué diferencia hay entre advisor y orquestador?
El advisor aconseja a un executor que ya está trabajando. El orquestador planifica y delega tareas a subagentes, normalmente más baratos, que ejecutan partes del trabajo.
¿Sirve para cualquier agente?
No. Encaja mejor en tareas largas, con herramientas, investigación, código o muchos pasos. En preguntas simples de un turno puede añadir coste sin aportar mucho.
¿Qué deben medir los equipos antes de adoptarlo?
Coste por tarea, tasa de éxito, número de llamadas al advisor, longitud de sus respuestas, latencia, errores evitados y calidad frente a un modelo único.
