M\u00e1s recientemente, en mi portal, publiqu\u00e9 un segundo art\u00edculo sobre c\u00f3mo Opus 5 super\u00f3 a Fable 5<\/a>. En este caso, aquella idea te\u00f3rica empez\u00f3 a verse reflejada en los datos: ante un modelo de primer nivel m\u00e1s caro y con ciertas limitaciones, las empresas empezaron a trasladar parte de su inversi\u00f3n a alternativas m\u00e1s econ\u00f3micas, reservando los modelos m\u00e1s potentes para las tareas que realmente los necesitan.<\/p>\n\n\n\n El siguiente paso es preguntarnos qu\u00e9 ocurre cuando no cambiamos de modelo una sola vez al principio de una conversaci\u00f3n, sino que construimos un sistema capaz de repartir el trabajo durante todo el proceso. Es decir, un sistema que asigna autom\u00e1ticamente diferentes funciones a distintos modelos y herramientas, sin que una persona tenga que elegir cada vez qu\u00e9 utilizar desde un men\u00fa desplegable.<\/p>\n\n\n\n En su forma m\u00e1s sencilla, el switching es la selecci\u00f3n del modelo (model selection): elegir cu\u00e1l es el m\u00e1s adecuado antes incluso de empezar a procesar una petici\u00f3n.<\/p>\n\n\n\n En una versi\u00f3n m\u00e1s avanzada, hablamos de routing. Aqu\u00ed el sistema utiliza informaci\u00f3n sobre la petici\u00f3n, el \u00e1mbito, el nivel de riesgo o el coste previsto para decidir qu\u00e9 camino debe seguir cada tarea.<\/p>\n\n\n\n En una versi\u00f3n todav\u00eda m\u00e1s din\u00e1mica, encontramos el cascade o sistema en cascada. En este caso, se intenta resolver primero el problema con un modelo econ\u00f3mico y solo se recurre a otro m\u00e1s potente si el resultado no es suficiente.<\/p>\n\n\n\n Por \u00faltimo, cuando hablamos de agentes, el switching se convierte en delegation o delegaci\u00f3n. La tarea se divide en diferentes partes y se asigna a distintos roles, que pueden tener modelos, herramientas y permisos diferentes.<\/p>\n\n\n\n Veamos un ejemplo pr\u00e1ctico. Una consulta de atenci\u00f3n al cliente sobre el estado de un env\u00edo puede resolverse en pocos segundos con un modelo econ\u00f3mico. Sin embargo, una reclamaci\u00f3n que implique una devoluci\u00f3n de mucho dinero o un posible problema legal necesitar\u00e1 un modelo m\u00e1s avanzado, acceso a documentaci\u00f3n adicional y, probablemente, una revisi\u00f3n humana antes de cerrar el caso.<\/p>\n\n\n\n Podemos entender este cambio con una comparaci\u00f3n bastante sencilla.<\/p>\n\n\n\n Un modelo \u00fanico ser\u00eda como tener a un profesional excepcional al que le pedimos que se encargue de absolutamente todo, desde las tareas administrativas m\u00e1s aburridas hasta los diagn\u00f3sticos m\u00e1s complejos.<\/p>\n\n\n\n Un sistema orquestado, en cambio, se parece m\u00e1s a una redacci\u00f3n o a un equipo de desarrollo. Cada tarea se asigna a quien mejor puede resolverla, teniendo en cuenta sus conocimientos, el coste, las herramientas disponibles y el nivel de responsabilidad que requiere.<\/p>\n\n\n\n Hay algo importante que debemos tener claro: esto no significa necesariamente que estemos creando una inteligencia artificial \u00abm\u00e1s inteligente\u00bb si nos fijamos \u00fanicamente en el modelo de lenguaje. Puede que, sencillamente, estemos construyendo un sistema m\u00e1s eficiente porque aprovecha mejor los recursos que tiene disponibles.<\/p>\n\n\n\n Por ejemplo, un modelo peque\u00f1o o r\u00e1pido puede encargarse de seleccionar informaci\u00f3n, extraer datos, clasificar contenidos y preparar primeros borradores. Un modelo de \u00faltima generaci\u00f3n puede intervenir \u00fanicamente cuando haga falta planificar, resolver situaciones ambiguas, tomar decisiones importantes o realizar una revisi\u00f3n final.<\/p>\n\n\n\n Tambi\u00e9n podemos recurrir a herramientas externas que no son modelos de lenguaje, sino programas inform\u00e1ticos capaces de comprobar datos, ejecutar pruebas o consultar bases de datos con una precisi\u00f3n que ning\u00fan LLM puede garantizar por s\u00ed solo.<\/p>\n\n\n\n El router es, en cierto modo, el recepcionista del sistema. Recibe una petici\u00f3n y analiza de qu\u00e9 tipo es y qu\u00e9 dificultad tiene. \u00bfEs una pregunta corta o larga? \u00bfNecesita conocimientos generales o un razonamiento m\u00e1s elaborado? \u00bfImplica poco o mucho riesgo? \u00bfNecesita herramientas externas?<\/p>\n\n\n\n Para tomar esta decisi\u00f3n puede utilizar reglas concretas definidas por quienes dise\u00f1an el sistema, un clasificador espec\u00edfico, otro modelo de lenguaje que act\u00fae como \u00e1rbitro o un sistema entrenado con datos que calcule la relaci\u00f3n entre calidad y coste de cada modelo disponible.<\/p>\n\n\n\n Sin embargo, el router tambi\u00e9n puede equivocarse. Si calcula que una tarea es m\u00e1s sencilla de lo que realmente es, puede enviarla a un modelo que no est\u00e9 preparado para resolverla y generar un resultado de poca calidad. Por el contrario, si considera que todas las tareas son complejas por precauci\u00f3n, acaba envi\u00e1ndolas al modelo m\u00e1s caro y pierde toda la ventaja econ\u00f3mica. En ese caso, el sistema deja de tener sentido.<\/p>\n\n\n\n El funcionamiento de la cascada es algo diferente.<\/p>\n\n\n\n En el routing tradicional, el sistema toma una decisi\u00f3n antes de generar cualquier respuesta: \u00abEsta pregunta va al modelo A\u00bb.<\/p>\n\n\n\n En un sistema en cascada, primero se genera una respuesta con un modelo econ\u00f3mico y, despu\u00e9s, se comprueba si es suficiente. Si no lo es, se corrige, se vuelve a generar, se env\u00eda a un revisor o se pasa a un modelo m\u00e1s caro.<\/p>\n\n\n\n El principal reto aqu\u00ed est\u00e1 en saber medir la calidad de la respuesta. El sistema puede utilizar puntuaciones de confianza, evaluadores espec\u00edficos, pruebas autom\u00e1ticas, comparaciones entre varias respuestas o un segundo modelo que act\u00fae como juez.<\/p>\n\n\n\n Pero este \u00faltimo tambi\u00e9n puede equivocarse, compartir los mismos sesgos que el modelo que ha generado la respuesta o dar m\u00e1s valor a una respuesta convincente que a una respuesta realmente correcta.<\/p>\n\n\n\n Un paso m\u00e1s all\u00e1 es dividir el problema en diferentes tareas.<\/p>\n\n\n\n Muchos de los trabajos que hacemos en el mundo real no tienen una \u00fanica respuesta. Suelen implicar una cadena de acciones: entender el objetivo, buscar fuentes, leer documentos, comparar opciones, hacer c\u00e1lculos o ejecutar c\u00f3digo, comprobar que se cumplen ciertos requisitos, preparar un resultado y, finalmente, revisarlo.<\/p>\n\n\n\n Un agente planner puede encargarse de crear un plan con todas esas subtareas y asignar cada una a quien corresponda. Por ejemplo:<\/p>\n\n\n\n Eso s\u00ed, hay algo importante que debemos tener en cuenta: dividir una tarea no siempre es mejor. Si el trabajo no se puede separar realmente en partes independientes, fragmentarlo puede hacer que se pierda informaci\u00f3n, a\u00f1adir pasos innecesarios y complicar la tarea de identificar d\u00f3nde se ha producido un error.<\/p>\n\n\n\n Anthropic ha recogido varios de estos patrones en su gu\u00eda \u00abBuilding effective agents\u00bb<\/a>. En ella define el modelo orchestrator-workers como un sistema central que divide din\u00e1micamente una tarea, delega las distintas partes en otros modelos y re\u00fane los resultados para crear una respuesta final.<\/p>\n\n\n\n Este enfoque resulta especialmente \u00fatil en problemas complejos en los que no podemos saber de antemano qu\u00e9 subtareas ser\u00e1n necesarias. Un ejemplo habitual es trabajar con proyectos de c\u00f3digo que afectan a varios archivos.<\/p>\n\n\n\n El \u00faltimo nivel es la verdadera orquestaci\u00f3n multiagente. Aqu\u00ed ya no hablamos \u00fanicamente de elegir modelos, sino de organizar todo el proceso: los roles, el orden de las acciones, las herramientas disponibles, la memoria compartida, los controles, los permisos, la gesti\u00f3n de errores, las condiciones para detenerse y qui\u00e9n asume la responsabilidad final si algo sale mal.<\/p>\n\n\n\n Un ejemplo pr\u00e1ctico nos ayuda a entender mejor todo esto.<\/p>\n\n\n\n El repositorio astra-flash-orchestrator<\/a>, publicado por el desarrollador Ethan+ (autor tambi\u00e9n de otros proyectos relacionados con agentes, como el asistente de voz Jarvis para Claude Code), est\u00e1 dise\u00f1ado como un flujo de trabajo nativo para Codex, el entorno de programaci\u00f3n basado en agentes de OpenAI.<\/p>\n\n\n\n La idea es que Astra se encargue de la planificaci\u00f3n, la arquitectura y la revisi\u00f3n final, mientras que DeepSeek V4.1 Flash, un modelo bastante m\u00e1s econ\u00f3mico, asume la implementaci\u00f3n, las pruebas y las tareas habituales de depuraci\u00f3n.<\/p>\n\n\n\n El funcionamiento, tal y como lo explica su creador en un debate p\u00fablico sobre el repositorio de Codex, es bastante f\u00e1cil de seguir.<\/p>\n\n\n\n Cuando recibe un objetivo complejo, Astra interpreta la petici\u00f3n, define su alcance y establece los criterios que debe cumplir el resultado. Despu\u00e9s, DeepSeek Flash se encarga de la implementaci\u00f3n: revisa el c\u00f3digo existente, escribe los cambios, ejecuta las pruebas y soluciona los problemas habituales que aparecen durante el proceso.<\/p>\n\n\n\n Por \u00faltimo, Astra revisa las modificaciones realizadas, comprueba que todo encaja con el plan inicial y decide si acepta el trabajo o si lo devuelve para hacer otra ronda de cambios.<\/p>\n\n\n\n En este proceso encontramos varias fases:<\/p>\n\n\n\n Es decir, no se trata de generar una respuesta de una sola vez, sino de trabajar mediante diferentes fases de revisi\u00f3n y mejora.<\/p>\n\n\n\n Lo interesante no son tanto los nombres de los modelos utilizados, que probablemente cambiar\u00e1n por otros en poco tiempo. Lo importante es que este ejemplo muestra de forma muy clara c\u00f3mo un sistema puede reservar el modelo m\u00e1s caro para las tareas que necesitan criterio y responsabilidad, mientras deja el trabajo m\u00e1s repetitivo y de mayor volumen en manos de un modelo mucho m\u00e1s econ\u00f3mico.<\/p>\n\n\n\n Astra act\u00faa como supervisor y Flash genera buena parte del trabajo operativo. Es una distribuci\u00f3n desigual de las responsabilidades y de la capacidad de decisi\u00f3n, no simplemente sustituir un modelo caro por otro barato.<\/p>\n\n\n\n Aqu\u00ed merece la pena adoptar una postura un poco m\u00e1s cr\u00edtica. En el debate original de GitHub, el autor cuenta que consigui\u00f3 reducir el uso de Astra aproximadamente un 94 %<\/a> durante una sesi\u00f3n de desarrollo de 23 horas.<\/p>\n\n\n\n Por otro lado, un an\u00e1lisis posterior del proyecto publicado por RuntimeWire<\/a> habla de una reducci\u00f3n de hasta el 98,9 % de los tokens de entrada consumidos por Astra por cada mil l\u00edneas de c\u00f3digo implementadas y probadas. Sin embargo, esta cifra se basa en una \u00fanica comparaci\u00f3n realizada en local, no en un benchmark controlado.<\/p>\n\n\n\n Son dos cifras diferentes, obtenidas de formas distintas, y hay que interpretarlas como tal: son datos compartidos por el propio autor del proyecto, no resultados de una evaluaci\u00f3n independiente que podamos aplicar a cualquier tipo de trabajo.<\/p>\n\n\n\n \u00bfQu\u00e9 deber\u00eda incluir entonces un benchmark realmente \u00fatil? Para empezar, tendr\u00eda que especificar los modelos utilizados, sus versiones, precios y la fecha en la que se realiz\u00f3 la medici\u00f3n. Tambi\u00e9n deber\u00eda detallar el tipo de repositorios analizados, su tama\u00f1o y nivel de dificultad; el n\u00famero de tareas realizadas; la tasa de \u00e9xito y qu\u00e9 se considera exactamente un resultado de la misma calidad.<\/p>\n\n\n\n Adem\u00e1s, habr\u00eda que contabilizar los tokens generados por todos los agentes implicados, no solo los del modelo premium que estamos evaluando. Tambi\u00e9n ser\u00eda necesario tener en cuenta el coste de los errores: nuevos intentos, correcciones, informaci\u00f3n adicional necesaria y tiempo que una persona ha tenido que dedicar a solucionar los problemas.<\/p>\n\n\n\n Y no podemos olvidarnos de otros aspectos importantes, como el tiempo total que tarda el proceso (no solo los tokens que conseguimos ahorrar sobre el papel), la frecuencia de errores que pasan desapercibidos y su gravedad, o las situaciones concretas en las que este sistema de delegaci\u00f3n ofrece peores resultados que utilizar directamente el modelo m\u00e1s avanzado, sin intermediarios.<\/p>\n\n\n\n Tambi\u00e9n hay otro detalle que no debemos pasar por alto: en el momento de publicar este art\u00edculo, el repositorio todav\u00eda no cuenta con versiones oficiales publicadas. Esto apunta a que estamos ante un proyecto joven y experimental, m\u00e1s que ante una herramienta madura y preparada para utilizarse en entornos de producci\u00f3n.<\/p>\n\n\n\n Y hay algo que conviene dejar claro: ahorrar tokens del modelo premium no significa autom\u00e1ticamente ahorrar dinero, tiempo o reducir los riesgos del proceso en su conjunto.autom\u00e1ticamente ahorrar dinero, tiempo o reducir los riesgos del proceso en su conjunto.<\/p>\n\n\n\n Screenshot del repositorio oficial en GitHub<\/a><\/p>\n\n\n\n Hay un videojuego independiente, Return of the Obra Dinn, en el que el jugador tiene que reconstruir qu\u00e9 les ha ocurrido a todos los miembros de una tripulaci\u00f3n a partir de peque\u00f1as pistas que pueden resultar ambiguas: una imagen congelada, una frase escuchada a medias o un detalle en la posici\u00f3n de los cuerpos.<\/p>\n\n\n\n El juego solo confirma que una deducci\u00f3n es correcta cuando se han acertado al menos tres hechos relacionados entre s\u00ed, no uno por uno.<\/p>\n\n\n\n Puede parecer una comparaci\u00f3n un poco extra\u00f1a, pero tiene bastante sentido para entender uno de los principales problemas de la orquestaci\u00f3n. Un sistema de delegaci\u00f3n solo funciona si tiene una forma fiable de saber cu\u00e1ndo el resultado de un agente es realmente correcto. Y esa comprobaci\u00f3n casi nunca puede depender de una \u00fanica se\u00f1al aislada. Hay que combinar varias pistas, igual que en el videojuego. De lo contrario, corremos el riesgo de dar por buena una respuesta que parece coherente, pero que en realidad no lo es.<\/p>\n\n\n\n En el desarrollo de software contamos con algunas se\u00f1ales bastante fiables: que el proyecto se compile correctamente, que pasen las pruebas unitarias y de integraci\u00f3n, los an\u00e1lisis est\u00e1ticos, las comprobaciones de c\u00f3digo (linting), los benchmarks o una revisi\u00f3n de los cambios realizados por una persona o por otro modelo.<\/p>\n\n\n\n Pero incluso en estos casos, que todas las pruebas funcionen no significa autom\u00e1ticamente que el cambio sea correcto, seguro y coherente con lo que quer\u00eda conseguir el producto. Al fin y al cabo, las pruebas las ha escrito alguien y esa persona puede haber dejado fuera precisamente los casos l\u00edmite m\u00e1s complicados.<\/p>\n\n\n\n En tareas editoriales, de investigaci\u00f3n, legales o m\u00e9dicas, comprobar los resultados es mucho m\u00e1s dif\u00edcil. Un texto bien escrito puede parecer totalmente convincente y, aun as\u00ed, contener fuentes incorrectas, citas inventadas o conclusiones que no est\u00e1n justificadas por la informaci\u00f3n original.<\/p>\n\n\n\n Hay que decirlo claramente: la orquestaci\u00f3n no elimina el problema de la fiabilidad del sistema. Simplemente lo traslada de la generaci\u00f3n de respuestas al dise\u00f1o de los mecanismos de control. Y eso es un problema diferente, pero no necesariamente m\u00e1s f\u00e1cil de resolver.<\/p>\n\n\n\n El caso de Astra Flash forma parte de una tendencia mucho m\u00e1s amplia y cada vez m\u00e1s visible en la industria. Las plataformas ya no se limitan a incorporar modelos cada vez m\u00e1s grandes. Tambi\u00e9n est\u00e1n desarrollando herramientas para combinar agentes, hacer que se comuniquen entre s\u00ed, asignarles diferentes herramientas y conseguir que trabajen de forma coordinada mediante flujos de trabajo compartidos.<\/p>\n\n\n\n Una se\u00f1al clara de este cambio es la aparici\u00f3n de protocolos espec\u00edficos para facilitar la interoperabilidad.<\/p>\n\n\n\n En abril de 2025, Google present\u00f3 el Agent2Agent Protocol, conocido como A2A, pensado para que agentes desarrollados con diferentes plataformas o frameworks puedan comunicarse, intercambiar informaci\u00f3n y coordinar acciones entre ellos.<\/p>\n\n\n\n Dos meses despu\u00e9s, en junio, Google don\u00f3 el protocolo a la Linux Foundation<\/a>, con el apoyo de empresas como AWS, Cisco, Salesforce, SAP y ServiceNow.<\/p>\n\n\n\n Este paso es m\u00e1s importante de lo que parece. Demuestra que la conversaci\u00f3n est\u00e1 dejando de centrarse \u00fanicamente en agentes independientes, creados por un \u00fanico proveedor, para empezar a abordar la compatibilidad entre sistemas completos de agentes desarrollados por empresas diferentes.<\/p>\n\n\n\n Eso no significa que el problema de la delegaci\u00f3n est\u00e9 resuelto. M\u00e1s bien, indica que la interoperabilidad y la coordinaci\u00f3n ya se consideran problemas importantes de infraestructura, y no simples experimentos para presentar en conferencias.<\/p>\n\n\n\n Anthropic defiende un enfoque bastante pr\u00e1ctico en su gu\u00eda sobre c\u00f3mo construir agentes: empezar por la soluci\u00f3n m\u00e1s sencilla posible e incorporar agentes, sistemas de routing y m\u00e1s autonom\u00eda \u00fanicamente cuando las mejoras obtenidas justifican la complejidad a\u00f1adida.<\/p>\n\n\n\n Seg\u00fan su planteamiento, el modelo orchestrator-workers resulta especialmente \u00fatil cuando no podemos anticipar qu\u00e9 subtareas ser\u00e1n necesarias, como ocurre a menudo en proyectos de desarrollo que afectan a varios archivos al mismo tiempo.<\/p>\n\n\n\n Por su parte, Andrew Ng identifica la reflexi\u00f3n (reflection), el uso de herramientas (tool use), la planificaci\u00f3n (planning) y la colaboraci\u00f3n entre varios agentes como algunos de los patrones fundamentales del llamado dise\u00f1o ag\u00e9ntico.<\/p>\n\n\n\n Su punto de vista es interesante porque vuelve a poner el dise\u00f1o del flujo de trabajo en el centro de la conversaci\u00f3n. Muchas veces, la mejora real no viene \u00fanicamente del \u00faltimo modelo disponible en el mercado, sino de c\u00f3mo el sistema planifica, act\u00faa, recibe informaci\u00f3n externa y corrige sus propios resultados.<\/p>\n\n\n\nQu\u00e9 significa realmente el switching<\/h2>\n\n\n\n
Del modelo \u00fanico a un sistema formado por varias piezas<\/h2>\n\n\n\n
Routing, cascada y delegaci\u00f3n: las principales t\u00e9cnicas<\/h2>\n\n\n\n
\n
El caso de Astra Flash Orchestrator<\/h2>\n\n\n\n
\n
La promesa del ahorro y lo que realmente demuestra<\/h2>\n\n\n\n
![\"\"](\"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2026\/11\/image.png\")
<\/figure>\n\n\n\nVerificar es tan complicado como delegar<\/h2>\n\n\n\n
No es un caso aislado<\/h2>\n\n\n\n
Las opiniones que importan<\/h2>\n\n\n\n
![\"\"](\"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2026\/11\/Tabla-de-metricas-y-su-importancia.png\")
<\/figure>\n\n\n\n