Modelos en Cascada vs Fusionados: Comparativa de arquitecturas para agentes conversacionales

ElevenAgents funcionan gracias a un motor de orquestación de baja latencia diseñado para conversaciones en tiempo real, añadiendo menos de 100 ms de retraso. Esta arquitectura combina lo mejor de la investigación de ElevenLabs con LLMs de vanguardia de proveedores líderes como OpenAI, Google y Anthropic, junto a modelos open-source seleccionados y alojados por ElevenLabs. Al usar varios modelos en diferentes etapas del flujo de respuesta, el agente garantiza conversaciones muy ágiles y con contexto. Aprovechando dinámicamente los puntos fuertes de cada modelo, conseguimos un rendimiento fiable y escalable en tareas empresariales y escenarios conversacionales, optimizando el equilibrio entre inteligencia, velocidad y coste.

La arquitectura del agente influye en lo natural, inteligente y coherente que suenan sus respuestas, y en si se comporta de forma predecible con el tiempo. Por ejemplo, un agente basado en una arquitectura fusionada puede sonar muy realista en intercambios cortos, pero tener dificultades para razonar o mantener la coherencia en conversaciones largas.

En ElevenLabs, usamos una arquitectura en cascada que conecta componentes especializados para reconocimiento de voz, razonamiento y generación de voz. En cambio, el modelo Realtime de OpenAI utiliza un enfoque fusionado que integra todas esas etapas en una sola red.

En este artículo, repasamos las cinco arquitecturas principales de agentes conversacionales que existen hoy, explicando sus diseños, ventajas y desventajas, y cómo los equipos eligen entre ellas según sus objetivos.herramientas y una base de conocimiento. Es recomendable usar agentes independientes en lugar de flujos de trabajo cuando el caso de uso no requiere verificar una secuencia estricta de pasos o cuando es importante evitar silos de conocimiento entre agentes. Los silos de conocimiento surgen cuando ciertas herramientas, documentos o contexto histórico solo están disponibles para algunos subagentes y no para otros. Esto es inherente a los flujos multiagente y supone un equilibrio entre flexibilidad y determinismo.

Qué priorizan los equipos al crear agentes

• Formulan solicitudes de generación efectivas
• Recuperan e incorporan documentos relevantes
• Generan y ejecutan llamadas a herramientas para informar las respuestas del agente
• Muestran resultados para evaluación y recogida de datos

Construir el contexto de la conversación 

Aunque también importan factores como la concurrencia, integraciones y calidad de voz, las dimensiones anteriores dependen más directamente de la arquitectura del agente. Los equipos más exitosos adaptan su arquitectura para optimizar estos aspectos según su caso de uso.

Las arquitecturas en cascada se construyen encadenando componentes especializados: , un modelo de lenguaje grande (LLM), y Texto a Voz. Cada etapa se puede optimizar, probar y actualizar de forma independiente.entrada anterior. Esto permite recuperar documentos de forma fiable incluso cuando la última entrada del usuario es un seguimiento, una confirmación o no contiene una pregunta explícita.

La recuperación, sin embargo, es solo una de las formas en que los agentes interactúan con sistemas externos.

Esta modularidad permite a los equipos integrar los LLM más avanzados para mejorar el razonamiento, aplicar límites claros en la capa de texto y controlar con precisión cómo habla el agente usando TTS contextual. El principal inconveniente es que las arquitecturas en cascada suelen perder más señales prosódicas —como entonación, ritmo y emoción— porque el habla se convierte en texto antes de regenerarse. Estas señales pueden recuperarse en parte con modelos explícitos, pero no se capturan de forma tan natural como en los enfoques fusionados. Otros aspectos, como la latencia y los turnos de palabra, suelen poder optimizarse hasta niveles similares en ambos enfoques.

Por su parte, los enfoques fusionados combinan estos pasos en un único modelo multimodal. El audio entra y sale, y el reconocimiento, razonamiento y generación de voz ocurren dentro de la misma red. Cuantas más herramientas se añaden, mayor es la carga de razonamiento para que el modelo elija la secuencia correcta. En el Agent Builder, la descripción de la herramienta explica qué hace y qué campos devuelve. Esta es la información que el modelo de lenguaje usa para entender el contexto de uso. Una vez definida, las condiciones específicas para invocar la herramienta deben estar en el prompt de sistema del agente. Por ejemplo:

