Arquitectura de un agente de voz con GPT-Live-1: cómo conectar voz y lógica de fondo

Construir un asistente de voz se ha reducido durante mucho tiempo a encadenar tres componentes independientes: reconocimiento de voz (STT), un modelo de lenguaje (LLM) y síntesis de voz (TTS). En la práctica, esta cascada genera una latencia perceptible y complica la gestión de una conversación en vivo. Cuando el interlocutor hace una pausa, cambia de idea o interrumpe al asistente, el desarrollador tiene que rastrear manualmente el estado, reiniciar el flujo de audio y sincronizar el contexto entre tres servicios distintos.

El 10 de septiembre de 2026, OpenAI habilitó el acceso al modelo GPT-Live-1 en la API (lanzamiento oficial). En lugar de enlazar servicios paso a paso, el modelo ofrece una capa de audio full-duplex: es capaz de recibir simultáneamente el flujo de sonido entrante y generar respuestas habladas.

Separación entre voz y cómputo

Si la ejecución de tareas en el backend requiere tiempo, estas se separan de la capa de voz para mantener una interacción conversacional continua. Una arquitectura práctica basada en GPT-Live-1 se apoya en la división de responsabilidades:

1. Frontend de voz. El modelo procesa de forma simultánea el audio entrante y saliente. Según los desarrolladores, este enfoque tolera mejor el ruido de fondo, las pausas y las interrupciones en comparación con una cascada STT–LLM–TTS, además de admitir la detección nativa de turnos de palabra (turn detection).
2. Backend de fondo. El análisis complejo de datos, las consultas a bases de datos y las llamadas a herramientas (tool calling) se delegan en modelos de texto dedicados o agentes externos.

Este esquema está diseñado para que la interfaz mantenga el contacto con el interlocutor y no se quede en silencio mientras el servicio en segundo plano prepara una respuesta sustancial. Aun así, la latencia real y la fluidez de la transición deben verificarse en cada stack específico.

Cómo funciona la delegación de tareas

La voz y el backend funcionan de manera asíncrona. Cuando el usuario solicita el estado de un pedido o una búsqueda en el repositorio, la aplicación gestiona el envío de la tarea a su backend.

En la documentación oficial se ofrece un ejemplo conceptual de esta coordinación utilizando el Codex SDK:

import { Codex } from "@openai/codex-sdk";

const thread = new Codex().startThread({
  workingDirectory: "./repo",
  sandboxMode: "read-only",
  approvalPolicy: "never",
});

async function answer(live, delegationId, context) {
  const { finalResponse } = await thread.run(
    `Answer the latest question using this repo.
     Reply in two short spoken sentences.\n${context}`
  );

  live.send({
    type: "session.commentary.append",
    delegation_id: delegationId,
    content: finalResponse,
  });
}

El código anterior es solo un fragmento oficial de integración: se han omitido la inicialización de la conexión y la gestión de eventos de delegación, por lo que no está pensado para ejecutarse de forma independiente.

Este fragmento ilustra el principio general de interacción: la aplicación transfiere el contexto de la intervención al hilo de trabajo de la herramienta y devuelve la respuesta obtenida a la sesión de audio mediante el evento session.commentary.append. El canal de voz permanece activo, lo que permite al agente pronunciar una breve frase introductoria si es necesario mientras el backend finaliza sus cálculos.

Criterios para elegir la arquitectura

A la fecha de publicación, el coste de la capa de voz es de $0.05 por minuto, lo que no incluye los gastos derivados de modelos en segundo plano ni llamadas a herramientas. Este esquema resulta conveniente en escenarios donde la continuidad del diálogo es fundamental:

• Llamadas telefónicas y reservas de citas. Procesos en los que cualquier pausa poco natural entre intervenciones hace que el cliente pregunte si todavía se le escucha.
• Soporte con lenguaje espontáneo. Diálogos en los que las personas suelen vacilar, reformular ideas sobre la marcha o expresarse con frases incompletas.
• Interacción por voz en tareas compartidas. Trabajo interactivo con código o documentos donde el usuario reflexiona en voz alta y prefiere no esperar a que concluya cada turno individual.

Si la tarea se limita a la introducción de comandos rígidos, el dictado de notas o la cumplimentación de formularios estándar, tiene sentido comparar esta solución con una cascada tradicional basada en STT.

Por dónde empezar a validar el prototipo

Los pasos que se indican a continuación representan recomendaciones para validar un prototipo, no un informe de pruebas concluidas. Antes de migrar un flujo de trabajo a la nueva arquitectura, conviene seguir estos pasos básicos:

• Mide el tiempo de respuesta del backend. Si la consulta a tu base de datos o a un modelo externo toma tiempo, configura la capa de voz para que confirme el inicio de la operación con una frase breve y natural en lugar de permanecer en silencio.
• Comprueba el comportamiento en entornos ruidosos. Prueba el prototipo en condiciones reales: con ruido ambiental de la calle, conversaciones de fondo o un micrófono inestable.
• Limita el formato de las respuestas del modelo en segundo plano. En el prompt del sistema para el backend, especifica de forma explícita que las respuestas deben limitarse a una o dos frases concisas, fáciles de asimilar al escucharlas.
• Establece límites de duración para las sesiones. Con una tarifa de $0.05 por minuto en la capa de voz, resulta útil limitar de forma programática el tiempo máximo de una llamada de prueba para evitar cobros innecesarios si la conexión del cliente se queda bloqueada.

Esta secuencia de pasos ayuda a detectar con antelación las latencias reales de las herramientas y a ajustar los prompts antes de escalar el sistema.