El harness de Cris

Harness es una palabra de moda en IA. Casi todo el que arma agentes la usa, y cada quien la llena con algo distinto. Este post cuenta qué hay dentro del nuestro.

Cris es el agente de PappCorn y tiene tres caras. Las tres trabajan como una empresa regulada. Solo hacen lo que una persona les habilitó. Esa persona decide, a conciencia, cuánta autonomía les da, cómo la mide y cómo la cierra si algo sale mal.

Lo escribimos para quien arma agentes o los evalúa con ojo técnico. Detrás de todo hay cuatro principios.

1. La IA se configura, no «se usa».
2. Se construye desde la seguridad.
3. Se entiende, para poder comandarla.
4. No la instalamos. Acompañamos a adoptarla.

0. Un personaje, tres caras

Cris Anfitrión existe para acompañar a más personas a apropiarse de la IA. Nosotros no alcanzamos a sentarnos con cada una, y él sí. Recibe a quien llega a pappcorn.ai, conversa, la conoce y le ayuda a configurar su IA para lo suyo. Lo pensamos como un compañero. Su chat entró a producción el 22 de septiembre, con lista de espera hasta el 6 de octubre.

Cris Partner Manager es para trabajar con nuestros partners en uno o varios productos, cada uno en su monorepo. Casi todos son startups. Conversa con ellos en Slack, responde sobre el trabajo en curso y los conecta con el equipo humano. Su primera versión entró a nuestro monorepo el 7 de agosto.

jarCris, o Cris Jarvis, es donde trabaja el equipo de PappCorn. Con él mantenemos desde el monorepo los harness, los productos y los plugins, todo el universo PappCorn. Hoy es un equipo de agentes que toma un issue, lo entiende, lo construye, lo prueba y lo deja listo para revisar. Desde mayo de 2025, en el monorepo se mergearon más de 1.300 PRs hechos con un agente de código en la sesión. El equipo de agentes llegó después, así que solo una parte de esos PRs pasó por él. Hoy, cuando hay una persona en la sesión, el PR sale a su nombre, y eso también es una configuración que eligió una persona.

Es el mismo personaje con la misma voz. Lo que cambia entre las tres caras es cuánto le confiamos, y eso depende de quién está al otro lado.

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

1. Qué es un harness, y por qué la IA se configura

Llamamos harness a todo lo que rodea al modelo. El prompt, la ventana de contexto, la memoria, las herramientas y sus permisos, el control del flujo y la medición. El modelo es una pieza más.

La idea no es nuestra. Dex Horthy la ordenó en 12-Factor Agents, donde dos de los factores son adueñarse de los prompts y adueñarse de la ventana de contexto. Ruiyao Xu y otros la llevan a la investigación en Harness², donde el rendimiento de un agente depende tanto del modelo como del harness que lo ejecuta, y el harness mismo se puede mejorar. Seguimos de cerca su trabajo.

De ahí sale nuestro primer principio. La IA se configura, no «se usa». Configurarla es decidir qué sabe, qué puede hacer y cómo se nota cuando falla. Con el mismo modelo, dos configuraciones dan dos productos distintos.

Lo predicamos también afuera. En universe, nuestro catálogo abierto, publicamos cris-asiste, un paquete de skills gratis para «configurar tu propia IA, no solo usarla». Te entrevista y arma contigo un agente pequeño, una skill o un asistente personal.

Cuando Cris se equivoca, casi nunca arreglamos el error cambiando de modelo. Lo arreglamos en el harness, que es lo único que de verdad es nuestro.

2. Cómo trabaja cada Cris

Anfitrión conversa y declara. En cada turno escribe su respuesta y, junto con ella, unas marcas que la persona no ve, con lo que entendió de ella: su nivel con la IA, si emprende y qué quiere lograr. El servidor quita las marcas antes de mostrar el texto y las lee. Recuerda a la persona con un perfil corto. La transcripción no se guarda.

Partner Manager lee y responde. Un mensaje en Slack pasa por diez filtros antes de que el modelo lo vea. Se descarta lo repetido, lo que viene de bots y lo que no está dirigido a Cris, y la identidad de quien escribe se verifica en vivo. Con sus herramientas, Cris verifica el estado real antes de afirmarlo.

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

