Vocero S2S

Arquitectura técnica objetivo y plan de implementación

Estado del documento: propuesta para revisión técnica
Fecha de corte de fuentes: 20 de julio de 2026
Ámbito: plataforma conversacional Speech-to-Speech desacoplada, local y extensible mediante MCP
Audiencia: arquitectura, plataforma, seguridad, MLOps, desarrollo, QA y operación

Convención de trazabilidad

• [REQ] Requisito proporcionado: proviene directamente de la descripción de Vocero S2S entregada por el solicitante.
• [REC] Decisión recomendada: propuesta de diseño que debe aprobarse mediante ADR.
• [BENCH] Supuesto pendiente: hipótesis que requiere medición, prueba de carga, evaluación legal o validación en el entorno objetivo.

1. Resumen ejecutivo

Vocero S2S se plantea como una plataforma conversacional en tiempo real que separa cuatro responsabilidades: experiencia web, control de sesión, inferencia de voz y lenguaje, e integración empresarial mediante Model Context Protocol (MCP). [REQ] La implementación inicial debe utilizar Parakeet TDT 0.6B para STT/VAD, LLaMA 3.1 8B Instruct para razonamiento y llamadas a herramientas, Qwen3-TTS 12Hz 1.7B Base en FP16 para síntesis y clonación zero-shot, y un nodo NVIDIA GB10 accesible inicialmente por el puerto 12345.

La arquitectura objetivo conserva esa cadena desacoplada, pero evita convertir la conexión WebSocket en el lugar donde vive toda la lógica. [REC] Se propone un Control Plane en el servidor UI & Relay para autenticación, autorización, perfil del agente, política de voz, orquestación MCP y auditoría; un Realtime Data Plane para audio y eventos con estado de sesión efímero y cancelación prioritaria; y un Inference Plane local que expone adaptadores versionados para STT, LLM y TTS. La separación permite reemplazar modelos, transporte o infraestructura sin alterar los contratos de negocio.

Para clientes web, WebRTC ofrece ventajas operativas para media en redes variables, mientras que WebSocket sigue siendo apropiado para enlaces servidor-a-servidor y para la primera versión ya planteada. La documentación de plataformas realtime recomienda WebRTC para browser/media y WebSocket para pipelines de servidor 1. [REC] Por ello, el plan adopta WebSocket como transporte inicial compatible y define WebRTC como evolución controlada, no como prerrequisito del MVP.

La gestión de interrupciones es una capacidad de primer orden: al detectar habla del usuario durante la respuesta, el sistema debe cancelar la generación todavía reversible, detener el audio, vaciar buffers no reproducidos y truncar el historial a lo efectivamente escuchado. Este patrón está documentado en sistemas realtime mediante cancelación y truncamiento de elementos de conversación 2, y en frameworks de agentes que ajustan el historial al audio efectivamente reproducido 3.

MCP se integra mediante un gateway empresarial con política, validación de esquemas, identidad delegada, límites, auditoría y adaptadores de versión. Decisión temporal crítica: al 20 de julio de 2026, el anuncio de 2026-07-28 describe explícitamente un Release Candidate cuyo estándar final se espera para el 28 de julio de 2026 y contiene cambios incompatibles 4. Por lo tanto:

1. [REC] la versión estable de compatibilidad inicial será 2025-11-25, verificada en la documentación oficial de transportes 5; esta decisión responde al corte temporal solicitado y no contradice la dirección técnica stateless propuesta por el RC;
2. [REC] 2026-07-28 se implementará sólo detrás de un adaptador experimental y feature flag;
3. [REC] el diseño del dominio se mantendrá preparado para el modelo stateless del RC: requests autocontenidos, estado de aplicación mediante handles explícitos y routing desacoplado de afinidad;
4. [REC] su promoción exigirá ratificación oficial, pruebas de conformidad y migración aprobada;
5. no se asumirá como estándar final en este documento.

Finalmente, la capacidad real de ejecutar STT, LLM y TTS concurrentemente en un único GB10 no está demostrada por un benchmark de la cadena completa. [BENCH] La primera salida de ingeniería debe ser un arnés reproducible que mida latencia extremo a extremo, memoria, ancho de banda, degradación bajo concurrencia, precisión de interrupción y calidad de clonación antes de comprometer capacidad o SLO contractual.

2. Alcance

2.1 Objetivos

• [REQ] Entregar conversación de voz bidireccional y de baja latencia desde un navegador.
• [REQ] Identificar al usuario mediante la API de cliente y personalizar la sesión según identidad o rol.
• [REQ] Cargar dinámicamente el perfil del agente, instrucciones, reglas y herramientas.
• [REQ] Preservar una voz clonada corporativa frente a parámetros por defecto enviados por el cliente.
• [REQ] Ejecutar STT, razonamiento, llamadas a herramientas y TTS en una cadena desacoplada.
• [REQ] Integrar sistemas empresariales sin modificar el núcleo mediante un gateway MCP.
• [REC] Incorporar barge-in, cancelación, backpressure, timeouts, aislamiento, trazabilidad y recuperación de fallas como capacidades del núcleo.
• [REC] Mantener contratos versionados que permitan sustituir transporte, modelos, runtimes y servidores MCP.
• [REC] Proporcionar evidencia operativa para dimensionamiento, SLOs y auditoría.