• Descripción de la herramienta lookup_order: “Recupera los detalles de un pedido del cliente por ID de pedido. Devuelve estado del pedido, artículos comprados, dirección de envío y número de seguimiento.”
• Instrucción en el prompt de sistema: “Después de verificar la identidad del cliente, llama a la herramienta lookup_order para recuperar los detalles de su pedido.”

Este diseño permite a las arquitecturas fusionadas preservar y reproducir la entonación de forma más efectiva, ya que el modelo procesa directamente la pronunciación y la entonación. Sin embargo, los modelos fusionados son más difíciles de probar y controlar, ya que no exponen salidas intermedias. Además, suelen depender de núcleos LLM más ligeros, lo que limita el razonamiento y el uso de herramientas en comparación con los enfoques en cascada que pueden combinarse con los modelos más potentes disponibles.Guía de Prompting. Dentro de este marco, se pueden definir varios tipos de herramientas, principalmente:

• Herramientas webhook que llaman a APIs externas.
• Herramientas cliente que envían solicitudes como eventos por websocket de la conversación.
• Herramientas de sistema para acciones integradas como transferencias de llamada.
• Herramientas MCP que conectan con servidores Model Context Protocol.

Las cinco arquitecturas posiblesvariable dinámica. Esta información se guarda como pares clave-valor simples, extraídos de la respuesta de la herramienta mediante mapeos predefinidos. Una vez establecidas, estas variables pueden usarse en el prompt de sistema, en parámetros de futuras herramientas y en condiciones de flujo. Este ciclo de retroalimentación da a los agentes una especie de memoria de trabajo que evoluciona con la interacción.

1. Cascada básica

Con la ejecución y orquestación listas, el siguiente paso es saber cómo medir el rendimiento.

En las arquitecturas en cascada básicas, el audio se transcribe, el LLM genera una respuesta en texto y luego el TTS pronuncia exactamente esas palabras. Como cada etapa trabaja solo con texto, los equipos tienen máxima visibilidad y control. Se pueden aplicar límites en la capa de texto, el LLM gestiona directamente el uso de herramientas y APIs, y los flujos deterministas permiten dirigir la conversación y aplicar lógica de negocio de forma predecible.

Sin embargo, el agente no reconoce matices del habla como el tono, ritmo o emoción, lo que puede limitar la naturalidad de la conversación.Recogida de datos y los Criterios de evaluación. La recogida de datos te permite extraer información estructurada de la transcripción de la llamada para análisis posteriores. Los clientes suelen exportar estos datos a su data lakehouse empresarial para informes o flujos de enriquecimiento. Por ejemplo, un agente de ventas puede extraer automáticamente los datos de un posible cliente de una conversación para crear o actualizar un lead en el CRM. Por otro lado, los criterios de evaluación determinan si una llamada se considera exitosa. Si se cumplen todos los criterios configurados, la llamada se marca como exitosa; si no, se marca como fallo. Así, las conversaciones cumplen siempre los estándares definidos de calidad e integridad, y se obtiene feedback rápido. Al terminar la llamada y activarse el webhook post-llamada, el agente procesa la transcripción final, incluyendo cualquier ejecución de herramienta y metadatos, con un LLM junto a todos los puntos de recogida de datos y criterios de evaluación configurados. El modelo usa este prompt combinado para decidir si se cumple cada criterio y extraer los datos especificados para análisis posteriores. Como el LLM interpreta estas configuraciones directamente en su prompt de entrada, es importante que estén claras y consistentes para que el modelo las entienda y aplique correctamente. Por eso recomendamos estas buenas prácticas para redactar criterios de evaluación y descripciones de recogida de datos.

Algunos casos de uso son:

