## Agentes que se detienen en la caja de chat La mayoría de los "agentes de IA" en producción hoy en día son interfaces de chat con un *system prompt*. La interfaz es un flujo de texto. El usuario ve *tokens*. El agente ve *tokens* de vuelta. Nada más existe en ese mundo: sin estado, sin estructura, sin noción de en qué parte de un proceso te encuentras. Pero el trabajo real no es una conversación. Es un proceso con UI, aprobaciones y herramientas. Un flujo de incorporación de patrimonio no es "háblame de ti". Es verificación de identidad, luego evaluación de riesgos, luego enrutamiento DMN, luego revisión del asesor, luego apertura de cuenta. Cada paso tiene un estado, produce una salida y termina en una decisión. Aplanar eso en una transcripción de chat elimina exactamente la estructura que hace que el trabajo sea auditable. AG-UI es un protocolo construido para esta brecha. En lugar de transmitir texto, el *backend* transmite eventos de UI tipados al *frontend*: tarjetas generativas, estados de llamadas a herramientas, tareas de humano en el bucle. El agente renderiza una interfaz viva, no una transcripción. El Episodio 2 de Agents, Orchestrated es lo que sucede cuando apuntas ese protocolo a un motor de procesos en lugar de a un *framework* de chat. ## Lo que construí: AURUM Private Bank La demo es un conserje de incorporación de banca privada ficticio, AURUM Private Bank. Un cliente aplica. El agente orquesta todo el flujo, desde la verificación de identidad hasta la apertura de cuenta, mientras el operador observa la misma ejecución como una instancia de proceso en vivo en Camunda Operate. Tres capas, y cada una se gana su lugar. **La experiencia.** El cliente no ve a un *chatbot* escribir. Las tarjetas se transmiten a la interfaz una por una a medida que avanza el proceso: identidad verificada, riesgo evaluado, cartera recomendada, revisión del asesor marcada. Cada tarjeta es un evento AG-UI tipado renderizado por el *frontend* de React. Se lee como una UI viva, no una transcripción, porque lo es. El *frontend* no tiene lógica de negocio; renderiza lo que emite el *backend*. **El *backend*.** El flujo es un proceso BPMN que se ejecuta en Camunda 8.9, y puedes ver el *token* moverse: Admisión, luego Identidad, luego Riesgo, luego enrutamiento DMN, luego Revisión del Asesor, luego el Agente de IA, luego cuenta abierta. El paso de Revisión del Asesor es una USER_TASK, y este es el detalle que más me importa. Cuando el *token* lo alcanza, el proceso se pausa y espera a un humano. No es un *hack* de *polling*, no es un trampolín de *webhook*. El estado de espera nativo del motor. Cada paso de la ejecución es visible en Camunda Operate a medida que ocurre. **El agente.** La capa de razonamiento es multi-modelo. Los modelos Claude en Amazon Bedrock y Gemini razonan sobre los datos del cliente, disparan una de 13 herramientas y emiten eventos AG-UI de forma nativa mientras trabajan. Diferentes modelos se encuentran detrás de diferentes partes del mismo proceso, y el motor de procesos los mantiene honestos: un modelo puede proponer, pero el *token* solo avanza cuando el paso se completa. Una nota de implementación que importa: no hay CopilotKit ni ChatKit en esta construcción. AG-UI se implementa directamente contra el *backend* de Camunda 8 utilizando el protocolo AG-UI EventSource, SSE plano desde un *backend-for-frontend* de Node.js a la aplicación React. El protocolo es lo suficientemente simple como para que ir directamente fuera menos código que adoptar un *framework*, y prueba que el patrón no está acoplado a ningún *kit* de *frontend* particular. ## Por qué el motor de procesos es el punto clave La clave, y la razón por la que existe este episodio: **cuando un motor de procesos es el orquestador**, la UX agéntica obtiene propiedades que las arquitecturas nativas de chat no pueden tener. No "aún no tiene". No puede tener, estructuralmente, porque las arquitecturas de chat mantienen el estado en la ventana de contexto del modelo. **Fiable.** Si el agente falla a mitad del flujo, el proceso BPMN se reanuda desde donde se detuvo el *token*. El estado reside en Camunda, no en la ventana de contexto del LLM. Una conexión caída o una llamada a modelo fallida es un reintento, no una incorporación perdida. **Pausable.** Una USER_TASK puede pausar el flujo y esperar una decisión humana, durante un minuto o una semana. El agente no gira, no hace *polling*, no mantiene una ventana de contexto abierta. El proceso espera, a coste cero, y se reanuda cuando el asesor actúa. **Auditable.** Cada transición de estado, cada llamada a herramienta, cada decisión se registra en Camunda Operate. El registro de auditoría existe sin una sola línea de código de registro personalizado. Cuando alguien pregunta "por qué este cliente fue enrutado a revisión del asesor", la respuesta es una instancia de proceso que puedes abrir, no una consulta de registro que esperas que haya sido instrumentada. > El patrón aquí es de orquestación primero, y es agnóstico al motor. Camunda es con lo que yo trabajo, pero el argumento es válido para Temporal o cualquier motor con estado duradero y estados de espera nativos. De lo que no puedes escapar es de hacer del LLM el orquestador. A eso se reduce la tesis: un proceso, tres modelos, cero código *glue*. El proceso BPMN es la única capa de coordinación. Los modelos se conectan a él. Nada hecho a medida lo mantiene unido. ## Lo que no llegó a la publicación de LinkedIn Las notas honestas, porque el vídeo pulido de la demo oculta decisiones reales. El banco es ficticio y los datos del cliente son sintéticos. Los pasos de identidad y riesgo llaman a herramientas que devuelven resultados plausibles, no proveedores KYC reales. Lo que es real es la arquitectura: un clúster de Camunda 8.9 en vivo, el AI Agent Connector v6, llamadas reales a modelos a Bedrock y Gemini, y una USER_TASK real que bloquea genuinamente el proceso hasta que un humano lo completa en el escritorio de aprobación de la demo. Ir directamente con AG-UI en lugar de usar CopilotKit me costó un día de lectura del protocolo de eventos y de construcción del puente SSE en el BFF. Valió la pena, pero solo lo recomendaría si quieres entender el protocolo; si solo quieres la UI, los *frameworks* están bien. Las 13 herramientas son el número que la demo necesitaba, no un *benchmark*. El enrutamiento multi-modelo funcionó, pero elegí el modelo por paso en tiempo de diseño. Nada en esta construcción selecciona modelos dinámicamente en tiempo de ejecución, y querría un *eval harness* en su lugar antes de permitir que algo así se haga frente a un cliente. Y la afirmación de "cero código *glue*" merece precisión: cero *glue* de orquestación. Todavía hay un BFF que traduce los eventos del motor a eventos AG-UI. Lo que está ausente es cualquier código personalizado que decida qué sucede a continuación. Esa decisión reside en el BPMN, donde un auditor puede leerla. ## Registro de envío - **Motor:** Camunda 8.9 (clúster SaaS), AI Agent Connector v6 - **Modelos:** Claude en Amazon Bedrock, Gemini - **Herramientas:** 13, disparadas por la capa de agente - **Protocolo:** AG-UI sobre SSE (EventSource), implementado directamente, sin CopilotKit ni ChatKit - **Frontend:** React, renderizando eventos AG-UI tipados como tarjetas generativas - **Backend:** BFF de Node.js que conecta Camunda con AG-UI - **Compuerta humana:** BPMN USER_TASK (Revisión del Asesor), visible en vivo en Camunda Operate - **Repositorio:** [letmereviewyourcode/camunda-agui-wealth-demo](https://github.com/letmereviewyourcode/camunda-agui-wealth-demo)