2.2 No objetivos

• Entrenar desde cero los modelos STT, LLM o TTS.
• Reemplazar ERP, CRM, catálogos u otros sistemas de registro.
• Permitir ejecución directa del LLM contra bases de datos o APIs sin gateway y política.
• Convertir el navegador en depositario de credenciales empresariales o material de voz maestro.
• Garantizar capacidad, latencia o concurrencia antes del benchmark en GB10.
• Declarar la versión MCP 2026-07-28 como estándar final antes de su ratificación.
• Diseñar en esta etapa un contact center completo, grabación regulatoria universal o telefonía SIP; pueden añadirse como dominios posteriores.

3. Principios de arquitectura

1. Control y media separados. El audio tiene requisitos de tiempo real; identidad, política y auditoría requieren consistencia y trazabilidad.
2. Contratos antes que implementaciones. Cada frontera publica eventos y esquemas versionados; los modelos quedan detrás de adaptadores.
3. Interrupción prioritaria. Cancelar y detener audio tiene precedencia sobre generar más contenido.
4. Estado explícito y con dueño. La sesión conversacional pertenece a Vocero; el estado MCP pertenece al adaptador de protocolo o a handles explícitos.
5. Zero trust entre planos. Cada salto autentica servicio, autoriza acción, limita alcance y propaga identidad auditada.
6. Mínimo privilegio para herramientas. Una tool sólo recibe los argumentos, identidad y scopes estrictamente necesarios.
7. Privacidad por defecto. Audio, transcripciones, prompts, respuestas y voces son datos sensibles; la retención es explícita y minimizada.
8. Fallar de forma conversacional. Los fallos técnicos se traducen en eventos deterministas y respuestas seguras, sin filtrar detalles internos.
9. Medir antes de prometer. La experiencia se gobierna por latencia de etapa y percentiles, no por promedios aislados.
10. Compatibilidad MCP versionada. El gateway negocia una versión estable y encapsula candidatos futuros.

4. Vista de contexto y contenedores

4.1 Vista lógica por planos

Experience Plane

• Cliente web, captura de micrófono, cancelación de eco, reproducción y controles de consentimiento.
• Mantiene sólo estado visual y cursores necesarios; no conserva secretos ni voz maestra.

Realtime Data Plane

• Terminación de WebSocket o WebRTC, relay de media y multiplexación de eventos.
• Impone límites de buffer, secuencia y tamaño; descarta datos obsoletos al cambiar de generación.
• Separa una cola de control de alta prioridad —cancel, barge_in, close— de la cola de audio/datos.

Conversation Control Plane

• Resuelve identidad, perfil, permisos y configuración efectiva.
• Mantiene la máquina de estados de sesión y turno.
• Construye contexto, coordina inferencia y decide si una tool puede ejecutarse, confirmarse o rechazarse.

Inference Plane

• Oculta detalles de runtime y expone capacidades uniformes: transcribe, generate, synthesize, cancel, health, capacity.
• Correlaciona cada salida con session_id, turn_id y generation_id para descartar respuestas tardías.

Enterprise Integration Plane

• Gateway MCP con adaptadores de versión, allowlists, validación, autorización, secretos de servicio, idempotencia y auditoría.
• Ninguna respuesta de tool se incorpora al contexto sin controles de tamaño, clasificación y sanitización.

5. Responsabilidades por componente

6. Vista de despliegue

[REC] El puerto 12345 debe ser interno, protegido por firewall, mTLS y autenticación de servicio; no debe publicarse directamente a Internet. [REC] Relay y Orchestrator se despliegan con al menos dos instancias lógicas en producción. Esto no implica que el MVP necesite alta disponibilidad física desde el primer día, pero los contratos no deben depender de memoria local exclusiva.

[BENCH] El GB10 es inicialmente un único dominio de fallo y capacidad. Antes de producción deben definirse: estrategia de nodo de reserva, cola de admisión, límite de sesiones, política de shedding y procedimiento de recuperación de modelos.

7. Máquina de estados y gestión de sesión

7.1 Estados propuestos

7.2 Identificadores

• connection_id: conexión de transporte; puede cambiar al reconectar.
• session_id: sesión conversacional estable y opaca.
• turn_id: entrada comprometida del usuario.
• generation_id: respuesta del agente; cambia después de cancelar o regenerar.
• tool_call_id: invocación única; debe ser idempotente cuando la tool lo soporte.
• voice_profile_id + voice_version: referencia inmutable a la voz autorizada.
• trace_id: correlación distribuida; no reemplaza identificadores funcionales.

