Traspaso Multiagente: Paso de Contexto entre Subagentes

El agente de investigación encontró la cuenta del cliente, confirmó el plan y obtuvo las últimas cuatro facturas. Después entregó al agente de facturación un resumen de una línea: “El cliente quiere un reembolso”. Sin la cuenta, el plan ni las facturas, el segundo agente vuelve a pedir el ID de cuenta. Cada dato perdido en esa transferencia cuesta dos veces: en llamadas duplicadas a la API y en decisiones tomadas con contexto incompleto.

Prueba Apidog hoy

Esta guía explica qué debe sobrevivir entre agentes, cómo transferirlo, cómo evitar pérdidas por resumir y cómo probar el límite entre dos agentes. El estado perdido es un modo de fallo central en sistemas de agentes en producción; este es su equivalente multiagente.

La opción más económica suele ser pasar referencias —identificadores— en lugar de cargas completas. Esto requiere que ambos agentes puedan recuperar el mismo registro de forma consistente mediante la misma API.

Qué debe cruzar el límite

No copie toda la conversación. El receptor heredaría demasiado contexto y tendría que decidir qué información importa. Transfiera solo estos cuatro grupos:

• Identificadores: IDs de cuenta, pedido, factura, ticket o trabajo. Son pequeños, estables y permiten recuperar los datos actuales.
• Decisiones tomadas: por ejemplo, “el cliente cumple los requisitos de reembolso según la política 3”. El siguiente agente no debe volver a debatirlas.
• Restricciones: presupuesto, aprobaciones, límites y acciones ejecutadas. Perderlas puede provocar cobros duplicados o solicitudes de aprobación repetidas.
• Preguntas abiertas: lo que el primer agente no pudo resolver. Declararlas evita que el receptor complete huecos con supuestos.

No transfiera respuestas de API en bruto, cadenas de razonamiento ni información que el agente receptor pueda obtener con una llamada barata.

Tres patrones de transferencia

1. Pasar toda la conversación

Puede funcionar con dos agentes y una tarea breve. Falla cuando el historial crece: el receptor gasta presupuesto leyendo mensajes y los datos importantes quedan enterrados. Esto se relaciona con el problema de mantener las respuestas de herramientas fuera de la ventana de contexto.

2. Pasar un resumen

Es el valor predeterminado de muchos frameworks, pero suele perder identificadores. Un modelo resumirá:

El cliente lleva dos años suscrito y está frustrado.

Cuando el receptor necesita algo verificable:

Cuenta 8812, plan Pro, cuatro facturas, reembolso aprobado para inv_44.

Use el resumen para intención y matices, no como fuente de verdad para IDs, importes o aprobaciones.

3. Pasar un objeto estructurado

Es el patrón más mantenible. El primer agente completa un esquema y el segundo consume campos, no prosa:

{
  "task_id": "task_2026_08_26_0031",
  "from_agent": "research",
  "to_agent": "billing",
  "entities": {
    "customer_id": "cus_8812",
    "invoice_ids": ["inv_41", "inv_42", "inv_43", "inv_44"],
    "subscription_id": "sub_119"
  },
  "decisions": [
    {
      "decision": "refund_eligible",
      "value": true,
      "basis": "policy 3.2, charged twice in one cycle"
    }
  ],
  "constraints": {
    "max_refund_cents": 4900,
    "human_approval_granted": false,
    "actions_taken": ["read_invoices"]
  },
  "open_questions": ["Customer has not confirmed which invoice to refund"],
  "summary": "Customer cus_8812 was double-charged in August. Refund of one invoice is approved under policy 3.2, up to 4900 cents. Awaiting the customer's choice of invoice."
}

Mantenga summary, pero junto a los campos estructurados, nunca en su lugar. Valide el objeto antes de transferir el control. Si falta customer_id, falle en el límite; no permita que el siguiente agente lo descubra tras varias llamadas.

Pase referencias, no cargas útiles

La transferencia más robusta pasa pocos datos: IDs y referencias. El receptor recupera el estado que necesita.

Este enfoque ofrece tres ventajas:

