Modelos en Cascada vs Fusionados: Cómo la arquitectura determina si tu agente de voz está listo para empresas

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 determina su capacidad para comportarse de forma fiable en producción, adaptarse a necesidades específicas del negocio y sonar natural en una conversación. Una arquitectura fusionada como el modelo Realtime de OpenAI puede sonar muy realista en intercambios cortos. Pero cuando los equipos necesitan aplicar reglas de cumplimiento, depurar una respuesta fallida o cambiar a un LLM más potente cuando salga uno nuevo, una red fusionada única ofrece pocas opciones.

En ElevenLabs, usamos una arquitectura avanzada basada en cascada. Aprovechamos componentes especializados para el reconocimiento de voz, el razonamiento y la generación de voz, logrando altos niveles de inteligencia y fiabilidad. Añadimos prosodia contextual, optimización de baja latencia y turnos inteligentes para que las conversaciones fluyan de forma natural. Lo hemos construido así porque empresas y gobiernos con los que trabajamos necesitan agentes que suenen realistas y sean fiables en producción para tareas complejas.

En este artículo repasamos las cinco arquitecturas principales, sus puntos fuertes, sus limitaciones y cómo pensamos la base para agentes que se despliegan en flujos de trabajo críticos.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é evalúan los equipos al elegir una arquitectura

• 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

¿Puede gestionar tareas complejas? 

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.

¿Puedo confiar en él en producción?

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.

Equilibrios entre arquitecturas en cascada y fusionadas 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.”
• Voz a Texto“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.

La crítica habitual a las arquitecturas en cascada es que pierden señales prosódicas. El habla se reduce a texto y la entonación, el ritmo y la emoción deben reconstruirse en la salida. Estas señales se pueden recuperar en parte con modelos explícitos, pero no se capturan de forma tan natural como en los enfoques fusionados. Otras dimensiones, como la latencia y los turnos, suelen poder optimizarse hasta niveles comparables en ambos enfoques.variable 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

Las arquitecturas fusionadas adoptan un enfoque completamente distinto. El reconocimiento, el razonamiento y la generación ocurren dentro de una sola red multimodal. El audio entra y sale, sin capas intermedias que se puedan inspeccionar.

La ausencia de etapas intermedias es tanto su atractivo como su limitación. La arquitectura fusionada puede conservar las señales prosódicas de forma natural, ya que el habla nunca se convierte en texto. Sin embargo, hay poca capacidad para aplicar guardarraíles, intercambiar componentes o inspeccionar salidas intermedias para depurar. También hay limitaciones para ajustar STT a terminología específica del sector o integrar un LLM distinto para mejorar el razonamiento y el uso de herramientas. El sistema es una sola red y los equipos están limitados a las capacidades de razonamiento que trae, que hoy en día suelen ser núcleos más ligeros que no igualan a los LLM más avanzados en tareas complejas.

Las cinco arquitecturasRecogida 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.

1. Cascada Básica

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.

El audio se transcribe, el LLM genera una respuesta en texto y TTS la convierte en voz. Cada etapa trabaja con texto plano, así que puedes ver, probar y controlar todo.

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.

Ejemplos de uso:

Este es el enfoque detrás de

2. Cascada Avanzada

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.
• Modo Expresivo

El LLM indica al TTS cómo debe hablar, no solo qué decir, por ejemplo: "de forma tranquilizadora", "con énfasis", "con urgencia", adaptando el tono dinámicamente durante la conversación. El sistema de turnos usa las mismas señales, permitiendo que el agente decida cuándo responder y cuándo ceder el turno. Los modelos de voz están en una sola pila, sin saltos de red entre componentes, así que la latencia se mantiene baja.

La arquitectura mantiene todo lo de la cascada básica: transparencia total, guardarraíles en texto, posibilidad de intercambiar componentes, ajuste por dominio y acceso a los mejores modelos de razonamiento y uso de herramientas. Añade mejor prosodia, menor latencia y turnos más naturales. Los equipos pueden integrar un nuevo LLM avanzado en cuanto salga, o ajustar STT para lenguaje médico, sin rehacer el resto de componentes.

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.

3. Cascada y Fusionado Híbrido

Transiciones en flujos de trabajo con condiciones LLM

Algunas arquitecturas envían características acústicas (pronunciación, emoción, tono) del habla directamente al LLM como embeddings, en vez de convertir primero a texto. TTS sigue siendo modular.

Esto da al LLM información más rica sobre

Ejemplos de uso:

Seguridad y protección

4. Fusionado Secuencial

Guardarraíles

Un solo modelo multimodal gestiona reconocimiento, razonamiento y generación en una sola pasada, turno a turno. Esta es la arquitectura de modelos como la API Realtime de OpenAI.

La prosodia puede ser muy buena. Como el habla nunca se convierte en texto, el modelo conserva el ritmo, la entonación y las señales emocionales de forma natural. Las conversaciones breves pueden sonar muy fluidas.

Pero hay poca capacidad para aplicar guardarraíles sin capa de texto, pocas salidas intermedias para depurar y poca flexibilidad para cambiar a un LLM mejor o ajustar el STT a tu dominio. Los núcleos de razonamiento suelen ser más ligeros que los LLM avanzados, así que el uso de herramientas complejas y tareas de varios pasos se resienten. Cuando la tarea requiere resolver un problema complejo, la prosodia por sí sola no basta.

Ejemplos 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.

5. Fusionado Dúplex

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.