El harness de Cris

Este post es para quien quiere saber cómo se construye un agente de IA, y lo contamos con el nuestro. Cris nació para nuestro equipo, después empezó a trabajar con nuestros partners y ahora conversa con todas las personas que quieran aprender a configurar su IA para controlarla y potenciarse con ella.

En mayo de 2026 aprobamos 16 cambios al código de PappCorn. En septiembre fueron 457, y octubre va en 449 a día 23.¹ Pasamos de un cambio cada dos días a casi veinte al día, y la mayoría los escribió un agente de IA con una persona al lado.

Escribir código dejó de frenarnos. Lo que no escala es revisar a ojo. Con un cambio cada dos días, una persona lo lee completo antes de que entre. Con veinte al día eso ya no se puede, y la pregunta pasa a ser otra. ¿Cómo sabemos que el agente hizo lo correcto sin que alguien lea cada línea? Lo mismo pasa con cada respuesta a un partner en Slack y con cada conversación en pappcorn.ai.

Nuestra respuesta es el harness de Cris, nuestro agente. Harness es todo lo que rodea al modelo de IA: lo que sabe, lo que recuerda, las herramientas que puede usar, los permisos que tiene y cómo medimos si lo hace bien. El modelo es una pieza más. Con un buen harness, el mismo modelo hace más trabajo y da menos sorpresas. Esto es lo que nos da el de Cris.

• Le podemos dar más trabajo. Pasamos a veinte cambios al día, y ninguno entra a producción sin dos llaves que el agente no tiene.
• Cada decisión importante se puede explicar. Lo que el agente puede hacer lo decide código que probamos caso por caso.
• Cuánto avanza solo lo decidimos nosotros. Su autonomía se sube o se baja por proyecto, y pausarlo en un canal es una línea de configuración.
• El gasto no se dispara. Cada mensaje tiene tope, el 71 % del texto reutilizable sale del caché, y un canal en pausa no gasta un token.
• Cuando se equivoca, lo arreglamos sin cambiar de modelo. El arreglo vive en el harness, que es lo único que de verdad es nuestro.

Este post cuenta las decisiones detrás del harness y en qué nos equivocamos mientras lo armábamos. Cómo funciona por dentro, con el código y las cifras, lo vamos a contar en un próximo post.

De dónde viene Cris

Cris nació el 28 de abril de 2026, cuando las instrucciones de nuestro monorepo pasaron a tener nombre y forma de orquestador. El harness es más viejo. En julio de 2025 Nicolás empezó a trabajar con sus propios agentes en el repositorio de una fintech donde ha sido CTO por más de diez años, y después armó agentes para el equipo de esa empresa. De ese año salieron casi todas las reglas que hoy tiene Cris.

Los agentes personales de una persona se volvieron el agente de un equipo. En septiembre de 2026, Nicolás mergeó 285 cambios entre ese repositorio y el nuestro. Entre el 1 y el 26 de octubre, las cinco personas del equipo de PappCorn mergearon 467 en nuestro monorepo.²

Contar cambios no mide lo que valen. Emerson Murphy-Hill, Jenna Butler y Alexandra Savelieva estudiaron en Microsoft la adopción de agentes que trabajan desde la terminal, y encontraron que quienes los adoptaron mergearon cerca de un 24 % más de cambios. Ellos mismos advierten que un cambio mergeado no es lo mismo que el valor que entrega. Las cifras nos importan por lo que obligan a resolver. Con este volumen nadie puede leer cada línea, y la pregunta pasa a ser cómo sabemos que el agente hizo lo correcto.

Las personas en el loop

El harness de Cris también son las personas que trabajan con él. En PappCorn somos cinco. Ricardo es el product manager. Leo, María Paula y Juan David son tech leads de nuestros partners. Nicolás arma el harness y trabaja con ellos en los mismos proyectos.

Cris escribe la mayoría de los cambios, y una persona del equipo pone la segunda llave antes de que alguno entre. Cuando algo sale mal, son ellos quienes lo ven y deciden qué se cierra.

Un agente, tres niveles de confianza

Cris es un solo personaje con una sola voz, pero trabaja en tres lugares muy distintos y en cada uno le confiamos algo diferente.

Cris Anfitrión recibe a quien llega a pappcorn.ai. Conversa con personas que no conocemos y les ayuda a configurar su IA para lo suyo. No tiene herramientas.

Cris Partner Manager trabaja con nuestros partners en Slack. Responde sobre el trabajo en curso, consulta el tablero donde lo llevamos y los conecta con el equipo humano.