7.3 Estado efectivo de sesión

[REC] Se calcula en este orden, sin permitir que el cliente incremente privilegios:

1. defaults seguros de plataforma;
2. política del tenant;
3. perfil del agente versionado;
4. atributos autorizados del usuario;
5. preferencias permitidas de sesión;
6. overrides por respuesta explícitamente allowlisted.

El sanitizador de session.update elimina o rechaza campos que puedan sustituir voice_profile_id, tools, instrucciones de sistema, límites o scopes. Toda diferencia entre configuración solicitada y efectiva queda en un evento session.configuration_applied con razones codificadas.

[REC] El estado efímero se guarda con TTL y control optimista de versión. La reanudación requiere token opaco de corta vida, misma identidad y comprobación de versión del perfil. Audio no confirmado y trabajos de generación no se reanudan: se cancelan y el cliente vuelve a LISTENING.

8. Flujos de ejecución

8.1 Flujo nominal conversacional y MCP

8.2 Tool call con confirmación

1. LLM emite intención, nunca una ejecución directa.
2. Orchestrator valida nombre contra la lista permitida y el esquema vigente.
3. Policy Engine clasifica la acción: lectura, escritura reversible, acción irreversible o prohibida.
4. Si requiere consentimiento, se emite tool.confirmation_required con resumen legible y campos no sensibles.
5. El usuario confirma; se crea confirmation_id ligado a hash de tool + argumentos + identidad + expiración.
6. MCP Gateway ejecuta con token delegado de alcance mínimo.
7. El resultado se valida, limita y clasifica antes de volver al LLM.
8. Se registra la decisión, no secretos ni payloads sensibles completos.

Para la compatibilidad estable 2025-11-25, el adaptador mantiene el lifecycle y la sesión del protocolo de acuerdo con el transporte oficial 5. El RC 2026-07-28 propone eliminar handshake y sesión de protocolo, usar requests autocontenidos, headers de routing y InputRequiredResult; estas capacidades quedan sólo en el adaptador experimental hasta ratificación 4.

8.3 Barge-in

Reglas:

• Un evento de interrupción salta las colas de tokens y audio.
• Todo chunk posterior de G1 se descarta por generation_id obsoleto.
• El cursor del cliente es la fuente de verdad del audio reproducido; si falta, se usa el último ACK conservador.
• Una tool de sólo lectura puede cancelarse; una acción ya confirmada e irreversible no se “deshace” por barge-in. Se informa estado y se evita repetirla.
• Se aplican AEC y umbrales adaptativos para reducir auto-interrupciones; las interjecciones breves se prueban como caso específico.

8.4 Errores y degradación

9. Contratos y eventos orientativos

[REC] Los siguientes esquemas son orientativos. Deben convertirse en JSON Schema versionado, con pruebas de compatibilidad y límites de tamaño. No representan un contrato final.

9.1 Envelope común

{
  "specversion": "1.0",
  "type": "vocero.audio.input.delta.v1",
  "source": "web-client",
  "id": "evt_opaque",
  "time": "RFC3339 timestamp",
  "subject": "session/{session_id}",
  "traceparent": "00-...",
  "data": {
    "session_id": "ses_opaque",
    "turn_id": "turn_opaque",
    "sequence": 42,
    "payload": {}
  }
}

9.2 Catálogo mínimo de eventos

Cliente → plataforma

• session.connect.v1
• session.update_requested.v1
• audio.input.delta.v1
• audio.input.commit.v1
• input.speech_started.v1
• output.playout_progress.v1
• generation.cancel_requested.v1
• tool.confirmation_submitted.v1
• session.close.v1

Plataforma → cliente

• session.configuration_applied.v1
• transcript.partial.v1
• transcript.final.v1
• response.text_delta.v1
• response.audio_delta.v1
• response.completed.v1
• output.stop_and_flush.v1
• tool.confirmation_required.v1
• tool.status.v1
• error.v1

9.3 Ejemplo de session.update_requested

{
  "type": "vocero.session.update_requested.v1",
  "data": {
    "session_id": "ses_opaque",
    "client_capabilities": {
      "audio_codecs": ["opus", "pcm16"],
      "supports_playout_ack": true
    },
    "preferences": {
      "locale": "es-CL",
      "turn_mode": "server_vad"
    }
  }
}

Campos como system_prompt, tools, mcp_credentials, ref_audio, ref_text o voice_profile_id no se aceptan desde este contrato público. Si llegan, el relay los rechaza o elimina según política, y registra la razón.

9.4 Ejemplo de intención de tool interna

