Ingeniería de arneses: El entorno que hace que los agentes de IA sean fiables.

Si se le encomienda a un ingeniero brillante una tarea sin herramientas, sin documentación, sin controles de seguridad y sin forma de verificar el resultado, el outcome será impredecible. Un modelo de lenguaje grande en estado bruto utilizado como agente se encuentra en esa situación. La ingeniería aplicada es la disciplina que soluciona esto: consiste en diseñar todo el entorno en el que opera el agente, incluyendo herramientas, memoria, medidas de seguridad, bucles de retroalimentación y entornos de ejecución aislados.

La fórmula básica es Agente = Modelo + Herramientas. El modelo se encarga del razonamiento y de la toma de decisiones. Todo lo demás corresponde a las herramientas: cómo se conectan los instrumentos, la memoria, los entornos aislados, las medidas de seguridad, la selección del contexto, los marcos de planificación y los ciclos de retroalimentación que garantizan que un agente en producción sea fiable y seguro. Databricks lo expresa de esta manera: sin herramientas, un modelo puede responder preguntas, pero no puede ejecutar código de forma fiable, llamar a APIs, acceder a archivos, recordar trabajos anteriores ni completar por sí solo flujos de trabajo de múltiples pasos.

Esta idea representa el tercer paso en una progresión. La ingeniería de prompts se centraba en saber qué decir. La ingeniería de contexto se centraba en saber qué información proporcionar. La ingeniería de herramientas se centra en saber qué sistema construir.

Seis componentes de las herramientas

Los artículos especializados coinciden más o menos en los siguientes componentes:

1. Integración de herramientas, que conecta el modelo con APIs externas, bases de datos, ejecutores de código y herramientas personalizadas a través de protocolos definidos.
2. Memoria y estado, organizados en contexto de trabajo, estado de sesión y memoria a largo plazo, persistiendo más allá de una ventana de contexto.
3. Gestión de contexto e instrucciones, que selecciona dinámicamente lo que aparece en cada llamada al modelo.
4. Planificación y descomposición, que guía al modelo a través de secuencias estructuradas en lugar de solicitar todo de una sola vez.
5. Verificación y medidas de seguridad, que incluyen comprobaciones de validación, verificación de formato, filtros de seguridad y bucles de autocorrección.
6. Modularidad, es decir, componentes que pueden activarse, desactivarse o reemplazarse de forma independiente.

Por qué es importante

Los agentes se están extendiendo por todas partes, desde bots de soporte hasta asistentes de análisis financiero y herramientas de programación autónomas. La mayoría de los que fallan en producción lo hacen porque el marco de trabajo es frágil, inseguro o impredecible, y no porque el modelo LLM subyacente sea débil. Cuatro razones explican esta atención:

• Transfiere el trabajo de la esperanza a la ingeniería. En lugar de programación intuitiva y suerte, las restricciones estructuradas y la retroalimentación determinista hacen que los resultados sean predecibles y reproducibles.
• Reduce la carga de revisión. Un buen marco de trabajo aumenta las posibilidades de lograr una solución correcta desde el primer intento y también proporciona un ciclo que corrige la mayor cantidad posible de problemas antes de que un humano los vea.
• Permite una verdadera autonomía. Sin él, un agente es un chatbot mejorado. Con él, puede ejecutar código, llamar a APIs, leer archivos, recordar trabajos anteriores y completar flujos de trabajo de múltiples pasos.
• Esto convierte a los agentes en aptos para uso en producción. Birgitta Böckeler, en su artículo en el sitio de Martin Fowler, describe dos tipos de control: las guías, que son controles de retroalimentación previa que orientan al agente antes de que actúe, y los sensores, que son controles de retroalimentación que le ayudan a corregir sus acciones después de actuar. Esta combinación distingue a los agentes de demostración de los de producción.

El ciclo central

La mayoría de los agentes funcionan según un ciclo de razonar, actuar y observar:

1. Razonar: el modelo analiza todo lo que está en el contexto (tarea, memoria, resultados anteriores) y elige la siguiente acción.
2. Actuar: el mecanismo correspondiente la ejecuta, por ejemplo invocando una herramienta, ejecutando código en un entorno aislado, accediendo a una API o guardando algo en el almacenamiento.
3. Observar: el mecanismo captura el resultado y lo devuelve al modelo como nuevo contexto.
4. Se repite el proceso, con el modelo utilizando ese resultado para elegir nuevamente.

El principio fundamental de diseño es una división clara de responsabilidades. El modelo propone; el mecanismo ejecuta, verificando esquemas, permisos, presupuestos y reglas de seguridad. El modelo nunca llama directamente a las herramientas: devuelve una solicitud estructurada, y el mecanismo la valida, la autoriza, la ejecuta e inserta el resultado. Gracias a esta división, los agentes permanecen seguros y auditables: las acciones se registran, los fallos siguen generando un resultado estructurado, y el nivel de riesgo determina la ruta de ejecución.

Origen del término

La historia es breve.

