Prompt, Contexto, Mecanismos de Aprovechamiento, Bucles: Las cuatro capas que subyacen a un agente de IA

Una pregunta frecuente al inicio: si un modelo de chat es simplemente palabras de entrada y palabras de salida, ¿cómo logran los agentes de IA reservar vuelos o escribir código? La respuesta se presenta en cuatro niveles, y cada uno existe porque el nivel inferior no puede explicar por sí solo el funcionamiento de un agente. Una forma breve de comprenderlos: un buen prompt sin contexto es como una frase dicha en una habitación vacía. Un buen contexto sin un marco de referencia es como un plan perfecto sin manos para llevarlo a cabo. Un marco completo sin un mecanismo de retroalimentación es como un trabajador hábil que sigue esperando a que alguien le diga “ahora, la siguiente tarea”.

Nivel uno: el prompt

La unidad de trabajo aquí es una sola entrada. El modelo no recuerda nada de antes de la llamada, por lo que el prompt debe contener todo lo necesario: un rol, contexto, instrucciones, ejemplos y un formato de salida, todo incluido en un único mensaje. Cuando los resultados son decepcionantes, la clave está en identificar qué elemento falla y no en reescribir todo.

La caja de herramientas es amplia:

• El prompt de tipo “zero-shot” hace la solicitud directamente sin ejemplos, confiando en que el modelo lo entienda.
• El prompt de tipo “few-shot” proporciona dos o tres ejemplos de entrada-salida, y el modelo busca patrones en ellos.
• El método “Chain-of-thought” pide al modelo que razone paso a paso primero, lo cual puede ser de gran ayuda en problemas de matemáticas, lógica y de múltiples partes.
• El prompt basado en roles, como “eres un editor senior” o “eres un revisor escéptico”, cambia el tono y el nivel de rigor.
• La inducción de metas y la autoconsistencia se basan en estos principios para problemas más difíciles.

Todo esto se resume en buenas instrucciones, algo similar a un correo electrónico claro, y responde a una pregunta concreta: ¿qué palabras se deben usar en este momento para esta solicitud específica? Una instrucción bien redactada para un resumen de investigación puede generar resultados precisos, con una estructura clara y sin elementos innecesarios.

La debilidad aparece con preguntas posteriores. Si se pregunta algo en la misma conversación que hace referencia a un punto tres mensajes atrás, el modelo podría pasarla por alto por completo y responder con confianza a una pregunta ligeramente diferente. No recuerda el contexto en el que se encuentra. Resulta que una buena oración es necesaria pero no suficiente, y falta algo en la fase previa a la instrucción.

¿Por qué no seguir escribiendo prompts mejores? Porque la ingeniería de prompts fue creada para tareas puntuales: preguntar, responder, listo. Una vez que el objetivo implica acciones en múltiples pasos, recordar eventos, usar herramientas o funcionar sin que una persona escriba cada instrucción, la frase ingeniosa deja de ser el cuello de botella. El cuello de botella se convierte en todo lo demás. La creación de prompts sigue siendo importante. Simplemente deja de ser lo único importante.

Capa dos: contexto

Aquí, la unidad de trabajo es lo que permanece dentro de la ventana del modelo en cada paso. La ventana es finita, mientras que la información disponible no lo es, por lo que la curaduría se vuelve esencial. Sin ella, los detalles importantes quedan ocultos bajo resultados obsoletos de herramientas y conversaciones antiguas, y la atención del modelo disminuye. Un curador decide qué se mantiene, comprime lo que es útil pero voluminoso y descarta el resto. La habilidad radica en saber qué descartar, no en incluir más contenido.

La habitación en la que se encuentra el modelo tiene un nombre: contexto. Eso significa todo lo que el modelo ve en una llamada específica, no solo el prompt: instrucciones del sistema, documentos recuperados, definiciones de herramientas, historial de conversaciones, memoria a largo plazo y resultados anteriores de las herramientas. La ingeniería de contexto puede resumirse como la selección cuidadosa de lo que ve el modelo para obtener un mejor resultado. El prompt determina qué palabras utilizar, mientras que la ingeniería de contexto se ocupa de saber qué conoce el modelo en ese momento exacto.