{
  "tool_call_id": "tc_opaque",
  "session_id": "ses_opaque",
  "turn_id": "turn_opaque",
  "tool": {
    "name": "production.report.get",
    "schema_version": "1.2.0"
  },
  "arguments": {
    "site_id": "site_authorized",
    "period": "value_from_user_or_context"
  },
  "execution": {
    "mode": "read",
    "idempotency_key": "idem_opaque",
    "deadline_ms": "configured_value"
  },
  "principal": {
    "subject_ref": "opaque_subject",
    "tenant_id": "tenant_opaque",
    "scopes": ["report:read"]
  }
}

9.5 Errores

{
  "type": "vocero.error.v1",
  "data": {
    "code": "MCP_TOOL_TIMEOUT",
    "category": "dependency",
    "retryable": false,
    "user_message_key": "tool.temporarily_unavailable",
    "correlation_id": "corr_opaque",
    "details_ref": "internal_log_reference"
  }
}

Los mensajes públicos no contienen stack traces, endpoints internos, prompts, tokens, argumentos sensibles ni nombres de secretos.

9.6 Compatibilidad MCP

McpAdapter
├── StableAdapter_2025_11_25   # default
├── CandidateAdapter_2026_07_28 # feature flag, no producción por defecto
└── ConformanceHarness
    ├── discovery
    ├── tools/list
    ├── tools/call
    ├── cancellation
    ├── schema validation
    ├── auth propagation
    └── error mapping

La arquitectura oficial de MCP separa una capa de datos JSON-RPC y una capa de transporte, y contempla lifecycle, primitives y notificaciones 6. [REC] Vocero preservará esa separación dentro del adaptador para evitar que detalles de transporte contaminen la lógica conversacional.

Capacidades candidatas que se preparan, pero no se activan como estándar final: el RC 2026-07-28 introduce server/discover, metadatos ttlMs y cacheScope en resultados de listas/lecturas, y headers Mcp-Method/Mcp-Name para routing 4. [REC] El gateway modelará discovery y caché mediante interfaces neutrales: el adaptador estable resolverá su mecanismo según 2025-11-25, mientras que el adaptador candidato podrá mapear esas capacidades nuevas. La caché nunca compartirá resultados más allá del alcance de identidad/tenant permitido y siempre respetará revocación y cambio de política.

10. Clonación de voz y gobernanza

10.1 Modelo operativo

[REQ] Qwen3-TTS debe utilizar ref_audio y ref_text para clonación zero-shot y preservar una locución corporativa. El model card de Qwen3-TTS 1.7B Base confirma streaming, soporte de español y clonación rápida desde audio breve 7. La documentación del repositorio describe generación streaming y clonación de voz 8.

Modos a evaluar:

• Full ICL — recomendado para máxima fidelidad: usa ref_audio y una transcripción ref_text exacta y alineada. [REC] Éste será el modo candidato por defecto para voces corporativas aprobadas.
• x-vector (x_vector_only_mode=True): permite operar sin ref_text, pero la investigación reporta menor fidelidad de timbre y prosodia. [BENCH] Sólo podrá promoverse para un perfil si supera los umbrales de calidad y riesgo definidos.

[REC] El cliente nunca envía referencias maestras durante una sesión. El perfil de agente contiene sólo voice_profile_id y voice_version; TTS resuelve la referencia desde Voice Vault mediante identidad de servicio. El relay elimina voces estándar propuestas por el cliente y el Orchestrator aplica la voz efectiva autorizada.

10.2 Ciclo de vida

1. Solicitud: propietario de la voz, propósito, tenant, idiomas y periodo de uso.
2. Consentimiento verificable: documento o evidencia de autorización; revisión legal según jurisdicción.
3. Ingesta controlada: antivirus, normalización, evaluación de ruido y transcripción alineada.
4. Evaluación: fidelidad, inteligibilidad, pronunciación, estabilidad y riesgo de suplantación.
5. Aprobación de cuatro ojos: dueño de negocio más seguridad/legal o roles equivalentes.
6. Versionado: hash de ref_audio, hash de ref_text, modelo, parámetros y fecha de vigencia.
7. Publicación: sólo perfiles aprobados pueden usarse en producción.
8. Monitoreo: uso por tenant/agente, anomalías y reclamaciones.
9. Revocación: bloqueo inmediato de nuevas sesiones; rotación de caché; evidencia de eliminación.

10.3 Controles

• Cifrado en tránsito y reposo con claves administradas.
• Separación por tenant y entorno; no copiar voces reales a desarrollo.
• URLs firmadas de corta vida o lectura directa por identidad de workload.
• Registro de acceso sin incluir el audio en logs.
• Marcas de procedencia o disclosure cuando la política corporativa o regulación lo exija.
• Pruebas de abuso: texto ofensivo, fraude, ingeniería social, extracción de referencia y uso cruzado entre tenants.
• [BENCH] Comparar Full ICL con ref_audio + ref_text frente a modo sin texto; no asumir equivalencia de calidad.
• [BENCH] Revisión jurídica de licencias de código y pesos antes de uso comercial; la evidencia recopilada no debe sustituir dictamen legal.

