Orquestación multiagente para soporte al cliente

Un solo agente de IA puede manejar preguntas básicas de clientes. Pero cuando tu operación de soporte abarca disputas de facturación, troubleshooting técnico, seguimiento de pedidos y devoluciones, cada una con fuentes de datos, herramientas y patrones de razonamiento distintos, un agente intentando hacerlo todo empieza a romperse. La orquestación multiagente resuelve esto enrutando conversaciones hacia agentes especializados que destacan en dominios estrechos.

Resumen rápido:

Los sistemas de un solo agente degradan su precisión a medida que añades más herramientas y dominios de conocimiento. La orquestación multiagente divide responsabilidades entre agentes especializados coordinados por un router.

Existen tres patrones principales: Router (un orquestador envía a especialistas), Jerárquico (managers delegan a subagentes) y Colaborativo (agentes se comunican peer-to-peer). Router es el punto de partida correcto para la mayoría de equipos de soporte.

Los handoffs a mitad de conversación requieren paso explícito de contexto: serializa estado de conversación, entidades activas y estado parcial de resolución en un payload de handoff para que el agente receptor no pida al cliente repetir información.

Nuestro enfoque de análisis

Esta guía sintetiza detalles operativos de tres categorías de fuentes:

Patrones de código de producción de repos open-source (por ejemplo, LangChain, LlamaIndex, documentación de pgvector y ejemplos de HuggingFace)
Investigación académica publicada en arxiv y en actas de conferencias sobre recuperación y generación
Debates de profesionales en r/MachineLearning, r/LocalLLaMA y r/LangChain donde ingenieros reportan restricciones reales de producción en orquestación multiagente

Evitamos afirmaciones puramente de marketing y priorizamos ejemplos que se despliegan en bases de código reales. Cuando citamos cifras de latencia o precisión, la metodología, dataset o condiciones de prueba se indican junto a ellas. Revisado por última vez: abril de 2026.

Por qué los sistemas de un solo agente tienen techo

Cuando das a un solo agente LLM acceso a 15 herramientas, 8 bases de conocimiento y un system prompt de 4,000 tokens, el rendimiento se degrada de formas predecibles:

La precisión de selección de herramientas cae. La investigación de múltiples benchmarks de LLM muestra que la precisión de uso de herramientas cae con fuerza más allá de 10-12 herramientas. El modelo empieza a confundir qué herramienta llamar y con qué parámetros.
Dilución del system prompt. Instrucciones detalladas para flujos de facturación compiten con procedimientos de envío y pasos de troubleshooting técnico. Cuanto más metes en un prompt, menos fiable es que el modelo siga cualquier instrucción individual.
Saturación de la ventana de contexto. Recuperar documentos de varios dominios llena el contexto con información solo vagamente relevante, reduciendo la relación señal-ruido para la pregunta real.
La evaluación se vuelve opaca. Cuando un agente maneja todo, no puedes saber si el mal rendimiento viene de recuperación, razonamiento, uso de herramientas o huecos de conocimiento de dominio.

La orquestación multiagente aborda cada punto dando a cada agente un alcance enfocado: menos herramientas, un system prompt dirigido y recuperación específica de dominio.

Qué es realmente la orquestación multiagente

La orquestación multiagente es una arquitectura donde varios agentes de IA especializados colaboran para manejar una conversación, coordinados por una capa de routing u orquestación. Cada agente tiene:

Un system prompt enfocado con instrucciones específicas del dominio
Un conjunto limitado de herramientas relevante para su dominio
Acceso a una base de conocimiento o fuente de datos específica de dominio
Límites claros que definen qué puede y qué no puede manejar

