La pregunta es sobre personas, no sobre agentes
Dé a un agente una forma de pagar y la reunión de revisión cambia. Nadie pregunta qué tan listo es el agente. Preguntan de quién es, qué hizo, qué habría podido hacer y quién dijo que sí.
Son preguntas de responsabilidad, y la respuesta debe poder consultarse después, no reconstruirse de memoria. Para eso sirve una traza.
Una traza, de la solicitud al resultado
En Waggle, cada acción es un evento en el bus de eventos. Un evento lleva un id, una hora, un origen, un tipo, un workspace, un principal y un id de traza. El principal indica qué persona o qué agente lo hizo, por id. Los eventos se enlazan en cadenas mediante el id de traza.
Una traza muestra cada turno de agente: el workspace, el agente, la cuenta a la que pertenece, qué lo desencadenó, el resultado, las herramientas y credenciales que usó y las aprobaciones, con quién decidió cada una. Siguiendo una cadena se puede leer un trabajo desde la solicitud de la persona, pasando por el turno del agente, la credencial que se le arrendó y la aprobación, hasta el resultado.
Esto existe hoy para el trabajo de agentes en general. La parte específica de pagos, una compra como un tipo propio de evento, es lo que construiremos a continuación.
Lo que suelen preguntar los revisores de seguridad de pagos
Los revisores que trabajan con estándares de tarjetas de pago como PCI DSS piden cosas parecidas, en términos generales. Cada persona responde individualmente. Las credenciales nunca se exponen a quien las usa. Hay límites sobre lo que se puede gastar. Y los registros vinculan cada acción con una persona.
No afirmamos cumplir ningún estándar. Lo que sí podemos hacer es explicar con claridad cómo se alinea el diseño con esas preguntas. Responsabilidad: cada evento nombra a su principal por id. Credenciales: están en custodia, y un agente tiene un arrendamiento (lease), nunca el valor. El registro: los eventos comparten un id de traza, de modo que una acción lleva de vuelta a la persona que la pidió o la aprobó.
Los límites de gasto son lo que aún no existe. Lo diremos cada vez que salga el tema.
Disponible hoy, y lo que estamos construyendo
Disponible hoy: eventos con principal e id de traza, trazas por turno de agente, aprobaciones que registran quién decidió y credenciales en custodia con arrendamientos para los agentes. Nada relacionado con pagos está disponible. Hoy un agente no puede gastar dinero a través de Waggle.
Estamos construyendo eventos de pago sobre el mismo bus: quién autorizó una compra, qué agente gastó, un límite de gasto por agente y aprobación reforzada por encima de un umbral. También un registro de pagos a prueba de manipulación y la redacción de números de tarjeta en la entrada, para que un número de tarjeta pegado en un mensaje no llegue al registro.
Conviene ser claros sobre el registro tal como es. El registro de eventos no está firmado ni encadenado por hash, y se conserva 90 días por defecto, más si se configura un archivo. Un revisor que necesite un registro que nadie pueda editar en silencio, conservado un año o más, necesita más de lo que tenemos. Firmar o encadenar por hash el registro de pagos, y una retención más larga, es lo que habría que añadir.
Pida a un modelo que lea la traza
Las trazas son herramientas del endpoint MCP, así que puede apuntar un asistente hacia ellas. Añada https://api.hachiflow.com/mcp a su cliente, inicie sesión y pregunte en lenguaje natural qué hicieron sus agentes.
El asistente llama a hachi_traces_ls para listar los turnos de agente, elige uno y llama a hachi_trace_get sobre él. Eso devuelve la cadena completa de eventos enlazados de ese trabajo, y el modelo la lee de vuelta como un relato breve: quién lo pidió, qué agente actuó, qué credencial usó, quién aprobó, qué ocurrió.
Hoy eso responde quién aprobó lo que hizo un agente. Los eventos de pago todavía no existen. Cuando existan, los estamos diseñando para que la misma pregunta cubra el gasto, con el importe y el límite que se aplicó.
La pregunta y las dos herramientas que usa. La respuesta sale de la traza, no de la memoria del modelo.
Las trazas también muestran qué dejar de pedirle a un modelo
Leer trazas tiene un segundo uso. Cuando la misma tarea aparece turno tras turno, con las mismas herramientas en el mismo orden y el mismo resultado, ya no es realmente una decisión de criterio. Es una rutina.
Esas son las tareas que conviene convertir en código determinista. Reserve el modelo para el trabajo que varía y deje que un script simple haga el que no varía. La traza indica cuál es cuál, porque registra lo que ocurrió y no lo que alguien recuerda.
Dónde nos deja esto
La responsabilidad sobre el trabajo de los agentes está disponible: principales, cadenas de trazas, aprobaciones y arrendamientos de credenciales. La responsabilidad sobre el gasto de los agentes está planificada: eventos de pago, límites de gasto, aprobación reforzada y un registro a prueba de manipulación. Preferimos decirle cuál es cuál antes que dar a entender que una cubre a la otra.