11. Seguridad

11.1 Vista de zonas y confianza

11.2 Amenazas principales y mitigaciones

11.3 Autorización de tools

La decisión se evalúa sobre:

permit = policy(
  tenant,
  principal,
  agent_profile_version,
  tool_name,
  tool_schema_version,
  action_class,
  resource_scope,
  argument_classification,
  confirmation,
  session_risk
)

El LLM puede proponer tool_name y arguments, pero no principal, scopes, credenciales, clasificación de acción ni resultado de política. [REC] Las acciones irreversibles requieren confirmación humana específica o una excepción corporativa documentada.

11.4 Datos y retención

Definir una matriz por clase:

• audio bruto;
• referencias de voz;
• transcripción;
• prompt/contexto;
• respuesta de modelo;
• argumentos y resultados de tools;
• telemetría y auditoría.

Para cada clase deben aprobarse propósito, base legal, ubicación, cifrado, retención, borrado, exportación, acceso, uso para entrenamiento y redacción. Pendiente: el solicitante no proporcionó políticas corporativas ni jurisdicciones; por tanto, no se fijan plazos de retención en este documento.

12. Observabilidad y SLOs iniciales

12.1 Modelo de telemetría

Trazas: una traza por turno con spans de captura, relay, STT, endpointing, LLM, policy, MCP, TTS, red y playout. El RC futuro propone nombres estandarizados para propagar W3C Trace Context en _meta, pero esa forma se tratará como candidata hasta ratificación 4. En el adaptador estable, Vocero propagará traceparent mediante metadata interna compatible sin exigir cambios futuros al dominio.

Métricas de experiencia

• turn_endpointing_ms: fin acústico a commit de turno.
• stt_partial_ms y stt_final_ms.
• llm_ttft_ms: commit a primer token.
• tts_ttfa_ms: texto disponible a primer audio.
• ttfs_ms: fin de habla a primer sonido reproducible.
• barge_in_stop_ms: detección de interrupción a silencio efectivo.
• tool_latency_ms por tool y outcome.
• turn_e2e_ms por ruta directa o con tool.
• tasa de reconexión, cancelación, falsos barge-in y abandono.

TTFT y latencia extremo a extremo se reconocen como dimensiones distintas y relevantes para cargas de voz/tiempo real 9.

Métricas de calidad

• WER/CER por idioma, acento, ruido y dominio.
• tasa de endpointing temprano/tardío.
• inteligibilidad y evaluación humana de naturalidad.
• similitud de locutor y estabilidad de voz.
• exactitud de tool selection, argumentos, política y task completion.

Métricas de recursos

• utilización y memoria GPU; KV cache; colas por modelo; tokens/s; audio seconds/s.
• profundidad y edad de buffer; drops; retransmisiones; jitter; playout underruns.
• conexiones activas, sesiones admitidas/rechazadas y errores por dependencia.

12.2 Objetivos iniciales — no son desempeño observado

[REC/BENCH] Estos valores son objetivos provisionales de ingeniería, no cifras medidas, garantías ni SLO contractual. Deben ratificarse después del benchmark con audio, red, herramientas y concurrencia reales.

Presupuesto provisional de ttfs_ms para análisis, no compromiso:

endpointing + STT final + scheduling + LLM TTFT + TTS primer audio + transporte/playout

No se asignan milisegundos fijos por etapa hasta contar con benchmark; el tablero debe mostrar contribución y percentiles por separado.

12.3 Alertas iniciales

• Burn-rate de disponibilidad y turnos exitosos.
• Crecimiento sostenido de cola o edad de buffer.
• GPU OOM, reinicio de modelo o health degradado.
• Divergencia entre generation.cancel y último chunk emitido.
• Error/latencia MCP por tool, tenant y dependencia.
• Accesos denegados o anomalías de voz.
• Ausencia de trazas o cardinalidad no controlada.

13. Escalabilidad, backpressure y resiliencia

13.1 Escalado

• Edge/Relay: horizontal por conexiones; estado mínimo; drenaje antes de deploy.
• Orchestrator: horizontal por sesión con lease en store; afinidad opcional como optimización, no requisito de corrección.
• MCP Gateway: horizontal; pools por downstream; bulkheads por tenant/tool.
• Inference: admission control basado en capacidad real, no sólo CPU; colas separadas STT, LLM y TTS; prioridades de cancelación y audio activo.
• Voice cache: caché cifrada y acotada por voces aprobadas; invalidación por versión/revocación.

13.2 Backpressure

[REC] Cada enlace publica high_watermark, low_watermark y política de overflow. El LLM puede producir texto más rápido de lo que TTS o la red consumen; el sistema debe frenar tokens, agrupar por unidades pronunciables y limitar audio anticipado. El problema general de productores rápidos y consumidores lentos está documentado en pipelines realtime 10.

