Los 5 niveles de los agentes de IA: del prompt a producción

Hoy en día hay cinco palabras que todo el mundo repite cuando habla de agentes: context engineering, loop engineering, Jev engineering, harness engineering y eval engineering.

Suenan como cinco enfoques que compiten entre sí. No lo son. Son cinco capas de un mismo sistema, y cada una responde a una pregunta distinta.

La forma más fácil de entenderlas es imaginar que acabas de contratar a un empleado nuevo:

• Contexto (Context) - qué tiene sobre el escritorio cuando le pides algo
• Bucle (Loop) - si sigue tu lista de verificación o decide por su cuenta cuál es el siguiente paso
• Jev - la recepción que clasifica el correo para que él solo vea lo importante
• Entorno (Harness) - su oficina. Las herramientas, las llaves y quién revisa su trabajo
• Evaluaciones (Evals) - el mismo examen todos los meses, para saber si realmente mejoró

Un agente de IA es ese empleado. El modelo es la persona, y estas cinco capas son todo lo que lo rodea. Si configuras bien estas cinco capas, un equipo pequeño puede asumir tareas que antes implicaban contratar más gente. El trabajo repetitivo pasa a un agente que aguanta en producción, y tu equipo se queda con las decisiones. Así es como se escala sin aumentar la plantilla en la práctica.

Para cada capa te explicaré qué es, cómo funciona, dónde usarla y cómo construirla.

Y para cada capa también preparé un atajo. Una forma más sencilla de lograr el mismo resultado sin construirlo desde cero, pensada para principiantes. Mis amigos de Viktor me ayudaron a armar estos atajos.

Viktor es un empleado de IA que vive en tu Slack o Microsoft Teams. Está en los mismos canales que el resto del equipo y trabaja como un compañero más, uno que sumas al equipo sin tener que abrir una nueva vacante.

Trabajar con él es igual que trabajar con una persona:

• Lo mencionas en un canal o hilo y le describes la tarea.
• Él deduce los pasos, hace el trabajo usando tus herramientas y publica el resultado en ese mismo hilo.

Configurarlo es muy simple. Solo tienes que añadir a Viktor a tu espacio de trabajo y aparecerá como un participante más, igual que cualquier otro miembro de tu equipo. Si quieres probarlo mientras lees, usa el código YARCHI100.

pic1. Las cinco capas de un agente

1. Context engineering

Definición

Antes de cada pregunta, le pones unos papeles en el escritorio al empleado. Si le dejas las tres páginas correctas, te responde en segundos. Si le dejas trescientas, la respuesta queda sepultada en medio del montón. Y no la encuentra.

El modelo es el empleado. El escritorio es la ventana de contexto: todo lo que el modelo ve antes de responder. Tus instrucciones, el historial del chat, los documentos extraídos de una base de datos, el resultado de cada herramienta que ejecutó.

El context engineering consiste en decidir qué va en el escritorio y en qué lugar.

Cómo funciona

Más contexto no significa mejores respuestas. A partir de cierto punto, significa peores respuestas.

Stanford lo comprobó directamente. Si le das a un modelo entre 20 y 30 documentos, su precisión con los que están en el medio cae a alrededor del 50 o 57 por ciento. Sin ningún documento, ese mismo modelo sacó un 56 por ciento. La respuesta estaba en la ventana y el modelo rindió peor que si no hubiera tenido nada.

Esto se debe a dos cosas:

• Los modelos prestan más atención al principio y al final de la ventana, y menos al medio.
• Cada token cuesta dinero y tiempo, sirva de algo o no.

El único mecanismo técnico que vale la pena conocer es el prompt caching. El proveedor guarda el inicio de tu prompt y lo reutiliza en la siguiente llamada, y un token en caché cuesta unas diez veces menos que uno nuevo.

El truco: la caché solo funciona si ese inicio es idéntico, byte por byte. Cambia un solo carácter cerca del principio y todo lo que viene después se cobra a precio completo. Por eso, la regla es siempre poner primero lo estable y dejar lo cambiante para el final.