1. Datos actualizados: si el registro cambió entre agentes, el segundo consulta el valor actual.
2. Menos tokens: una transferencia de cientos de bytes sustituye decenas de miles de tokens.
3. Mejor auditoría: cada lectura queda registrada como una llamada a la API, no como texto copiado entre prompts.

Cada agente debe tener credenciales separadas y con el alcance mínimo necesario. Un agente de investigación no necesita permisos para emitir reembolsos, y un agente de facturación no debería reutilizar una clave excesivamente privilegiada. Consulte el patrón de claves API de menor privilegio para agentes.

Si una nueva lectura es lenta o costosa, almacene el registro en caché dentro del orquestador y transfiera una referencia a esa entrada. El receptor sigue solicitando explícitamente los datos, pero la segunda lectura resulta barata.

Cuatro fallos comunes

Identificador descartado

El resumen dice “el cliente”, pero no incluye un ID. El receptor busca por nombre, encuentra varias coincidencias y escoge la incorrecta.

Prevención: valide los IDs de entidad requeridos antes de permitir la transferencia.

Acción repetida

El primer agente ya envió un correo, pero no lo registra. El segundo lo envía otra vez.

Prevención: mantenga actions_taken, revíselo antes de cada escritura y use claves de idempotencia para agentes de IA.

Aprobación perdida

Una persona aprobó el reembolso durante la ejecución del primer agente. El segundo vuelve a pedir aprobación y transmite que el sistema no conserva el contexto.

Prevención: transfiera aprobaciones y presupuestos como restricciones explícitas vinculadas a la tarea, no al agente.

Invención confiada

El receptor necesita un dato ausente y, en vez de preguntar, inventa uno compatible con la narrativa.

Prevención: use open_questions y una regla explícita: si falta un identificador necesario, detenerse y preguntar.

Los bucles agravan los cuatro problemas. Si A transfiere a B y B devuelve la tarea a A, el estado se degrada en cada pasada. Limite los saltos y conserve el objeto de tarea original durante toda la ejecución.

Pruebe el límite entre agentes

Una transferencia es un punto de integración. Pruébela como tal.

Verifique el objeto de transferencia

Ejecute el primer agente con un escenario fijo y compruebe que el objeto resultante contiene:

• identificadores obligatorios;
• decisiones y su justificación;
• acciones realizadas;
• restricciones y aprobaciones;
• preguntas abiertas.

Aunque el agente sea no determinista, la aserción sobre su salida estructurada puede ser determinista. Vea la guía para probar agentes de IA no deterministas.

Pruebe el receptor de forma aislada

Entregue al agente receptor un objeto válido y verifique su comportamiento. Después, envíele una transferencia incompleta —por ejemplo, sin customer_id— y confirme que pregunta en vez de adivinar.

Esta prueba detecta la invención confiada.

Ejecute ambos agentes contra mocks

No pruebe reembolsos reales en cada cambio. Dirija ambos agentes a endpoints simulados para que la suite pueda ejecutarse en CI. La práctica de ejecutar agentes contra simulaciones en lugar de producción evita que las pruebas produzcan efectos reales.

Con Apidog, los mocks pueden partir de la misma definición de API que consumen los agentes, reduciendo la divergencia entre pruebas y contrato.

Registre cada transferencia

Registre el objeto completo en cada límite junto con el ID de tarea. Cuando una ejecución falle, el registro mostrará qué agente tenía un dato y cuál lo perdió. Complemente esto con rastreo de llamadas a herramientas de agentes.

Qué transfieren los frameworks

Los frameworks proporcionan primitivas de transferencia, pero no deciden qué información es crítica.

• La documentación de handoffs del SDK de agentes de OpenAI modela la transferencia como una herramienta que el agente puede invocar. Es práctico, pero deja la decisión en una parte no determinista del sistema. Valide siempre al salir.
• La guía multiagente de LangGraph trata el estado como un objeto explícito que cada nodo lee y escribe. Se acerca al patrón de transferencia estructurada; todavía debe definir qué campos son obligatorios.
• El artículo de Anthropic sobre cómo construyeron un sistema de investigación multiagente aporta detalles operativos sobre la instrucción necesaria para que un subagente trabaje de forma útil.

