Pregunte a diez equipos de TI del mercado medio en Allen cómo será su próximo proyecto de IA y un número sorprendente le describirá una flota: un agente de investigación, uno de triaje, uno de redacción, uno de QA, todos pasándose el trabajo entre sí. Suena a arquitectura moderna. La mayoría de las veces es una forma de convertir un problema resoluble en cinco problemas irresolubles. El diseño multiagente es real y en ocasiones necesario, pero está muy sobreprescrito, y el costo de equivocarse recae en el equipo pequeño que tiene que mantenerlo funcionando a las 2 de la mañana.
Allen está en el corredor de la US-75, al norte de Plano y al sur de McKinney, y las organizaciones de TI de aquí lo reflejan: equipos reducidos que atienden a varias unidades de negocio a la vez, con frecuencia abarcando operaciones corporativas, distribución y manufactura ligera, flujos de trabajo cercanos al sector salud, servicios financieros y una huella de instalaciones que puede incluir infraestructura real de centro de datos y telecomunicaciones. Cuando un solo equipo es dueño de tanta superficie, el instinto de levantar un agente por unidad de negocio es fuerte. Lo que sigue es un marco de decisión para saber cuándo ese instinto acierta y cuándo es teatro costoso.
El punto de partida honesto es un solo agente con herramientas excelentes, un alcance estrecho y un banco de pruebas de evaluación real. Superará a un sistema de tres agentes en la mayoría de los flujos de trabajo del negocio, y costará menos construirlo, operarlo y depurarlo.
La razón son los límites. Cada vez que usted entrega trabajo de un agente a otro, serializa un estado interno rico (razonamiento parcial, hipótesis descartadas, la textura de cómo lucían realmente los datos de origen) en un mensaje corto. Esa compresión pierde información por diseño, y el agente receptor no puede hacer una pregunta aclaratoria como sí podría un colega. Un solo agente que sostiene todo el problema nunca paga ese impuesto, y falla de maneras que usted puede leer en una sola traza en lugar de cinco.
Hay una segunda razón que importa más cada año. La capacidad de los modelos ha mejorado más rápido que las herramientas de orquestación. Las arquitecturas inventadas para compensar el razonamiento débil de un solo modelo hoy resuelven un problema que en parte ya desapareció, mientras que la complejidad operativa que introdujeron sigue intacta. Antes de dividir cualquier cosa, agote las opciones baratas: descripciones de herramientas más precisas, esquemas de salida estructurada, recuperación que de verdad devuelva los documentos correctos y código determinista simple para los pasos que son deterministas. Una proporción sorprendente de "necesitamos que los agentes se coordinen" resulta ser automatización de procesos común y corriente, con un agente que toma en el medio las decisiones que requieren criterio.
Tres condiciones lo justifican: alcances de herramientas y permisos genuinamente distintos, dominios de falla genuinamente distintos que usted quiere aislar, y contexto que no cabrá en un solo conjunto de trabajo. Si no puede nombrar al menos una de ellas en una sola oración, tiene un problema de prompt o de herramientas, no un problema de arquitectura.
Dos filtros más ayudan. Divida por sustantivos, no por verbos: un agente por sistema o por dominio de datos envejece mejor que un agente por paso del proceso actual, porque los procesos cambian constantemente y los sistemas de registro no. Y prefiera la menor cantidad de agentes que satisfaga la condición que usted nombró. Pasar de uno a dos es una decisión arquitectónica real. Pasar de dos a siete suele ser alguien modelando un organigrama en software.
Use varios agentes cuando los permisos de las herramientas sean genuinamente distintos, cuando necesite aislamiento real de fallas o cuando el contexto no quepa en un solo conjunto de trabajo. Casi cualquier otra razón es un problema de prompt disfrazado de arquitectura.
Un traspaso debe llevar cuatro cosas: la tarea, la evidencia, la confianza y la ruta de escalamiento. Los traspasos laxos, es decir, un agente escribiendo un párrafo en prosa para que otro lo interprete, son el punto donde la mayoría de los sistemas multiagente se rompen en silencio.
Trate un traspaso como un contrato de API, no como una conversación. La tarea es el resultado específico solicitado, con criterios de aceptación declarados, no implícitos. La evidencia es el material de origen y los identificadores que el siguiente agente necesita para verificar la afirmación por sí mismo: ID de registros, URI de documentos, resultados de consultas, marcas de tiempo. La confianza es una señal explícita sobre qué tan seguro está el agente emisor y sobre qué no pudo verificar. La ruta de escalamiento indica exactamente qué hacer cuando la confianza es baja o falta evidencia, incluyendo qué cola humana lo recibe y con qué contexto adjunto. Ese último punto es el que los equipos se saltan, y es la razón por la que tantas cadenas de agentes producen disparates con toda seguridad: nadie definió nunca cómo se ve un "no lo sé" en el protocolo. Nuestro artículo sobre diseño del escalamiento a humanos profundiza en ese punto.
En la práctica, esto significa un esquema tipado con campos obligatorios, validado en el límite, y con los mensajes que no pasan la validación enrutados a una persona en lugar de forzados en silencio a algo que simplemente se pueda parsear. Si el agente receptor tiene que inferir qué quiso decir el emisor, usted construyó un teléfono descompuesto con precio por token.
Tres patrones cubren casi todo lo que vale la pena construir: supervisor y trabajadores, canalización secuencial, y distribución en paralelo con un reconciliador. Elija según la forma del trabajo, no según lo que usó la demostración del framework que vio.
Un supervisor descompone una solicitud, la enruta a trabajadores especializados y es dueño de la respuesta final. Es lo mejor cuando el trabajo entrante es heterogéneo y la ruta no puede conocerse de antemano, como la recepción de una mesa de servicio donde el caso puede ser una solicitud de acceso, una falla de hardware o una disputa de facturación. El modo de falla es un supervisor que termina siendo un enrutador caro. Si solo está clasificando, reemplácelo con código de clasificación y quédese con el dinero.
Etapas fijas con entradas y salidas definidas: extraer, luego validar, luego actuar. Es lo mejor cuando el orden es genuinamente necesario y las etapas tienen alcances de herramientas distintos. Este es el patrón que la mayoría de los flujos de trabajo del mercado medio realmente necesita, y es el más fácil de observar, porque una canalización tiene una sola ruta y cada etapa puede probarse de forma aislada. Donde una etapa sea totalmente determinista, hágala código. Un agente cuyo trabajo es dar formato a una fecha es un pasivo, no una arquitectura.
Muchos trabajadores idénticos procesan fragmentos independientes al mismo tiempo, y un reconciliador fusiona los resultados y resuelve los conflictos. Es lo mejor para trabajo de volumen sobre un corpus grande: revisión de contratos, triaje de registros, respuestas a cuestionarios de seguridad. El reconciliador es todo el diseño. Si solo concatena, usted construyó un índice de búsqueda más lento. Necesita reglas explícitas de conflicto y la autoridad para reportar que el corpus se contradice a sí mismo. Cuando la división sí se justifica, para un equipo de TI reducido en Allen que cubre varias unidades de negocio, la canalización suele ser la primera construcción correcta y la distribución en paralelo la segunda.
Algo siempre falla, así que decida de antemano qué capa reintenta y si la acción es segura de repetir. En la práctica, buena parte de los incidentes multiagente no son fallas del modelo en absoluto: son la lógica de reintento ejecutando el mismo efecto secundario tres veces.
Tres reglas mantienen esto bajo control. Reintente en el alcance más pequeño que pueda tener éxito, es decir, la llamada a herramienta que expiró, no el flujo de trabajo completo de siete pasos. Haga que todo efecto secundario sea idempotente mediante una clave de solicitud, de modo que una repetición se convierta en una operación nula en lugar de un ticket duplicado, un correo duplicado o un registro de pago duplicado. Defina acciones compensatorias para los pasos que no pueda volver idempotentes, y sea honesto: algunos pasos simplemente deben detenerse y esperar a una persona. Agregue un cortacircuitos por cada dependencia aguas abajo, para que una API de proveedor con fallas degrade una sola rama en lugar de consumir el presupuesto de reintentos de toda la flota. Esta es una práctica común de los sistemas distribuidos, y por eso la madurez en AI DevOps, más que la elección del modelo, tiende a separar a los pilotos que sobreviven al contacto con producción. Los resultados parciales también merecen su propia decisión: un flujo de trabajo que completó cuatro de seis ramas, ¿es un éxito, un fracaso o un caso para revisión humana? Responda eso en tiempo de diseño, no durante el incidente.
El costo y la latencia se acumulan de forma multiplicativa y no aditiva, y eso sorprende a la gente. Cada agente normalmente vuelve a procesar el contexto compartido, así que una cadena de tres agentes puede consumir bastante más del triple de los tokens de un solo agente haciendo el mismo trabajo.
La latencia se comporta distinto según el patrón. Una canalización secuencial suma: el tiempo total es la suma de las etapas más la sobrecarga de los traspasos, y una cadena de cinco etapas que parece aceptable en una demostración puede incumplir un SLA interactivo bajo carga. Una distribución en paralelo está limitada por su trabajador más lento, así que la latencia de cola se vuelve la latencia típica, y una sola rama atascada mantiene secuestrado al reconciliador a menos que usted fije un plazo y le permita reportar cobertura parcial. Presupueste ambas cosas por adelantado: un techo de tokens por flujo de trabajo y un plazo máximo de ejecución, aplicados en código, con instrumentación del costo por unidad de trabajo completada en lugar del costo por llamada. Si usted no puede decir cuánto cuesta un flujo de trabajo completado, no puede juzgar si el segundo agente se ganó su lugar. Nuestras notas sobre la economía de los agentes de IA profundizan en el modelado de costo unitario.
Porque sin ella, depurar se convierte en arqueología. Cada agente, cada llamada a herramienta y cada traspaso de una ejecución deben llevar el mismo ID de correlación, y usted necesita poder reconstruir la ejecución completa como una sola línea de tiempo, incluyendo entradas, salidas, reintentos y la confianza asociada a cada traspaso.
Los registros por agente no bastan. Las fallas interesantes viven entre los agentes: el campo que se perdió, la señal de confianza que nadie leyó, el reintento que volvió a ejecutar un efecto secundario. Usted quiere tiempos a nivel de span, atribución de tokens y de costo por salto, y la capacidad de reproducir un traspaso específico contra un prompt modificado. También quiere evaluación por salto, porque una puntuación de calidad de extremo a extremo le dice que el flujo de trabajo empeoró sin decirle cuál agente retrocedió. Esa es la misma razón por la que el control debe diseñarse desde el inicio en lugar de agregarse después, un tema que tratamos en observabilidad y monitoreo de agentes y en gobernanza de la orquestación multiagente.
Elija un flujo de trabajo, construya primero la versión de un solo agente y divídala solo cuando una falla medida se lo indique. Un trimestre es tiempo de sobra si usted resiste la tentación de construir una plataforma antes de tener un caso de uso.
Los equipos a lo largo del corredor de la US-75 suelen manejar bien este proceso cuando hay un responsable con nombre propio a cargo de los números y el piloto se mantiene dentro de una sola unidad de negocio antes de abrirse a toda la organización. Ahí también es donde una buena Consultoría de IA se gana su lugar, en buena medida diciendo que no a los cuatro agentes que usted no necesitaba.
Infonaligy diseña y construye agentes de IA a medida y flujos de trabajo con agentes para equipos del mercado medio en Allen y en todo Dallas–Fort Worth, de forma presencial aquí y de manera remota en nuestras demás áreas de servicio. Empezamos con la línea base de un solo agente, la medimos con honestidad y dividimos el flujo de trabajo solo donde los permisos, el aislamiento de fallas o el contexto lo exijan de verdad, con traspasos tipados, trazabilidad correlacionada y una ruta definida de escalamiento a personas desde el primer día. Si alguien le está ofreciendo una flota de agentes y usted quiere una segunda opinión antes de comprometer un trimestre, escríbanos a hello@infonaligy.com o llámenos al 800-985-1365.
Infonaligy trabaja con organizaciones de toda el área metropolitana de Dallas–Fort Worth, Texas y Oklahoma de forma presencial, con entrega remota en todo el país.
Empezamos con una sesión práctica sobre un flujo de trabajo real, no con una propuesta de plataforma. Nuestros ingenieros mapean los límites de herramientas y permisos, identifican dónde el contexto o el aislamiento de fallas obligan genuinamente a dividir, y especifican el contrato de traspaso, la ruta de escalamiento y la trazabilidad antes de escribir una sola línea de código. Usted recibe un plan de construcción con un presupuesto de costo y latencia por flujo de trabajo completado, además de una prueba explícita de si el segundo agente se ganó su lugar. Somos neutrales en cuanto a modelos y frameworks, y le diremos cuándo un solo agente con algo de automatización común y corriente es la mejor respuesta.
Infonaligy