La ingeniería de prompts, contexto, bucles y grafos resultó ser una sola pieza de la misma máquina. El arnés (harness) es donde finalmente conviven todas.
Cada etapa del desarrollo con IA tuvo su propio título profesional. La ingeniería de prompts llegó primero, cuando el oficio consistía en encontrar la frase correcta.
Le siguió la ingeniería de contexto, una vez que quedó claro que la frase importaba menos que todo lo que se cargaba a su alrededor. Este verano fue el turno de los bucles, y unas semanas después, de los grafos.
El término que se está extendiendo ahora es harness engineering (ingeniería de arnés), y es el primero que explica todos los demás.
Un arnés es todo lo que rodea al modelo: las herramientas que puede llamar, los archivos que lee antes de nada, los directorios donde puede escribir, las comprobaciones que debe superar su salida, el cronograma que lo despierta y la regla que termina la ejecución.
Cada disciplina anterior resulta ser un único componente de ese marco, construido por separado y con su propio nombre.
Empecé a prestar atención por una razón práctica. El modelo subyacente sigue cambiando, a veces escalando diecisiete puestos en la clasificación con una sola actualización, y el arnés es la única parte del sistema que permanece siendo tuya.
1/ Siete ingenierías, una máquina
Disciplina
La pregunta que responde
Dónde vive dentro del arnés
Ingeniería de prompts
Qué estoy pidiendo exactamente
SKILL.md, la especificación de la tarea cargada primero
Ingeniería de contexto
Qué ve el modelo en cada paso
El ensamblador de contexto: restricciones, esquemas, páginas recuperadas
Ingeniería de herramientas
Qué puede tocar y en qué formato
Definiciones de herramientas con entradas y salidas tipadas
Ingeniería de bucles
Qué inicia una ejecución y qué la termina
El ejecutor: disparadores, condiciones de parada, presupuestos
Ingeniería de grafos
Qué recuerda y cómo se conectan las cosas
La capa de memoria: nodos, aristas tipadas, alias
Ingeniería de evaluación
Cómo se rechaza un resultado
El verificador, fuera del control del agente
Ingeniería de arnés
Qué mantiene unido todo lo anterior
El marco, los permisos y los hooks
Lee la tabla de arriba a abajo y es una historia. Léela de abajo hacia arriba y es una arquitectura: la ingeniería de arnés es el trabajo de decidir dónde vive cada una de las otras seis, para que ninguna termine escondida en un prompt.
Ese último punto es el que tiene más peso.
Un prompt es el lugar más fácil para poner cualquier cosa, así que todo deriva hacia él: el formato de salida, la regla de parada, las correcciones de la semana pasada, la lista de cosas que el agente nunca debe tocar. Funciona perfectamente con el modelo para el que lo escribiste, pero luego el siguiente modelo lee el mismo párrafo de manera diferente.
2/ Anatomía de un arnés
El hábito más útil que he adoptado es escribir todo el arnés como un único archivo de configuración, para que nada importante quede implícito:
1# harness.yaml2model: kimi-k3 # una línea. todo lo de abajo sobrevive a un cambio3tools: [browser, fs, shell, search]4permissions:5 write: [./10-returns, ./20-graph, ./40-runs]6 ask_first: [send, publish, pay, delete]7context:8 always: [SKILL.md, CONSTRAINTS.md, SCHEMA.md]9 per_agent: return_schema10runner:11 trigger: cron "0 2 * * *" # nocturno, mientras duermes12 stop: 40 verified nodes OR 3 passes with nothing new13 budget: { agents: 300, minutes: 45, retries: 2 }14memory:15 graph: ./20-graph16 aliases: ./aliases.csv17verify:18 - script: checks/schema.py19 - agent: reviewer, fresh context20hooks:21 pre_tool: hooks/pre_tool.sh22 post_run: append 40-runs/
Tres líneas en ese archivo hacen la mayor parte del trabajo.
`model:` es una línea a propósito. Todo lo demás está escrito para que no le importe qué dice esa línea. Esa es toda la historia de la portabilidad.
`permissions:` importa más que `tools:`, aunque esté más abajo en el archivo. Escribir qué puede cambiar el agente y sobre qué debe preguntar primero es lo que separa un sistema que dejas funcionando durante la noche de uno que te quedas mirando.
`verify:` tiene dos entradas por una razón. El script no cuesta nada y detecta cualquier error mecánico. El revisor es un segundo agente que nunca vio trabajar al primero, porque un agente que califica su propia salida encuentra siempre razones para aprobarla.
En disco, el arnés es una carpeta, y cada ingeniería de la tabla tiene su propia dirección dentro de ella.
3/ Por qué Kimi K3 es el motor que pondría dentro
Lo que necesita el arnés
Lo que aporta Kimi K3
Un ejecutor que pueda expandirse (fan-out)
Agent Swarm: hasta 300 agentes trabajando en un problema al mismo tiempo, sin escribir un orquestador
Código lo suficientemente fuerte para escribir sus propias comprobaciones
#1 en Frontend Code Arena con 1,679, por delante de Fable 5 (1,631) y GPT-5.6 Sol (1,618), liderando 6 de 7 dominios
Un motor que mejora debajo de ti
De #18 a #1 en una sola actualización de julio
La primera fila importa más de lo que parece. Casi todos los arneses caseros desarrollan un orquestador hecho a mano en algún momento, y suele ser el archivo más frágil de la carpeta. Con el swarm, la expansión se convierte en una línea de presupuesto, agents: 300, y el arnés solo tiene que manejar lo que regresa.
La segunda fila importa porque un arnés es principalmente código que el modelo escribe para ti: scripts de hooks, comprobaciones de esquema, el pequeño panel que lee 40-runs. Un motor que lidera la arena frontend acierta esas cosas a la primera mucho más a menudo.
La tercera fila es el argumento para la ingeniería de arnés en un solo dato. Cuando un modelo sube diecisiete puestos de la noche a la mañana, un arnés pone ese ascenso a trabajar el mismo día, porque la única línea que tiene que cambiar es model.
4/ Hooks: Los reflejos
Un hook es un script corto que el arnés ejecuta en un momento fijo, independientemente de lo que decida hacer el modelo. Los hooks son donde un arnés deja de ser una estructura de carpetas y empieza a comportarse como un sistema de seguridad.
Hook
Cuándo se dispara
Qué hace
pre_tool
Antes de cualquier llamada a herramienta
Bloquea escrituras fuera de la lista de permisos
post_tool
Después de cada retorno
Ejecuta la comprobación de esquema y rechaza la salida malformada en el acto
pre_send
Antes de que algo salga de la máquina
Lo mantiene en cola hasta que tú lo apruebes
on_fail
Después de un resultado rechazado
Adjunta la razón del fallo al reintento
post_run
Cuando se alcanza la condición de parada
Añade el registro de la ejecución a 40-runs y muestra las diferencias en el grafo
El hook pre_tool de la primera fila cabe en cinco líneas:
1# hooks/pre_tool.sh2case "$TARGET" in3 ./10-returns/*|./20-graph/*|./40-runs/*) exit 0 ;;4 *) echo "blocked: $TARGET is outside the write list"; exit 1 ;;5esac
Solo el hook on_fail cambia la economía de un bucle. Un reintento que lleva la razón por la que falló el último intento es una corrección. Sin esa razón, el bucle paga por el mismo error una segunda vez.
5/ Cómo es una noche
Une todas las piezas y el arnés se comporta como un turno de noche que sigue reglas. A las 02:00 se dispara el activador y la consulta de lanzamiento selecciona todos los nodos que necesitan trabajo. El swarm se expande, un agente por nodo.
Los retornos que no cumplen el esquema son rechazados por post_tool antes de llegar al grafo, y cada nodo rechazado reintenta una vez adjuntando su razón de fallo. Cuando un agente intenta escribir fuera de su carpeta, pre_tool lo detiene sin despertar a nadie.
Los nodos fusionados y las aristas tipadas aterrizan en 20-graph. Un correo electrónico redactado llega a pre_send y espera. post_run añade el registro, y el bucle se detiene por su cuenta, muy dentro del presupuesto de 45 minutos de la configuración.
A las 07:30 lees un archivo y tomas dos decisiones. Ese es el costo total de la mañana de ejecutar la ingeniería de bucles y la ingeniería de grafos de esta manera, y ese es todo el objetivo del arnés: todo lo que podía funcionar sin ti funcionó, y las pocas cosas que te necesitaban están esperando en un solo lugar.
6/ La prueba de intercambio
La auditoría más rápida de cualquier configuración de agente: cambia la línea del modelo y vuelve a ejecutarlo. Lo que se rompa era un arnés viviendo en el lugar equivocado.
Qué se rompe después del intercambio
Dónde estaba escondido
Dónde pertenece
El formato de salida se desvía
"siempre responde como JSON" en el prompt
Un esquema de retorno más un script que rechaza cualquier otra cosa
Las ejecuciones dejan de terminar solas
"sigue hasta que sea exhaustivo"
Una condición de parada basada en conteos
Las correcciones de la semana pasada desaparecen
El historial del chat
CONSTRAINTS.md, cargado en cada ejecución
La misma empresa aparece tres veces
El juicio del modelo
aliases.csv, comprobado antes de fusionar
Escribe en algún lugar donde no debería
Una frase educada en el prompt
Una lista de permisos y un hook pre_tool
Una configuración que pasa la prueba de intercambio es portable, y ser portable es lo que hace que valga dinero.
Cuánto cuesta y cuánto paga
Las empresas invierten trimestres enteros en plataformas internas de agentes. Un arnés funcional es una carpeta, un archivo de configuración y cinco scripts cortos, y funciona con una suscripción a Kimi. Esa brecha es la oportunidad.
Canal
Qué paga
Qué necesitas primero
Configuración de arnés para un equipo pequeño
Una tarifa única de cuatro cifras por la configuración, hooks y verificador alrededor de su flujo de trabajo
Un arnés propio, funcionando según un horario
Retainer de día de lanzamiento
Una cuota mensual para ejecutar la prueba de intercambio en cada gran lanzamiento de modelo y mover al equipo al que lidere
Un cliente cuyas ejecuciones ya registran en 40-runs
Plantilla de arnés de nicho
La carpeta y el yaml empaquetados para una industria: investigación, reclutamiento, cumplimiento normativo
El mismo arnés probado en dos mercados diferentes
El segundo canal es el que yo construiría primero. Cada gran lanzamiento reordena la clasificación; solo K3 subió diecisiete puestos en una actualización, y cada equipo con un arnés necesita alguien cuyo trabajo sea ejecutar la prueba de intercambio el día del lanzamiento.
La versión corta
La ingeniería de prompts, contexto, herramientas, bucles, grafos y evaluación resultan ser componentes de una sola máquina, y la ingeniería de arnés consiste en decidir dónde vive cada uno de ellos.
Pon el modelo detrás de una línea, los permisos por delante de las herramientas y el verificador fuera del agente. Entonces, el próximo salto en la clasificación será un cambio de configuración en lugar de una reconstrucción.
Y si esto te pareció útil:
- Guarda este artículo en favoritos. Los enlaces cambian y aparecen nuevos repositorios semanalmente, necesitarás esto como referencia
- Para análisis profundos semanales sobre arquitectura de IA, trading cuantitativo y la economía de agentes, sígueme: @polydao
- Únete al Canal de TG: Buzzoni Notes - aquí comparto mis prompts crudos, skills personalizados y alpha que es demasiado pronto para X