Una analogía del sector de la construcción ayuda a entenderlo. Al contratar a un contratista por un día, se puede entregarle una orden de trabajo redactada perfectamente, pero sin el plano del edificio, el historial de permisos y las notas de la inspección de ayer, esa redacción no servirá de nada. El contratista hará lo incorrecto con total confianza. Eso refleja el fallo anterior: el modelo no era tonto, solo estaba insuficientemente informado. La mayoría de los fallos de los agentes se deben a problemas de contexto, no al modelo en sí. El modelo funciona bien, pero nadie le proporcionó el plano del edificio.

La solución obvia es proporcionarle todo: la conversación completa, cada documento, cada interacción anterior. Cuanta más información, mejor respuesta. Los expertos descubrieron lo contrario y le dieron un nombre: deterioro por contexto. Incluso los modelos con ventanas muy grandes empeoran de manera notable cuando estas se llenan de material apenas relevante. El modelo no se queda sin espacio; la señal se pierde entre el ruido y los detalles irrelevantes comienzan a tratarse como importantes. La mejor instrucción es proporcionar la carpeta adecuada y no todo el archivador. La disciplina en una sola frase es la curaduría sobre la acumulación: decidir qué entra en el “cuarto” y, igual de importante, qué queda afuera.

Incluso con una habitación perfectamente planificada, rápidamente surge una segunda pared. Un contexto impecable genera un plan excelente para seguir, pero luego el modelo simplemente se detiene. No puede abrir el archivo, ejecutar el código ni verificar si el plan funcionó. Es como tener al contratista con un plano perfecto pero sin manos.

Tercera capa: el arnés

La unidad de trabajo ahora es la máquina en sí. Un modelo básico solo genera texto. El arnés lo convierte en algo capaz de actuar, verificar su propio trabajo y recuperarse de los fallos, a través de tres fases:

• Reunir: juntar todo lo necesario.
• Actuar: ejecutar el modelo, llamar a herramientas o subagentes.
• Verificar: comprobar el resultado mediante pruebas o un evaluador.

En caso de fallo, todo el ciclo se vuelve a intentar con un contexto actualizado. Esa diferencia es lo que distingue a la llamada a una API de la ejecución de un agente.

Una fórmula útil: agente = modelo + arnés. Todo lo que rodea al modelo cuenta como arnés, es decir, el código, la configuración y la lógica de ejecución. Esto incluye las herramientas a las que se puede acceder, la memoria legible y escribible, los límites en las acciones permitidas, la orquestación que elige el siguiente paso y el estado que perdura más allá de una sesión.

La palabra en sí es adecuada. Un caballo es poderoso, pero sin un arnés no puede trabajar en la granja, ya que las correas y las riendas dirigen su fuerza bruta hacia tareas útiles. Sustituyamos al caballo por un modelo: este tiene inteligencia, pero sin herramientas, memoria, medidas de seguridad y orquestación, esa inteligencia no tiene a dónde ir.

Un punto cambia por completo la perspectiva. El arnés no hace que el modelo sea más inteligente. Si se reemplaza el modelo por uno mejor, el arnés sigue siendo el mismo, ya que se trata de un componente intercambiable en su interior y no del elemento principal. Lo que aporta es estructura: un modelo inteligente que no tiene estado propio se convierte en un componente dentro de un sistema cerrado que toma acciones, verifica los resultados y continúa exactamente desde donde terminó hoy.