El orquestador decide qué agente debería manejar el turno actual, gestiona handoffs entre agentes y mantiene continuidad de conversación.

                    ┌─────────────────┐
                    │   Orquestador   │
                    │ (Agente Router) │
                    └────────┬────────┘
                             │
           ┌─────────┬──────┴──────┬──────────┐
           ▼         ▼             ▼           ▼
    ┌────────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
    │Facturación │ │ Técnico  │ │ Envíos   │ │Devoluciones│
    │  Agente    │ │ Agente   │ │ Agente   │ │  Agente    │
    └────────────┘ └──────────┘ └──────────┘ └──────────┘
         │              │            │             │
    ┌────┴────┐   ┌────┴────┐  ┌───┴────┐   ┌───┴────┐
    │ Billing │   │  Tech   │  │ Order  │   │ Return │
    │   KB    │   │   KB    │  │Tracking│   │ Policy │
    │+ Stripe │   │+ Logs   │  │  API   │   │  KB    │
    └─────────┘   └─────────┘  └────────┘   └────────┘

Patrones de arquitectura

Patrón 1: Router (punto de partida recomendado)

Un solo agente orquestador clasifica cada mensaje entrante y lo enruta al especialista adecuado. El orquestador no responde preguntas por sí mismo: solo decide quién debería hacerlo.

Cuándo usarlo: tienes 3-8 dominios de soporte claramente definidos. La mayoría de conversaciones permanecen dentro de un solo dominio. Quieres una arquitectura simple y fácil de depurar.

typescript
interface AgentConfig {
  id: string;
  name: string;
  description: string;
  systemPrompt: string;
  tools: Tool[];
  knowledgeBaseId: string;
}

interface RoutingDecision {
  agentId: string;
  confidence: number;
  reasoning: string;
}

const AGENTS: AgentConfig[] = [
  {
    id: "billing",
    name: "Billing Agent",
    description: "Handles invoices, charges, refunds, plan changes, and payment methods",
    systemPrompt: `Eres un especialista de soporte de facturación. Tienes acceso al
historial de facturación del cliente mediante Stripe. Puedes emitir reembolsos
de hasta $50 sin aprobación. Para montos superiores a $50, escala a un agente humano.`,
    tools: [stripeLookup, issueRefund, changePlan, applyCredit],
    knowledgeBaseId: "kb-billing",
  },
  {
    id: "technical",
    name: "Technical Agent",
    description: "Handles setup issues, API errors, integration problems, and bug reports",
    systemPrompt: `Eres un ingeniero de soporte técnico. Tienes acceso a la
configuración de cuenta del cliente y logs de error recientes. Guía a los usuarios
por pasos de depuración antes de escalar.`,
    tools: [getAccountConfig, fetchErrorLogs, runDiagnostic, createBugReport],
    knowledgeBaseId: "kb-technical",
  },
  {
    id: "shipping",
    name: "Shipping Agent",
    description: "Handles order tracking, delivery issues, and address changes",
    systemPrompt: `Eres un especialista de envíos y entregas. Puedes consultar
estado de pedidos e información de tracking. Para paquetes perdidos, inicia una
investigación antes de ofrecer un reemplazo.`,
    tools: [trackOrder, updateAddress, initiateTrace, requestReplacement],
    knowledgeBaseId: "kb-shipping",
  },
  {
    id: "returns",
    name: "Returns Agent",
    description: "Handles return requests, exchanges, and return policy questions",
    systemPrompt: `Eres un especialista de devoluciones y cambios. Verifica que el
artículo esté dentro de la ventana de devolución antes de iniciar. Los productos
digitales no son reembolsables salvo que sean defectuosos.`,
    tools: [checkReturnEligibility, initiateReturn, schedulePickup, processExchange],
    knowledgeBaseId: "kb-returns",
  },
];

async function routeMessage(
  message: string,
  conversationHistory: Message[]
): Promise<RoutingDecision> {
  const agentDescriptions = AGENTS.map(
    (a) => `- ${a.id}: ${a.description}`
  ).join("\n");

  const response = await llm.chat({
    model: "gpt-4o-mini", // Modelo rápido y barato para routing
    messages: [
      {
        role: "system",
        content: `Eres un agente de routing. Clasifica el mensaje del cliente y
selecciona el mejor agente para manejarlo. Responde solo con JSON.

Agentes disponibles:
${agentDescriptions}

Si el mensaje no encaja claramente con ningún agente, enruta a "general".
Considera todo el historial de conversación para contexto.`,
      },
      ...conversationHistory,
      { role: "user", content: message },
    ],
    response_format: { type: "json_object" },
  });

  return JSON.parse(response.content) as RoutingDecision;
}

