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

Hay cinco palabras que la gente no para de repetir cuando habla de agentes. Context engineering, loop engineering, Jev engineering, harness engineering, 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: lo que tiene sobre el escritorio cuando le pides algo
• Loop (bucle): si sigue tu checklist 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
• Harness (entorno): su oficina. Las herramientas, las llaves y quién revisa su trabajo
• Evals (evaluaciones): la misma prueba 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 trabajo que antes implicaba contratar más gente. Lo repetitivo se lo lleva un agente que aguanta en producción, y tu equipo se queda con las decisiones. Así se ve en la práctica escalar sin sumar personal.

Para cada capa te voy a 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 simple 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 todos los demás y trabaja como un compañero de equipo, 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 define los pasos, hace el trabajo usando tus herramientas y publica el resultado en ese mismo hilo.

La configuración es simple. Solo tienes que agregar a Viktor a tu espacio de trabajo y aparecerá como participante, 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 papeles sobre el escritorio al empleado. Ponle ahí las tres páginas correctas y te responde en segundos. Ponle trescientas y la respuesta quedará enterrada en medio del montón. Se le va a pasar por alto.

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

Context engineering es decidir qué va sobre el escritorio y en qué lugar.

Cómo funciona

Más contexto no significa mejores respuestas. Pasado cierto punto, significa peores respuestas.

Stanford lo comprobó directamente. Dale a un modelo entre 20 y 30 documentos y 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.

Dos cosas explican esto:

• 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 o no.

El único mecanismo 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 detalle: la caché solo funciona si ese inicio es idéntico, byte por byte. Cambia un carácter cerca del principio y todo lo que viene después se cobra a precio completo. Por eso, el orden siempre es: primero lo estable, al final lo que cambia.

Cómo construirlo

Cada pieza de contexto va a uno de 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 timestamps al principio ni claves JSON en orden aleatorio.
2. Herramientas. No las agregues ni las quites a mitad de la conversación. Rompe la caché y deja al modelo llamando herramientas que ya no existen. Para restringir una herramienta en algún paso, bloquea la llamada pero conserva 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. Descarta el contenido, conserva 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 límite. Anthropic midió que 58 definiciones de herramientas consumían unos 55,000 tokens antes de que el usuario escribiera una sola palabra. Dejar que el modelo busque las herramientas en vez de cargarlas todas llevó a Opus 4 del 49 al 74 por ciento en su benchmark.

Por debajo de unas 20 herramientas, mantenlas cargadas. Por encima, pásate a búsqueda.

Un truco más para trabajos grandes: manda un subagente. Lee los 50 archivos en su propia ventana y te devuelve un resumen de una página. Tu contexto principal solo ve el resumen.

pic2. Qué entra en una llamada al modelo

Atajo

Viktor te quita casi todo este peso de encima, porque su contexto vive 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 solicitud de hoy.
• Fuentes conectadas. Con Notion, Google Drive o HubSpot conectado, dejas de pegar archivos en el chat. Nombras el documento o el registro y él lee la fuente. Es la regla del disco, resuelta por ti.
• 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 queda de tu lado:

• Escribe un brief corto de la empresa una sola vez: qué venden, quién compra, qué números importan, qué no debe hacer nunca.
• Una tarea por hilo, dejando claro en el primer mensaje qué significa "terminado".
• Si aprendió algo mal, borra su memoria desde la configuración en lugar de corregirlo en cada hilo.

2. Loop engineering

Definición

Puedes darle al empleado un checklist: abre el archivo, cambia la línea 12, guarda. O puedes darle un objetivo: haz que pase el test.

Con un objetivo, prueba algo, mira qué pasó y decide qué hacer después. El checklist es un workflow. El objetivo es un loop.

Cómo funciona

Un loop 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. Agrega el import, vuelve a ejecutar.
4. Un test sigue fallando. Lee ese error, corrígelo, vuelve a ejecutar.
5. Todo pasa. Detenerse.

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 siguen siendo un workflow. Tres pasos que eligió el modelo son un loop.

Usa un loop solo cuando no puedas escribir los pasos de antemano. Si puedes escribirlos, escríbelos. Un workflow es más barato, corre en paralelo y, cuando falla el paso cuatro, vuelves a correr el paso cuatro, no todo.