jarCris reparte el trabajo entre agentes distintos. Cada issue pasa por fases, de entender el problema a entregar, ordenadas por los cuatro riesgos de producto de Marty Cagan. Un agente encuadra el valor, otro diseña, otro construye, otro prueba y otro prepara la entrega. Ese reparto ordena el trabajo, y ningún agente revisa lo que él mismo escribió. Las llaves del merge son otras. Una es la de un revisor automático que corre en CI con su propia credencial, distinta de la del agente que escribió el código. La otra es la etiqueta que autoriza el merge, y esa la pone una persona. Saltzer y Schroeder lo llamaron separation of privilege. Un mecanismo que pide dos llaves para abrirse es más robusto que uno que se abre con una sola. En una empresa se le dice el principio de los cuatro ojos.

En las tres caras, el modelo propone y algo que no es el modelo decide qué pasa con eso.

3. Solo lo que le habilitamos

El segundo principio es construir desde la seguridad. Un agente debe hacer lo que le está permitido. No todo lo que no le está prohibido.

Una startup puede hacer todo lo que no sea ilegal. Un banco regulado solo hace lo que su licencia le habilita, y cada actividad nueva la pide y la justifica. Nuestros agentes trabajan como el banco.

Jerome Saltzer y Michael Schroeder lo escribieron en 1975, en The Protection of Information in Computer Systems, publicado en Proceedings of the IEEE. Su principio de fail-safe defaults dice «Base access decisions on permission rather than exclusion». Por defecto no hay acceso. El de least privilege pide que cada programa trabaje con el mínimo de privilegios que necesita su trabajo.

En la práctica, el harness de Cris se construye de abajo hacia arriba. Se empieza por lo que el agente puede hacer, y se habilitan permisos uno a uno. El camino inverso arranca con un agente que puede todo y cierra caminos después. Ese camino suele dar más resultados y más rápido, y para una tarea puntual es lo más inmediato. A cambio, puede dejar abiertos caminos que uno no quisiera tener, y casi nunca se sabe cuáles son hasta que alguien pasa por ellos.

Partner Manager trabaja con una lista positiva de herramientas. Lo que no está en la lista se niega sin preguntar, porque no hay nadie a quien preguntarle. La lista depende del canal, y si hay duda sobre qué perfil le toca, baja al de menos permisos.

Los permisos de Anfitrión nacen cerrados y se abren con hechos. Una función pura recibe la etapa, el perfil y las señales de la conversación, y devuelve qué puede hacer Cris. Regalarle a la persona un plan solo se abre cuando hay nivel, segmento y objetivo. Nombrar al equipo humano se abre cuando la persona lo pide, y se cierra cuando Cris ya lo ofreció. Preguntar el precio no abre ningún permiso. Cris responde con la verdad y sigue ayudando.

Simon Willison describió la trifecta letal de un agente. Datos privados, contenido no confiable y una forma de comunicarse hacia afuera, juntos en el mismo agente. Luca Beurer-Kellner y otros recogieron en Design Patterns for Securing LLM Agents against Prompt Injections patrones para que una entrada no confiable no pueda disparar acciones con consecuencias. Anfitrión no tiene herramientas, así que no las junta.

Partner Manager sí reúne las tres. Lee datos privados, porque consulta el tablero donde llevamos el trabajo. Lee contenido que no controlamos, porque los mensajes del canal los escriben otras personas. Y tiene una forma de comunicarse hacia afuera, que es su propia respuesta. Por eso no alcanza con que sus herramientas sean de solo lectura. Para filtrar algo no hace falta escribir en ningún lado, basta con contestar. Le quitamos las herramientas que le permitirían buscar y recorrer el tablero. Una instrucción inyectada ya no puede pedirle que busque tareas ni que liste espacios. Lo que está fuera de su lista se niega sin preguntar. Eso acota el riesgo, y no lo da por cerrado.

Un agente que empieza pudiendo todo es tan seguro como la imaginación de quien lo cerró. Preferimos que detrás de cada permiso haya alguien que decidió abrirlo.

4. La autonomía la decide una persona

Además de qué puede hacer Cris, está cuánto avanza sin preguntar. Esa decisión la toma una persona, por repositorio, y la puede cambiar.

jarCris tiene cuatro niveles.

Debajo de los cuatro hay un piso que ningún nivel baja. No arranca la construcción si falta el registro de riesgos. Un cambio que toca autenticación, secretos o fronteras entre partners pasa por una revisión de seguridad y por una persona antes de entregarse. Las operaciones de producción las corre una persona. Y el loop nunca finge un verde.

Ese piso también es una decisión humana. Lo fijamos nosotros, con lo que sabemos hoy, y se puede revisar. El nivel se elige por capas, del valor del repositorio a un issue delicado que se aprieta a mano. Elegir autopilot para un tipo de trabajo es una persona diciendo que ese trabajo sale sin volver a preguntarle, y el registro la nombra.