La idea clave es que el router usa un modelo pequeño y rápido (como GPT-4o-mini o Claude Haiku). El routing es una tarea de clasificación, no una tarea de razonamiento: no necesitas un modelo frontier para ello.

Patrón 2: Jerárquico

Un orquestador de alto nivel delega a managers de dominio, que a su vez delegan a subagentes. Esto añade una capa de jerarquía para organizaciones complejas.

Cuándo usarlo: tienes más de 10 dominios o subdominios. Algunos dominios son lo bastante complejos para justificar especialización interna (por ejemplo, "Técnico" se divide en "Soporte API", "Soporte de integraciones" y "Soporte de infraestructura").

                    ┌─────────────────┐
                    │  Orquestador    │
                    │    superior     │
                    └────────┬────────┘
                    ┌────────┴────────┐
                    ▼                 ▼
            ┌──────────────┐  ┌──────────────┐
            │   Manager    │  │   Manager    │
            │   Técnico    │  │  Comercio    │
            └──────┬───────┘  └──────┬───────┘
              ┌────┼────┐       ┌────┼────┐
              ▼    ▼    ▼       ▼    ▼    ▼
            API Integ Infra  Billing Ship Returns

typescript
interface HierarchicalAgent extends AgentConfig {
  children?: HierarchicalAgent[];
  canHandle: (message: string, context: ConversationContext) => Promise<boolean>;
}

async function hierarchicalRoute(
  message: string,
  context: ConversationContext,
  agents: HierarchicalAgent[]
): Promise<AgentConfig> {
  // Primer nivel: elegir el manager de dominio
  const manager = await selectBestAgent(message, context, agents);

  // Si el manager tiene hijos, enrutar de nuevo dentro de ese dominio
  if (manager.children && manager.children.length > 0) {
    return hierarchicalRoute(message, context, manager.children);
  }

  return manager;
}

El tradeoff es latencia: cada salto de routing añade una llamada LLM. Con dos niveles, añades 200-400 ms. Para la mayoría de casos de soporte, esto es aceptable porque el usuario ya está esperando una respuesta. Pero mídelo.

Patrón 3: Colaborativo

Los agentes se comunican directamente entre sí en lugar de pasar por un orquestador central. Un agente puede invocar a otro cuando se da cuenta de que el problema cruza dominios.

Cuándo usarlo: las conversaciones suelen abarcar varios dominios en un solo turno. Por ejemplo, una solicitud de devolución que también requiere reembolso involucra tanto al Agente de Devoluciones como al Agente de Facturación.

typescript
interface AgentMessage {
  fromAgent: string;
  toAgent: string;
  type: "handoff" | "query" | "response";
  payload: {
    conversationState: ConversationState;
    request: string;
    partialResolution?: Record<string, unknown>;
  };
}

class CollaborativeAgent {
  constructor(
    private config: AgentConfig,
    private registry: AgentRegistry
  ) {}

  async handle(message: string, state: ConversationState): Promise<AgentResponse> {
    const response = await llm.chat({
      model: "gpt-4o",
      messages: [
        { role: "system", content: this.config.systemPrompt },
        ...state.history,
        { role: "user", content: message },
      ],
      tools: [
        ...this.config.tools,
        // Herramienta especial: pedir ayuda a otro agente
        {
          name: "delegate_to_agent",
          description: "Pass part of the request to another specialist agent",
          parameters: {
            agentId: { type: "string", enum: this.registry.getAgentIds() },
            request: { type: "string" },
            context: { type: "string" },
          },
        },
      ],
    });

    // Si el agente invocó delegate_to_agent, ejecutar la delegación
    if (response.toolCalls?.some((tc) => tc.name === "delegate_to_agent")) {
      return this.handleDelegation(response, state);
    }

    return { content: response.content, state };
  }

