¿Cómo se operan sistemas de IA multiagente en producción?

En GOGOGO LLC creamos sistemas multiagente: un orquestador que reparte el trabajo entre agentes especializados, cada uno con herramientas concretas. También uso agentes a diario para crear nuestros propios productos, entre ellos el juego GoTasty. Esto es lo que he visto que importa cuando los agentes salen de la demo y tocan sistemas reales. Nada es exótico. Casi todo es la disciplina que ya esperamos de cualquier servicio, aplicada a un software que decide qué hacer a continuación.

¿Qué diferencia a un sistema multiagente de un único prompt grande?

Un solo modelo con un prompt largo y todas las herramientas conectadas es fácil de empezar y difícil de fiar. Cuando hace algo mal, no sabes qué parte del prompt lo causó, y no puedes limitar un comportamiento sin tocarlos todos. Un sistema multiagente divide el trabajo: un coordinador es dueño de la ejecución y decide qué especialista hace cada paso, y cada especialista tiene un solo rol. Roles claros dan responsabilidades claras: cuando un paso falla, sabes de quién era.

Esa división es también lo que hace operable el sistema. Puedes probar, versionar y revertir un agente sin volver a desplegar los demás, y dar a cada uno su propio modelo, presupuesto y permisos.

¿Por qué registrar cada paso?

Porque tendrás que responder "¿por qué hizo eso?" sobre una ejecución del martes pasado, y el modelo no lo recordará. Nuestra regla es que cada traspaso, llamada a herramienta, puntuación y resultado se guarda con la entrada que vio el agente y la versión del agente que lo produjo. Eso te da tres cosas:

• Repetición. Puedes volver a ejecutar un caso fallido con un prompt o un modelo nuevo y comparar.
• Auditoría. Cualquiera puede seguir una decisión hasta el contexto que la causó, algo que importa en cuanto un cliente pregunta.
• Reversión. Si un cambio empeoró las cosas, sabes exactamente qué ejecuciones tocó.

Registra en los límites, no solo al final. Una respuesta final que parece correcta puede esconder una llamada a herramienta que nunca debió ocurrir. Lo contamos con más detalle en observabilidad por defecto.

¿Cómo se acotan las herramientas de un agente?

Empieza por la tarea, no por lo que hay disponible. Un agente que redacta respuestas no necesita enviarlas. Un agente que lee una base de datos no necesita permiso de escritura. Cada herramienta que añades es una nueva forma de fallar, así que cada agente recibe el conjunto más pequeño que le permite terminar su tarea, limitado a una superficie de producto.

Después ordena las acciones por sus consecuencias. Leer, redactar y calcular pueden ir libres. Todo lo irreversible, todo lo que gasta dinero y todo lo que toca credenciales necesita primero la aprobación de una persona. A nuestros propios agentes de programación les aplicamos la misma regla: en el repositorio de GoTasty pueden hacer commit y push en ramas de trabajo sin preguntar, pero preguntan antes de un paso irreversible, un pago o una credencial, y algunos ajustes de la consola en la nube están reservados a una persona. En el emulador de Android, nuestros agentes de QA deben dirigirse a un solo dispositivo por su número de serie, no lanzar nunca un comando de cierre general y usar puertos fijos. Reglas pequeñas como estas son las que permiten dejar a los agentes trabajando con seguridad.

¿Cómo deben pasarse el trabajo los agentes?

Con datos tipados, no con un párrafo. Cuando un especialista pasa el trabajo al siguiente, el traspaso dice cuál es la tarea, qué se ha decidido, en qué pruebas se basa y qué sigue abierto. No hay estado oculto en una conversación que el siguiente agente no puede ver. Si los datos no validan, el traspaso falla de forma visible en lugar de que el siguiente agente adivine.

Lo mismo vale para la memoria. El contexto debe guardarse por cliente y por conversación, versionado y consultable, para que un agente lea lo anterior desde un registro y no desde un resumen que escribió otro modelo y nadie revisó.

¿Cómo sabes si un sistema multiagente está mejorando?

Lo puntúas. Cada agente necesita una definición de buen resultado que se pueda comprobar, a ser posible con código: ¿la respuesta contestó la pregunta?, ¿pasó el build?, ¿la acción cumplió la política? Donde el código no llega, una persona revisa una muestra de forma periódica. Nuestros agentes de QA de GoTasty funcionan así: un build pasa cuando el log muestra cero errores de Unity y el bot abre cada zona dentro de su ventana de tiempo, no cuando un agente dice que se ve bien. El bot registra su ritmo cada 15 segundos, y las pruebas de ritmo usan un paso fijo de 1/30 s y un aleatorio con semilla, así que dos ejecuciones del mismo build dan los mismos números.

Las puntuaciones a lo largo del tiempo son la forma de notar una deriva tras actualizar un modelo y de decidir si un agente nuevo se gana su sitio. Lo explicamos a fondo en puntuar sistemas multiagente.

¿Por dónde empezar?

1. Escribe el flujo de trabajo como pasos y marca los que cambian algo fuera del sistema.
2. Da a cada paso un agente, un rol y las herramientas mínimas.
3. Define los datos de traspaso entre pasos antes de escribir prompts.
4. Registra cada límite desde el primer día, con la versión del agente.
5. Pon a una persona delante de cada acción irreversible hasta que los registros demuestren que puedes quitarla.

Para ver cómo lo aplicamos a nuestros productos, empieza por la página de sistemas de agentes o por el historial de ingeniería de este sitio, que lista cada cifra con su fecha y su fuente.