Cómo construirlo

Cada fragmento de contexto va en uno de estos cuatro lugares:

1. System prompt. Solo lo que es cierto en cada llamada: rol, restricciones, formato de salida. Mantenlo idéntico byte por byte. Nada de marcas de tiempo al principio ni claves JSON en orden aleatorio.
2. Herramientas. No las añadas ni las quites a mitad de conversación. Rompe la caché y deja al modelo llamando a herramientas que ya no existen. Si necesitas restringir una herramienta en algún paso, bloquea la llamada pero mantén la definición.
3. Disco. Todo lo que sea grande o persistente va a un archivo, y en la ventana solo queda la ruta. Igual con una página web: conserva la URL, descarta el cuerpo. Tira el contenido, quédate con la clave que permite recuperarlo.
4. Cola. Cada pocos pasos, vuelve a plantear el objetivo actual cerca del final del contexto. No puedes arreglar el medio, así que mantén lo importante fuera de ahí.

Las herramientas también tienen un límite. Anthropic midió que 58 definiciones de herramientas consumían unos 55,000 tokens antes de que el usuario escribiera una sola palabra. Permitir que el modelo busque las herramientas en lugar de cargarlas todas hizo que Opus 4 pasara del 49 al 74 por ciento en su benchmark.

Si tienes menos de 20 herramientas, mantenlas cargadas. Si son más, pásate a la búsqueda.

Un truco más para tareas grandes: envía un subagente. Lee los 50 archivos en su propia ventana y te devuelve un resumen de una página. Tu contexto principal solo llega a ver ese resumen.

pic2. Qué entra en una llamada al modelo

Atajo

Viktor te quita casi todo este peso de encima, porque su contexto funciona a nivel de empresa.

• Memoria. Mantiene una memoria persistente de tu negocio para todo el equipo. Lo que aprendió de tu cofundador la semana pasada no tienes que pegarlo en tu petición de hoy.
• Fuentes conectadas. Con Notion, Google Drive o HubSpot conectados, dejas de pegar archivos en el chat. Nombras el documento o el registro y él lee la fuente. Es la regla del disco, pero ya resuelta.
• Skills. Grabas tu pantalla haciendo una tarea una sola vez. Él convierte la grabación en un procedimiento escrito, tú lo corriges y lo apruebas. A partir de ahí, esa instrucción queda fija y revisada, como un buen system prompt.

Lo que te toca hacer a ti:

• Redactar un breve resumen de la empresa una sola vez: qué vendes, quién compra, qué números importan y qué no debe hacer nunca.
• Una tarea por hilo, explicando en el primer mensaje qué significa "terminado".
• Si aprendió algo mal, borra su memoria desde los ajustes en lugar de corregirlo en cada hilo.

2. Loop engineering

Definición

Puedes darle al empleado una lista de verificación: abre el archivo, cambia la línea 12, guarda. O puedes darle un objetivo: haz que pase el test.

Con un objetivo, prueba algo, observa qué pasó y decide qué hacer después. La lista de verificación es un workflow. El objetivo es un bucle.

Cómo funciona

Un bucle son cuatro movimientos que se repiten: pensar, actuar, observar, decidir. Corregir un bug se ve así:

1. Ejecuta los tests. Tres fallan.
2. Lee el primer error. Falta un import.
3. Añade el import, vuelve a ejecutar.
4. Un test sigue fallando. Lee ese error, corrígelo, vuelve a ejecutar.
5. Todo pasa. Fin.

Nadie escribió esos pasos de antemano. El modelo eligió cada uno después de ver el resultado anterior.

Esa es toda la diferencia. Cien pasos que escribiste tú siguen siendo un workflow. Tres pasos que eligió el modelo son un bucle.

Usa un bucle solo cuando no puedas escribir los pasos de antemano. Si puedes escribirlos, escríbelos. Un workflow es más barato, se ejecuta en paralelo y, si falla el paso cuatro, vuelves a ejecutar el paso cuatro, no todo desde el principio.