  private async handleDelegation(
    response: LLMResponse,
    state: ConversationState
  ): Promise<AgentResponse> {
    const delegation = response.toolCalls.find(
      (tc) => tc.name === "delegate_to_agent"
    );
    const targetAgent = this.registry.get(delegation.args.agentId);

    const delegatedResult = await targetAgent.handle(
      delegation.args.request,
      { ...state, delegatedFrom: this.config.id }
    );

    // Alimentar el resultado al agente original para componer una respuesta final
    return this.synthesizeResponse(response, delegatedResult, state);
  }
}

Los patrones colaborativos son los más potentes, pero también los más difíciles de depurar. Los agentes pueden entrar en loops, producir respuestas contradictorias o perder de vista la pregunta original. Usa este patrón solo cuando el patrón Router realmente no pueda manejar tus requisitos cross-domain.

Manejar handoffs a mitad de conversación

La parte más difícil de los sistemas multiagente no es el routing: son los handoffs. Cuando el Agente A ha manejado una conversación durante tres turnos y el cliente gira hacia otro dominio, el Agente B necesita suficiente contexto para continuar sin fricción.

El payload de handoff

Define un payload de handoff estructurado que viaja entre agentes:

typescript
interface HandoffPayload {
  // Historial completo de conversación
  conversationHistory: Message[];

  // Resumen estructurado de lo resuelto hasta ahora
  resolutionState: {
    customerIntent: string;
    identifiedIssues: string[];
    actionsCompleted: Array<{
      action: string;
      result: string;
      timestamp: string;
    }>;
    pendingActions: string[];
  };

  // Entidades del cliente extraídas durante la conversación
  entities: {
    customerId?: string;
    orderId?: string;
    productId?: string;
    accountEmail?: string;
    [key: string]: string | undefined;
  };

  // Por qué ocurre el handoff
  handoffReason: string;

  // Siguiente paso sugerido por el agente origen
  suggestedAction?: string;
}

async function executeHandoff(
  fromAgent: AgentConfig,
  toAgent: AgentConfig,
  state: ConversationState
): Promise<HandoffPayload> {
  // Pedir al agente saliente que resuma el estado
  const summary = await llm.chat({
    model: "gpt-4o-mini",
    messages: [
      {
        role: "system",
        content: `Eres ${fromAgent.name}. La conversación se está transfiriendo
a ${toAgent.name}. Produce un resumen JSON estructurado del estado de la conversación
para que el agente receptor pueda continuar sin pedir al cliente que repita
información. Incluye: intención del cliente, problemas identificados, acciones
tomadas, entidades (IDs de pedido, emails, etc.) y por qué estás haciendo handoff.`,
      },
      ...state.history,
    ],
    response_format: { type: "json_object" },
  });

  return JSON.parse(summary.content) as HandoffPayload;
}

Inyectar contexto en el agente receptor

El agente receptor necesita el payload de handoff en su system prompt o como mensaje prefijado:

typescript
function buildHandoffSystemPrompt(
  agentConfig: AgentConfig,
  handoff: HandoffPayload
): string {
  return `${agentConfig.systemPrompt}

--- CONTEXTO DE HANDOFF ---
Esta conversación fue transferida desde otro agente.

Intención del cliente: ${handoff.resolutionState.customerIntent}
Problemas identificados: ${handoff.resolutionState.identifiedIssues.join(", ")}
Acciones ya completadas:
${handoff.resolutionState.actionsCompleted
  .map((a) => `- ${a.action}: ${a.result}`)
  .join("\n")}

Pendiente: ${handoff.resolutionState.pendingActions.join(", ")}
Razón del handoff: ${handoff.handoffReason}
${handoff.suggestedAction ? `Siguiente paso sugerido: ${handoff.suggestedAction}` : ""}

Entidades del cliente:
${Object.entries(handoff.entities)
  .filter(([, v]) => v)
  .map(([k, v]) => `- ${k}: ${v}`)
  .join("\n")}

IMPORTANTE: NO pidas al cliente repetir información ya capturada arriba.
Continúa la conversación de forma natural desde donde fue transferida.
--- FIN DEL CONTEXTO DE HANDOFF ---`;
}

