Un agente, muchos especialistas: por qué una IA personal debe dirigir el trabajo en lugar de hacerlo todo ella misma.
Un asistente de IA personal funciona mejor como orquestador: dirige las tareas a agentes de programación, modelos y scripts simples, con permisos graduados.
Fuentes: I Stopped Trying to Build One AI Agent That Does Everything
Qwen, Nemotron, Gemma, DeepSeek. Inferencia local, AWS Bedrock, Azure. Diferentes entornos de ejecución, diferentes tamaños, diferentes precios, diferentes grados de decepción. Una larga serie de experimentos con Hermes, Codex, OpenCode, modelos locales y APIs en la nube suele partir de la creencia de que existe un modelo correcto por encontrar. Tarde o temprano resulta que ese es el problema equivocado. Detrás de ello se esconde una segunda suposición, y es la más interesante: ¿por qué debería el agente personal hacerlo todo?
El sueño de Jarvis
La primera arquitectura es casi vergonzosamente simple: una persona, luego un agente, y después todo lo demás.
Los mensajes dirigidos a ese agente podrían ser: verificar los proyectos, solucionar un problema en uno de los repositorios, listar el calendario del día siguiente, informar si el servidor Linux está en buen estado, investigar un tema y devolver las partes importantes. Se espera que el agente se encargue de todo ello.
Suena maravilloso, pero es precisamente allí donde comienzan los problemas, porque todo se convierte en una superficie API enorme.
Ya existen herramientas mejores para algunas tareas
La programación es el caso más claro. Codex y OpenCode no son simplemente ventanas de chat conectadas a un modelo; funcionan dentro de un entorno de programación. Entienden la estructura de los repositorios, leen y buscan archivos, editan varios archivos a la vez, ejecutan comandos, inspeccionan errores, realizan pruebas, examinan las diferencias y realizan iteraciones. Se trata de una gran cantidad de mecanismos especializados.
Ahora, supongamos que al agente personal se le pide que implemente una función en un proyecto. Hay dos enfoques posibles.
Enfoque A. Proporcionar al agente un modelo muy potente, acceso al sistema de archivos y acceso a la shell. Enseñarle operaciones de repositorios. Desarrollar funciones de gestión de contexto, manejo de diferencias, ejecución de comandos, bucles de pruebas y recuperación de errores. Seguir perfeccionando el flujo de trabajo de programación. Felicidades: se está reconstruyendo un agente de programación desde cero.
Enfoque B. El agente reconoce una tarea de programación y la transfiere a Codex u OpenCode. Eso es claramente más sensato.
Un asistente no necesita ser el mejor en todo
Este es un verdadero cambio de mentalidad. Un asistente personal no tiene por qué ser el mejor programador, investigador, ingeniero DevOps, planificador o sistema de conocimiento del mundo. Debe saber quién debe realizar el trabajo. Esa es una responsabilidad diferente, y posiblemente más importante.
Las organizaciones humanas funcionan de la misma manera. Un director ejecutivo no escribe cada función de backend, no configura cada clúster de Kubernetes, no investiga cada mercado, no crea cada hoja de cálculo, no programa cada reunión ni responde a cada solicitud de soporte. Su valor proviene en parte de comprender qué debe hacerse, quién debe encargarse de ello y si el resultado es aceptable. Un orquestador de IA personal puede considerarse bajo esos mismos términos: no realiza todas las tareas, pero entiende bien las intenciones para dirigir el trabajo correctamente.
Una forma diferente de sistema
Sustituya la cadena de persona, agente, un modelo gigante y todo lo demás por algo como esto:
┌──────────────┐
│ Me │
└──────┬───────┘
│
▼
┌─────────────────┐
│ Google Chat │
└────────┬────────┘
│
▼
┌─────────────────┐
│ Hermes │
│ Orchestrator │
└────────┬────────┘
│
┌─────────────────┼──────────────────┐
│ │ │
▼ ▼ ▼
Coding Agents AI Models Tools
Codex/OpenCode Local / Cloud APIs / Servers
│ │ │
└─────────────────┼──────────────────┘
│
▼
Final Result
El trabajo del agente se vuelve mucho más claro. Entiende a la persona, comprende las capacidades disponibles, elige la adecuada, proporciona el contexto necesario, observa el resultado y da un informe. Ese es el asistente que realmente merece la pena tener.
El chat como única puerta de entrada
Una aplicación de chat como Google Chat cobra sentido con este diseño. No debe mostrar la complejidad subyacente. Desde el punto de vista del usuario, existe una sola conversación. Un mensaje como “verificar si ocurrió algo importante con el Proyecto X hoy” podría hacer que el agente consulte el sistema de tareas, revise GitHub, examine el estado del servidor, lea material relevante, quizás pida a otro modelo que analice algo y luego resuma. El usuario no debería necesitar saber nada de eso ni abrir cinco aplicaciones. La interfaz representa la intención, y todo lo demás es la implementación.
La programación como caso de uso del modelo
Imagínese estar lejos de la computadora. Un mensaje de teléfono indica que hay un problema en el flujo de autenticación del Proyecto X y pide una solución si es sencilla. En principio, la cadena de operaciones funciona de esta manera: el agente determina a qué proyecto se refiere, reúne suficiente contexto para encontrar el repositorio, reconoce que el código debe modificarse y lo delega a un agente de programación. Codex u OpenCode abre el repositorio, investiga, edita los archivos relevantes, ejecuta pruebas, verifica las diferencias y devuelve el resultado. El orquestador lo recibe e informa algo como: la validación del token de actualización utilizó la condición de vencimiento incorrecta, el agente de programación lo corrigió, las pruebas relevantes pasaron y aquí está lo que cambió.
Dificilmente importa qué modelo generó qué token en el proceso. Lo importante es que el trabajo se realizó correctamente.
Los modelos se convierten en infraestructura
Una vez que el agente forma parte de una capa de orquestación, preguntas como si utilizar Qwen, DeepSeek, un modelo local, Bedrock o Azure dejan de excluirse mutuamente. La respuesta puede ser simplemente sí, con diferentes niveles de inteligencia para distintas tareas. Un modelo local sencillo se encarga del enrutamiento básico. Un modelo en la nube económico elabora resúmenes. Un modelo de razonamiento más potente toma las decisiones difíciles. Un agente de programación gestiona los repositorios. Otro especialista se ocupa de otras tareas. Los modelos se convierten en infraestructura, y la infraestructura debe ser reemplazable.
Evitar la dependencia de un único proveedor
Los modelos cambian a una velocidad absurda. Lo que hoy parece la opción obvia puede parecer mediocre seis meses después. Los precios varían, los proveedores cambian, los modelos abiertos mejoran, las ventanas de contexto se amplían, las herramientas de llamada funcionan mejor y llegan nuevas arquitecturas de inferencia. Si toda la configuración personal asume que el Modelo X hace todo, cambiar resulta problemático. Una mejor estructura sería:
Task
↓
Router
↓
Best available capability
Hoy el último paso podría ser con un proveedor y mañana con otro, y el flujo de trabajo no debería preocuparse por eso.
El router puede ser más importante que el modelo
Se invierte mucho tiempo en comparar modelos: A obtiene una puntuación de 74, B de 78, C tiene un millón de tokens de contexto, D cuesta un 60 por ciento menos. Esa información es útil. Ahora imagine un sistema que sepa que A es el mejor para una tarea de razonamiento relacionada con la programación, que B es rápido y económico para la clasificación, que C es innecesario porque la solicitud puede responderse localmente, que otra solicitud no necesita ningún LLM sino solo una llamada a API, que una solicitud debe ir directamente a Codex y que otra necesita una pregunta al usuario antes de que ocurra algo.
Aquí parte de la inteligencia reside en el sistema que decide cómo se utiliza esa inteligencia, lo cual es mucho más interesante que otra tabla de clasificación.
No todos los pasos necesitan un LLM
Los agentes hacen que sea fácil olvidarlo. Al preguntar si un servidor está en línea, un agente no necesita un modelo de razonamiento con 200 mil millones de parámetros para determinar si el servidor existe. Realiza una verificación de estado, interpreta el resultado y responde. Al preguntar cuánto espacio en disco queda, ejecuta lo siguiente:
df -h
luego analiza la salida y responde. Un modelo de razonamiento costoso en cada paso no constituye inteligencia; a veces se trata simplemente de mala ingeniería.
Permisos
Una vez que un agente puede delegar acciones, surge un problema más complejo: ¿qué puede hacer? Leer un calendario es diferente de enviar un correo electrónico. Leer un repositorio es distinto a fusionar una solicitud de pull request. Revisar un servidor difiere significativamente de eliminar archivos. Por lo tanto, un agente personal útil necesita un modelo de permisos junto con sus herramientas, más o menos como este:
- La lectura se realiza sin solicitar permiso.
- La preparación de borradores y planes también se hace sin pedir autorización.
- Las acciones de bajo riesgo pueden ejecutarse por sí solas.
- Cualquier acción de consecuencias importantes requiere la aprobación humana.
Al pedirle que averigüe por qué un servicio está inactivo, el agente puede proceder directamente. Si decide que la base de datos está dañada y planea borrarla y recrearla, primero debería haber una confirmación. La autonomía no debería ser binaria; debe graduarse según el nivel de riesgo.
Memoria y contexto
Otra razón en contra de convertir cada herramienta especializada en asistente personal es el contexto. Codex debería comprender el repositorio, pero no toda la vida del usuario. Una herramienta de infraestructura debería conocer los servidores, no cada conversación que se haya tenido. El calendario conoce las reuniones y el gestor de tareas conoce las tareas. El orquestador puede convertirse en la capa que entiende cómo se relacionan esos sistemas.
Tomemos como ejemplo la pregunta sobre lo que está sucediendo con un proyecto específico. Ninguna consulta a una base de datos por sí sola puede responderla. Una buena respuesta toma en consideración el trabajo de desarrollo reciente, la actividad en GitHub, las tareas, las decisiones anteriores, el estado de despliegue y lo que el usuario planeaba hacer a continuación. Es en este contexto interno entre sistemas donde una capa de orquestación personalizada se vuelve verdaderamente valiosa.
La trampa de la sobreingeniería
El peligro es evidente. Pensar de esta manera facilita la creación de un diagrama como este:
User
↓
Intent Classifier
↓
Planning Agent
↓
Model Router
↓
Memory Agent
↓
Permission Agent
↓
Coding Agent
↓
Validation Agent
↓
Reflection Agent
↓
Supervisor Agent
↓
Another Agent Watching the Other Agents
Y luego pasar tres meses creando una organización de IA para que uno pueda preguntar qué hay en el calendario de hoy. Eso no ayuda a nadie. La lección de todo este experimento es que la complejidad debe ganarse su lugar. Doce agentes solo porque un diagrama de arquitectura se ve bien es una mala razón; las capacidades que ahorran tiempo repetidamente sí lo son.
Delegación antes que autonomía
Los agentes completamente autónomos reciben mucha atención: se les da una tarea, se los deja funcionando durante horas, se permite que los agentes conversen y tomen decisiones entre sí, y luego se vuelve una vez que todo está hecho. Eso es interesante, pero no es el punto de partida adecuado para un sistema personal. La delegación altamente fiable debe preceder a la máxima autonomía. El objetivo es indicar “haz X” y que el sistema elija de manera fiable la herramienta o agente correcto e informe sobre lo que ocurrió. Una vez que eso funcione extremadamente bien, la autonomía puede aumentar gradualmente.
Más herramientas especializadas, no menos
Al principio, el objetivo parece ser la consolidación: hay demasiadas herramientas de IA, así que se crea una sola IA que las reemplace. Pero eso resulta ser incorrecto. El estado final probablemente involucre sistemas de IA más especializados, con la diferencia de que ya no necesitan gestión individual, algo que resuelve la capa de orquestación. El futuro podría ser menos una sola IA que gobierne todo y más una única interfaz para coordinar todo. La diferencia es sutil, pero significativa.
Para qué sirve el agente
Después de implementar un sistema de este tipo, romper cosas, conectar una interfaz de chat, probar modelos y reflexionar profundamente sobre agentes de programación especializados, cobra relevancia el papel del agente personal. No tiene por qué ser la IA más inteligente del conjunto. Debe ser aquel que conoce a la persona y sus sistemas. Debería entender qué se le está pidiendo, qué contexto es importante, qué capacidad es adecuada, qué puede hacer, cuándo necesita confirmación y cómo devolver el resultado. Eso es suficiente; todo lo demás puede delegarse.
La arquitectura que merece la pena
El destino se ve más o menos así:
ME
│
▼
GOOGLE CHAT
│
▼
┌─────────────────┐
│ HERMES │
│ │
│ Intent │
│ Context │
│ Memory │
│ Permissions │
│ Orchestration │
└────────┬────────┘
│
┌──────────────────┼───────────────────┐
│ │ │
▼ ▼ ▼
AI MODELS CODING AGENTS TOOLS
│ │ │
Local / Cloud Codex/OpenCode GitHub/APIs
Fast / Strong Servers/Tasks
│ │ │
└──────────────────┼───────────────────┘
│
▼
HERMES
│
▼
ME
Lo importante no es tener una caja individual. Todo lo que esté bajo el orquestador debería poder reemplazarse con el tiempo. Aparece un agente de codificación mejor: se sustituye. Aparece un modelo local mejor: también se sustituye. La inferencia en la nube se vuelve más económica: se envían allí más tareas. Un proveedor deja de ser fiable: se evita utilizando otro. No debería ser necesario rediseñar la forma en que se utiliza el asistente cada vez que cambia la industria de la IA.
IA personal, quizás al revés
La mayoría de los productos de IA compiten por cuán inteligente es su modelo, lo cual es comprensible. Sin embargo, a medida que los modelos mejoran, surge otra capa de importancia: la coordinación. Eso significa saber qué quiere decir la persona, su contexto, qué sistemas son relevantes, qué herramientas existen, qué modelo es adecuado, qué acciones son seguras, cuándo hacer preguntas y cuándo no utilizar la IA en absoluto. El asistente que realmente vale la pena tener no es necesariamente el que obtiene la puntuación más alta en las pruebas de rendimiento, sino aquel que hace que toda la inteligencia y el software disponibles parezcan formar un único sistema.
La versión breve de la conclusión
El punto de partida es el deseo de contar con un agente de IA personal. Implementar uno demuestra que un asistente persistente es en realidad un problema de infraestructura. Buscar el modelo perfecto muestra que la selección de modelos es en realidad un problema de enrutamiento. Decidir qué debe hacer el agente indica que un asistente personal puede ser, en esencia, un problema de orquestación. La arquitectura pasa de buscar el modelo más inteligente y proporcionarle todas las herramientas a un sistema que comprende la intención y dirige las tareas al lugar adecuado. Se trata de una descripción mucho menos mágica de Jarvis, pero mucho más cercana a algo que realmente se pueda construir y utilizar a diario.
Leer más
- Construye un agente de planificación en LangGraph: planificar, ejecutar, replanificar, informar — Un agente de planificación de cuatro nodos de LangGraph para investigación financiera: planes estructurados, un registro de herramientas consciente del espacio de nombres, límites de replanificación y un ejemplo de ejecución trazada.
- MiniCPM5-2B vs rivales 4B: por qué un entorno agente cuenta una historia diferente — Un modelo de 2.5B que supera a los rivales de 4B en puntuaciones de un solo intento queda dos a tres veces por detrás en entornos agente. La confusión entre versiones del índice, el rendimiento local y cuándo es adecuado su uso.