La autonomía también incluye quién firma cada acto. Se configura si el PR lo abre el agente o sale a nombre de la persona, desde qué cuenta sale cada comentario y cada aprobación, y quién pone la etiqueta que autoriza el merge. Cada una de esas piezas se deja puesta o se quita, y lo decide una persona. Es la misma idea del resto del post, llevada al monorepo. La persona elige qué habilita.

Erik Schluntz y Barry Zhang, en Building effective agents, recomiendan empezar por la solución más simple, darle al agente condiciones de parada y puntos donde se detiene a pedir retroalimentación humana. Horthy lo pone en su factor 7, contactar a las personas con una llamada a herramienta. En nuestro caso, esa parada también la activa una persona cuando cierra lo que había habilitado.

Cerrar ya nos pasó, con fecha.

• 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 abrir sesión de agente y sin gastar un token. La pausa se relee en cada turno, y levantarla es borrar una entrada.
• 30 de agosto. Una persona vio que el loop de revisión podía poner la etiqueta de merge en una corrida sin nadie presente, y cambió la configuración para que no lo hiciera. El 14 de septiembre corrigió lo que había cerrado de más. Hoy, con una persona en la sesión, el loop etiqueta sin volver a preguntar. Sin nadie, no etiqueta.
• 20 de octubre. La medición con el modelo real arrancaba sola en cada PR que tocara el prompt. La pasamos a lanzamiento manual. Lanzarla es aprobar el gasto.

Las pausas responden con texto fijo porque un tope que llama al modelo para avisar que se acabó el tope cuesta lo que el tope quería evitar. Cada turno de Partner Manager tiene, además, un tope de turnos y de gasto.

5. El modelo declara y el código decide

El tercer principio es entender la IA para poder comandarla.

En Anfitrión, eso se traduce en una regla. El modelo declara hechos y el código toma las decisiones con consecuencias. Una función lee lo que Cris declaró y deriva la etapa de la persona en cinco pasos, de conocerla a ayudarle a construir, sin saltos. Otra deriva los permisos. Con los mismos hechos dan siempre el mismo veredicto, así que se prueban con tablas de casos sin llamar al modelo.

En cada turno, el veredicto le llega al modelo en un bloque al final del prompt. Le dice en qué etapa va la persona y qué tiene permitido. El modelo ve el permiso, pero no lo otorga. Si se adelanta y anuncia el plan de regalo antes de tiempo, el plan igual no sale.

Esto tampoco lo inventamos. Horthy lo dice en sus factores 4 y 8. Las herramientas son salidas estructuradas, y el flujo de control es tuyo. Schluntz y Zhang separan los flujos de trabajo, donde el código orquesta, de los agentes que dirigen su propio proceso. Anfitrión es un flujo de trabajo a propósito.

Lo que ganamos es poder explicar cada decisión de Cris con una línea de código y una tabla de casos. Un prompt bien escrito ayuda mucho, y aun así no se puede auditar como una función.

6. Medir antes de cambiar

Si el modelo declara y el código decide, alguien tiene que verificar que el modelo declara bien. Hamel Husain lo argumenta en Your AI Product Needs Evals. Los productos de IA que se estancan casi siempre carecen de una forma seria de evaluarse.

Antes de cambiar cómo conversa Cris, corremos siete conversaciones guionadas contra el modelo real, con la misma lógica que en producción. El código revisa cada conversación con once chequeos deterministas. Que no nombre un plan sin permiso, que no hable de pagar sin permiso, que no filtre las marcas, que no asuma el género de quien escribe, que no repita la pregunta. La versión de Anfitrión que entró a producción el 16 de octubre pasó 7 de 7 perfiles, en la quinta corrida.

El tono sí lo juzga un modelo, y Lianmin Zheng y otros documentaron en Judging LLM-as-a-Judge los sesgos que eso trae. Por eso la opinión del juez nunca pisa un chequeo en código.

La medición tiene límites. Los guiones son fijos y no reaccionan a lo que responde Cris, así que convive con pruebas a mano. Y todavía se lanza a mano. Llevarla a CI es parte del plan de la sección 10.

7. Los tokens justos

El texto permanente del prompt es lo más caro que tiene un agente, porque se paga en cada turno de cada persona. Por eso el prompt de Anfitrión va por capas.

Primero van las instrucciones, iguales para todas las personas. Después, lo que sabe PappCorn según el plan de la persona. Al final va lo que cambia, que es el contexto de esa persona y el bloque con la etapa y los permisos que decidió el código.

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

