El harness del agente: cómo construir planos de control que conviertan a un LLM en un sistema production-ready

Vinoth Govindarajan, ingeniero de OpenAI que trabaja en infraestructura de datos e IA, presentó en InfoQ una de las charlas más operativas del año sobre sistemas agentic en producción. La tesis central es directa: un agente de IA en producción no es un modelo con un prompt. Es un harness — un sistema alrededor del modelo que decide qué se ejecuta, en qué orden, con qué autoridad, y deja un recibo verificable de lo que ocurrió. La frase que resume toda la charla y que cualquier equipo de platform engineering debería grabar en la pared de su oficina es esta: «el modelo propone, el harness confirma, y el recibo lo demuestra». Para equipos que están poniendo agentes en producción en 2026 — desde SREs automatizando respuestas a incidentes hasta atención al cliente con agentes conversacionales — esta distinción entre modelo y harness es la que separa un demo de un sistema que puedes operar.

Qué es un harness y por qué el modelo no es suficiente

Govindarajan empieza con una metáfora que atraviesa toda la charla: un auto. El modelo es el motor. Importa — nadie compra un auto de producción mirando solo la potencia — pero lo que de verdad te importa es la dirección, los frenos, el tablero, la caja negra y la transmisión. Los agentes son iguales: el modelo te da capacidad, pero el harness te da control. Un motor potente sin frenos no es autonomía, es una responsabilidad con buena aceleración.

La definición operativa de harness que ofrece es la siguiente: el sistema alrededor del modelo que permite que el modelo opere más seguro en el mundo real. Ese sistema tiene que decidir si una propuesta del modelo pertenece al estado de escritura, si la mutación está ordenada, si el trabajo está acotado, si la autoridad es válida, y si el resultado puede ser probado. Cinco preguntas, cinco decisiones que el harness tiene que tomar antes de que cualquier acción del modelo toque estado persistente.

La analogía con sistemas distribuidos no es decorativa. Govindarajan viene de construir sistemas distribuidos en Uber y Apple, y el resto de la charla está estructurada como una conversación entre lo que los ingenieros de reliability ya saben (idempotencia, retries, locks, ordering, state boundaries) y lo que los agentes cambian. La respuesta corta: los modos de fallo son los mismos, pero los agentes los hacen más fáciles de provocar y más difíciles de explicar. Un sistema distribuido tradicional falla de formas conocidas y reproducibles; un sistema agentic falla de formas que dependen del contexto, del estado interno del modelo, y del orden en que múltiples agentes deciden cooperar.

Las tres reglas operativas que tienes que recordar

Si solo puedes llevarte tres ideas de la charla, Govindarajan las formula así:

Primera: posees el estado. Un hecho necesita un dueño y un camino de replay. Si tu sistema no puede reconstruir el hecho después, no lo posee realmente. Esta es la regla que más impacto tiene en el diseño: en sistemas tradicionales, el estado vive en una base de datos con transacciones ACID; en sistemas agentic, el «estado» incluye no solo la base de datos, sino la memoria del agente, el transcript de la conversación, las anotaciones del workflow, y los side effects que el agente ya disparó. Todos esos componentes tienen que ser replayable desde un punto conocido, no solo restaurables desde un backup.

Segunda: ordenas la mutación. La concurrencia está bien. El entrelazado accidental no. Los agentes pueden hacer trabajo en paralelo, leer en paralelo, llamar sub-agentes o herramientas en paralelo, pero el estado compartido necesita un único camino de commit. Esto suena a consejo de sistemas distribuidos estándar, y lo es. La diferencia en sistemas agentic es que el «orden» no viene solo de la base de datos — viene también del orden lógico de la conversación. Si un agente responde a un usuario y luego actualiza la base de datos, pero la respuesta al usuario se confirma antes de que la base de datos se actualice, hay una ventana donde el usuario ve un estado que el sistema no tiene. Esa ventana es invisible para los mecanismos tradicionales de consistency.

Tercera: pruebas la acción. El transcript no es el recibo. El transcript puede decirte qué dijo el agente o qué intentó el modelo. Necesitas saber qué fue intentado, qué fue aprobado, y qué fue confirmado en el borde user-visible. La diferencia entre «el modelo dijo que recordaría algo» y «el sistema recordó algo» es exactamente la diferencia entre un demo y un sistema production-ready.

El caso OpenClaw: cuando el sistema olvida lo que el usuario pidió

Govindarajan usa OpenClaw como caso de estudio público. El ejemplo que abre la charla es uno que cualquier equipo que opere agentes ha visto en producción: el usuario le pide al agente que recuerde algo para el próximo turno — un reembolso, una preferencia, un contexto. El agente responde «lo recordaré». El usuario ve la respuesta, todo parece haber funcionado. Pero detrás del escenario, el sistema no reconstruyó de forma confiable el futuro para el próximo turno. La acción ocurrió, pero el registro que debería haber hecho parte de la memoria durable del agente no ocurrió. Para los agentes en producción, este tipo de bug importa más que un crash, porque el transcript parece coherente pero la realidad cambió en el orden incorrecto — o no se registró en absoluto.