Políticas:

1. Eventos de control nunca comparten una cola bloqueante con audio.
2. Parciales STT obsoletos pueden coalescerse; finales y commits no.
3. Tokens no sintetizados de una generación cancelada se descartan.
4. Audio generado pero no reproducido se descarta al interrumpir.
5. Una conexión lenta no puede consumir memoria sin límite.
6. El cliente reporta buffered_ms y playout; el servidor ajusta chunking o pausa.
7. Las colas tienen deadline; trabajo vencido no se procesa “por completitud”.

13.3 Resiliencia

• Timeouts por etapa y deadline total propagado.
• Circuit breakers por dependencia y modelo.
• Retries con jitter sólo para operaciones idempotentes.
• Bulkheads por tenant y tool para evitar fallos en cascada.
• Health de proceso, readiness de modelo y señal de capacidad diferenciados.
• Warm-up verificado antes de recibir sesiones.
• Deploy con drenaje de conexiones y cancelación segura.
• Snapshots de configuración y rollback de perfiles/modelos.
• Runbooks para GPU OOM, degradación STT/TTS, MCP lento, store no disponible y compromiso de voz.

[BENCH] La posibilidad de alojar simultáneamente toda la cadena en un GB10, y el número de sesiones sostenibles, deben medirse. Parakeet TDT 0.6B v3 dispone de soporte de streaming documentado y timestamps 11; esto valida la capacidad funcional, no la capacidad concurrente del sistema completo.

14. Plan de implementación por fases

Las fases no incluyen fechas ni duraciones porque no se entregaron disponibilidad de equipo, ambientes, procurement ni ventanas de cambio. Cada fase termina con una decisión explícita de continuar, corregir o detener.

Fase 0 — Descubrimiento, contratos y riesgos

Entregables

• Inventario de requisitos funcionales, datos, tenants, roles, herramientas y acciones sensibles.
• ADRs iniciales y modelo de amenazas.
• Catálogo de eventos v1 y esquemas de audio/control.
• Matriz de licencias y gobernanza de voz.
• Definición del corpus de benchmark y plan de medición.

Dependencias

• Acceso a APIs de auth/profile y definición de MCP del cliente.
• Responsables de seguridad, legal, negocio y operación.
• Hardware GB10 y artefactos versionados de modelos.

Criterios de aceptación

• Requisitos etiquetados y aprobados; pendientes con dueño.
• Ningún secreto ni voz real requerido para desarrollo temprano.
• ADR-001 a ADR-006 en estado Proposed o Accepted.
• Amenazas críticas con control y prueba asociada.

Riesgos

• Ambigüedad de identidad/roles.
• Licencias o consentimiento de voz no resueltos.
• Tools MCP sin idempotencia o clasificación de riesgo.

Fase 1 — Vertical slice local sin tools de escritura

Entregables

• Cliente web + WebSocket, Relay, Orchestrator e Inference Gateway.
• STT → LLM → TTS streaming con una voz de prueba autorizada.
• Máquina de estados, IDs, cancelación y logs estructurados.
• Simuladores deterministas de STT/LLM/TTS para CI.

Dependencias

• Modelos cargables y runtime compatible.
• Certificados de servicio y entorno aislado.

Criterios de aceptación

• Conversación nominal reproducible.
• Reconexión no duplica turnos.
• Cancelar una generación impide chunks tardíos en playout.
• La voz solicitada por cliente no reemplaza la voz efectiva.
• Primera línea base de latencia y recursos registrada.

Riesgos

• Contención de GPU.
• Latencia de endpointing.
• Inestabilidad del runtime o incompatibilidad FP16.

Fase 2 — Barge-in, backpressure y sesión robusta

Entregables

• Cola de control prioritaria y output.stop_and_flush.
• Playout ACK/cursor; truncamiento de historial.
• Límites de buffer, shedding, deadlines y circuit breakers.
• Pruebas con ruido, eco, interjecciones y red degradada.

Dependencias

• Instrumentación por etapa.
• Dataset de conversaciones y condiciones acústicas representativas.

Criterios de aceptación

• Cero audio de generación obsoleta después del límite aprobado de interrupción.
• Sin crecimiento no acotado de memoria con cliente lento.
• Sin doble respuesta después de reconexión/cancelación.
• Falsos barge-in medidos y dentro del umbral que defina negocio.

Riesgos

• Eco que dispara VAD.
• Cursor de playout impreciso.
• Races entre cancelación, TTS y entrega de red.

Fase 3 — Gateway MCP de lectura

Entregables

• StableAdapter_2025_11_25.
• Discovery allowlisted, validación de schemas y tools/call de lectura.
• Policy Engine, identidad delegada, límites, auditoría e idempotencia.
• Servidor MCP simulado y pruebas de contrato.

Dependencias

