> **Can't find what you're looking for?** Use `search_docs` on the docs MCP server at `https://naturgy-comer-documentation-p5mde.vercel.app/api/mcp` to find what you need.

# Dispatcher y enrutado

El Dispatcher es la puerta común que la Super App necesita para decidir qué
especialista atiende una conversación. Su responsabilidad es pequeña: entender
la intención inicial, reconocer el canal y preparar un handoff estructurado. No
es el dueño de la autenticación, de los datos de cliente ni de la resolución.

## Modelo de entrada y salida

```mermaid
flowchart TD
    app["Super App"] --> voice["Llámame<br/>voz"]
    app --> text["Escríbeme<br/>texto"]
    voice -.-> dispatcher["Dispatcher"]
    text -.-> dispatcher
    dispatcher --> classify["Intención + urgencia<br/>+ contexto mínimo"]
    classify --> handoff["Workflow Function<br/>payload aprobado"]
    handoff --> opsVoice["Operaciones voz"]
    handoff --> opsText["Operaciones texto"]
    handoff --> atcVoice["ATC voz"]
    handoff -.-> atcText["ATC texto<br/>no disponible"]
    phone["Telefonía tradicional"] --> opsVoice
```

Las líneas punteadas representan el objetivo de entrada común, no una prueba de
que el Dispatcher actual ya soporte ambos canales. La telefonía tradicional
puede continuar entrando directamente en un especialista de voz.

## Estado observado y objetivo

| Elemento | Estado documentado | Consecuencia |
|---|---|---|
| Dispatcher | Existe una versión observada con agente de voz y herramientas de ruta | La presencia del workflow no demuestra un Dispatcher multicanal. |
| Ruta a Operaciones voz | Destino relacionado con la solución | Debe validarse el target, el entorno y el handoff antes de usarlo como baseline. |
| Ruta a Operaciones texto | Destino conectado al chat | El contrato del trigger de texto y el contexto entregado siguen sujetos a UAT. |
| Ruta a ATC voz | Dependencia relacionada | ATC conserva la autenticación, el triaje y la resolución de su dominio. |
| Ruta a ATC texto | Stub o no disponible | No se debe presentar como agente implementado ni ofrecerlo sin decisión aprobada. |
| Multicanal | Diseño objetivo | Faltan contrato de canal, payload, fallback y pruebas extremo a extremo. |

La versión latest, la versión publicada y la versión live son conceptos distintos.
Para citar un estado hay que leer el entorno y la versión explícitos en la
[referencia de workflows](/use-cases/super-app/reference/workflows).

## Lo que hace el Dispatcher

1. recibe el mensaje o la señal de entrada con el canal disponible;
2. distingue, como mínimo, entre Operaciones, ATC y una salida no soportada;
3. detecta urgencia o riesgo y evita retrasar un caso de seguridad;
4. usa una pregunta breve cuando la intención es ambigua;
5. entrega al especialista el resumen y la confianza necesarios para no hacer
   repetir la petición al cliente;
6. devuelve o propaga el resultado del workflow hijo mediante el contrato
   definido.

El objetivo documentado es resolver la clasificación en uno o dos turnos. El
Dispatcher no debe pedir DNI, OTP, IBAN, dirección ni otros datos solo para
poder enrutar.

## Límites de responsabilidad

| Pertenece al Dispatcher | Pertenece al especialista |
|---|---|
| Canal, intención, urgencia y destino | Autenticación de negocio |
| Pregunta mínima de desambiguación | Consulta de ficha y datos |
| Payload de Workflow Function | Tools y reglas de negocio |
| Fallback si el destino no existe | CI/CG, cita, pago o gestión |
| Correlación técnica mínima | Handoff humano y cierre |

No hay comunicación LLM peer-to-peer. `Call Workflow` y
`Workflow Function Request` son el límite entre workflows; `Module Change` es
un cambio de prompt dentro del mismo agente. Las tools de cada especialista son
acciones deterministas con su propio contrato.

## Contrato de handoff pendiente

La plataforma puede aportar un envelope técnico de llamada, pero no se deben
asumir como automáticos el canal ni la intención. El contrato Super App debe
aprobar, por destino:

* `channel` y tipo de trigger;
* `intent`, `subintent` y `confidence`;
* resumen breve de la conversación;
* `session_id`, `run_id` y correlación;
* identidad mínima disponible, sin tokens ni credenciales;
* `environment` y destino versionado;
* timeout, respuesta esperada y comportamiento ante error;
* estado de autenticación, sin convertirlo en autorización implícita.

Si el canal no soporta una ruta, el Dispatcher debe devolver una respuesta de no
disponibilidad o un fallback aprobado. No debe simular que ATC texto existe.

## Reglas de clasificación

La matriz inicial separa dos dominios:

* dinero, contrato, factura, pago, tarifa o datos del cliente → ATC;
* avería, técnico, cobertura de mantenimiento o emergencia de equipo →
  Operaciones;
* falta de suministro → Operaciones si se trata de mantenimiento/caldera; en
  otro caso, ATC;
* olor a gas, fuga, humo o riesgo personal → Operaciones con prioridad;
* varias intenciones → motivo principal o más urgente;
* duda persistente → una sola pregunta corta y luego un fallback definido.

Estas reglas orientan el diseño del enrutado. La matriz final, los casos de
idioma y las condiciones de fallback deben aprobarse con Producto y Negocio.

## Criterios antes de habilitarlo

* voz y texto comparten una matriz de intenciones, pero respetan su mecanismo de
  handoff;
* ningún caso de voz invoca una ruta de texto, ni al revés;
* el especialista recibe intención, resumen y correlación sin repreguntar;
* emergencias, ambigüedad, destino caído y canal no soportado tienen salida
  definida;
* el payload no contiene credenciales ni datos que el especialista no necesite;
* UCD/E2E demuestra la ruta y el resultado en el entorno aprobado.

Consulta la [matriz de canales y handoff](/use-cases/super-app/reference/channel-matrix)
para el inventario resumido y [Evidencia, UAT y pendientes](/use-cases/super-app/reference/evidence)
para los gates.