jarCris es donde trabajamos nosotros. Es un equipo de agentes que toma un issue, lo entiende, lo construye, lo prueba y lo deja listo para revisar. De ahí sale la mayoría de esos veinte cambios al día.

Desliza para ver todo el diagrama, o ábrelo a tamaño completo.

Un desconocido en un chat público, un partner en Slack y nuestro propio equipo piden tres respuestas distintas a la misma pregunta de confianza. Por eso una sola regla de permisos para todo no nos sirvió.

Por qué no arrancamos con un agente que puede todo

Una forma común de armar un agente es darle acceso amplio y cerrar caminos a medida que aparecen problemas. Para una tarea puntual es el camino más rápido. El problema es que deja abiertos caminos que nadie decidió abrir, y casi nunca se sabe cuáles son hasta que alguien pasa por ellos.

Con Partner Manager lo vimos claro. Simon Willison describió la trifecta letal de un agente, que es juntar en el mismo agente datos privados, contenido que escribe gente que no controlamos y una forma de comunicarse hacia afuera. Partner Manager reúne las tres. Lee nuestro tablero, lee mensajes de otras personas, y lo que responde en el canal ya sale hacia afuera. Con eso, alguien puede escribir un mensaje diseñado para que el agente le cuente lo que sabe. Para filtrar algo no hace falta escribir en ningún lado, basta con contestar.³

Por eso armamos el harness de Cris al revés. Empezamos por lo que el agente puede hacer, y cada permiso se abre con una decisión de alguien.

Seis decisiones de diseño

De ahí salieron seis decisiones. Cada una cambia algo que la forma común de armar agentes trae por defecto.

Lo que no está habilitado no existe. Por defecto, un agente puede hacer todo menos lo que se le prohibió. En Cris es al revés. Hay una lista de lo que sí puede hacer, cada herramienta y cada permiso entra a ella con una decisión, y lo que no está en la lista se niega sin preguntar. Se parece a un banco regulado, que solo hace lo que su licencia le habilita. Jerome Saltzer y Michael Schroeder lo escribieron en 1975 como fail-safe defaults. «Base access decisions on permission rather than exclusion», o sea, decidir el acceso por lo que se permite y no por lo que se excluye.

El modelo declara y el código decide. Por defecto, el modelo toma las decisiones importantes, guiado por lo que dice el prompt. En Cris, el modelo solo reporta lo que entendió, y un pedazo de código normal decide qué pasa con eso. Un prompt bien escrito ayuda mucho, pero nadie puede garantizar qué va a hacer el modelo con él. Una función sí se puede probar caso por caso.

La autonomía la gira una persona. Por defecto, cuánto avanza el agente sin preguntar queda fijo en el código del agente. En Cris es una perilla que una persona gira, proyecto por proyecto, y que puede cerrar cuando quiera. Debajo hay un piso que ninguna posición de la perilla baja.

Ningún agente aprueba lo suyo. Para que un cambio entre al código que corre en producción hay que pasar por el merge, y el merge pide dos llaves. Una es un revisor automático con su propia cuenta. La otra es una etiqueta que pone una persona. Ninguna de las dos la tiene el agente que escribió el código. Saltzer y Schroeder lo llamaron separation of privilege. En una empresa se le dice el principio de los cuatro ojos.

Medir antes de cambiar. Ningún cambio en cómo conversa Cris sale al público sin probarse antes contra el modelo real.

El prompt se paga en cada turno. Los modelos cobran por tokens, que son pedazos de texto, y las instrucciones fijas del prompt se vuelven a enviar en cada mensaje de cada persona. Por eso son lo más caro que tiene un agente. Antes de agregar una línea preguntamos si esa regla se puede revisar con código. Si toca agregar texto, quitamos otro.

Estas ideas tienen historia. Dos vienen de la seguridad informática de los años setenta. Dex Horthy ordenó varias para agentes en 12-Factor Agents, y Ruiyao Xu y otros mostraron en Harness² que el rendimiento de un agente depende tanto del modelo como del harness que lo ejecuta. Lo nuestro fue aplicarlas todas a la vez en un agente que habla con el público, y medir qué pasa.

Lo que aprendimos

