Milo

Milo entiende qué quieres hacer con tu crédito y construye la interfaz que lo resuelve, sin que tengas que buscarla tú.

Comment

Inspiration

Todos hemos hablado con un asistente bancario que solo contesta con texto: te explica tu tasa, tu plazo, tus opciones... y ahí se detiene. Si quieres simular un nuevo plazo o pedir una reestructura, tienes que irte a otra pantalla, a otra app, o esperar a un ejecutivo. Cada uno de esos saltos es un punto donde la persona se cansa y se va sin resolver nada.

El reto de Banorte × Tec de Monterrey lo planteaba de forma muy clara: que el modelo no solo conteste, sino que arme la pantalla que resuelve el problema financiero de quien pregunta. Esa frase fue nuestro punto de partida. Quisimos invertir la lógica del chatbot bancario típico: en lugar de un asistente que responde, un agente que construye.

What it does

Milo es un agente financiero que interpreta la intención del usuario en lenguaje natural y, en vez de responder con un párrafo de texto, genera en tiempo real el componente de interfaz que resuelve exactamente esa necesidad.

Si el usuario escribe "quiero pagar menos intereses de mi tarjeta", Milo no le explica sus opciones en texto: le muestra un plan de reestructura con distintos plazos, su CAT y el pago mensual de cada uno, listo para aplicar. Si en cambio pregunta cuánto lleva pagado, genera una línea de tiempo de amortización. Si quiere simular un crédito nuevo, un simulador con monto y plazo ajustables. Si quiere comparar tarjetas, un comparador lado a lado. Y si pregunta si le conviene liquidar antes, una calculadora de ahorro por prepago.

Es el mismo agente y el mismo backend en todos los casos — lo que cambia es el componente que se genera, según la intención detectada. Y cada vez que el usuario interactúa con esa interfaz (ajusta un plazo, mueve un monto), esa interacción regresa al agente como contexto nuevo, así que la conversación nunca se corta: se convierte en acción.

How we built it

La arquitectura se sostiene en tres piezas que no son negociables según las bases del reto:

  • LLM (Gemini API) al centro de la experiencia: interpreta la intención del usuario y decide qué componente mostrar. Importante: el modelo nunca calcula tasas ni CAT, solo orquesta.
  • MCP (Model Context Protocol) como capa que conecta al agente con datos y acciones reales — en nuestro caso, contra una fuente de datos financieros tipo Snowflake — en lugar de una integración ad-hoc entre el LLM y el backend.
  • A2UI para describir la interfaz que el agente decidió generar, de forma que el frontend la renderice como un componente propio, vivo y accionable (no una imagen ni un bloque de texto fijo).

Detrás de A2UI, el backend calcula CAT y amortización con reglas determinísticas fijas — el LLM decide qué mostrar, nunca cómo se calcula. Y el ciclo se cierra: cada interacción del usuario con la UI generada regresa al agente como contexto, para que pueda producir una nueva acción o una nueva pantalla.

Challenges we ran into

El reto técnico más grande fue diseñar el "viaje" completo de la interfaz: no bastaba con que el LLM generara una pantalla una sola vez, sino que cada toque del usuario tenía que volver al agente como contexto para que la conversación se sintiera continua y no como una serie de pantallas desconectadas.

También tuvimos que resolver un problema de confianza: si dejamos que un LLM calcule una tasa o un CAT, corremos el riesgo de que alucine una cifra financiera. La solución fue separar tajantemente las responsabilidades — el modelo decide qué mostrar, un backend con reglas fijas calcula los números — pero eso significó diseñar bien la frontera entre lo que decide el agente y lo que garantiza el backend.

Por último, el dominio de "servicios y productos financieros" es enorme (banca personal, inversiones, crédito, pagos, seguros, educación financiera), y con el tiempo de un hackathon tuvimos que resistir la tentación de abarcar todo y enfocarnos en un problema acotado — crédito — para resolverlo completo en vez de dejar cinco flujos a medias.

Accomplishments that we're proud of

Logramos un flujo funcionando de punta a punta: el usuario escribe su necesidad, el agente interpreta, consulta datos vía MCP, genera el componente vía A2UI, y la interacción con ese componente regresa como contexto. No es una demo de una sola pantalla: el mismo agente y el mismo backend generan cinco componentes distintos según la intención detectada, lo que demuestra que la solución realmente se adapta y no está "cableada" a un solo caso de uso.

También nos sentimos orgullosos de la garantía de precisión: pase lo que pase con el modelo de lenguaje, ningún componente de crédito puede mostrar una tasa o un CAT inventado, porque esos números siempre salen de una regla fija en el backend.

What we learned

Aprendimos la diferencia entre un modelo que orquesta y un modelo que calcula — y por qué esa frontera es la que hace confiable a un agente financiero. También entendimos por qué un protocolo estándar como MCP vale más que una integración directa y rápida: nos permite cambiar de modelo o de fuente de datos sin reescribir el resto del sistema.

En el terreno de UI generativa, aprendimos que lo difícil no es generar una pantalla bonita una vez, sino cerrar el ciclo: hacer que cada interacción con esa interfaz regrese al agente como contexto real. Ahí es donde una interfaz generada deja de ser un truco visual y se vuelve parte de la conversación.

What's next for Milo

El siguiente paso es un piloto acotado con Banorte — un producto, un segmento de clientes — para validar con datos reales que Milo efectivamente reduce la fricción y ayuda a atender a tiempo a un cliente antes de que caiga en cartera vencida.

Después, escalar el mismo agente y el mismo protocolo a otros dominios financieros: perfilamiento de riesgo y simulación de portafolios en inversión, cotización de seguros, y educación financiera. La arquitectura ya está pensada para eso — lo que cambia entre dominios son los datos y los componentes, no el agente.

Built With

Share this project:

Updates