Govindarajan es específico sobre por qué este tipo de fallo es peor que un crash. Un crash es molesto, pero al menos te da una frontera. Algo se detuvo. Ves un error. Puedes replay desde el último punto bueno conocido. Un éxito silencioso es peor: es una mentira. El canal dice éxito, el usuario ve que algo ocurrió, pero el operador no tiene razón para dudar y el sistema perdió parte de su memoria. La próxima vez que el agente responda, lo hará con un contexto incompleto, posiblemente con confianza, posiblemente incorrecto.

El ejemplo específico de OpenClaw que cita Govindarajan tiene exactamente esa forma: el camino de entrega user-visible parecía saludable mientras que el turno no se grabó en el camino persistente del que el contexto futuro dependía. El contexto futuro heredó un hueco. Puede responder con confianza, pero está razonando sobre un registro incompleto. Por eso no quiere empezar con un benchmark de modelo: un benchmark puede decirte sobre el comportamiento del modelo, no puede decirte si el borde persistente y el borde de entrega están de acuerdo.

Las tres preguntas de producción que tienes que hacerte

Una vez que un sistema puede enviar mensajes, actualizar bases de datos, ejecutar comandos o disparar workflows, las preguntas de producción cambian. Govindarajan las reduce a tres:

¿Quién poseía el estado? Qué pipeline de memoria o workflow poseía el estado, cuál era la fuente de verdad, quién confirmó primero. Cuando dos eventos llegan juntos, sabes cuál decidió el orden. Si la respuesta es «no sé, depende del agente», tienes un problema.

¿Quién puede mostrar qué ocurrió? No qué intentó el modelo, no qué dijo el agente. Qué persistió el borde user-visible. Esto se traduce en práctica a: tu sistema tiene un log de auditoría que no es el transcript del modelo. Es un log separado, firmado, con timestamps, que dice exactamente qué estado cambió, cuándo, y por qué acción del usuario o del sistema.

Estas no son preguntas del modelo. Son preguntas de producción. La distinción importa porque muchos equipos, al empezar a desplegar agentes, intentan responderlas con herramientas del modelo: mejor prompt, mejor fine-tuning, mejor RAG. Esas herramientas pueden ayudar, pero no resuelven problemas de ownership de estado. El modelo no sabe qué posee; el harness sí, o debería.

Cómo se traduce esto en código que puedes escribir hoy

Hay cinco patrones concretos que la charla implica y que cualquier equipo puede empezar a implementar sin esperar a un framework nuevo.

Una única ruta de commit. Cualquier mutación a estado persistente pasa por una sola función, registrada, con idempotencia verificada. Si el agente quiere actualizar la base de datos, no lo hace directamente: lo hace a través de un servicio que registra quién pidió el cambio, qué validó la autoridad, y qué se confirmó. El servicio de commit es a la vez el cuello de botella (para concurrency control) y la fuente de verdad (para auditoría). Implementación práctica: un endpoint HTTP o una cola con exactamente un consumidor, no múltiples.

Identificadores estables para cada hecho. Un hecho no es una fila en una tabla: es un identificador estable que sobrevive a migraciones, a renames de columna, a reorganizaciones del esquema. Cuando un agente ejecuta una acción, esa acción tiene un ID que se mantiene en logs, en métricas, en alertas, y en el transcript. Si en seis meses necesitas responder «qué pasó el 14 de marzo a las 10:32», el ID está en todos los lugares relevantes.

Recibo verificable de cada acción. Cada acción ejecutada por un agente produce un recibo que incluye: el ID de la acción, el input que la generó, el output que produjo, el timestamp, el identificador del usuario que la autorizó (o del sistema que la aprobó automáticamente), y la firma criptográfica del ejecutor. El recibo es lo que permite reproducir qué pasó sin tener que confiar en el transcript del modelo. Es el equivalente del recibo de una transacción financiera: si tienes el recibo, puedes demostrar la operación; si no lo tienes, no existe.

Reorder buffer para mutaciones concurrentes. Cuando múltiples sub-agentes o herramientas se ejecutan en paralelo, sus mutaciones se serializan a través de un buffer que aplica el orden lógico antes de aplicar el orden físico. Esto evita race conditions que aparecen cuando dos agentes modifican el mismo registro simultáneamente, y permite reproducir el estado en cualquier punto del orden lógico, no solo del orden cronológico.

Políticas de aprobación como código. Las decisiones de qué puede hacer un agente sin aprobación humana y qué requiere confirmación se codifican en archivos versionados, no en prompts del modelo. Esto permite revisar quién cambió qué política, hace cumplir las decisiones de forma consistente, y separa la lógica de negocio (qué es importante aprobar) del comportamiento del modelo (cómo razonar sobre la aprobación).

Lo que tu equipo debería medir

La charla termina con una lista de métricas que cualquier equipo de platform engineering debería empezar a trackear si opera agentes en producción. Govindarajan no las enumera con nombres exactos, pero se pueden inferir del resto del argumento.