1. Soporte al cliente una frase o viñeta corta es mejor que varios objetivos en un solo criterio.
2. Asistentes de ventas formula el objetivo para que el éxito o fallo se pueda decidir a partir de la transcripción (lo que se dijo, lo que hizo el agente, lo que pidió el usuario). Evita objetivos que requieran contexto externo que el LLM no tiene.
3. Recepcionistas IA el LLM ya sabe que para marcar como éxito el objetivo debe cumplirse, como fallo si no se cumple, y como desconocido si no puede saberlo por la transcripción. Por tanto, el objetivo debe estar escrito para que “cumplido” y “no cumplido” estén bien definidos; si es ambiguo, el modelo puede tender a desconocido o clasificaciones incorrectas.
4. NPCs para entretenimiento y videojuegos a veces se envían muchos criterios juntos. Si son largos, pueden añadir ruido y causar alucinaciones.
5. Sustitución de IVR cualquier explicación que dé el LLM sobre si se cumple un criterio se dará en el mismo idioma que la descripción, así que tenlo en cuenta.

2. Cascada avanzada

1. Describe exactamente qué extraer: la descripción es la señal principal para el LLM. Explica qué significa el campo, en qué situación debe rellenarse y qué hacer si no está claro (por ejemplo, “Déjalo en null si el cliente no indicó una fecha preferida”).
2. Haz que coincida con el tipo esperado: el valor que da el LLM siempre coincidirá con el tipo de dato asignado (booleano, string, entero, etc). Así que la descripción debe ajustarse a eso. Por ejemplo, “Extrae el número de artículos solicitados” para entero, y “Sí/No si el cliente aceptó la oferta” para booleano.
3. Usa enums cuando sea posible: para tipo string, si el conjunto de valores es fijo, usa enum en el esquema; así limitas el modelo y reduces salidas no válidas.
4. Un objetivo de extracción por elemento: No mezcles hechos no relacionados en una sola descripción; divide en elementos separados para que cada llamada tenga un objetivo claro.
5. Mantén las descripciones cortas: Pueden ser unas frases; no hace falta un párrafo largo. La transcripción ya está en el mensaje del usuario, así que el esquema + descripción breve es suficiente.

Las arquitecturas en cascada avanzadas incorporan TTS contextual, donde el LLM no solo decide qué decir, sino también cómo decirlo, enviando instrucciones como "di esto de forma tranquilizadora" o "responde con énfasis" al modelo TTS. El agente habla con un tono y estilo más realista, manteniendo los mismos límites, flujos deterministas, uso de herramientas y auditabilidad que una cascada básica.

Este es el enfoque detrás de

Algunos casos de uso son versiones más expresivas de:

Soporte al cliente ofrecen una interfaz visual para diseñar flujos de conversación complejos. Al final, generan el objeto lógico que usa el orquestador para gestionar varios subagentes, herramientas y transferencias bajo un identificador de agente independiente. Los flujos de trabajo añaden componentes adicionales a tener en cuenta, además de los ya mencionados para agentes independientes, incluyendo cómo:

• Interactúan los prompts de sistema y los objetivos conversacionales de los subagentes.
• Se determina el recorrido por los distintos puntos de transición del grafo.

Objetivos conversacionales especializados

Algunas arquitecturas en cascada envían características acústicas (por ejemplo, pronunciación, emoción, tono) del habla original directamente al LLM como embeddings. Así se conserva mejor la intención del usuario, manteniendo la modularidad del TTS. El uso de herramientas y límites sigue siendo posible, pero el bloque fusionado ASR+LLM es más difícil de auditar que un traspaso limpio de texto, y el LLM ya no se puede cambiar tan fácilmente como en un modelo en cascada.

Sobre esta base compartida, los flujos de trabajo introducen subagentes especializados que operan en un grafo dirigido. Cada subagente tiene un objetivo muy concreto y amplía la configuración base con instrucciones adicionales, herramientas y fuentes de conocimiento relevantes solo para su función. En vez de redefinir toda la configuración conversacional, los subagentes añaden su intención sobre el agente base mediante composición de prompts y extensión selectiva de contexto. Aunque el historial de conversación se mantiene entre transiciones de subagente para asegurar continuidad, cada subagente opera con una visión limitada y controlada del sistema. Las bases de conocimiento y herramientas se exponen de forma selectiva, creando silos claros que evitan fugas entre responsabilidades. Para reforzar este aislamiento, el objeto orquestador se reconstruye en cada transición como si fuera un agente independiente. Así, el estado del prompt, la configuración y las capacidades disponibles del subagente activo son totalmente deterministas. Este diseño permite que los flujos de trabajo mantengan coherencia global y especialización local, logrando un comportamiento predecible, separación clara de funciones y control preciso sobre cómo se aplica el contexto, el conocimiento y las acciones en cada etapa de la interacción.

