One Spark
El modelo no es el agente
Un modelo de lenguaje, por sí solo, recibe texto y devuelve texto. Un agente hace cosas: consulta un sistema, revisa un archivo, prepara una póliza, manda un correo. Lo que convierte al primero en el segundo es todo lo que lo rodea.
A ese conjunto se le llama arnés (en inglés, harness). La fórmula que se repite en la comunidad técnica es simple: agente = modelo + arnés. Y el harness engineering es la disciplina de diseñar ese arnés a propósito, en lugar de dejarlo a la improvisación.
Es un término todavía en formación. Distintas fuentes lo definen con matices, como un trabajo académico que lo describe como el entorno de ejecución que gestiona contexto, herramientas, memoria, permisos y verificación, y esta guía que lo presenta como el diseño de las restricciones y los ciclos de retroalimentación del agente. Coinciden en lo esencial: el arnés envuelve al modelo y cubre herramientas, contexto, controles y retroalimentación.
Qué incluye un arnés
Estas son las piezas que revisamos en cada agente:
- Herramientas. Qué puede hacer el agente y con qué parámetros: leer una base de datos, buscar un pedido, crear un borrador. Una herramienta ambigua produce errores ambiguos.
- Contexto y memoria. Qué información ve y en qué momento: documentos, reglas del negocio, el historial relevante. Poco contexto lo hace inventar; demasiado, lo confunde.
- Permisos y límites. Qué puede hacer solo y qué debe pedir confirmar. Lo que escribe, paga o envía merece más control que lo que solo consulta.
- Verificación. Comprobar que lo que hizo es cierto con evidencia (una suma que cuadra, un registro que existe), no con su propia palabra.
- Evaluaciones. Un conjunto de casos con respuesta conocida que se repite después de cada cambio, para saber si el agente mejoró o empeoró.
- Observabilidad. Un registro de cada decisión, error y costo por tarea, para poder explicar qué pasó.
- Recuperación. Qué hace cuando algo falla: reintentar, detenerse o pasar el caso a una persona.
Por qué importa
En nuestra experiencia, cuando un agente falla casi nunca es porque el modelo sea poco capaz. Falta un dato en el contexto, una herramienta devuelve algo ambiguo, nadie verifica el resultado o nadie puede reconstruir lo que ocurrió. Todo eso se corrige en el arnés.
Por eso cambiar a un modelo más grande no sustituye al arnés: ayuda, pero no agrega permisos, no verifica ni deja bitácora.
Cómo se aplica a un agente de empresa
Imagina un agente que ayuda a conciliar los pagos de una tienda con sus pedidos. Es un caso ilustrativo, no un cliente:
- Herramientas: leer el estado de cuenta, buscar pedidos y proponer una conciliación. No tiene una herramienta para mover dinero.
- Contexto: las reglas de conciliación de la empresa y los pedidos del periodo.
- Permisos: solo lectura. Propone, y una persona aprueba.
- Verificación: antes de proponer, comprueba que los montos suman y que cada pedido aparece una sola vez.
- Evaluaciones: 30 conciliaciones históricas con resultado conocido, que se vuelven a correr cada vez que cambian las reglas.
- Observabilidad: cada propuesta guarda la evidencia que usó.
Con ese arnés, el error más probable deja de ser un cargo mal conciliado que nadie ve y pasa a ser una propuesta marcada para revisar.
Cómo lo hacemos en One Spark
Trabajamos con agentes todos los días: para desarrollar software, y en agentes propios de finanzas, contabilidad y contenido. De ahí salen reglas que repetimos en los proyectos de clientes:
- El contexto se escribe y se versiona. Cada proyecto tiene archivos de contexto, instrucciones por rol y una memoria con lo aprendido, para que el agente no parta de cero.
- Permisos mínimos y confirmación en dos fases. Lo que escribe, gasta o publica primero se propone y después se confirma.
- Un auditor independiente. Para tareas sensibles usamos un agente de solo lectura que revisa el trabajo de otro y entrega evidencia, sin modificar nada.
- «Verificado» significa evidencia ejecutada. No damos por hecho algo hasta correr la prueba y ver la salida real, o revisar lo que sirve producción.
- Pruebas y evaluaciones en cada cambio. Este mismo sitio tiene pruebas automáticas que se corren antes de cada despliegue.
- El modelo se elige por tarea. El más capaz para planear y decidir; uno más barato para tareas mecánicas.
- Todo queda registrado. Las decisiones y los cambios viven en el repositorio, no en la memoria de alguien.
Cuándo hace falta un arnés serio
Un asistente que solo responde preguntas con tus documentos necesita un arnés ligero: buen contexto, permisos por rol y evaluaciones básicas. Cuanto más actúa el agente (envía, paga, escribe en tus sistemas), más peso debe tener el arnés. Si quieres ver qué ofrecemos, revisa agentes de IA a la medida o agenda un diagnóstico y lo revisamos con tu caso.
Preguntas frecuentes
¿Harness engineering es lo mismo que prompt engineering?
No. El prompt es una sola pieza del contexto que recibe el modelo. El arnés incluye además las herramientas, los permisos, la verificación, las evaluaciones y la observabilidad.
¿Y context engineering?
Es la parte que decide qué información llega al modelo y cuándo. El arnés la contiene y suma el entorno de ejecución, los controles y los ciclos de retroalimentación.
¿Se le puede poner un arnés a un agente que ya tengo?
Sí. Primero se mide: se registran sus decisiones y se arma un conjunto de casos de prueba. Con eso se ven dónde falla y se agregan permisos, verificación y evaluaciones sin empezar de cero.
¿Un modelo más grande evita necesitar un arnés?
No. Un modelo mejor ayuda, pero no suple la falta de permisos, de verificación o de registro de lo que hizo. Esas piezas son del entorno, no del modelo.