Tasa de éxito silencioso vs éxito confirmado. Qué fracción de las acciones del agente se completaron según el transcript pero no se confirmaron en el log persistente. Una tasa distinta de cero indica un bug del harness, no del modelo. Esta métrica se construye cruzando el log del transcript con el log persistente, y debería ser vigilada igual que se vigila la tasa de errores de una API.

Latencia entre transcript y persistencia. Cuánto tiempo pasa entre que el agente emite una respuesta al usuario y el sistema confirma que el estado fue persistido. Una latencia alta o variable indica que el camino persistente tiene cuellos de botella o dependencias que pueden fallar. En sistemas donde la consistencia entre lo que el usuario ve y lo que el sistema recuerda es importante, esta métrica es un leading indicator de incidentes.

Tasa de re-ejecución por replay. Qué fracción de las acciones del agente tuvieron que re-ejecutarse durante un replay para reconstruir el estado. Una tasa alta indica que el camino de replay no está bien definido o que hay estado que no es replayable. Esta métrica se construye observando incidentes o drills de disaster recovery, no operación normal.

Cobertura de auditoría. Qué fracción de las acciones ejecutadas por el agente tienen un recibo completo. Una cobertura menor al 100% indica que hay rutas de mutación que no pasan por el harness. Es un agujero de seguridad y de cumplimiento, no solo una métrica operacional.

Por qué esta charla es importante aunque no uses OpenAI

OpenClaw es el caso de estudio, pero la lección no es sobre OpenClaw. Es sobre el hecho de que cualquier sistema agentic suficientemente complejo — cualquier producto que use LLMs para tomar decisiones que afectan estado persistente — va a enfrentar los mismos problemas de ownership, orden y prueba. La charla no vende un producto de OpenAI; vende una forma de pensar sobre el problema. Govindarajan dice explícitamente que no es un pitch de OpenClaw ni de ningún producto, y que usa OpenClaw como caso de estudio público porque su harness y su naturaleza abierta lo hacen visible. El resto del argumento aplica igual a Anthropic, a Google, a Cohere, o a un sistema interno que tu equipo está construyendo con LangChain, LlamaIndex o un framework custom.

Los tres takeaways — posees el estado, ordenas la mutación, pruebas la acción — son anteriores a los agentes. Son principios de sistemas distribuidos clásicos. Lo que la charla aporta es la aplicación específica al contexto agentic: cómo esos principios se manifiestan cuando el actor que toma la decisión no es determinista, no es repetible, y no siempre razona sobre el mismo contexto. Esa es la pieza que la mayoría de los equipos que están desplegando agentes por primera vez no tienen internalizada. Y es la pieza que separa un demo de un sistema production-ready.

El error común que esta charla desmonta

El error más común al desplegar agentes en producción es tratarlos como si fueran APIs tradicionales. El razonamiento implícito es: el modelo es como una función, le paso inputs y me devuelve outputs, y el resto del sistema es como cualquier backend. La realidad es diferente. El modelo no es determinista; puede dar respuestas distintas al mismo input. El modelo no es idempotente; la misma llamada dos veces puede tener efectos distintos si el contexto cambió. El modelo no es auditable de la misma forma que una API; el transcript del modelo es interpretativo, no declarativo.

El harness es lo que convierte al modelo en algo operable. Es lo que toma un comportamiento probabilístico y lo expone como una API con semánticas claras: qué hace, qué puede fallar, qué garantías ofrece, qué se necesita para llamarla correctamente. Sin el harness, tienes un demo. Con el harness, tienes un sistema.

Verificación de hechos y fuentes

- Presentación original de Vinoth Govindarajan en InfoQ: https://www.infoq.com/presentations/ai-agent-harness/?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=global - Transcript completo de la presentación disponible en el enlace anterior - Trabajo previo de Govindarajan en sistemas distribuidos (Uber, Apple) según su biografía en la presentación

Los tres takeaways operativos («posees el estado», «ordenas la mutación», «pruebas la acción») son formulaciones textuales del presentador durante la charla. Los nombres de patrones técnicos (single commit path, stable identifiers, verifiable receipts, reorder buffer, policies as code) son interpretaciones editoriales basadas en los principios descritos, no claims textuales del presentador. Las métricas sugeridas son derivadas operativas, no listadas explícitamente en la charla.

Cierre

Si tu equipo está desplegando agentes en producción — o está a punto de hacerlo — esta charla es la lectura o el visionado obligatorio de esta semana. No porque tenga respuestas concretas a todos tus problemas, sino porque tiene el marco mental correcto para formular las preguntas. La diferencia entre un equipo que opera agentes con éxito y uno que lucha con incidentes inexplicables es, la mayoría de las veces, si ese equipo entendió que el modelo es el motor y el harness es el auto. Si tu equipo todavía está tratando al modelo como si fuera el sistema entero, este es el momento de corregir el modelo mental. La próxima vez que un agente haga algo que no debería, la diferencia entre un incidente manejable y un desastre operativo será si tenías el harness correcto o no.