Los bucles también son caros. Un agente usa aproximadamente cuatro veces más tokens que una llamada única. Las configuraciones multiagente multiplican por quince.

Cómo construirlo

Un bucle necesita cuatro partes. Quita cualquiera de ellas y deja de funcionar:

1. Un objetivo con un "terminado" claro. No "corrige el bug". Mejor: "el test que falla en auth_test.py pasa y nada más se rompió".
2. Un verificador. Algo externo al modelo que diga aprobado o suspendido: una suite de tests, un compilador, un linter. La investigación sobre autocorrección es clara en esto: funciona con feedback externo real y falla cuando el modelo solo se revisa a sí mismo. Sin verificador no hay bucle, solo gasto sin fin.
3. Una regla de parada. El verificador aprueba, o llegas al límite de turnos, o los dos últimos intentos dieron el mismo resultado.
4. Un presupuesto. Tanto de turnos como de dinero.

En código, todo cabe en unas pocas líneas:

1for turn in range(MAX_TURNS):
2    action = model.next_step(goal, history)
3    result = run(action)
4    history.append(result)
5
6    if checker(result):       break   # terminado
7    if repeated(history, 2):  break   # atascado
8    if spent() > BUDGET:      break   # demasiado caro
9else:
10    fallback_workflow(goal)

La mejor configuración para producción que he visto publicada es híbrida. Atlan aplica primero un filtro determinista, y solo alrededor del 14 por ciento de las alertas entrantes llegan siquiera al agente.

Después, el bucle tiene tres ciclos como máximo. Si tras tres intentos la confianza sigue por debajo del 50 por ciento, toma el control un workflow fijo en Python.

Filtra primero, itera brevemente y ten un plan B.

pic3. Cómo decidir entre un workflow y un bucle

Atajo

Cada tarea que le asignas a Viktor en un hilo es un bucle. Tú escribes el objetivo, él elige los pasos, trabaja con tus herramientas y vuelve al hilo con el resultado.

Las cuatro partes se aplican así:

• Objetivo. Te rebate los briefs incompletos y pregunta en lugar de adivinar. Aun así, define qué significa "terminado". "Informe de ingresos de la semana pasada, totales coincidentes con Stripe, publicado en #finance antes de las 9am del lunes" es mucho mejor que "haz el informe".
• Verificador. Señala los números raros antes de publicar. Refuérzalo indicando contra qué fuente comparar: el total de Stripe, el número de filas, la suite de tests.
• Regla de parada. Las acciones sensibles se pausan para que las revise un humano, y el resultado siempre vuelve a ti.
• Presupuesto. Créditos. El nivel de razonamiento define el precio de cada paso y, en tareas recurrentes, la frecuencia importa. Un informe horario cuesta muchísimo más que uno semanal.

El modelo híbrido de Atlan también funciona sin código. El trabajo que se repite se convierte en una tarea programada: él la propone y se queda pausada hasta que la apruebes. Ese es tu workflow.

Todo lo que sea abierto va a un hilo, y ese es tu bucle. Tú eres el plan B.

3. Jev engineering

Definición

El experto de una oficina no abre todos los sobres. Alguien en recepción clasifica el correo: facturas a un montón, spam a la basura, contratos al abogado.

Tu agente hace dos tipos de trabajo: redactar algo y decidir algo. Ahora mismo, un modelo grande hace ambas cosas, así que estás pagándole al abogado para que clasifique el correo.

Jev es la recepción. Nunca redacta. Solo elige.

Cómo funciona

Le das a Jev una pregunta y las posibles respuestas por adelantado. Devuelve una de tres cosas, junto con una puntuación de confianza:

• sí o no
• una opción de un conjunto
• un número en una escala

Como solo elige, es rápido y barato. Las cifras que prometen son de 70 a 500 milisegundos frente a 3 o 329 segundos, y $0.042 por millón de tokens de entrada con la salida gratis.

Ahora, la parte honesta. Jev tiene dos semanas de vida y apenas empiezan a llegar pruebas independientes.

