Un agente generalista o varios agentes especializados: cómo elegir

En 60 segundos: Empezá con un agente y un flujo acotado. Puede cubrir varias tareas si comparten datos, políticas, permisos y una forma parecida de medir calidad. Dividilo cuando las pruebas muestren confusión entre herramientas o instrucciones, cuando una función necesite acceso más sensible o cuando cada área requiera evaluaciones y responsables distintos. Varios agentes no aportan una inteligencia misteriosa: separan contexto, memoria, herramientas, permisos e instrucciones. Esa separación puede mejorar el control, pero suma llamadas al modelo, traspasos, estados que sincronizar y nuevos puntos de fallo. Un coordinador puede conservar una sola interfaz para el usuario, siempre que el coste de enrutar y combinar resultados esté justificado.

Una empresa quiere automatizar seguimiento comercial y tareas administrativas. La primera pregunta suele ser si un solo agente puede encargarse de ambas funciones. Técnicamente, puede. La decisión útil es otra: ¿puede hacerlo con límites claros, resultados medibles y acceso razonable a los sistemas?

Un agente que prepara seguimientos desde el CRM y otro que arma reportes desde el ERP pueden usar exactamente el mismo modelo. La especialización aparece en la configuración que rodea al modelo. Cambian las instrucciones, los datos que entran en cada ejecución, las herramientas disponibles, las credenciales y los criterios con los que se revisa el resultado.

OpenAI describe un agente a partir de modelo, herramientas e instrucciones, y recomienda aprovechar primero las capacidades de un único agente. Su guía propone considerar la división cuando la lógica se vuelve difícil de seguir o el agente elige mal entre herramientas similares. Ese es un punto de partida más sólido que decidir por organigrama: tener cuatro departamentos no obliga a construir cuatro agentes.

Qué significa cada patrón

Un agente generalista usa una sola configuración operativa para resolver varias clases de petición. Puede seleccionar distintas herramientas y adaptar sus instrucciones según la tarea, pero conserva una identidad, un ciclo de ejecución y, normalmente, una política común de acceso y supervisión.

Varios agentes especializados separan parte de esa configuración. Un especialista comercial puede leer oportunidades y preparar tareas; uno de reporting puede consultar vistas aprobadas y producir un informe; uno de programación puede trabajar en un repositorio; y uno de SEO puede revisar páginas o preparar cambios en el CMS. Pueden responder directamente o trabajar detrás de otro componente.

La frontera importante se puede revisar en cinco piezas:

Pieza	Qué conviene preguntar antes de dividir
Instrucciones	¿Las reglas se contradicen o solo necesitan secciones bien organizadas?
Contexto y memoria	¿Las tareas comparten historial útil o cada una arrastra datos irrelevantes para la otra?
Herramientas	¿Los nombres y usos están claros o el agente confunde acciones parecidas?
Permisos	¿Todas las tareas deberían operar con el mismo alcance de lectura y escritura?
Evaluación	¿Se puede medir todo con el mismo conjunto de casos, riesgos y criterios de aprobación?

Esta lista evita atribuir el resultado a una supuesta personalidad más inteligente. Si dos agentes usan el mismo modelo, dividirlos no mejora por sí solo la capacidad base. Lo que cambia es la información y el poder operativo que recibe cada ejecución.

Comparación entre un agente y varios

Dimensión	Un agente generalista	Varios agentes especializados
Contexto	Puede reutilizar una historia común y resolver peticiones que mezclan funciones. También puede acumular material irrelevante.	Cada ejecución puede recibir menos información y más enfocada. Los datos compartidos deben transferirse o consultarse de nuevo.
Latencia	Una ruta directa suele necesitar menos decisiones y llamadas.	Enrutar, delegar y combinar respuestas puede aumentar el tiempo. Las tareas independientes se pueden ejecutar en paralelo si el caso lo permite.
Coste	Comparte infraestructura y puede resolver una petición en menos pasos. Un contexto grande o un modelo sobredimensionado también cuestan.	Permite asignar modelos y presupuestos por función, pero cada traspaso o verificación consume recursos.
Precisión	Funciona bien cuando las herramientas y políticas son compatibles. Puede confundir instrucciones solapadas.	Un alcance menor facilita instrucciones específicas. La precisión total todavía depende de que el enrutamiento y los traspasos sean correctos.
Evaluación	Hay menos componentes, aunque el conjunto de pruebas puede crecer con cada función.	Cada especialista puede tener casos y métricas propios. También hay que probar el coordinador y las combinaciones entre agentes.
Permisos	Una sola identidad es sencilla de operar, pero puede terminar acumulando accesos.	Las credenciales se pueden acotar por función. Hay que gobernar más identidades, secretos y registros de auditoría.
Mantenimiento	Un cambio se despliega en un lugar. Las instrucciones pueden volverse extensas y frágiles.	Los equipos pueden actualizar una función sin tocar las demás. Versiones, contratos y traspasos añaden trabajo.
Experiencia del usuario	Ofrece un punto de entrada y conserva mejor una conversación transversal.	Da respuestas más enfocadas si el usuario elige bien. Sin coordinación, puede obligarlo a repetir contexto o decidir a quién preguntar.

