1Topología
Cuatro agentes independientes, cada uno con su propio agent_id, su alcance y su modelo de riesgo. No hay agente enrutador: los agentes se derivan entre sí con transfer_to_agent según la matriz de la sección 4.
transfer_to_number hacia colas humanas. La PoC corre sobre widget web, donde no hay telefonía: transfer_to_number está reemplazado por el client tool transferir_humano, que registra la derivación en la consola. Las transferencias entre agentes sí son reales.
2Mapa de agentes
Un agente consume RAG puro, uno consume tres APIs de lectura, dos son transaccionales de escritura. El modelo de riesgo determina qué puede hacer cada uno.
| Agente | Auth | Fuente de datos | Tools | ¿Divulga datos? | Fase |
|---|---|---|---|---|---|
bf-faqConsultas Generales |
none | RAG | 9 documentos de KB | No | 1 |
bf-bloqBloqueo de Tarjeta |
light | API | bf_bloqueo_crear_ticket |
No | 1 |
bf-descDesconocimiento |
light | API | bf_reclamo_crear |
No | 1 |
bf-ctaConsultas de Cuenta |
strong | API | bf_cuenta_resumen, bf_cuenta_movimientos, bf_pago_estado |
Sí | 2 |
Regla dura: si auth_level no es strong, ningún agente divulga saldos, cupos, movimientos, montos ni fechas de vencimiento. bf-cta es el único que puede alcanzar ese nivel, y solo con la identidad heredada de una sesión ya autenticada.
3Endpoints y warm up
Las 5 webhook tools viven en un único Worker. Dos escriben en el sistema de casos, tres leen del core bancario autenticando con el session_token heredado de la sesión.
| Tool | Método | Auth | Qué hace |
|---|---|---|---|
bf_bloqueo_crear_ticket | POST | X-PoC-Token | Crea el ticket de bloqueo. Idempotente por conversation_id. No ejecuta el bloqueo en el core. |
bf_reclamo_crear | POST | X-PoC-Token | Crea el caso de desconocimiento con hasta 3 cargos en detalle y la tipificación del PASO 5. |
bf_cuenta_resumen | GET | Bearer {{session_token}} | Cupo total, utilizado, disponible, monto facturado, fechas. |
bf_cuenta_movimientos | GET | Bearer {{session_token}} | Últimos movimientos, tope duro de 5. Filtros por monto aproximado y por comercio. |
bf_pago_estado | GET | Bearer {{session_token}} | Pagos del período. Devolver vacío no significa que el cliente no pagó. |
Los Workers arrancan en frío tras unos minutos sin tráfico. Ese primer request paga el arranque del isolate y se nota en la primera tool de una demo. Correr el warm up antes de una presentación lo elimina.
4Matriz de transferencias
Cualquier derivación que no esté en esta tabla va a humano. Ningún agente devuelve una conversación al agente que se la pasó: la variable transfer_history viaja en cada salto y cada agente la verifica antes de transferir.
| Desde | Hacia | Condición |
|---|---|---|
bf-faq | bf-bloq | Pérdida, robo o extravío de tarjeta |
bf-faq | bf-desc | Cargo que el cliente no reconoce |
bf-faq | bf-cta | Consulta de saldo, cupo, movimientos o pago |
bf-bloq | bf-desc | Solo después de completar el bloqueo, si hay cargos desconocidos |
bf-desc | bf-bloq | Tarjeta sin bloquear y cargos recientes o en curso |
bf-cta | bf-desc | El cliente no reconoce un movimiento leído |
bf-cta | bf-bloq | Menciona pérdida o robo durante la consulta |
| Cualquiera | transferir_humano | Pedido explícito, alteración sostenida, riesgo, fallo repetido de tool, fuera de alcance |
bf-bloq nunca es destino final: siempre termina en humano, porque en Fase 1 el agente no ejecuta el bloqueo, solo lo deja pedido y documentado.
5Configuración de la plataforma
| Capa | Elección | Por qué |
|---|---|---|
| TTS | eleven_flash_v2_5 · optimize_streaming_latency: 3 | Prioridad latencia. Objetivo de la spec: primer audio bajo 1.200 ms. |
| Voz | es-CL femenina neutra | Misma voz validada en los PoCs de BCI y Falabella retail. Acento chileno consistente. |
| ASR | Scribe realtime + keyword boost | Refuerzo de CMR, cupo, cartola, avance, RUT, Tottus, Sodimac, dígito verificador. |
| LLM | gemini-2.5-flash · temperature 0.2 · max_tokens 300 | Estos flujos no requieren creatividad. Toda la variabilidad deseable ya está en el bloque de estilo. |
| Turnos | turn_timeout 7s · silence_end_call 15s | Sección 6 de la spec: un "¿sigues ahí?" a los 7 segundos, cierre a los 15. |
| Idioma | detect_language apagado | Deliberado: si el cliente cambia de idioma, el agente sigue en español y ofrece transferencia. |
| Privacidad | Retención 30 días · redacción de PII | Provisorio de PoC. El valor definitivo lo define Legal del banco. |
Dónde se va el tiempo en un turno con tool
ASR (~200–400 ms) + generación del LLM (~2–4 s) + ejecución de la tool (~150 ms) + TTFB de TTS (~75 ms). El LLM domina el presupuesto. Es también donde está la palanca de optimización: prompt más corto o modelo más rápido.
A tener en cuenta: el prompt de cada agente ensambla los bloques comunes B1–B6 literales más el prompt específico, y queda en el orden de 12–13 mil caracteres. Es lo que pide la spec y da trazabilidad uno a uno contra el documento de compliance, pero está por encima del rango habitual. Si en las pruebas aparece dilución de instrucciones o latencia de más, el primer ajuste es condensar B2 y B3 sin perder ninguna regla.
6Qué está mockeado y qué no
- Real: los 4 agentes, sus prompts completos, la voz, el RAG sobre 9 documentos, las transferencias entre agentes, la validación de RUT por módulo 11, la captura estructurada de datos y los criterios de evaluación.
- Mockeado: el sistema de casos (tickets y folios), el core bancario (cupo, movimientos, pagos) y las colas humanas de destino.
- Fuera de alcance total del proyecto: cobranza, mora, deuda vencida, repactación y convenios de pago. Los agentes cortan y derivan sin dar dato ni opinión.
- No construido a propósito: agente enrutador, menú de opciones, venta proactiva, y cualquier tool que escriba en el core bancario.
La KB de bf-faq se armó con información pública del sitio de Banco Falabella y lleva fecha de vigencia en cada documento. Los montos del tarifario se publican en PDF y no están cargados: ante esas consultas el agente deriva y registra el vacío en dc_kb_gap, que es exactamente el mecanismo previsto para iterar la KB.