El prompt no controla tu agente de IA: el harness sí
Dos años oyendo que el truco está en la redacción del prompt. El truco está en otra parte, y si no la construyes, tu agente improvisa donde no debería.
En este artículo
El Cuñado y el prompt perfecto
El Cuñado lleva dos años convencido de que el secreto está en la redacción. Que si le metes las instrucciones bien escritas al modelo, el agente se porta. Que el truco es el prompt correcto.
Y no es que esté completamente equivocado. Un prompt bien construido marca diferencia. Pero hay un abismo entre "marca diferencia en un chat" y "mantiene un sistema en pie con tráfico real, usuarios impredecibles y casos que nadie anticipó en el diseño".
Ese abismo tiene nombre: harness.
Forbes publicó hace poco un análisis sobre harness engineering que lo resume bastante bien: el prompt es solo la punta del iceberg. Lo que hay debajo del agua, lo que realmente sostiene el sistema, es una capa de arquitectura determinista que el modelo ni ve ni controla.
Qué es un harness (y qué no es)
Antes de seguir: el harness no es un framework misterioso ni una palabra de gurú. Es un concepto de ingeniería que viene del mundo del testing (un "arnés" que envuelve un componente para controlarlo desde fuera) y que aplicado a sistemas de IA significa exactamente eso: la arquitectura que rodea al modelo y gestiona todo lo que el modelo no debería decidir solo.
Cuatro piezas concretas:
Routing: decide a qué parte del sistema llega cada input del usuario. No el modelo. El código. Si el usuario pregunta por una factura, va a la skill de facturación. Si pregunta por una incidencia técnica, va a la skill de soporte. El modelo no elige su propio destino.
Skills modulares: piezas especializadas que hacen una tarea concreta y bien definida. Cada skill tiene un scope claro, entradas esperadas y salidas esperadas. El modelo opera dentro de ese scope. No fuera.
Capas de validación: comprueban lo que entra al modelo y lo que sale antes de que llegue al usuario. Formato, coherencia, límites de lo que está permitido responder. Si la salida no pasa la validación, no sale.
Constitución del sistema: reglas fijas, inmutables, que el modelo no puede transgredir independientemente de lo que le pida el usuario o de lo que "decida" hacer. No es un prompt de sistema. Es lógica en código que opera por encima del modelo.
Nada de esto es probabilístico. Es Python. Es lógica. No alucina porque no puede alucinar: o la condición se cumple o no se cumple.
El prompt le dice al modelo qué hacer. El harness determina en qué mundo opera ese modelo.
Sin harness: el modelo improvisa donde no debería
Aquí está el problema real que nadie te cuenta cuando te venden la fantasía del "agente autónomo".
Sin harness, el modelo toma decisiones operativas. Decide él si escalar una incidencia o no. Decide si llamar a una API externa o responder con lo que tiene. Decide si pedir más contexto al usuario o tirar con lo que le llegó. Decide si una respuesta está dentro de lo que la empresa permite decir.
A veces acierta. Los modelos actuales son bastante buenos. Pero "bastante buenos" y "a veces" son palabras que en producción se traducen en incidentes.
Imagina un agente de atención al cliente sin harness. El usuario le escribe algo ambiguo. El modelo interpreta, decide que es una solicitud de cancelación y ejecuta la acción. O lo contrario: el usuario quiere cancelar y el modelo decide que quizás solo necesita ayuda y lo redirige en bucle. Sin una capa determinista que diga "si el usuario menciona cancelación, valida identidad primero y luego enruta a retención", el modelo hace lo que le parece.
Lo que le parece al modelo es estadísticamente probable. No es determinista. No es auditable de la misma manera. Y en producción, eso importa.
Con harness: el código decide lo operativo, el modelo hace lo suyo
La inversión de control es el concepto clave aquí. Y es exactamente eso: una inversión.
Sin harness, el modelo está en el centro de todo. Recibe el input, decide qué hacer, genera la respuesta, y tú rezas para que haya entendido bien.
Con harness, el modelo es una pieza dentro de un sistema más grande. El routing ya decidió a qué skill llega el input. La skill ya tiene el contexto exacto que necesita. El modelo genera el texto (que es lo que hace bien) y la validación comprueba que lo que salió tiene sentido antes de que llegue al usuario. La constitución garantiza que ningún output viole las reglas del sistema, independientemente de lo creativo que se haya puesto el modelo.
El modelo no sabe nada de esto. No necesita saberlo. Su trabajo es generar texto útil dentro de un carril bien definido. El carril lo construyes tú.
Esto conecta directamente con algo que ya hemos visto en sistemas de pagos agénticos: el control tiene que estar en la infraestructura, no en el prompt. No es una opinión estética. Es una necesidad de ingeniería.
Dicho esto: la frontera entre qué decides en código y qué dejas al modelo no es fija ni universal. Es una decisión de diseño que depende del dominio. Hay sistemas excelentes en producción donde esa frontera está en sitios muy distintos (un agente de soporte técnico con alta variabilidad en las consultas puede dejar más margen al modelo que un agente de pagos donde cada acción tiene consecuencias financieras directas). Lo que no cambia es que alguien tiene que haber tomado esa decisión conscientemente, no por omisión.
El trade-off del harness: más control, más rigidez
Aquí viene lo que los entusiastas del harness suelen omitir: un harness mal diseñado es tan peligroso como no tenerlo. Solo que falla de otra manera.
Sin harness, el sistema falla por exceso de libertad del modelo. Con un harness demasiado estricto, el sistema falla por rigidez ante casos que nadie anticipó en el diseño.
Vuelve al ejemplo del agente de cancelaciones. Imagina que el harness tiene una regla determinista: "cualquier mensaje que contenga la palabra 'cancelar' enruta directamente a retención, sin pasar por validación de contexto". Funciona bien el 90% del tiempo. Pero el usuario que escribe "quiero cancelar la incidencia que abrí ayer, ya me lo han resuelto" acaba en retención intentando explicarle a un agente de ventas que no quiere irse a ningún lado. El harness hizo exactamente lo que le dijiste que hiciera. El problema es que lo que le dijiste era demasiado rígido.
El diseño del harness requiere el mismo criterio que cualquier otra decisión de arquitectura: pensar en los casos edge, en la variabilidad real del input, en qué pasa cuando el mundo no se comporta como el diagrama de flujo. Añadir capas deterministas no es gratis. Cada regla que metes en código es una apuesta sobre cómo se va a comportar el sistema en situaciones que todavía no has visto. Equivócate en esa apuesta y habrás construido una trampa muy bien documentada.
LangGraph y la orquestación real en producción
He orquestado agentes en producción con exactamente este enfoque. Incluyendo LangGraph.
LangGraph es un framework open-source para construir flujos de trabajo de agentes de IA generativa. Permite definir grafos de estados donde cada nodo es una operación (una llamada al modelo, una validación, una decisión de routing) y las aristas son las transiciones entre estados. Es una forma de hacer explícita la arquitectura del harness.
Lo que hace útil a LangGraph no es que sea mágico. Es que te fuerza a pensar en términos de estados y transiciones en lugar de en términos de "le digo al modelo que haga X". Cuando defines el grafo, estás definiendo el harness. Estás decidiendo qué nodos son deterministas (validaciones, routing, llamadas a APIs) y cuáles son probabilísticos (el modelo generando texto). La separación es explícita y visible.
Pero LangGraph no es la única manera de hacer esto. Si estás evaluando opciones, hay alternativas reales con perfiles distintos: CrewAI tiene sentido cuando necesitas coordinar múltiples agentes con roles diferenciados y quieres una abstracción de alto nivel para eso; AutoGen de Microsoft encaja mejor en escenarios de conversación multi-agente donde los agentes se coordinan entre sí con más autonomía; DSPy va por otro camino (en lugar de orquestar flujos, optimiza los propios prompts y módulos de forma programática, útil cuando el cuello de botella está en la calidad del output del modelo más que en la arquitectura del flujo). Ninguno es mejor en abstracto. Depende de qué problema estás resolviendo.
Lo que no puedes es no construir nada y esperar que el prompt lo supla.
La diferencia entre los sistemas que aguantaron y los que explotaron en la cara del cliente no estaba en si el prompt era bonito. Estaba en si alguien había pensado en qué decisiones debía tomar el código y cuáles podía tomar el modelo.
La trampa del "prompt largo como harness"
Hay un error común que vale la pena nombrar explícitamente porque lo he visto muchas veces: intentar un prompt de sistema larguísimo como sustituto del harness.
La lógica es comprensible. "Si le digo al modelo exactamente qué hacer en cada situación posible, no necesito arquitectura extra." El resultado es un prompt de 3.000 palabras lleno de instrucciones condicionales, casos edge y reglas de negocio.
El problema es que un prompt largo no es determinista. El modelo lo lee, lo procesa estadísticamente y genera una respuesta que probablemente siga las instrucciones... la mayor parte del tiempo. Pero "la mayor parte del tiempo" no es lo mismo que "siempre". Y cuanto más largo y complejo el prompt, más oportunidades hay de que el modelo interprete algo de una manera que no esperabas.
Una validación en código que comprueba si el output contiene información de tarjetas de crédito antes de enviarlo al usuario es determinista. No falla. Un prompt que dice "nunca incluyas información de tarjetas de crédito" es una instrucción al modelo. El modelo puede seguirla. O puede no seguirla si el usuario es lo suficientemente creativo con su input.
Esto es especialmente relevante si estás construyendo sistemas que tocan datos sensibles o ejecutan acciones con consecuencias reales. El artículo sobre arquitectura de chatbot empresarial listo para producción entra en detalle en exactamente este tipo de capas.
Lo que no sé (y por qué importa decirlo)
Aquí viene la parte que los gurús del prompt omiten: no tengo cifras comparativas limpias.
No hay métricas publicadas que digan "con harness tienes un X% menos de fallos en producción frente a sin harness". Si alguien te vende ese número sin una fuente concreta y verificable, te está vendiendo el mismo tipo de humo que el del prompt mágico. Solo que con más vocabulario técnico.
Lo que sí puedo decir, desde la experiencia directa orquestando estos sistemas, es que la diferencia es cualitativa y observable: los sistemas con harness bien construido tienen fallos predecibles y auditables. Cuando algo sale mal, puedes trazar exactamente en qué nodo falló, con qué input, y por qué. Los sistemas sin harness tienen fallos que dependen de cómo interpretó el modelo una situación que nadie anticipó, y trazarlos es mucho más complicado.
La auditabilidad no es un lujo. En cualquier sistema que opere en un contexto regulado, o que tome acciones con consecuencias reales para usuarios reales, saber exactamente por qué el sistema hizo lo que hizo no es opcional. Pero la auditabilidad tampoco se mantiene sola: necesita evals que comprueban que el sistema sigue comportándose como esperas cuando cambias algo, regression tests que detectan cuándo una modificación rompe un comportamiento que funcionaba, y golden sets (conjuntos de casos conocidos con outputs esperados contra los que validar). Sin eso, la arquitectura determinista que construiste se degrada silenciosamente con cada iteración. No es una solución mágica; es mantenimiento. El mismo que necesita cualquier sistema de software que opera en producción.
El prompt importa. Pero no es suficiente
Para no llevarte una conclusión equivocada: el prompt sigue importando.
Un prompt bien construido hace que el modelo genere texto más útil, más coherente con el tono que necesitas, más preciso en el dominio en el que opera. No es irrelevante. Es necesario.
Pero es insuficiente como único mecanismo de control en un sistema que opera en producción con usuarios reales.
La distinción es entre lo que el modelo hace (generar texto) y lo que el sistema hace (gestionar qué información recibe el modelo, qué puede hacer con ella, y qué pasa con su output antes de que llegue al usuario). El prompt controla la primera parte. El harness controla la segunda.
Si construyes un agente de IA y solo tienes la primera parte, tienes un modelo con instrucciones. Si tienes las dos, tienes un sistema.
La diferencia entre las dos cosas es lo que separa una demo que impresiona en un hackathon de un sistema que aguanta en producción seis meses después.