Manejar turnos multi-dominio

A veces un solo mensaje del cliente abarca dos dominios: "Quiero devolver mi pedido y también obtener un reembolso por el coste de envío". El patrón Router maneja esto procesando el mensaje en dos fases:

typescript
async function handleMultiDomainMessage(
  message: string,
  state: ConversationState
): Promise<string> {
  // Paso 1: descomponer el mensaje en subtareas específicas de dominio
  const decomposition = await llm.chat({
    model: "gpt-4o-mini",
    messages: [
      {
        role: "system",
        content: `Descompón este mensaje del cliente en tareas separadas
específicas de dominio. Devuelve un array JSON de objetos { agentId, task }.
Si el mensaje pertenece a un solo dominio, devuelve un array con un elemento.`,
      },
      { role: "user", content: message },
    ],
    response_format: { type: "json_object" },
  });

  const tasks: { agentId: string; task: string }[] = JSON.parse(
    decomposition.content
  ).tasks;

  // Paso 2: ejecutar cada subtarea con el agente apropiado
  const results: string[] = [];
  for (const { agentId, task } of tasks) {
    const agent = getAgent(agentId);
    const result = await agent.handle(task, state);
    results.push(result.content);
    // Actualizar estado con cualquier acción realizada
    state = result.state;
  }

  // Paso 3: sintetizar una respuesta unificada
  const synthesis = await llm.chat({
    model: "gpt-4o",
    messages: [
      {
        role: "system",
        content: `Combina estas respuestas de agentes en una sola respuesta coherente
para el cliente. No repitas información. Sé conciso.`,
      },
      {
        role: "user",
        content: `El cliente preguntó: "${message}"\n\nRespuestas de agentes:\n${results
          .map((r, i) => `${i + 1}. ${r}`)
          .join("\n\n")}`,
      },
    ],
  });

  return synthesis.content;
}

Evaluación y monitoring

Los sistemas multiagente son tan buenos como tu capacidad de medirlos. Necesitas visibilidad en tres capas: precisión de routing, rendimiento por agente y calidad de resolución end-to-end.

Precisión de routing

Rastrea si el orquestador envía mensajes al agente correcto. Esto requiere un conjunto de evaluación etiquetado:

typescript
interface RoutingEval {
  message: string;
  conversationHistory: Message[];
  expectedAgentId: string;
}

async function evaluateRouting(evalSet: RoutingEval[]): Promise<{
  accuracy: number;
  confusionMatrix: Record<string, Record<string, number>>;
}> {
  const confusionMatrix: Record<string, Record<string, number>> = {};
  let correct = 0;

  for (const example of evalSet) {
    const decision = await routeMessage(
      example.message,
      example.conversationHistory
    );

    // Rastrear predicho vs. esperado
    if (!confusionMatrix[example.expectedAgentId]) {
      confusionMatrix[example.expectedAgentId] = {};
    }
    confusionMatrix[example.expectedAgentId][decision.agentId] =
      (confusionMatrix[example.expectedAgentId][decision.agentId] || 0) + 1;

    if (decision.agentId === example.expectedAgentId) correct++;
  }

  return {
    accuracy: correct / evalSet.length,
    confusionMatrix,
  };
}

Apunta al menos a 95% de precisión de routing. Modos de fallo comunes:

Modo de fallo	Ejemplo	Fix
Intención ambigua	"Mi pedido está mal" (¿envío o devoluciones?)	Añadir paso de aclaración antes de enrutar
Solapamiento de dominios	Reembolso después de devolución (facturación + devoluciones)	Usar descomposición multi-dominio
Dominios escasos	Agente con pocos ejemplos de entrenamiento	Ampliar descripciones de agentes con ejemplos