• En clasificación de correos, una regresión logística básica logró un 98.9 por ciento frente al 98.6 de Jev.
• En detección de phishing, Jev alcanzó un 62.6 por ciento mientras que Claude Haiku 4.5 llegó al 81.3.
• La cifra de "cero alucinaciones" viene con la nota al pie de los propios autores: no es empírica, solo significa que la salida siempre coincide con el esquema.

La puntuación de confianza tampoco es una probabilidad real tal cual sale de la caja. Trátala como un ranking y define tus propios umbrales con tus datos etiquetados.

Cómo construirlo

La configuración sensata es una puerta delante del modelo caro:

1. Entra todo.
2. Jev responde una pregunta muy concreta sobre cada elemento.
3. Si hay confianza y es rutinario: se resuelve barato. Etiquetado, enrutado o descartado.
4. Si hay dudas o es inusual: va al modelo principal.

1d = jev.choose(item, options=["spam", "order_status", "refund", "other"])
2
3if d.confidence >= 0.7 and d.option != "other":
4    handle_cheap(d.option, item)
5else:
6    main_model(item)   # fail closed: lo dudoso va por la vía cara

Antes de todo eso, prueba lo más simple que podría funcionar. Etiqueta unos cientos de ejemplos reales, entrena un clasificador básico y sube de nivel solo si no es suficiente.

Son treinta minutos de trabajo, y es la referencia que cualquier promesa de un proveedor tiene que superar.

pic4. Los tres tipos de preguntas que responde Jev

Atajo

Jev no forma parte del stack oficial de Viktor, pero la idea se aplica en dos lugares que tú controlas:

• El nivel de razonamiento. Funciona con tres: Smart en Claude Opus, Balanced en Claude Sonnet a casi la mitad de precio, y Ultra en Claude Fable al doble. Clasificar peticiones o extraer un número no requiere el nivel más alto.
• La puerta delante de él. Si quieres que gestione un flujo como correos de soporte o alertas, no le entregues todo el flujo. Pon primero un clasificador o una llamada a Jev, para que solo los elementos que requieren criterio se conviertan en tareas para él.

Esta es una de las dos capas donde tu propio trabajo de ingeniería sigue importando, incluso con Viktor.

4. Harness engineering

Definición

Mismo empleado, dos oficinas. En la primera tiene las herramientas adecuadas, un manual en la pared, un compañero que revisa su trabajo y ninguna llave de la caja fuerte. En la segunda tiene un portátil y tu contraseña de administrador.

Mismas habilidades, resultados muy distintos. El empleado es el modelo. La oficina es el entorno (harness).

Agente = modelo + harness.

Cómo funciona

El harness es todo lo que no es el modelo: herramientas, permisos, el sandbox, los archivos que explican el proyecto, las revisiones de la salida.

Se convirtió en una disciplina propia en 2026 porque la gente empezó a medir, y el modelo explicaba menos de lo esperado:

• Anthropic cambió solo los recursos del contenedor y movió la puntuación de un benchmark 6 puntos.
• LangChain congeló el modelo y movió el mismo benchmark 13.7 puntos cambiando únicamente el harness.
• Luego ajustaron el harness alrededor de un modelo abierto diez veces más barato hasta que sacó 0.86 frente al 0.87 de Opus 4.8.

Ya no compras solo un modelo. Compras un modelo y un harness juntos.

Lo necesitas en cuanto el agente toca algo real: un repositorio, una bandeja de entrada, un pago, una base de datos de producción.

Cómo construirlo

Construye de afuera hacia adentro:

