Cuando un agente de IA falla en el paso de piloto a producción, la primera reacción suele ser mejorar el prompt o cambiar de modelo. Muchas veces la pregunta útil es otra: ¿por qué le estamos preguntando eso al modelo?
Esta pieza defiende una tesis sencilla de decir y difícil de aplicar: muchos agentes se complican porque le piden al modelo decisiones que ya tenían una regla. Diseñar un agente es decidir qué decide el modelo y qué decide el código. Va a código lo que se repite, tiene una única respuesta correcta o cuesta caro cuando sale mal; va al modelo lo que pide criterio, con una persona que decide donde hay riesgo.
Workflow o agente: dos extremos del mismo eje
En diciembre de 2024, Erik S. y Barry Zhang publicaron en Anthropic una distinción que se ha vuelto referencia. En un workflow, los modelos y las herramientas se orquestan por caminos de código predefinidos. En un agente, el modelo dirige su propio proceso y decide qué herramientas usar. Su recomendación de partida: buscar la solución más simple posible y añadir complejidad solo cuando haga falta.
El mismo texto pone nombre al intercambio. Los workflows dan previsibilidad y consistencia en tareas bien definidas; los sistemas agénticos suelen cambiar latencia y coste por un mejor resultado en la tarea. Ninguno de los dos es mejor en abstracto. Lo que importa es en qué punto de ese eje pones cada decisión, no cómo llamas al sistema entero.
Cuánto del bucle hacer determinista
Phil Winder lo formula de forma práctica en un artículo de octubre de 2026 sobre lo que aprendió construyendo agentes: un harness (el arnés que rodea al modelo) es un bucle con uno o varios modelos dentro, y su ingeniería consiste en decidir cuánto de ese bucle hacer determinista. Para decidirlo propone una pregunta: qué cuesta una respuesta equivocada y quién la detecta.
Su criterio para lo que va a código es concreto: los pasos que se repiten, que tienen una única respuesta correcta y que están en el centro del problema. El juicio, como entender qué quiso decir alguien o valorar si un argumento se sostiene, se queda en un modelo o en una persona. Uno de sus ejemplos: en un agente que navega menús telefónicos, pasar a código la elección de la siguiente opción redujo la exploración de un menú de prueba de 46 pasos a 6.
Dex Horthy llega al mismo sitio desde otro lado. En sus «12-Factor Agents» cuenta que muchos productos que se presentan como agentes son, sobre todo, código determinista con pasos de modelo puestos en los puntos justos. Uno de sus principios es literal: sé dueño de tu flujo de control.
| Si la decisión… | Va a | Qué necesita |
|---|---|---|
| Tiene una única respuesta correcta (un cálculo, un formato válido) | Código | Pruebas automáticas |
| Se repite igual en cada caso (una ruta de aprobación por importe) | Código | Que alguien la mantenga cuando cambie la regla |
| Cuesta caro si sale mal y nadie revisa cada salida | Código o una persona | Registro de quién decidió y por qué |
| Pide interpretar lo que alguien quiso decir | Modelo | Evals con casos de respuesta conocida |
| No encaja en ninguna regla conocida | Modelo, con salida a una persona | Una ruta de excepción |
Criterio elaborado por onext a partir de Phil Winder (2026) y Anthropic (2024)
Un ejemplo: revisar gastos de viaje
Un ejemplo ilustrativo, sin cliente detrás: un agente que revisa las notas de gastos de viaje de una empresa. Si todo se le pregunta al modelo, cada nota depende de cómo interprete el prompt ese día. Si se reparte, queda así:
- El modelo lee el ticket y extrae fecha, importe, proveedor y a qué tipo de gasto corresponde. Es lo ambiguo: tickets arrugados, idiomas, conceptos mal escritos.
- El código comprueba que el importe está dentro del límite de su categoría y que la factura tiene los datos fiscales obligatorios. Tiene una única respuesta correcta.
- El código decide quién aprueba según el importe. La política de la empresa ya lo dice; no hay nada que interpretar.
- Una persona recibe lo que no encaja: un gasto fuera de política, un ticket que el modelo no sabe clasificar con seguridad.
El modelo sigue haciendo el trabajo que solo él puede hacer, y lo que podía salir mal por una mala interpretación ya no depende de él. Qué recibe esa persona y en qué orden lo contamos en la ruta de excepción.
Cada decisión que se queda en el modelo hay que medirla. Cada decisión que pasa a código hay que mantenerla. Elegir dónde va cada una es elegir qué coste prefieres pagar.
Medir lo que decide el modelo significa tener evals: casos con respuesta conocida que se ejecutan en cada cambio, como explicamos en cómo construir un golden set y en evals en cada pull request. Y hay decisiones que no deberían depender del modelo por seguridad: qué herramientas puede usar y con qué permisos, como contamos en prompt injection y permisos de herramientas.
Más código no siempre es mejor
La tentación contraria también existe: escribir reglas para todo hasta que el agente es un programa rígido con un modelo de adorno. Winder recoge el argumento de Han Lee, que sostiene que buena parte del código del harness se disolverá en la siguiente generación de modelos. El consejo de Winder: añadir código al harness solo para corregir un fallo que ya has visto.
Los datos tampoco van en una sola dirección. El mismo artículo cuenta que, cuando el equipo de SWE-agent quitó el comprobador de sintaxis de la orden de edición de su agente, el porcentaje de problemas resueltos bajó del 18,0 % al 15,0 %. Una comprobación determinista bien puesta ayudaba al modelo, no lo sustituía.
Riesgo Una regla escrita también se equivoca: cuando cambia la política de la empresa y nadie actualiza el código, el agente aplica con total seguridad una norma que ya no existe. Pasar una decisión a código no la elimina; cambia quién tiene que vigilarla.
Lo que haríamos el lunes
Si tu agente está en piloto, hay un ejercicio que cabe en una mañana. Escribe en una tabla todas las decisiones que toma hoy el modelo, desde clasificar una entrada hasta decidir que ha terminado. Al lado de cada una, dos columnas: si tiene una regla clara y qué pasa cuando sale mal. Las que tienen regla y fallan a menudo son las primeras candidatas a pasar a código, empezando por las más baratas de escribir. Las que se quedan en el modelo son las que necesitan evals y una ruta de excepción antes de llegar a producción. Si el modelo que usas devuelve además una probabilidad junto a la decisión, puedes poner un umbral, como explicamos en el modelo que decide en vez de escribir.
Cómo lo planteamos en onext
Es el criterio con el que trabajamos en los proyectos de agentes: el modelo decide solo lo que necesita criterio, lo que tiene regla va a código con sus pruebas, y una persona decide donde hay riesgo. Lo que construimos se queda en tu equipo, también la lista de qué decide cada parte y por qué. Del piloto a producción, el resto del camino está en ingeniería de IA: del piloto a producción.
Preguntas frecuentes
¿Qué diferencia hay entre un workflow y un agente de IA?
Anthropic lo explica así: en un workflow, los modelos y las herramientas se orquestan por caminos de código predefinidos; en un agente, el modelo dirige su propio proceso y decide qué herramientas usar. No son dos categorías cerradas, sino los extremos de un mismo eje: casi todos los sistemas reales mezclan las dos cosas.
¿Qué decisiones de un agente deberían ir a código?
Las que se repiten, tienen una única respuesta correcta y están en el centro del problema: un cálculo, una validación de formato o una ruta de aprobación fija. Phil Winder lo resume en esa regla, y añade una pregunta para decidir cuánto hacer determinista: qué cuesta una respuesta equivocada y quién la detecta.
¿Y qué decisiones conviene dejar al modelo?
Las que piden criterio: entender qué quiso decir alguien, redactar una respuesta o clasificar un caso que no encaja en ninguna regla. Para esas decisiones hacen falta evals que midan cómo decide el modelo y una ruta de excepción para el caso dudoso, con una persona que decide donde hay riesgo.
¿Qué es el harness de un agente?
Phil Winder lo define como un bucle con uno o varios modelos dentro, y la ingeniería del harness como decidir cuánto de ese bucle hacer determinista. Es todo lo que rodea al modelo: el código que decide qué se le pregunta, qué herramientas tiene, qué se comprueba antes y después y qué pasa cuando falla.
¿Más código hace siempre más fiable un agente?
No. Una regla escrita también puede estar mal y hay que mantenerla cuando cambia el negocio. Winder recoge además el argumento de Han Lee: buena parte del código del harness se disolverá en la siguiente generación de modelos. Por eso recomienda añadir código solo para corregir un fallo que ya se ha visto.
¿Por dónde empiezo si mi agente ya está en piloto?
Haz la lista de las decisiones que toma hoy el modelo y marca las que tienen una regla clara o un error caro. Esas son las candidatas a pasar a código, empezando por las que fallan a menudo y son más baratas de escribir. Las que quedan en el modelo necesitan evals y una ruta de excepción antes de llegar a producción.
Fuentes
- Erik S. y Barry Zhang, «Building effective agents», Anthropic, 19 de diciembre de 2024.
- Phil Winder, «Harness Engineering: What We Learnt Building AI Agents», Winder.AI, 11 de octubre de 2026.
- Dex Horthy (HumanLayer), «12-Factor Agents», repositorio en GitHub (sin fecha de publicación visible; consultado el 18 de octubre de 2026).
- Las citas de fuentes en inglés están traducidas por onext. La tabla de criterios, el ejemplo de gastos de viaje (ilustrativo, sin cliente) y el ejercicio son elaboración propia de onext.
Bernat López es fundador y CEO de onext, boutique de IA. Acompaña a equipos de desarrollo y de producto a trabajar con IA con método —especificación antes de programar, una persona que decide donde hay riesgo y Spec-Driven Development— y aplica a su propia empresa lo que propone: onext funciona con su propio sistema agéntico.
LinkedIn →