Métricas por agente

Cada agente debería rastrear de forma independiente:

Métrica	Qué mide	Objetivo
Tasa de resolución	% de conversaciones resueltas sin escalado humano	>80%
Relevancia de respuesta	Puntuación LLM-as-judge sobre calidad de respuesta (escala 1-5)	>4.0
Precisión de llamadas a herramientas	% de llamadas con parámetros correctos	>95%
Tasa de alucinación	% de respuestas con afirmaciones no fundamentadas	<2%
Turnos promedio hasta resolución	Número de mensajes de ida y vuelta	<4
Tasa de handoff	% de conversaciones transferidas a otro agente	Seguir tendencia

Dashboard de monitoring end-to-end

En producción, registra cada decisión de routing, invocación de agente, llamada a herramienta y handoff. Estructura tus logs para poder consultarlos:

typescript
interface AgentEvent {
  conversationId: string;
  timestamp: string;
  eventType: "route" | "agent_invoke" | "tool_call" | "handoff" | "resolution";
  agentId: string;
  data: {
    routingConfidence?: number;
    toolName?: string;
    toolArgs?: Record<string, unknown>;
    handoffFrom?: string;
    handoffTo?: string;
    resolutionStatus?: "resolved" | "escalated" | "abandoned";
    latencyMs: number;
  };
}

// Patrones de consulta para tu dashboard de monitoring:
// - Distribución de confianza de routing por agente
// - Matriz de frecuencia de handoff (qué agentes transfieren a cuáles)
// - Latencia P95 por agente
// - Tendencia de tasa de resolución en el tiempo
// - Tasa de error de herramientas por agente

Cuándo NO usar orquestación multiagente

Los sistemas multiagente añaden complejidad. No uses este patrón salvo que tengas una razón clara:

Un solo agente funciona bien cuando:

Tienes menos de 5 herramientas y 1-2 bases de conocimiento
Tu soporte cubre un solo dominio (por ejemplo, solo facturación)
Tu system prompt cabe cómodamente bajo 2,000 tokens
La precisión de selección de herramientas está por encima de 95% con tu configuración actual
Tienes un equipo pequeño y ancho de banda de ingeniería limitado para mantenimiento

Señales de que necesitas multiagente:

La precisión de selección de herramientas cae por debajo de 90% al añadir herramientas nuevas
Estás metiendo instrucciones contradictorias en un solo system prompt
Distintos dominios necesitan configuraciones LLM distintas (modelo, temperatura, max tokens)
Quieres desplegar y versionar agentes de dominio de forma independiente
La evaluación requiere conjuntos de prueba específicos por dominio

Un agente único bien ajustado con buen RAG y definiciones claras de herramientas superará a un sistema multiagente mal diseñado. Empieza simple. Añade agentes cuando las mediciones demuestren que los necesitas.

Checklist de producción

Antes de desplegar un sistema multiagente:

Conjunto de evaluación de routing: al menos 200 ejemplos etiquetados que cubran todos los agentes y casos límite
Esquema de payload de handoff: estandarizado, versionado, validado con JSON Schema
Agente fallback: agente general que maneja mensajes no enrutables
Ruta de escalado humano: cada agente puede escalar a un humano con contexto completo
Circuit breakers: si un agente falla 3 veces seguidas, omitirlo y escalar
Presupuestos de latencia: router <200 ms, respuesta de agente <3 s, total <5 s
Logging: cada evento (route, invoke, tool call, handoff) se registra con conversation ID
Seguimiento de coste: uso de tokens y conteo de llamadas a herramientas por agente
Framework de A/B testing: comparar agente único vs. multiagente en tasa de resolución

Ideas clave