Los loops también son caros. Un agente usa aproximadamente cuatro veces los tokens de una sola llamada. Las configuraciones multiagente rondan las quince veces.

Cómo construirlo

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

1. Un objetivo con un "terminado" claro. No "arregla el bug". Sino: "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 reprobado: una suite de tests, un compilador, un linter. La investigación sobre autocorrección es consistente en esto: funciona con feedback externo real y falla cuando el modelo solo se revisa a sí mismo. Sin verificador no hay loop, solo gasto sin fin.
3. Una regla de parada. El verificador aprueba, o llegas al límite de turnos, o los últimos dos intentos dieron el mismo resultado.
4. Un presupuesto. De turnos y de dólares, ambos.

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 loop tiene tres ciclos como máximo. Si la confianza sigue por debajo del 50 por ciento tras tres intentos, toma el control un workflow fijo en Python.

Filtra primero, itera poco, ten un plan B.

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

Atajo

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

Las cuatro partes se mapean así:

• Objetivo. Te rebate los briefs incompletos y pregunta en lugar de adivinar. Aun así, define qué es "terminado". "Reporte de ingresos de la semana pasada, totales coinciden con Stripe, publicado en #finance antes de las 9am del lunes" le gana por mucho a "haz el reporte".
• Verificador. Marca los números que no cuadran antes de publicar. Hazlo más fuerte indicando contra qué fuente verificar: el total de Stripe, el conteo 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 tier de razonamiento define el precio de cada paso, y en tareas recurrentes la frecuencia importa. Un reporte 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 queda pausada hasta que la apruebes. Ese es tu workflow.

Todo lo abierto va a un hilo, y ese es tu loop. 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 en una pila, 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, más un puntaje 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. Los números que prometen son de 70 a 500 milisegundos frente a 3 a 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 las pruebas independientes apenas están llegando.

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

El puntaje de confianza tampoco es una probabilidad real tal cual viene. Trátalo como un ranking y define umbrales con tus propios 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 específica sobre cada elemento.
3. Seguro y rutinario: se resuelve barato. Etiquetado, ruteado o descartado.
4. Dudoso o 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 el camino caro

Antes de todo eso, prueba lo más obvio 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 línea base 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 publicado de Viktor, pero la idea aplica en dos lugares que tú controlas:

• El tier de razonamiento. Funciona con tres: Smart sobre Claude Opus, Balanced sobre Claude Sonnet a casi la mitad del costo, Ultra sobre Claude Fable al doble aproximadamente. Ordenar solicitudes o extraer un número no requiere el tier más alto.
• La puerta delante de él. Si quieres que maneje 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 correctas, un manual en la pared, un colega que revisa su trabajo y ninguna llave de la caja fuerte. En la segunda tiene una laptop y tu contraseña de administrador.

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

Agente = modelo + harness.

Cómo funciona

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

Se convirtió en su propia disciplina 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ó un puntaje de benchmark 6 puntos.
• LangChain congeló el modelo y movió el mismo benchmark 13.7 puntos cambiando únicamente el harness.
• Después ajustaron el harness alrededor de un modelo abierto diez veces más barato hasta que sacó 0.86 contra el 0.87 de Opus 4.8.

Ya no estás comprando un modelo. Estás comprando un modelo y un harness juntos.

Lo necesitas en el momento en que el agente toca algo real: un repo, 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 excepto una lista de permitidos. 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 córtelos en todo. Revisiones más lentas, como un segundo modelo revisando un diff, solo en lo que importa.
4. Permisos. Cuando los agentes piden aprobación, las personas aprueban 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 necesita ser largo. Cuatro líneas ya cambian el comportamiento:

1# AGENTS.md
2- Monorepo: /api (FastAPI), /web (Next.js), /jobs (cron)
3- Corre los tests con `make test`. Tienen que pasar antes de cualquier commit
4- Nunca edites /migrations a mano, usa `make migration`
5- El acceso a la DB es de solo lectura. Pregunta antes de cualquier cambio de esquema

Los hooks son la versión obligatoria de la misma idea. En Claude Code, un hook es un script pequeño que corre antes de llamar a una herramienta y puede bloquearla. "Nunca 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 scaffolding después de que una actualización del modelo lo volviera innecesario.