• De 2022 a 2024 fue la era de los prompts. Los desarrolladores dedicaron innumerables horas a redactar, estructurar y proporcionar ejemplos para obtener mejores resultados.
• A mediados de 2025 la atención se desplazó hacia el contexto. Lo que ve el modelo es tan importante como la forma en que se le formula la pregunta, por lo que la recuperación de información, la compresión y la gestión de la ventana de contexto pasaron a ser prioritarias.
• El 5 de febrero de 2026, Mitchell Hashimoto, cofundador de HashiCorp y creador de Terraform, publicó una entrada en la que describía un hábito: cada vez que un agente cometía un error, él implementaba una solución permanente en su entorno para que ese mismo error fuera estructuralmente imposible de ocurrir. Lo denominó “ingeniería del arnés”, en una frase similar a: cada vez que un agente cometa un error, tómese el tiempo de diseñar una solución para que nunca vuelva a cometerlo de esa manera.
• El 11 de febrero, OpenAI publicó una importante retrospectiva técnica sobre cómo desarrollar e implementar un producto sin código escrito a mano, lo que validó dicho concepto.
• En marzo, Anthropic publicó un seguimiento en el que describía una arquitectura completa de arnés con tres agentes, y Thoughtworks, Databricks, Red Hat, LangChain y otras empresas emitieron guías detalladas. El término ya se había popularizado.

Principios que perduran

1. El modelo propone, el motor de ejecución lo lleva a cabo. Nunca permita que el LLM invoque herramientas directamente. Esta separación es la base del diseño seguro de agentes.
2. Cada llamada a una herramienta genera un resultado, incluso cuando falla. Tanto el éxito como el rechazo de permisos o los tiempos de espera deben llegar al agente como observaciones estructuradas. El fallo silencioso es enemigo de la autonomía.
3. El riesgo modifica el proceso. Utilice al menos tres niveles: operaciones de solo lectura que se ejecutan de forma autónoma, borradores que simulan el trabajo sin efectos secundarios externos, y escrituras externas que requieren aprobación.
4. Reúna el contexto, no lo descargue todo de golpe. En lugar de incluir toda la conversación en cada turno, estructúrela en capas: políticas a nivel de sistema, instrucciones específicas para cada tarea y sugerencias en tiempo real obtenidas justo a tiempo. Etique como tal los datos no confiables.
5. Asigne presupuestos a las tareas largas. Cada bucle necesita límites en cuanto a pasos, tiempo real, tokens (por turno y de forma acumulativa) y costo en dólares.
6. Convierta los fallos recurrentes en características del sistema. Si una herramienta sigue devolviendo respuestas mal formadas, ajustar el prompt no es la solución adecuada. Escriba un validador dentro del sistema, donde deben realizarse las reparaciones permanentes.
7. Combine sensores computacionales e inferenciales. Los linters, verificadores de tipo y ejecutores de pruebas brindan retroalimentación rápida y fiable. La revisión de código por IA y el uso de LLM como juez abordan cuestiones semánticas que las herramientas deterministas no pueden resolver. Los equipos más exitosos dan prioridad a las restricciones deterministas, ya que ofrecen garantías.
8. Gestione la entropía. El código generado por IA acumula desorden con el tiempo, por lo que ejecute agentes de limpieza periódicos para mantener la consistencia de la documentación, realizar escaneos de violaciones de restricciones, aplicar normas de patrones y auditar dependencias.
9. Comience de forma sencilla. El consejo de Philipp Schmid es evitar flujos de control complejos y, en su lugar, proporcionar herramientas atómicas sólidas, dejar que el modelo elabore el plan y añadir medidas de seguridad, intentos repetidos y verificaciones. La lección dolorosa es que los pipelines que en 2024 requieren una codificación manual elaborada a menudo pueden gestionarse con una sola instrucción en 2026, por lo que los mecanismos de control deben construirse de tal manera que la lógica ingeniosa de ayer pueda eliminarse una vez que el modelo alcance ese nivel.

Tres pilares

Algunos profesionales organizan el trabajo en torno a tres pilares en lugar de seis componentes:

• Ingeniería de contexto: proporcionar al agente la información adecuada en el momento oportuno, combinando documentos estáticos con datos de observabilidad en tiempo real.
• Restricciones arquitectónicas: asegurar un buen código mediante máquinas, a través de dependencias en capas, herramientas de análisis de código, pruebas estructurales y ganchos de pre-commit.
• Gestión de entropía: limpieza programada para que los conjuntos de código escritos por IA no se deterioren.

Un truco económico con un gran efecto

LangChain informó que solo un cambio a nivel de herramientas incrementó su puntuación en Terminal Bench 2.0 del 52,8 % al 66,5 %, lo que significó pasar de estar fuera del top 30 al top 5. El cambio consistió en un enfoque de razonamiento en tres etapas: un alto esfuerzo de razonamiento para la planificación y verificación, y un esfuerzo medio para la implementación. El modelo permaneció sin modificaciones, lo que demuestra hasta qué punto pueden llegar los cambios únicamente en las herramientas. La profundidad de estas herramientas varía enormemente entre los mejores agentes de programación actuales.

Conclusión

La pregunta ha pasado de cómo formular mejor las instrucciones a qué sistema construir. El modelo ya no es el producto, sino el marco de soporte. Lo que diferencia una demostración controlada impresionante de un sistema en producción que funciona en el mundo real es precisamente ese marco de soporte, por lo que cualquiera que construya agentes en 2026 lo necesitará. Un primer paso práctico es auditar una configuración actual según los seis componentes y los nueve principios mencionados anteriormente, identificar las piezas faltantes y integrarlas en el marco de soporte.