4. Fusionado Secuencial

Transiciones en flujos de trabajo con condiciones LLM

En las arquitecturas fusionadas secuenciales, un único modelo multimodal gestiona el reconocimiento, razonamiento y generación de voz. Opera turno a turno: escucha hasta que el usuario termina y luego produce el audio directamente. Al procesar el audio de principio a fin, estas arquitecturas capturan de forma natural matices como pronunciación, ritmo y entonación, logrando una voz más fluida y expresiva.

El inconveniente es que los límites son más difíciles de aplicar sin una capa de texto, el uso de herramientas está limitado por núcleos de razonamiento más ligeros y la visibilidad es reducida al no haber salidas intermedias claras.

Cuando una conversación pasa a una nueva etapa, el sistema activa una versión del agente adaptada a ese paso. Cada etapa funciona con instrucciones propias y acceso solo al conocimiento y herramientas relevantes para su responsabilidad. Por ejemplo, una etapa de gestión de reembolsos puede consultar políticas de reembolso sin heredar contexto de onboarding o triaje. El paso entre etapas se rige por condiciones de transición explícitas. Estas condiciones determinan cuándo cambiar de responsabilidad y permiten que las decisiones de enrutamiento ocurran de forma natural según avanza la conversación. Para mantener la continuidad, la experiencia del usuario es fluida entre transiciones, heredando el contexto relevante sin exponer la mecánica interna. También hay salvaguardas que monitorizan las transiciones para evitar ciclos improductivos, asegurando que el flujo siga siendo estable y orientado al objetivo.

Seguridad y protección

5. Fusionado Dúplex

Guardarraíles

En las arquitecturas fusionadas dúplex, el modelo procesa entrada y salida al mismo tiempo. Esto puede generar una conversación más natural, con solapamiento de voz más realista en diálogos cortos, pero también añade mucha complejidad. Los límites son difíciles de aplicar, las interrupciones pueden causar errores y la visibilidad es mínima comparada con las arquitecturas en cascada.

Gestión de datos conforme a normativa

A veces, los interlocutores pueden compartir información sensible con un agente que está sujeta a requisitos estrictos de almacenamiento y procesamiento, como datos médicos que requieren tratamiento conforme a HIPAA. Para estos casos, ofrecemos el Modo Sin Retención (ZRM) a nivel de agente o espacio de trabajo. Cuando está activado, todos los datos de la llamada se procesan solo en memoria y nunca se guardan de forma persistente. Al finalizar la llamada y el procesamiento, ElevenLabs no retiene ninguna información. Por tanto, las transcripciones, grabaciones y análisis no están disponibles en el panel de agentes, y esta política se aplica tanto a sistemas de cara al cliente como a logs internos. Aunque los datos no se retienen, sí se procesan durante la llamada, y cualquier webhook post-llamada recibirá los resultados, permitiendo a los clientes guardar transcripciones o análisis en sus propios sistemas si lo necesitan.

Cómo elegir la arquitectura adecuada para tu caso de uso

No existe una arquitectura única válida para todos los agentes conversacionales. Cada variante tiene sus ventajas y desventajas, desde la previsibilidad y control de los modelos en cascada hasta la naturalidad prosódica de los fusionados.

En este artículo hemos visto cómo los agentes de ElevenLabs gestionan el contexto conversacional, las herramientas, la evaluación y los flujos estructurados para ofrecer experiencias fiables y en tiempo real a gran escala. A medida que los clientes despliegan agentes en entornos cada vez más complejos, seguimos ampliando la flexibilidad de nuestro motor de orquestación, desde modelos de evaluación configurables y controles de transición más ricos hasta mayor visibilidad sobre la composición de prompts y uso de tokens en cada etapa.

Nuestro equipo de Forward Deployed Engineering colabora estrechamente con los clientes para que estas capacidades evolucionen al ritmo de los despliegues reales. La próxima generación de agentes ofrecerá aún más transparencia, determinismo y adaptabilidad sin sacrificar la baja latencia que hace posible la conversación en tiempo real.