Tres decisiones que conviene cerrar antes de publicar una interfaz de agente

La mayoría de los equipos que construyen una interfaz de agente empiezan por el cuadro de chat y van hacia atrás. El autor de esta pieza sostiene que el orden correcto es el inverso: las decisiones que definen el producto se toman antes, casi siempre por defecto y sin que nadie repare en que eran decisiones. Las tres que plantea son dónde corre el bucle del agente, cómo entrega el modelo la interfaz y qué dimensión se ha cargado tu batería de pruebas.

Dónde vive el bucle

El bucle del agente es el código que llama al modelo, ve una llamada a herramienta, la ejecuta y vuelve a llamar al modelo. De dónde viva depende quién guarda la clave de API, dónde se pausa una aprobación, dónde persisten los hilos y a qué calendario de versiones estás atado. Tras comparar cinco librerías, las respuestas se ordenan en tres formas.

Un servidor del proveedor metido en la ruta de la petición: despliegas su runtime y el navegador habla con él, con lo que ganas custodia de claves, autenticación, enrutado y middleware de confianza, y pagas un segundo servidor en el camino caliente. Código del proveedor dentro de tu propia ruta: no hay nada extra que desplegar, pero el bucle es suyo aunque el endpoint sea tuyo. Y tu agente, donde la interfaz habla directamente con el servidor del agente: un solo bucle, el del framework que ya elegiste, a cambio de no poder mostrar nada que el servidor no envíe.

El autor se queda con la tercera para la mayoría de equipos, y es sobre la que está construido Threadplane. Su argumento: si ya corres un agente, ya tienes un servidor que guarda la clave, autentica y ve cada llamada a herramienta; poner delante la caja de un proveedor es abrir un segundo sitio donde resolver un problema que ya resolvías en uno. Eso no quita que convenga un endpoint propio delante para autenticación y credenciales. La diferencia con el runtime de un tercero es quién es dueño del código que corre dentro.

Interfaz generativa no es una sola cosa

Bajo esa etiqueta conviven tres mecanismos: el renderizado por llamada a herramienta, donde mapeas el nombre de la herramienta a un componente y que hacen todas las librerías; las especificaciones declarativas, donde el modelo escribe un árbol de UI en un formato estándar y el cliente lo pinta desde un catálogo que tú registras, con json-render y A2UI como los dos formatos abiertos que están ganando terreno; y las aplicaciones en sandbox, donde un servidor MCP devuelve un recurso ui:// y el cliente lo monta en un iframe, que es MCP Apps.

La elección que importa está dentro del segundo grupo y es la forma del contrato. Con una especificación fija el contrato es de la aplicación: tú defines el esquema, validas el conjunto entero antes de montarlo y tus manejadores deciden qué significa un clic. Con un protocolo vivo la superficie es del agente, que la crea, la sigue editando entre turnos y recibe acciones estructuradas. Si puedes validar toda la interfaz antes de pintarla, empieza por la especificación fija; si la superficie tiene que sobrevivir a su primer render, sube al protocolo. Una tarjeta de resumen de pedido es lo primero. Un itinerario de tres días que se rellena de precios y se reescribe cuando el usuario protesta es lo segundo.

Qué dimensión borra tu harness

Los agentes no devuelven lo mismo dos veces, así que lo habitual es grabar sus respuestas como fixtures y reproducirlas. Dónde colocas el mock decide qué se está probando de verdad: en la frontera de la aplicación solo demuestras que tu componente pinta lo que le diste, mientras que si el mock va en el proveedor del modelo, con el servidor del agente real contra un endpoint falso, entran en juego el enrutado, el streaming y los round-trips de herramientas.

Y todo harness determinista se compra la determinación borrando una dimensión del sistema real. El suyo borra el tiempo: las respuestas llegan en uno o dos trozos en lugar de token a token. Con eso desaparece una clase de bug entera. Un agente hijo emite tokens, el cliente los fusiona en la transcripción como una burbuja de más, la ejecución se asienta y la transcripción se reconstruye bien. Cualquier aserción sobre el DOM final pasa, porque un sistema asentado se corrige solo. La pregunta no es si el harness está en verde, sino qué dimensión le has quitado y qué pruebas han vuelto a activarla.

Cada una de estas preguntas trae una respuesta por defecto con la primera librería que instales. Ninguna es incorrecta, pero todas son decisiones. Las del autor: bucle en el agente con un endpoint propio delante, especificación fija para arrancar y subir al protocolo según la superficie, y mock en el proveedor del modelo sabiendo qué se deja por el camino. Quien esté montando lo mismo en otro framework tiene la invitación a contar dónde ha caído él.