Cerrar autonomía también es parte del trabajo. El 30 de agosto alguien del equipo vio que el agente que revisa los cambios podía poner la etiqueta de merge cuando trabajaba solo, sin nadie presente. Esa etiqueta es justo la llave que tiene que poner una persona, así que el agente estaba fabricando una autorización que nadie había dado. Lo cerramos. Cerramos de más, y el 14 de septiembre lo corregimos. Hoy, si hay una persona trabajando con él, pone la etiqueta sin volver a preguntar. Si está solo, no la pone.

Un tope que llama al modelo cuesta lo que quería evitar. El 30 de septiembre un partner se quedó sin créditos y su canal pasó a pausa. Desde ahí Cris responde un mensaje fijo que escribimos nosotros, sin despertar al agente y sin gastar un token. Si el aviso lo escribiera el modelo, cada mensaje del canal costaría plata justo cuando no hay con qué pagarla.

Lo que el prompt no sostiene se pasa a código. Le pedimos a Cris en sus instrucciones que no asumiera el género de quien le escribe, y en las mediciones le siguió diciendo «tranquila» a gente que nunca había dicho su género. Tres versiones de la regla no lo arreglaron. Lo arregló una función que corrige esas palabras antes de mostrar el mensaje. La versión de Anfitrión que salió el 16 de octubre pasó las siete conversaciones de la medición en el quinto intento. Las cuatro veces anteriores la medición la frenó, y para eso existe.

Medir también gasta, y alguien tiene que aprobarlo. El 17 de octubre conectamos la medición para que corriera sola cada vez que alguien propusiera un cambio a las instrucciones. El 20 la pasamos a arranque manual. Correrla es aprobar el gasto, y eso lo decide una persona.

Los límites

Este diseño tiene sentido para nosotros porque Cris habla al mismo tiempo con desconocidos, con partners y con nuestro código, y se equivoca en público. Para una tarea puntual, un agente con acceso amplio da resultados más rápido, y montarle listas de permisos, funciones que deciden y una medición sería exagerar.

El riesgo de la trifecta en Partner Manager está acotado y sigue abierto. Quitarle herramientas reduce lo que un mensaje con trampa le puede pedir, pero lo que responde sigue saliendo hacia afuera.

Lo que creemos

Detrás de las seis decisiones hay cuatro cosas que creemos. La IA se configura, no «se usa». Se construye desde la seguridad. Hay que entenderla para poder comandarla. Y no la instalamos, acompañamos a adoptarla. Las contamos una por una en Cómo vemos la IA.

Un harness se escribe en semanas y se sostiene durante años, porque los modelos cambian y el trabajo de la persona también. Detrás de los tres Cris hay un equipo humano que sostiene estos harness y decide cuándo abrir y cuándo cerrar. Algunas piezas las compartimos en universe, nuestro catálogo abierto de plugins y conectores. Partner Manager usa uno de esos conectores tal como lo publicamos.

Lo que sigue es usar la medición para proponer cambios a las instrucciones, con una persona que revisa cada propuesta. Ningún proceso va a editar en vivo el prompt de un agente que habla con el público.

Para cerrar

Un harness es una lista de decisiones. Qué puede hacer el agente, cuánto avanza sin preguntar, cómo se mide y quién lo apaga. Si estás armando el tuyo, escribe esa lista antes del primer prompt.

Si quieres ver cómo se siente del otro lado, conversa con Cris en pappcorn.ai →

Notas

1. Cada cambio es un pull request mergeado en el monorepo de PappCorn, contado en GitHub, al 23 de octubre de 2026. Incluyen código, documentación y el trabajo de todos los partners que viven en el monorepo.
2. Pull requests mergeados, contados en GitHub al 26 de octubre de 2026 según la cuenta que los abrió. Los 285 de Nicolás suman los dos repositorios. Como en la nota 1, incluyen código y documentación.
3. Anfitrión no tiene herramientas, así que no junta las tres partes de la trifecta. Por eso la seguridad de este post habla casi solo de Partner Manager.

En qué nos apoyamos

Citarlas no quiere decir que sus autores respalden lo que hicimos.

• Jerome H. Saltzer y Michael D. Schroeder. The Protection of Information in Computer Systems. Proceedings of the IEEE, vol. 63, n.º 9, pp. 1278–1308, 1975.
• Dex Horthy. 12-Factor Agents.
• Ruiyao Xu y otros. Harness²: Recursive Agent Harnessing for an Open World. 2026.
• Simon Willison. The lethal trifecta for AI agents. 2025.
• Emerson Murphy-Hill, Jenna Butler y Alexandra Savelieva. Adoption and Impact of Command-Line AI Coding Agents. 2026.