Anthropic recomienda aumentar la complejidad solo cuando haga falta y señala que los sistemas con más pasos suelen intercambiar coste y latencia por mejor desempeño en determinadas tareas. No existe una ganancia gratuita. La comparación debe hacerse con casos reales del flujo, no con el número de agentes como métrica.

Cuándo un agente generalista es suficiente

Un único agente es un buen candidato cuando las tareas comparten fuente de verdad, política y nivel de riesgo. Imaginemos un asistente interno que responde por una cuenta comercial concreta. Puede resumir una oportunidad, detectar que falta el próximo paso y preparar el bloque comercial de un reporte semanal. Todo sale de las mismas vistas de CRM, usa acceso de lectura y deja el resultado para revisión.

También puede manejar herramientas distintas si están bien descritas y no compiten entre sí. Una acción buscar_oportunidad y otra crear_borrador_reporte tienen propósitos fáciles de distinguir. Antes de dividir, conviene mejorar nombres, parámetros, instrucciones y manejo de errores; después se vuelve a ejecutar el conjunto de pruebas.

La memoria compartida aporta valor cuando una petición depende de la anterior. “Mostrame las oportunidades sin actividad” y “resumí las tres primeras para la reunión” deberían conservar filtros y referencias. Separar demasiado pronto puede obligar a reconstruir ese estado en cada traspaso.

El diseño de contexto también importa. Anthropic define el contexto de un agente como el conjunto que incluye instrucciones, herramientas, datos externos e historial. Enviar todo lo disponible no garantiza una respuesta mejor; para este artículo, lo tratamos como un presupuesto que se selecciona según la tarea.

Para situar esta decisión dentro de un despliegue más amplio, la guía sobre agentes de IA para empresas recorre tres pilotos y los controles previos a conceder permisos de escritura.

Cuatro ejemplos donde la frontera cambia

Seguimiento comercial

Un agente acotado puede detectar oportunidades sin próximo paso, explicar la evidencia y preparar una tarea. Si además responde preguntas sobre el mismo pipeline, un generalista sigue siendo razonable. La división gana sentido cuando se mezclan reglas incompatibles por país, marcas o canales, o cuando una parte puede enviar mensajes y otra debe permanecer en modo lectura.

Nuestra guía sobre el primer agente para recuperar ventas olvidadas muestra cómo empezar con una población, un responsable y acciones revisables.

Reporting

Un agente de reporting puede compartir modelo e infraestructura con ventas si consulta las mismas vistas y entrega resultados de solo lectura. Conviene separarlo cuando trabaja con cierres financieros, datos de varias filiales o definiciones gobernadas por otro equipo. La razón no es que “finanzas necesita más inteligencia”. Necesita fuentes, permisos, calendario de corte y pruebas diferentes.

Programación

Un agente de programación requiere repositorios, terminal, pruebas y reglas de revisión. Es una frontera fuerte frente a un asistente comercial porque sus herramientas pueden modificar código y activar pipelines. La guía sobre acceso seguro de un agente al repositorio explica cómo acotar cuenta, repositorio, entorno y aprobaciones.

SEO

Revisar títulos, enlazado y datos estructurados puede empezar como una herramienta dentro del mismo agente que mantiene el sitio. Publicar en el CMS cambia la decisión: aparecen permisos de escritura, control editorial, URLs canónicas y un riesgo distinto al de generar una recomendación. Si los mismos casos de prueba no cubren análisis y publicación, separar ambas capacidades puede facilitar el control.

El patrón coordinador más especialistas

Un coordinador recibe la petición, decide qué especialista necesita y reúne el resultado. El usuario conserva una sola conversación. Los especialistas operan con instrucciones y herramientas acotadas.

La documentación de orquestación del OpenAI Agents SDK distingue dos variantes frecuentes. En el patrón de manager, el coordinador mantiene el control y llama a especialistas como herramientas. En un handoff, transfiere la conversación y el especialista pasa a ser quien responde. También se puede enrutar mediante código cuando las categorías son conocidas y se busca un comportamiento más predecible.

Este patrón sirve cuando una solicitud cruza áreas. Por ejemplo: “revisa oportunidades sin actividad, calcula el resumen de la semana y prepara una actualización para la web interna”. El coordinador puede pedir un resultado estructurado a ventas, otro a reporting y otro a SEO, y luego presentar una respuesta común.

Hay que diseñar los contratos entre componentes:

• qué datos recibe cada especialista y cuáles quedan fuera
• qué formato debe devolver
• cómo cita los registros de origen
• qué ocurre si encuentra datos contradictorios
• quién conserva el estado compartido
• qué acciones requieren aprobación
• cuánto tiempo, coste y número de intentos puede consumir

