El prototipo de la fase 3 responde bien lo general (“¿qué requisitos tiene el crédito X?”) y deriva lo particular (“¿cuánto es MI próxima cuota?”) — porque no tiene manos. Esta fase se las da: las herramientas que consultan los sistemas de Finandes, expuestas por MCP — y construidas con la paranoia correcta, porque en una financiera “el agente puede consultar cuentas” es una frase que un auditor va a leer.

La tesis de la fase

Cada herramienta es un contrato mínimo — hace una cosa concreta, sobre el cliente verificado, con credenciales que el modelo jamás ve — y el servidor MCP que las agrupa es un microservicio más de la plataforma: con su identidad, sus permisos y su registro. La regla que ordena la fase entera: la identidad del cliente no la decide el modelo — viene verificada desde el canal — y toda herramienta la exige como parámetro imposible de falsificar. Así se mata al confused deputy antes de que nazca.

Las tres herramientas del caso

El criterio de selección fue el de siempre — las herramientas concretas que el flujo necesita, no el fetch genérico — y el análisis de los correos del dataset dio el podio claro:

Herramienta	Qué hace	Riesgo	Nivel
`consultar_estado_cuenta`	Resumen del crédito del cliente: cuotas pagadas, pendientes, al día o en mora	Lee datos personales	Lectura
`proxima_cuota`	Fecha y monto de la próxima cuota del cliente	Lee datos personales	Lectura
`generar_certificado`	Emite el certificado estándar (deuda vigente / sin deuda) como PDF adjunto al borrador	Crea un documento oficial	Generación — con marca de “borrador” hasta la fase 8

Nota lo que no está: nada que modifique (repactar, condonar, cambiar datos). No es timidez — es la política de la fase 1: lo delicado se deriva, y las herramientas de escritura entrarían solo con la gobernanza de aprobación que este catálogo conoce bien — si el caso de negocio algún día las pide.

El patrón central: la identidad viene verificada

El confused deputy en versión Finandes: el correo dice “soy Juan Pérez, RUT tal, ¿cuánto debo?” — y si el agente consulta lo que el texto del correo afirma, cualquiera que escriba un RUT ajeno recibe datos ajenos. La solución es estructural, no de prompt:

   LA IDENTIDAD NO LA DECIDE EL MODELO

  correo entra por el canal autenticado
  (el cliente escribió desde SU correo
  registrado — o desde el portal con sesión)
        │
        ▼
  el SISTEMA resuelve: correo_remitente
  → cliente_id verificado
        │
        ▼
  cliente_id viaja en el ESTADO del grafo,
  fuera del alcance del modelo
        │
        ▼
  toda herramienta lo exige como parámetro:
  consultar_estado_cuenta(cliente_id=ESTADO)
  — el modelo puede PEDIR la consulta,
  jamás ELEGIR el cliente

En código, la herramienta no acepta lo que el modelo diga:

@tool
def consultar_estado_cuenta(runtime_ctx) -> EstadoCuenta:
    """Estado del crédito del cliente de ESTA conversación.
    Sin parámetros de identidad: el cliente ya está resuelto."""
    cliente_id = runtime_ctx.cliente_id   # del canal, no del prompt
    return crm.estado_cuenta(cliente_id)  # credencial en el borde

Tres capas del mismo principio en esas seis líneas: la identidad fuera del alcance del modelo (viaja en el runtime, no en el prompt — la inyección más creativa no puede cambiarla), la credencial en el borde (crm usa su secreto de Secrets Manager vía la identidad del servicio — el modelo jamás ve una llave), y el contrato mínimo (la herramienta sin parámetros de identidad no puede usarse mal — el diseño más seguro es el que elimina la categoría del error).

El servidor MCP: un microservicio con modales

Las tres herramientas viven en un servidor MCP propio — mcp-finandes-soporte — y la decisión de usar el protocolo estándar (en vez de funciones pegadas al agente) compra tres cosas: el contrato tipado y versionado (las herramientas se documentan, prueban y evolucionan como la API que son), la reutilización (el agente de la fase 3 es su primer cliente; el asistente interno del próximo año será el segundo — sin tocar el servidor), y el punto de control (cada invocación queda registrada con cliente, herramienta y resultado — el insumo directo de la auditoría de la fase 6 y las métricas de la fase 8).

Operativamente es un microservicio más de la plataforma: correrá junto al agente en la infraestructura de la fase 7, con su managed identity de permisos mínimos (lee el CRM; nada más), en la red privada, detrás del mismo perímetro.

Ojo — el certificado y la escalera: generar_certificado es la herramienta más delicada del trío: produce un documento oficial de una financiera. Por eso nace con dos cinturones: el PDF sale marcado como borrador y viaja adjunto al borrador de respuesta (que un humano revisa y envía — el flujo de la fase 3 no cambió), y el certificado definitivo — sin marca, enviado directo — es una decisión de la fase 8, tomada con datos del piloto y solo para los casos donde la tasa de error medida lo permita. La escalera de confianza no es solo para humanos delegando en agentes: es para agentes ganándose capacidades.

El entregable: el servidor MCP con las tres herramientas (contra un CRM de prueba con datos sintéticos — los reales llegan con los permisos de la fase 7), el grafo de la fase 3 extendido con el nodo de herramientas, y la primera alegría medible del proyecto: los correos de “¿cuánto debo?” — antes derivados por falta de manos — ahora respondidos con datos, cita y borrador.

Errores comunes

La identidad como parámetro del modelo. consultar(rut=el_que_diga_el_correo) es el confused deputy con invitación. La identidad se resuelve en el canal y viaja fuera del prompt — sin excepciones.
Credenciales en el contexto. La llave del CRM en el prompt o el estado del grafo es exfiltrable por diseño. El borde, siempre: el servicio la usa, el modelo ni la huele.
Herramientas genéricas. consultar_crm(query) le da al modelo un lenguaje de consulta completo — superficie infinita. Tres herramientas concretas hacen auditable lo que una genérica vuelve incontrolable.
Escritura antes de tiempo. “Ya que estamos, que pueda repactar” — la capacidad de modificar sin la gobernanza de aprobación construida es el incidente mayor esperando. Lectura ahora; escritura con su fase y su política.
Saltarse MCP “porque es un solo agente”. Las funciones pegadas al agente se convierten en el segundo sistema de herramientas cuando llegue el segundo agente. El contrato estándar cuesta poco hoy y evita la duplicación de mañana.
Probar contra el CRM real. El prototipo con datos reales de clientes viola la fase 2 entera. Sintéticos hasta que la infraestructura con permisos y perímetro exista — que es exactamente la fase 7.

La frase para llevarse

“Manos sí, llaves no: herramientas concretas con contrato mínimo, la identidad del cliente resuelta por el canal y fuera del alcance del modelo, credenciales en el borde, y las capacidades ganándose por escalera — el certificado nace borrador. El servidor MCP que agrupa todo es un microservicio con modales: identidad propia, permisos mínimos, cada invocación registrada.”

Qué viene

Fase 5: las evals. Tenemos agente con manos y criterios firmados desde la fase 1 — falta el puente: la suite que mide los criterios contra el dataset de la fase 2, corre en cada cambio, y frena lo que empeora. Clasificación con su matriz por categoría, groundedness verificado con juez, el error crítico con su umbral draconiano — y la disciplina que lo cambia todo: ningún cambio al agente se despliega sin pasar por la suite.

Capstone — Fase 4: herramientas y MCP