1. Contención. Lo que el agente físicamente no puede alcanzar. Un contenedor, una rama separada, un usuario de base de datos de solo lectura, sin red salvo una lista blanca. Haz esto antes del primer prompt.
2. Guías. Lo que lo orienta antes de actuar. Un archivo en el repo como AGENTS.md, descripciones de herramientas lo bastante claras para que el modelo elija la correcta, algunos ejemplos de buenos resultados.
3. Sensores. Lo que lo revisa después de actuar. Linter, verificador de tipos, suite de tests: rápidos y deterministas, así que úsalos en todo. Revisiones más lentas, como un segundo modelo analizando un diff, solo en lo que importa.
4. Permisos. Cuando los agentes piden aprobación, la gente aprueba el 93 por ciento de las veces. El aviso de aprobación no protege casi nada. La protección real son las acciones que simplemente no están disponibles. Guarda la aprobación para las pocas cosas que son verdaderamente irreversibles.

Un archivo de guía no tiene que ser largo. Cuatro líneas ya cambian el comportamiento:

1# AGENTS.md
2- Monorepo: /api (FastAPI), /web (Next.js), /jobs (cron)
3- Run tests with `make test`. They must pass before any commit
4- Never edit /migrations by hand, use `make migration`
5- DB access is read only. Ask before any schema change

Los hooks son la versión obligatoria de esta misma idea. En Claude Code, un hook es un pequeño script que se ejecuta antes de llamar a una herramienta y puede bloquearla. "No hagas push a main" funciona como hook, no como una línea en el prompt.

Una advertencia. Cada pieza de tu harness es una apuesta a que el modelo no puede hacer algo, y esas apuestas caducan. Anthropic eliminó un componente entero de su scaffolding después de que una actualización del modelo lo volviera innecesario.

Revisa tu harness cada pocos meses y borra lo que el modelo ya superó.

pic5. Los cuatro anillos de un harness

Atajo

Si agente = modelo + harness, casi todo lo que obtienes con Viktor es harness. El modelo que lleva debajo es Claude. Todo lo que rodea al modelo viene listo:

• Herramientas. Más de 3,200 integraciones: GitHub, Linear, HubSpot, Stripe, Notion, Google Drive y muchas más. Si una herramienta no tiene conexión lista, él mismo puede crearla.
• Guías. Skills. En lugar de escribir tú AGENTS.md, grabas tu pantalla, él redacta el procedimiento y tú lo editas.
• Sensores. Señala los datos que no cuadran y cuestiona los briefs con piezas faltantes. Y cada paso queda registrado en un hilo de Slack que tu equipo puede leer.
• Permisos. Los correos de clientes y los cambios financieros se pausan para pedir aprobación. Las nuevas automatizaciones programadas quedan pausadas hasta que alguien las active.

La parte que ningún producto puede construir por ti es la contención, porque depende de las credenciales que tú le entregues. Recuerda ese 93 por ciento y conéctalo con el acceso mínimo necesario para el trabajo:

• un usuario de base de datos de solo lectura
• una clave de Stripe restringida
• una bandeja de soporte compartida, no la tuya personal
• un token de GitHub limitado a repositorios específicos

Lo que no puede tocar, no lo puede romper.

pic6. El harness de Viktor

5. Evals engineering

Definición

¿Cómo sabes que un empleado nuevo ha mejorado? Le haces el mismo examen que el mes pasado y comparas.

Sin el mismo examen, cada cambio que haces es una suposición. Los evals son ese examen para tu agente: un conjunto de tareas del que ya conoces la respuesta correcta, que ejecutas cada vez que modificas algo.

Cómo funciona

Hay dos tipos de comprobaciones:

• End to end. ¿La respuesta final salió bien? Te dice que la puntuación cambió, pero no por qué.
• De comportamiento. ¿Ocurrió algo específico? ¿Llamó a search antes de responder? ¿Hizo una pregunta aclaratoria cuando la petición era ambigua? ¿Verificó antes de decir que había terminado?

Las comprobaciones de comportamiento se ejecutan sobre el trace, el registro de todo lo que hizo el agente, no solo sobre la respuesta final. La regla de Google es que esta suite debe terminar en menos de cinco segundos, para poder ejecutarla con cada cambio.

Si un modelo es el que califica, eso es un juez, y el juez también necesita revisión. Airbnb descubrió que cerca de tres cuartas partes de sus respuestas de referencia generadas por modelos variaban al repetir la ejecución con el mismo input. Su eval estaba midiendo su propio ruido.