Cada framework moverá algo. Ninguno puede definir por usted los hechos esenciales de una tarea.

Mantenga el objeto de tarea fuera de la conversación

Almacene el estado durablemente, indexado por task_id. Cada agente debe leerlo y escribirlo directamente.

La conversación es un contenedor débil para el estado: puede compactarse, truncarse o resumirse. Ninguna de esas operaciones sabe qué campos son irremplazables. Una fila de base de datos no tiene ese problema.

El flujo es simple:

1. El agente carga el objeto de tarea al comenzar.
2. Tras cada acción, actualiza actions_taken y guarda el estado.
3. En una transferencia, pasa task_id.
4. El receptor carga el mismo objeto.

Así, los datos importantes no viajan en el prompt y no pueden desaparecer durante una sumarización. También obtiene un punto de reanudación: si una ejecución falla en el paso cuatro, el reintento parte del estado acumulado, no de cero.

Plataformas que modelan el estado de tarea

Si los agentes se ejecutan en entornos de línea de comandos, normalmente deberá implementar este objeto durable. Algunas plataformas de gestión de trabajo de agentes ya lo modelan.

Sharkly organiza el trabajo alrededor de una tarea que conserva objetivo, estado, responsable, agente o equipo asignado, comentarios, estado de ejecución y resultado. Un equipo combina un agente líder con otros agentes y personas, evitando transferencias informales basadas en prompts. Su documentación es una referencia útil para identificar los campos que suelen importar en una implementación propia.

Lista de verificación

• Existe un esquema de transferencia y se valida en el límite.
• Los IDs de entidad son obligatorios.
• Las decisiones incluyen su justificación.
• Las acciones realizadas se registran y se verifican antes de escribir.
• Aprobaciones y presupuestos pertenecen a la tarea, no al agente.
• Las preguntas abiertas son explícitas.
• Los datos se pasan por referencia cuando recuperarlos es barato.
• El número de saltos está limitado.
• El objeto de tarea original sobrevive a todos los saltos.
• Cada transferencia se registra con el ID de tarea.
• Las pruebas de CI usan mocks e incluyen transferencias incompletas deliberadamente.

La mayoría de los fallos multiagente no son fallos de razonamiento: son datos que existían en un agente y no llegaron al siguiente. Diseñe la transferencia como una interfaz, con esquema, validación y pruebas. El segundo agente dejará de preguntar lo que el primero ya resolvió.

Use Apidog para mantener mocks y pruebas de límite junto a la API que utilizan ambos agentes.

Preguntas frecuentes

¿Vale la pena una transferencia estructurada para dos agentes?

Para dos agentes en una tarea corta, pasar la conversación puede ser suficiente. El objeto estructurado se justifica con tres o más agentes, tareas largas o transferencias entre procesos o entornos distintos.

¿Debe el modelo construir el objeto de transferencia?

Use código siempre que sea posible. IDs, acciones realizadas y aprobaciones deben provenir del orquestador y de eventos reales, no de la memoria del modelo. Reserve el modelo para summary y open_questions.

¿Cómo evito la degradación de contexto en un bucle?

Mantenga un único objeto de tarea durante toda la ejecución y actualícelo. No lo regenere en cada límite. Después, limite el número de saltos; si una tarea necesita demasiados, probablemente la descomposición sea incorrecta.

¿Qué hago con frameworks que ya incluyen handoffs?

Úselos, pero confirme qué transfieren. Muchos trasladan solo el historial de mensajes, lo que deja los identificadores expuestos a la pérdida por resumir. Añada una carga estructurada junto al mecanismo del framework.

¿Necesitan los subagentes credenciales de API separadas?

Sí. Cada agente debe disponer únicamente de los permisos necesarios para su función. Compartir una clave potente elimina el aislamiento y dificulta atribuir las llamadas.

¿Cuánto debe contener summary?

Unas pocas oraciones sobre intención y matices no representables en campos estructurados. IDs, importes, estados y decisiones verificables deben vivir en campos validados.