Eso también explica qué significa cuando una IA parece recordar algo entre sesiones. El modelo no está recordando; el sistema de soporte lo anotó en algún lugar y se lo devolvió más tarde. Cada llamada al modelo comienza desde cero, y el sistema de soporte simula la continuidad al recuperar las notas del día anterior, la lista de tareas del día actual y el estado del sistema de archivos, entregándolo todo como contexto antes de que el modelo empiece a pensar. Por lo tanto, la ingeniería de contexto y la ingeniería del sistema de soporte están estrechamente vinculadas, ya que el sistema de soporte decide qué contexto se debe compilar en cada llamada.

Capa cuatro: el bucle

Un modelo con herramientas y memoria parece ser la cima. ¿Qué más podría necesitar un agente? Un ritmo cardíaco. La ingeniería de bucles es la capa más reciente, a la que aún se le está dando nombre a medida que la desarrollan.

Aquí está la brecha. Incluso con un arnés completo, alguien debe seguir sentado frente al teclado decidiendo qué hará el agente a continuación: escribir una instrucción, leer el resultado, elegir la siguiente instrucción y repetir. Eso implica la intervención humana en cada paso, siempre.

La ingeniería de bucles reemplaza este intercambio manual por un sistema que impulsa el ciclo por sí mismo: pensar, actuar, observar lo que ocurrió, elegir el siguiente paso y repetir, sin que ninguna persona tenga que volver a escribir las instrucciones. Esto se asemeja a la diferencia entre conducir un automóvil y tener un control de velocidad automático; la persona ya no presiona el acelerador cada segundo, sino que ha definido qué significan la velocidad de crucero y la detención.

Un ejemplo concreto ayuda a comprenderlo. Un agente asignado a corregir un error lee el mensaje de error, elabora un plan, modifica el código y ejecuta el conjunto de pruebas. Como las pruebas siguen fallando, ajusta su enfoque, vuelve a modificar el código y ejecuta las pruebas nuevamente. Solo cuando las pruebas pasan, o cuando ha intentado suficientes veces y concluye que está atascado, acude a un humano. Cada uno de esos ciclos constituye el bucle, y nadie escribe “intenta de nuevo” en medio de ellos.

¿Qué puede salir mal? Un bucle que funciona sin supervisión también puede repetir el mismo error, más rápido, sin que nadie se dé cuenta durante un tiempo. Por eso, los diseños cuidadosos incluyen un sistema de evaluación dentro del bucle: un punto de control, ocasionalmente un segundo modelo que actúa como juez, que califica los resultados según una rúbrica. Solo después de superarla puede el bucle considerar que la tarea está completada. Una vez que ya no hay nadie que supervise cada paso, la verificación deja de ser opcional y pasa a formar parte de las funciones del bucle.

Los cuatro juntos

La instrucción consiste en decirle a alguien qué hacer, una sola vez. El contexto se encarga de que tenga la carpeta adecuada sobre su escritorio antes de comenzar. El arnés le proporciona manos, herramientas y una memoria que perdura hasta el fin de semana. El bucle significa que ya no es necesario estar mirando por encima de su hombro: trabaja, verifica su propio resultado, lo intenta de nuevo si está incorrecto, y solo viene a buscarlo cuando realmente está terminado.

Cuatro preguntas superpuestas, cada una sin respuesta de la anterior. Juntas, forman lo que hoy en día la gente simplemente llama un agente, como si fuera obvio y siempre fuera a ser tan sencillo. No lo era. Cada capa se hizo clara solo porque alguien siguió preguntando por qué hasta que se revelaron los límites de la capa anterior.

Leer más

• Prompt, Contexto, Harness, Bucle: Las cuatro capas para diseñar un agente de IA — Cuatro capas anidadas determinan el comportamiento de un agente. Conozca qué controla cada una, un ejemplo práctico de triaje en GitHub y por qué debe construir primero los componentes Harness y Bucle.
• Notas prácticas: Su agente de programación no necesita un prompt mejor — Guía paso a paso de las Notas prácticas: Su agente de programación no necesita un prompt mejor: contratos, verificaciones y espacios para código listos para usar para los equipos que implementan este patrón.