Cómo construirlo

1. Empieza por los fallos reales. Revisa ejecuciones reales, encuentra qué salió mal y convierte cada caso en un test. Los conjuntos dorados de Airbnb manejan de 50 a 100 ejemplos, e incluir fallos es obligatorio.
2. Escribe una comprobación de comportamiento por caso. Un caso, una cosa que verificar.
3. Revisa a tu juez. Califica una muestra a mano y comprueba cada cuánto coinciden tú y el modelo antes de confiar en él.
4. Muestrea producción. Airbnb extrae el 5 por ciento del tráfico real todos los días. Tu conjunto de evals se degrada a medida que el uso real se aleja de él.

Un solo caso puede ser así de pequeño:

1input: "Refund order #1042, customer says it arrived broken"
2expect:
3  - looks up the order before replying
4  - asks for approval before issuing the refund
5check:
6  - trace has get_order before send_reply
7  - trace has approval_request before refund

No te fijes solo en la tasa de aprobación general. Puede subir mientras un comportamiento específico se rompe en silencio. Vigila las comprobaciones individuales.

pic7. De dónde salen los buenos casos de eval

Atajo

Ningún producto puede entregarte esta capa hecha, porque solo tú sabes qué aspecto tiene la respuesta correcta para tu negocio. Pero el método se aplica directamente:

• Después de dos semanas, elige 20 de sus hilos en los que conozcas la respuesta correcta. Incluye todos aquellos en los que tuviste que corregirlo.
• Escribe una comprobación sencilla por caso. ¿Citó una fuente para cada número? ¿Preguntó cuando el brief era ambiguo? ¿Se detuvo antes de que algo saliera de la empresa?
• Vuelve a pasar el conjunto tras cada cambio: una nueva skill, un brief editado, un nivel distinto. Pasar de Smart a Balanced ahorra casi la mitad de los créditos, así que pruébalo antes de cambiarlo definitivamente.
• Una vez por semana, califica a mano cinco hilos al azar.

Juntándolo todo

Cinco capas, cinco preguntas. El contexto es lo que ve. El bucle es quién decide. Jev se encarga de las decisiones baratas. El harness es lo que puede alcanzar y quién lo revisa. Los evals son cómo lo sabes.

Con Viktor, tres vienen prácticamente integradas: contexto, bucle y harness. Jev, los evals y las credenciales que le entregas siguen siendo tu trabajo de ingeniería.

Si empiezas hoy, el movimiento útil más barato para cada una:

• Contexto: mueve tus instrucciones estables al system prompt y deja de cambiarlas.
• Bucle: ponle un límite de turnos y un límite de dólares antes de dejarlo funcionando.
• Jev: etiqueta 200 ejemplos de lo que tu agente decida con más frecuencia.
• Harness: ejecuta tu agente como un usuario que no pueda borrar nada.
• Evals: anota tus últimos cinco fallos como casos de prueba.

Con Viktor, ese mismo día se ve así:

• Contexto: escribe el resumen de la empresa y graba tu primera skill.
• Bucle: incluye una definición de "terminado" en cada tarea y elige el nivel a propósito.
• Jev: filtra cualquier flujo antes de que se convierta en tareas para él.
• Harness: conéctalo con credenciales de solo lectura y alcance limitado.
• Evals: guarda 20 hilos reales como tu primer conjunto de pruebas.

Es un día de trabajo y cubre las cinco.

Mi opinión: el modelo ya no es la parte difícil. Lo difícil son las cinco capas que lo rodean. Configúralas bien y sumarás capacidad sin sumar personal. La mayoría de los equipos debería tomar las tres primeras ya hechas y dedicar su tiempo a las dos que definen la calidad: las decisiones baratas y los evals.

Gracias a Viktor por patrocinar este artículo.

Pruébalo gratis en @viktor_com. $100 en créditos, sin tarjeta. Enlace completo en mi primera respuesta.

Usa el código YARCHI100 al registrarte.

Colaboración pagada