• Servidor MCP del cliente y esquema de autorización.
• Clasificación de tools y datos.

Criterios de aceptación

• Tool no allowlisted es rechazada antes del downstream.
• Argumentos y resultados inválidos no alcanzan LLM/sistemas.
• Cada tool call se correlaciona con usuario, sesión, turno y política.
• Timeouts no causan retries inseguros.

Riesgos

• Prompt injection en resultados.
• Credenciales con exceso de privilegios.
• Contratos downstream inestables.

Fase 4 — Escrituras, confirmación y gobernanza de voz

Entregables

• Flujos de confirmación ligados a hash e idempotency key.
• Ledger de acciones y estado desconocido.
• Voice Vault, workflow de aprobación, revocación y caché segura.
• Pruebas de abuso y runbooks de incidente.

Dependencias

• Aprobación legal de voces/licencias.
• Semántica de idempotencia en sistemas empresariales.

Criterios de aceptación

• Ninguna acción sensible se ejecuta sin política/confirmación requerida.
• Repetición de evento no repite side effect.
• Revocar una voz bloquea nuevas síntesis y limpia cachés.
• Acceso cruzado entre tenants falla y queda auditado.

Riesgos

• Acciones no idempotentes.
• Consentimiento incompleto.
• Exfiltración o uso indebido de voz.

Fase 5 — Preproducción, SLO y resiliencia

Entregables

• Pruebas de carga, soak, caos y recuperación.
• Dashboards, alertas, SLOs ratificados y runbooks.
• Capacity model y límites de admisión.
• DR/backup para configuración, auditoría y Voice Vault.
• Revisión de seguridad y go-live checklist.

Dependencias

• Tráfico/perfiles representativos.
• Entorno equivalente a producción.
• On-call y ownership definidos.

Criterios de aceptación

• Objetivos de experiencia ratificados o renegociados con evidencia.
• Recuperación de fallos críticos demostrada.
• Ninguna vulnerabilidad crítica abierta.
• Operación puede detectar, diagnosticar y mitigar escenarios de runbook.

Riesgos

• Único GB10 como SPOF.
• Capacidad insuficiente bajo mezcla real.
• Diferencias entre red de prueba y campo.

Fase 6 — Despliegue progresivo y evolución

Entregables

• Canary por usuarios/tenant y rollback automático.
• Revisión post-piloto con calidad, latencia, seguridad y task completion.
• Roadmap WebRTC si WebSocket no satisface objetivos.
• CandidateAdapter_2026_07_28 sólo si la especificación fue ratificada.

Criterios de aceptación

• Canary sin regresión en SLOs/seguridad.
• Soporte y escalamiento operativo validados.
• Migración MCP pasa conformance suite y ADR de promoción.

15. Estrategia de pruebas

15.1 Pirámide

Unitarias

• máquina de estados, sanitización, policy, mapping de errores, deduplicación, expiración y redacción.

Contrato

• JSON Schema de eventos, compatibilidad hacia atrás, adaptadores MCP, APIs de perfil e identidad.

Integración

• STT/LLM/TTS reales; MCP simulado y real; Voice Vault; KMS; stores.

End-to-end

• audio a audio con playout medido, rutas directas, tools, confirmación, cancelación y reconexión.

Carga y soak

• sesiones concurrentes, mezcla de turnos, audio largo, cliente lento, tools lentas, churn de conexiones y modelos calientes/fríos.

Caos

• proceso muerto, GPU OOM, store lento, pérdida de red, respuesta tardía, certificado vencido, dependencia parcial y restart durante tool call.

Seguridad

• authn/authz, tenant isolation, replay, prompt injection, schema bombs, SSRF, egress, secretos, DLP, abuso de voz y supply chain.

15.2 Matriz mínima de escenarios

15.3 Oráculos y reproducibilidad

• Audio de prueba versionado, con consentimiento y etiquetas.
• Fakes deterministas para carreras y errores.
• Semillas/parámetros de generación registrados donde aplique.
• Golden transcripts y schemas, pero tolerancias acústicas definidas.
• Captura de timestamps monotónicos en cada frontera.
• Reporte por percentiles y condición, no sólo promedio.
• Comparación A/B de configuraciones de VAD, chunking y voz.

16. Matriz de decisiones y ADRs

Cada ADR debe incluir contexto, decisión, alternativas, consecuencias, riesgos, estado y condición de revisión. Las decisiones reversibles pueden iniciarse como Proposed; las que afectan seguridad, datos, licencias o compatibilidad externa requieren aprobación explícita.

17. Pendientes y preguntas abiertas

Producto y experiencia

• ¿Qué canales se incluyen: sólo browser, móvil, telefonía o todos?
• ¿Qué idiomas, acentos, vocabulario y condiciones acústicas son prioritarios?
• ¿Qué comportamiento se espera al fallar voz: texto, voz alternativa o cierre?
• ¿Qué acciones requieren confirmación verbal, visual o autenticación reforzada?