Los agentes únicos degradan cuando se sobrecargan con demasiadas herramientas, bases de conocimiento e instrucciones. La orquestación multiagente distribuye complejidad entre especialistas enfocados.
Empieza con el patrón Router. Un orquestador ligero que clasifica y envía es la arquitectura más simple que funciona.
Los handoffs son la parte más difícil. Invierte en payloads de handoff estructurados que transporten estado de conversación, entidades extraídas y progreso de resolución.
Mide en cada capa: precisión de routing, calidad por agente y tasa de resolución end-to-end. No puedes mejorar lo que no mides.
No sobrediseñes. Un solo agente con buena recuperación supera a un sistema multiagente construido sin datos claros de rendimiento que motiven la división.

Cuándo la orquestación multiagente es incorrecta para soporte

Bots de un solo dominio que cubren un producto donde un agente bien instruido con buena recuperación supera a cualquier router
Equipos sin tracing ni herramientas de evaluación, ya que los modos de fallo multiagente son casi imposibles de depurar sin spans y replay
Presupuestos de latencia por debajo de un par de segundos, donde el salto de routing consume presupuesto antes de que el agente trabajador empiece
Casos de uso donde el estado compartido entre agentes es frágil (carritos de larga duración, formularios parciales) y un solo agente dueño del contexto es más simple
Despliegues sensibles al coste donde cada agente extra duplica o triplica el gasto de tokens por conversación
Productos tempranos antes de ajustar recuperación, evals y un baseline de agente único

Preguntas frecuentes

¿Qué es la orquestación multiagente en soporte al cliente?

La orquestación multiagente es una arquitectura donde varios agentes de IA especializados, cada uno enfocado en un dominio específico como facturación, soporte técnico o envíos, colaboran para manejar conversaciones de clientes. Una capa de routing u orquestación dirige cada mensaje al especialista correcto, gestiona handoffs entre agentes y mantiene continuidad de conversación. Este enfoque mejora precisión al dar a cada agente un alcance enfocado con menos herramientas y conocimiento específico de dominio.

¿Cómo decide un agente router qué especialista usar?

El agente router usa un LLM (normalmente un modelo rápido y barato como GPT-4o-mini o Claude Haiku) para clasificar el mensaje del cliente contra descripciones de cada especialista disponible. Considera todo el historial de conversación, no solo el último mensaje, para manejar cambios de contexto. La salida es una decisión de routing con ID de agente y puntuación de confianza. Los mensajes por debajo del umbral de confianza pueden activar una pregunta de aclaración o enrutarse a un agente fallback general.

¿Qué pasa cuando una conversación abarca varios dominios?

Cuando un solo mensaje involucra varios dominios (por ejemplo, devolver un artículo y pedir un reembolso), el orquestador descompone el mensaje en subtareas específicas de dominio, ejecuta cada una con el agente apropiado y luego sintetiza una respuesta unificada. Esto evita obligar a un agente a manejar una tarea fuera de su alcance. Para conversaciones que cambian gradualmente de dominio, un payload de handoff transporta el estado completo de conversación para que el agente receptor continúe sin fricción.

¿Cómo evitas que los clientes repitan información durante handoffs entre agentes?

Los payloads de handoff estructurados resuelven esto. Antes de transferir, el agente saliente genera un resumen JSON con: intención del cliente, problemas identificados, acciones ya completadas, entidades extraídas (IDs de pedido, emails) y próximos pasos pendientes. El agente receptor recibe este contexto inyectado en su system prompt con una instrucción explícita de no volver a preguntar información ya capturada. Esto preserva continuidad de conversación incluso entre límites de dominio.

¿Cuándo debería usar orquestación multiagente frente a un solo agente?

Usa un solo agente cuando tienes menos de 5 herramientas, 1-2 bases de conocimiento y un dominio de soporte enfocado. Pasa a multiagente cuando la precisión de selección de herramientas cae por debajo de 90%, tu system prompt supera 2,000 tokens de instrucciones conflictivas, o necesitas evaluación específica por dominio y ciclos de despliegue independientes. Valida siempre con medición: si un solo agente resuelve con precisión más de 90% de conversaciones, añadir complejidad de orquestación puede no valer la pena.

Orquestación multiagente para soporte al cliente: guía de arquitectura