El orden sale de cómo funciona el caché de prompts. Sirve cuando el comienzo del prompt es idéntico entre llamadas, y un byte distinto al principio invalida todo lo que viene detrás. Lianmin Zheng y otros mostraron en SGLang cuánto se gana reutilizando el trabajo ya hecho sobre un prefijo común. Una prueba verifica que las instrucciones sean idénticas en todas las etapas.

En una muestra de producción, el 71 % de los tokens que se podían cachear se leyó del caché. El resto se volvió a escribir, porque el caché vence tras unos minutos sin tráfico, y con poco tráfico vence seguido. Lo vamos a medir otra vez cuando haya tráfico continuo.

Antes de agregar una línea al prompt, preguntamos si la regla cabe en un chequeo en código. Si toca agregar texto, quitamos otro.

8. Los bloques que compartimos en universe

universe es nuestro catálogo abierto de plugins y conectores. Las piezas gratis tienen licencia MIT: los conectores gmail-mcp, gsheets-mcp y whatsapp-mcp, que corren con tus propias credenciales, y los paquetes de skills best-practices-git y cris-asiste.

Partner Manager carga @pappcorn/gsheets-mcp tal como lo publicamos desde universe, sin una versión privada. Además hay una línea de productos con licencia. El detalle está en el catálogo.

9. Acompañamos a adoptarla

El cuarto principio. No instalamos IA. Acompañamos a adoptarla.

Detrás de los tres Cris hay un equipo humano que sostiene estos harness y decide cuándo abrir y cuándo cerrar. También damos soporte de persona a persona a quien tiene acceso a Platform, nuestra plataforma de partners, y a universe.

Un harness se escribe en semanas y se sostiene durante años, porque los modelos y el trabajo de la persona cambian. Una instalación que nadie sostiene empieza a envejecer el día que se entrega.

Por eso hablamos de apropiarse de la IA. Quien adopta un agente tiene que entender qué hace, poder cambiarlo y saber a quién llamar. Eso no viene en una instalación. Sale de trabajar junto a alguien.

10. Lo que sigue

Todo lo de esta sección es plan.

Lo primero es que la medición corra en CI con réplicas y con un criterio estadístico de regresión, para que un chequeo que cae por azar no se lea como un cambio roto.

Lo segundo es usar la medición para proponer cambios. Un loop pequeño buscará dónde divergen las réplicas, porque lo que a veces pasa y a veces no suele esconder el arreglo más barato. Propondrá cambios sobre regiones acotadas del prompt, la versión actual y la propuesta competirán a ciegas, y el resultado será un PR en borrador para una persona. El loop no va a mergear ni desplegar nada.

Ningún proceso va a editar en vivo el prompt de un agente que habla con el público. Un agente que se mejora solo mientras corre deja de ser un agente que alguien puede comandar.

11. En qué nos apoyamos

Estas son las ideas de otros que usamos o seguimos de cerca. 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. Fail-safe defaults y least privilege (sección 3), separation of privilege (sección 2).
• Dex Horthy. 12-Factor Agents. Adueñarse de los prompts y de la ventana de contexto (sección 1), las herramientas como salidas estructuradas y el control del flujo (sección 5), contactar a las personas con una llamada a herramienta (sección 4).
• Ruiyao Xu y otros. Harness²: Recursive Agent Harnessing for an Open World. 2026. El harness como parte del rendimiento del agente, y su mejora (secciones 1 y 10).
• Erik Schluntz y Barry Zhang. Building effective agents. 2024. Flujos de trabajo frente a agentes, condiciones de parada y puntos de control humano (secciones 4 y 5).
• Simon Willison. The lethal trifecta for AI agents. 2025 (sección 3).
• Luca Beurer-Kellner y otros. Design Patterns for Securing LLM Agents against Prompt Injections. 2025 (sección 3).
• Hamel Husain. Your AI Product Needs Evals. 2024 (sección 6).
• Lianmin Zheng y otros. Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena. 2023 (sección 6).
• Lianmin Zheng y otros. SGLang: Efficient Execution of Structured Language Model Programs. 2023 (sección 7).
• Marty Cagan. INSPIRED, 2.ª edición. 2017. Los cuatro riesgos de producto (sección 2).

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, empieza por escribir esa lista antes del primer prompt.

Si quieres ver cómo se siente del otro lado, conversa con Cris en pappcorn.ai →. Y si quieres los bloques con los que lo armamos, están en el catálogo de universe.