Identidad y autorización

• Contrato real de /api/v1/auth/user-by-phone y mecanismo de autenticación.
• Modelo de roles, tenants, scopes y separación de datos.
• Token exchange/delegación hacia MCP y sistemas downstream.

MCP

• Inventario de servidores, tools, schemas, side effects, idempotencia y SLO downstream.
• Versión estable realmente soportada por el servidor del cliente.
• Estrategia de cache/refresh de discovery.
• Ratificación futura de 2026-07-28 y disponibilidad de SDK/conformance suite.

Inferencia y capacidad

• Runtime exacto para LLaMA, asignación de memoria y política de KV cache.
• Concurrencia sostenible de STT + LLM + TTS en GB10.
• Efecto de context length, prompt del agente y tool results sobre TTFT.
• Cold start, carga de modelos, fragmentación y recuperación OOM.
• Calidad de Parakeet en audio y dominio reales.

Voz y legal

• Titular y evidencia de consentimiento de cada voz.
• Licencia aplicable a pesos, código, redistribución y uso comercial.
• Reglas de disclosure, retención, localización y derecho de revocación.
• Métrica y umbral de aceptación de fidelidad/seguridad.

Operación

• Ambientes, topología, certificados, secretos, KMS, stores y backups.
• RTO/RPO y modelo on-call.
• Política de logs, sampling, redacción y retención.
• Capacidad de nodo de reserva o alternativa de servicio.

18. Riesgos consolidados

Las probabilidades no numéricas reflejan ausencia de datos; deben actualizarse después de pruebas y revisión organizacional.

19. Criterio de arquitectura lista para piloto

La solución está lista para piloto sólo cuando:

1. los requisitos y ADRs críticos están aprobados;
2. la ruta estable MCP está probada y la candidata futura permanece aislada;
3. el benchmark extremo a extremo demuestra capacidad para la carga piloto;
4. barge-in y backpressure pasan pruebas acústicas y de red;
5. tools sensibles tienen política, confirmación e idempotencia;
6. la voz está autorizada, versionada y revocable;
7. seguridad no mantiene hallazgos críticos abiertos;
8. tableros, alertas y runbooks permiten operar el servicio;
9. SLOs provisionales fueron ratificados o sustituidos con evidencia;
10. existe rollback probado de aplicación, perfil, modelo y configuración.

20. Fuentes

1. [1] OpenAI — Realtime and audio — https://developers.openai.com/api/docs/guides/realtime
2. [2] Microsoft Azure — Realtime audio — https://learn.microsoft.com/en-us/azure/ai-services/openai/how-to/realtime-audio
3. [3] LiveKit — Turns overview — https://docs.livekit.io/agents/logic/turns/
4. [4] Model Context Protocol — 2026-07-28 Release Candidate — https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/
5. [5] Model Context Protocol — Transport specification 2025-11-25 — https://modelcontextprotocol.io/specification/2025-11-25/basic/transports
6. [6] Model Context Protocol — Architecture overview — https://modelcontextprotocol.io/docs/learn/architecture
7. [7] Qwen — Qwen3-TTS 12Hz 1.7B Base model card — https://huggingface.co/Qwen/Qwen3-TTS-12Hz-1.7B-Base
8. [8] QwenLM — Qwen3-TTS repository — https://github.com/QwenLM/Qwen3-TTS
9. [9] Telnyx — Inference Benchmark: TTFT vs E2E Latency — https://telnyx.com/resources/inference-benchmark-ttft-vs-e2e
10. [10] Arun Baby — Real-Time Agent Pipelines — https://www.arunbaby.com/ai-agents/0016-real-time-agent-pipelines/
11. [11] NVIDIA — Parakeet TDT 0.6B v3 model card — https://huggingface.co/nvidia/parakeet-tdt-0.6b-v3

Apéndice A — Checklist de implementación

• [ ] Requisitos [REQ], recomendaciones [REC] y supuestos [BENCH] revisados.
• [ ] ADRs críticos aprobados.
• [ ] Modelos y hashes fijados; SBOM y licencias revisadas.
• [ ] Identidad, roles, scopes y tenants definidos.
• [ ] Event schemas v1 publicados y contract-tested.
• [ ] Stable MCP adapter probado contra 2025-11-25.
• [ ] Candidate MCP adapter deshabilitado por defecto.
• [ ] Voice Vault, consentimiento, rotación y revocación operativos.
• [ ] Admission control y límites de buffer configurados.
• [ ] Barge-in medido hasta playout real.
• [ ] Tool confirmation e idempotencia verificadas.
• [ ] Telemetría redactada y correlacionada.
• [ ] SLOs ratificados con benchmark.
• [ ] Runbooks y rollback ensayados.
• [ ] Revisión de seguridad y go-live completadas.