El coordinador también se equivoca. Puede elegir al especialista incorrecto, perder un filtro durante el traspaso, ejecutar trabajo duplicado o combinar respuestas incompatibles. Sus decisiones necesitan trazas y evaluaciones propias. Si casi todas las peticiones van a un solo especialista, la capa de coordinación probablemente sobra.

Permisos: una razón válida para separar

Separar identidades puede reducir el alcance de un error. El agente de reporting no necesita desplegar código; el de SEO que analiza páginas no necesita publicar; el comercial que prepara un borrador no necesita aprobar descuentos.

El control AC-6 de NIST SP 800-53 formaliza el principio de mínimo privilegio: permitir solo los accesos necesarios para cumplir las tareas asignadas. Aplicado a agentes, esto favorece credenciales específicas, permisos temporales cuando corresponda y aprobación adicional para acciones sensibles.

Aun así, crear más agentes no aplica mínimo privilegio automáticamente. Si todos heredan la misma cuenta administrativa, la separación existe solo en los prompts. Para que sea una barrera real, deben cambiar las credenciales o políticas que el sistema valida fuera del modelo.

Señales para dividir el agente

La división se justifica cuando aparece evidencia repetida en pruebas o producción:

• el agente elige herramientas incorrectas aunque sus nombres y descripciones ya se corrigieron
• instrucciones válidas para una función interfieren con otra
• una tarea arrastra contexto sensible o irrelevante hacia peticiones que no lo necesitan
• una función requiere permisos de escritura o datos que las demás no deberían recibir
• los equipos necesitan ciclos de despliegue, responsables o evaluaciones independientes
• una parte del flujo se puede ejecutar en paralelo y el beneficio compensa la coordinación
• los incidentes no se pueden atribuir con claridad dentro de una configuración demasiado amplia

No hace falta esperar a un incidente grave. Un banco de casos de evaluación puede revelar el límite antes de ampliar accesos.

Señales de sobrediseño

La arquitectura se está adelantando al problema cuando:

• cada especialista tiene una sola herramienta y siempre se llama en el mismo orden
• un flujo determinista resolvería el enrutamiento con menos coste y variación
• varios agentes comparten modelo, instrucciones, credenciales y contexto casi idénticos
• el usuario repite datos porque ningún componente conserva el estado correcto
• hay más pruebas sobre traspasos que sobre el resultado de negocio
• el equipo no puede explicar qué fallo concreto corrige cada separación
• el volumen o valor de las tareas no cubre la operación de la nueva arquitectura

En esos casos, funciones, módulos o pasos programados pueden dar separación técnica sin convertir cada pieza en un agente.

Un árbol de decisión práctico

1. ¿La tarea tiene un disparador, una salida y un responsable claros? Si no, acotá el flujo antes de elegir arquitectura.
2. ¿Las funciones comparten datos, políticas, permisos y forma de evaluar? Si sí, probá un agente con herramientas bien delimitadas.
3. ¿Falla de manera repetida por instrucciones complejas o herramientas solapadas? Primero mejorá descripciones, parámetros y contexto. Dividí si el problema persiste en las evaluaciones.
4. ¿Una función necesita permisos o datos mucho más sensibles? Separá la identidad operativa aunque mantengas una sola interfaz.
5. ¿El usuario sabe a qué función dirigirse? Permití acceso directo al especialista. No agregues un coordinador sin necesidad.
6. ¿La petición suele cruzar funciones y necesita una respuesta común? Probá un coordinador con contratos estructurados, límites y trazas.
7. ¿La mejora supera la latencia, el coste y el mantenimiento añadidos? Conservá la arquitectura dividida solo si la medición lo confirma.

Cómo evolucionar desde un flujo pequeño

Empezá con una tarea de valor y un conjunto de casos reales, incluidos datos faltantes, solicitudes ambiguas y acciones prohibidas. Usá un agente en modo lectura o con aprobación humana. Registrá resultado, herramientas elegidas, tiempo, coste, correcciones y excepciones.

Después, organizá la implementación por capacidades aunque todavía exista un solo agente. Mantené las herramientas, políticas y pruebas de ventas, reporting, programación o SEO en módulos identificables. Esa separación prepara una futura división sin pagar todavía la coordinación.

Cuando una frontera falle de forma persistente, extraé solo esa función. Dale su propio contexto, permisos y evaluación. Compará la nueva versión con la línea base: tasa de éxito por caso, errores de selección, tiempo total, coste y carga de revisión. Agregá un coordinador cuando los usuarios necesiten una entrada común o cuando varias funciones deban colaborar en la misma solicitud.

La arquitectura final puede seguir siendo un agente, terminar en dos especialistas directos o incorporar un coordinador. La cantidad correcta es la menor que cumple el objetivo con calidad, permisos acotados y una operación que el equipo puede mantener.

Kiia diseña estos pilotos desde el proceso y sus límites. Podemos mapear un flujo, definir sus evaluaciones y decidir con evidencia si conviene ampliar un agente o separar capacidades. Conocé nuestro enfoque de integración de sistemas y llevá a la conversación cinco casos recientes, incluidos dos que hayan salido mal.