Relee 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 detrás 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 más. Si una herramienta no tiene conexión lista, él puede crearla.
• Guías. Skills. En lugar de escribir AGENTS.md tú mismo, grabas tu pantalla, él redacta el procedimiento y tú lo editas.
• Sensores. Marca los datos que no cuadran y cuestiona los briefs con piezas faltantes. Y cada paso queda en un hilo de Slack que tu equipo puede leer.
• Permisos. Los correos de clientes y los cambios financieros se pausan para 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 está hecha de las credenciales que le entregas. Recuerda el 93 por ciento y conéctalo con el menor acceso que requiera 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 repos 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 mejoró? Le haces la misma prueba que le hiciste el mes pasado y comparas.

Sin la misma prueba, cada cambio que haces es una apuesta. Los evals son esa prueba para tu agente: un conjunto de tareas donde ya conoces la respuesta correcta, que corres cada vez que cambias algo.

Cómo funciona

Hay dos tipos de revisiones:

• End to end. ¿La respuesta final salió bien? Te dice que el puntaje cambió, no por qué.
• De comportamiento. ¿Ocurrió algo específico? ¿Llamó a search antes de responder? ¿Hizo una pregunta aclaratoria cuando la solicitud era vaga? ¿Verificó antes de decir "listo"?

Las revisiones de comportamiento corren sobre el trace, el log de todo lo que hizo el agente, no solo sobre la respuesta final. La regla de Google es que esta suite termine en menos de cinco segundos, para poder correrla con cada cambio.

Si un modelo califica, eso es un juez, y el juez también necesita revisión. Airbnb descubrió que cerca de tres cuartos de sus respuestas de referencia generadas por modelo salían distintas 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, convierte cada caso en un test. Los golden sets de Airbnb corren de 50 a 100 ejemplos, y los fallos son obligatorios.
2. Escribe una revisión de comportamiento por caso. Un caso, una cosa que verificar.
3. Revisa a tu juez. Califica una muestra a mano y mira qué tan seguido coinciden tú y el modelo antes de confiar en él.
4. Muestrea producción. Airbnb extrae el 5 por ciento del tráfico en vivo todos los días. Tu set de evals se degrada a medida que el uso real se aleja de él.

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

1input: "Reembolsar pedido #1042, el cliente dice que llegó roto"
2expect:
3  - busca el pedido antes de responder
4  - pide aprobación antes de emitir el reembolso
5check:
6  - el trace tiene get_order antes de send_reply
7  - el trace tiene approval_request antes de refund

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

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

Atajo

Ningún producto puede entregarte esta capa lista, porque solo tú sabes cómo se ve la respuesta correcta para tu negocio. Pero el método se aplica directo:

• Después de dos semanas, elige 20 de sus hilos donde conozcas la respuesta correcta. Incluye todos aquellos donde tuviste que corregirlo.
• Escribe una revisión simple por caso. ¿Vinculó una fuente para cada número? ¿Preguntó cuando el brief era vago? ¿Se detuvo antes de que algo saliera de la empresa?
• Vuelve a correr el set después de cada cambio: una skill nueva, un brief editado, un tier distinto. Pasar de Smart a Balanced ahorra cerca de 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.

Armando todo

Cinco capas, cinco preguntas. Contexto es lo que ve. Loop es quién decide. Jev se encarga de las decisiones baratas. Harness es lo que puede alcanzar y quién lo revisa. Evals es cómo lo sabes.

Con Viktor, tres vienen prácticamente listas: contexto, loop y harness. Jev, los evals y las credenciales que le entregas siguen siendo tu 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.
• Loop: ponle un límite de turnos y un límite de dólares antes de dejarlo corriendo.
• Jev: etiqueta 200 ejemplos de lo que tu agente decida con más frecuencia.
• Harness: corre tu agente como un usuario que no pueda borrar nada.
• Evals: anota tus últimos cinco fallos como casos de prueba.

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

• Contexto: escribe el brief de la empresa y graba tu primera skill.
• Loop: incluye una definición de "terminado" en cada tarea y elige el tier 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 set de pruebas.

Eso 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 sumas capacidad sin sumar personal. La mayoría de los equipos debería tomar las tres primeras listas para usar y dedicar su propio 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. Link completo en mi primera respuesta.

Usa el código YARCHI100 al registrarte.

Alianza pagada