Ingeniería de prompts, contexto, aprovechamiento y bucles: las cuatro capas de un agente de IA
La ingeniería de prompts y la ingeniería de contexto abarcan dos de las cuatro capas. Lo que controlan la ingeniería de harness y loop, un ejemplo de triaje en GitHub, y el orden de compilación.
Fuentes: Prompt, context, harness, loop: the four layers of engineering an AI agent
A mediados de 2025, el CEO de Shopify, Tobi Lütke, escribió que la verdadera habilidad al trabajar con LLMs no era en absoluto la ingeniería de prompts, sino proporcionar suficiente contexto para que la tarea pudiera resolverse de manera plausible. Andrej Karpathy estuvo de acuerdo, calificándolo como un oficio que implica incluir precisamente la información adecuada en la ventana de contexto para lo que haga a continuación el modelo. Poco después, el término “ingeniería de contexto” reemplazó a “ingeniería de prompts” en la mayoría de las discusiones serias sobre el desarrollo basado en LLMs.
Un año después, los equipos que desarrollan agentes de programación autónomos, bots para la triaje de problemas y pipelines de despliegue autoreparables siguen chocando contra el mismo obstáculo. La ingeniería de contexto resultó ser solo una de las cuatro capas que componen el problema. De la más específica a la más general, las capas son el prompt, el contexto, la infraestructura y el ciclo, y cada una envuelve a la capa que está dentro de ella. Las dos externas, la ingeniería de infraestructura y la ingeniería de ciclo, reciben la menor atención, lo cual es extraño, ya que ahí radica ahora la mayor parte de los beneficios.
Imagínelo como cuatro preguntas. ¿Cómo está redactada la solicitud? Eso es el prompt. ¿Qué sabe ya el modelo al iniciarse? Eso es el contexto. ¿Qué puede hacer realmente una vez en funcionamiento? Eso es la infraestructura. ¿Y cuándo, y con qué frecuencia, lo llaman? Eso es el ciclo. Hoy en día, la mayor parte de los beneficios reales se encuentran en el ciclo, una capa que hace apenas un año apenas tenía nombre.
Lo que sigue es un marco de trabajo para diferenciar las capas, además de un orden de construcción. Supone que ya has realizado llamadas a herramientas o funciones a través de una API de LLM. Si no es así, comienza por ahí.
En la práctica se observa un patrón que explica por qué este marco es útil. Cuando el resultado del agente es decepcionante, la solución casi nunca está en el prompt; casi siempre se encuentra en una capa superior.
Capa 1: el prompt, o lo que dices
La ingeniería de prompts es la capa más específica y se ocupa de una sola cosa: cómo se redacta una instrucción para el modelo.
Ejemplos: cómo se redacta un prompt de sistema, cómo se presenta un ejemplo de few-shot, si solicitas razonamiento paso a paso o una deliberación cuidadosa, y si la respuesta debe devolverse en formato JSON o como texto libre. Se trata del arte de escribir un mensaje que haga que el modelo haga lo que deseas en su siguiente turno.
El trabajo es real. La precisión en una misma tarea puede diferir enormemente entre una instrucción vaga y una precisa. Tomemos como ejemplo en funcionamiento a un agente de triaje para un proyecto de GitHub. Un prompt débil se ve así:
Look at this GitHub issue and label it.
Y uno preciso:
You are a triage agent for project X. For each issue, output JSON with:
component (one of the values in the taxonomy provided in context)
severity (critical | high | medium | low)
team (the owning team from the on-call table provided in context)
Base severity only on user-facing impact stated in the issue, not on your
own guess about difficulty. If the component is ambiguous, set
"component": "unknown" rather than guessing.
El modelo, las herramientas y todo lo demás son idénticos, pero el segundo prompt genera un resultado estructurado y defendible. Sin embargo, hay que fijarse en lo que se da por sentado: se ejecuta en un solo turno de una sola llamada. Presume que la taxonomía y la tabla de agentes ya están cargadas, que las herramientas existen, y que algo más decide cuándo se invoca al modelo.
La mayoría de los tutoriales se detienen en este punto. La mayoría de los sistemas de agentes en producción apenas están comenzando aquí.
Capa 2: el contexto, o lo que sabe el modelo
La ingeniería de contexto abarca todo lo que ingresa al sistema antes de que el modelo analice tu prompt. Se encuentra antes del proceso de elaboración del prompt. Incluso un prompt impecable produce resultados erróneos cuando el contexto es incorrecto.
Eso incluye qué documentos, archivos de código o registros de base de datos se recuperan e insertan, qué esquemas de herramientas se cargan y cuáles se dejan de lado para guardar tokens, cuánta historia de conversación se mantiene en comparación con la que se resume o se descarta, y qué indican las instrucciones del sistema sobre el papel y los límites del modelo.
Drew Breunig catalogó las formas en que falla el contexto en 2025. La intoxicación por contexto ocurre cuando una alucinación entra en el marco de referencia y sigue siendo citada una y otra vez. La distracción por contexto se da cuando un marco de referencia excesivamente largo hace que el modelo dependa de él y descuide lo que aprendió durante el entrenamiento. La confusión por contexto ocurre cuando material irrelevante reduce la calidad de las respuestas. El conflicto por contexto surge cuando herramientas o hechos recién añadidos contradicen las instrucciones existentes.
El contexto también cuesta dinero, y su codificación afecta el costo total. TOON, una codificación compacta del modelo de datos JSON, supuestamente utiliza aproximadamente un 42,6% menos de tokens que JSON en su propio conjunto de pruebas a mediados de 2026, con una precisión de recuperación cercana al 72,2% frente al 71,4% de JSON. El ahorro depende de la estructura de los datos: en datos tabulares planos, la reducción alcanza casi el 59%; en datos anidados mixtos, se acerca al 33%; y el formato CSV puro puede superar a ambos cuando los datos son completamente planos. Estas son las cifras proporcionadas por el propio proyecto, por lo que conviene verificarlas con sus propios datos. La conclusión es que un mismo conjunto de información, expresado en tres formatos diferentes, varía en precio y en la fiabilidad con la que se puede recuperar. La ingeniería de contexto implica elegir no solo qué incluir, sino también cómo codificarlo.
Una breve ilustración muestra cómo sucede esto. Imagine un agente de generación de artículos que sigue produciendo resultados genéricos. Se pasan dos días reescribiendo la instrucción, añadiendo ejemplos y restricciones, y definiendo con más precisión el papel del agente, pero nada cambia. El problema nunca estuvo en la instrucción. Se cargan treinta esquemas de herramientas en el contexto desde el principio, lo que eclipsa las instrucciones relevantes. Al pasar a un sistema de carga diferida, en el que la definición solo aparece cuando el agente la solicita, se mejora la calidad sin cambiar ni una palabra de la instrucción. Se perdieron dos días en el nivel equivocado.
Mientras que la ingeniería de instrucciones se ocupa de elegir las palabras, la ingeniería de contexto se encarga de determinar qué podrá ver el modelo antes de que usted diga algo.
Nivel 3: el entorno de ejecución, o lo que puede hacer el modelo
El entorno de ejecución es el ambiente ejecutable alrededor del modelo: todo a lo que puede acceder y todo lo que interactúa con él.
La conocida guía de Anthropic sobre cómo crear agentes eficaces introdujo la idea de una interfaz agente-computadora, deliberadamente similar a la interfaz humano-computadora. Su argumento es que se debe invertir tanto esfuerzo en diseñar cómo un agente trabaja con herramientas como la industria lo hace en cómo los humanos trabajan con software.
Aquí hay una definición simplificada de herramienta del ejemplo de triaje:
{
"name": "apply_label",
"description": "Apply a label to a GitHub issue. Only use after reading the issue body and checking the component taxonomy.",
"parameters": {
"type": "object",
"properties": {
"issue_number": { "type": "integer" },
"labels": { "type": "array", "items": { "type": "string" } }
},
"required": ["issue_number", "labels"]
}
}
El campo description se encarga del contexto. Limita cuándo el modelo utiliza la herramienta, no solo qué argumentos pasa. Pero el esquema representa la mitad del conjunto de herramientas.
La otra mitad reside en el orquestador, que envuelve la herramienta en elementos que el modelo nunca ve. Una puerta de aprobación decide si apply_label se ejecuta automáticamente o se coloca en cola para ser procesado por una persona. Un límite de frecuencia, por ejemplo 60 escrituras de etiquetas por hora, evita que un bucle descontrolado sobrecargue el repositorio. Un límite de entorno confina lo que la herramienta puede acceder. Estos envoltorios dan forma al comportamiento sin necesidad de modificar el prompt del sistema.
Un conjunto de herramientas también incluye:
- Sistema de archivos. Qué archivos puede abrir, editar, crear o eliminar el modelo.
- Memoria. Cómo se almacenan y recuperan las informaciones a lo largo de las interacciones, como registros de correcciones, decisiones anteriores y convenciones del proyecto.
- Feedback. La vía por la cual los resultados, el texto de error y el estado del entorno llegan al siguiente paso.
- Límites de seguridad. Permisos, aislamiento y controles de aprobación.
Si se proporcionan herramientas adecuadas a una instrucción promedio, generalmente superará el rendimiento de una instrucción brillante pero sin herramientas. Un agente que no puede abrir el archivo que necesita no se beneficia en nada de una redacción mejor. Primero, asegúrese de contar con las herramientas necesarias.
Capa 4: el bucle, o lo que lo convierte en un agente
La ingeniería de bucles es el mecanismo que hace que un agente sea autónomo. Actúa, observa el resultado, decide qué hacer a continuación y continúa hasta que se cumple un objetivo o se activa una condición de parada, sin necesidad de intervención humana en cada paso. Esta capa transforma a un chatbot que utiliza herramientas en algo capaz de resolver problemas por sí solo.
Aquí está la misma idea en pseudocódigo. Es ilustrativo y no es ejecutable: se han omitido ayudantes como model.decide y execute.
def agent_loop(goal, max_iterations=10):
context = gather_initial_context(goal)
consecutive_errors = 0
for i in range(max_iterations):
action = model.decide(context, goal)
if action.type == "done":
return action.result
result = execute(action)
if result.error:
consecutive_errors += 1
if consecutive_errors >= 3:
# stuck: same approach keeps failing, decompose differently
context.add("Previous approach failed 3 times. Try a different strategy.")
consecutive_errors = 0
else:
consecutive_errors = 0
context.add(result)
return escalate_to_human(context)
Unas pocas líneas contienen las decisiones importantes: cuándo detenerse, cuándo cambiar de estrategia y cuándo rendirse. OpenAI integró este patrón en un producto al añadir la orden /goal a Codex CLI en abril de 2026. Se establece un objetivo y el sistema sigue iterando hasta que considera que dicho objetivo se ha cumplido o se agota el presupuesto de tokens.
Un bucle simple vuelve a intentarlo hasta que algo funciona. Uno bien diseñado se da cuenta de que está atascado, descompone el problema de manera diferente, solicita ayuda humana o abandona el enfoque fallido. El diseñador Matt Webb comentó en marzo de 2026 que un agente al que se le da un problema y un bucle while eventualmente lo resolverá. La palabra “eventualmente” es clave en la ingeniería: presupuestos de intentos, retrasos tras fracasos repetidos y estrategias de descomposición para cuando una sola pasada se estanca.
Esa es la razón por la cual esta capa representa el cambio más significativo en términos de poder. Con la ingeniería de prompts, una persona escribe cada instrucción. Con la ingeniería de contexto, una persona decide qué ve el modelo en cada llamada. Con la ingeniería de herramientas, una persona crea las herramientas una sola vez y el modelo las reutiliza indefinidamente. La ingeniería de bucles es diferente en naturaleza: una persona diseña un sistema que envía prompts al modelo, evalúa el resultado y lo vuelve a llamar sin que nadie más esté presente. El control pasa de quien envía los prompts al agente a quien diseñó el sistema que los genera.
Jon Udell propuso a mediados de 2026 una forma de enmarcar este tema que vale la pena recordar: le disgusta la expresión “humano en el bucle” porque atribuye autoridad a las máquinas, cuando en realidad sigue siendo nuestro bucle y ahora reclutamos agentes para que se unan al equipo.
Las cuatro capas en un solo agente: triaje de problemas en GitHub
Imagínese a un agente que trabaja en nuevos problemas de GitHub para un proyecto de código abierto de tamaño medio: etiquetando el componente, evaluando su gravedad y enviándolo al equipo adecuado.
- Indicación. La indicación del sistema le ordena encontrar el componente afectado, clasificar su gravedad de crítica a baja, asignar el equipo correcto y responder con JSON estructurado.
- Contexto. Para cada decisión, el sistema proporciona el título y el cuerpo del mensaje, los cinco comentarios más recientes, la taxonomía del componente (un archivo YAML revisado cada tres meses), problemas similares anteriores con sus etiquetas (obtenidos mediante búsqueda vectorial como ejemplos) y la persona de turno.
Cada 100 casos, el sistema compara su precisión con las correcciones realizadas por humanos y ajusta sus umbrales. En un sistema similar, se informa que el umbral de confianza tuvo que comenzar en 0.85 y no en el valor supuesto de 0.7, ya que las etiquetas incorrectas generaban más trabajo para los humanos que las que se pasaban por alto. Ese tipo de calibración forma parte de la ingeniería de bucles: solo se puede determinar mediante la ejecución del sistema y la observación de sus errores a lo largo del tiempo.
Si se elimina cualquier capa, el sistema falla de manera diferente. Sin instrucciones, el formato de salida es una suposición. Sin contexto, se inventan nombres para los componentes. Sin herramientas adecuadas, puede decidir qué hacer pero no puede etiquetar ni buscar. Sin bucles, lo que queda es un asistente que solo actúa cuando alguien escribe “triage this issue” en una ventana de chat, uno por uno.
De dónde proviene el vocabulario
El término “ingeniería de prompts” data de 2022. Riley Goodside propuso dividirlo en ingeniería de contexto y programación de prompts en 2023, pero el vocabulario solo se consolidó después de que Lütke y Karpathy utilizaran “ingeniería de contexto” en junio de 2025, y Simon Willison explicara por qué era una denominación más adecuada.
“Harness” y “scaffolding” pasaron a usarse de forma habitual gracias al trabajo de Anthropic en agentes eficaces, lo cual formalizó la interfaz agente-computadora y trató el diseño de herramientas como una ingeniería de primer nivel.
La ingeniería de bucles es la más reciente de las cuatro, y nadie la acuñó. Surgió de la convergencia de varios esfuerzos: el bucle orientado a objetivos de OpenAI en Codex, la distinción hecha por Anthropic entre flujos de trabajo (rutas fijas) y agentes (bucles dirigidos por el modelo), la escalabilidad de LangChain desde un enrutador hasta una máquina de estados y finalmente un agente autónomo, además de la práctica cada vez más extendida de que el ser humano diseña el bucle y se mantiene al margen de sus pasos individuales.
La división en cuatro capas aquí presentada es una síntesis de ese uso convergente y no constituye un estándar de la industria. No obstante, nombrar las capas acelera el diagnóstico. Preguntarse si un problema se debe a la instrucción, al contexto, al mecanismo de aprovechamiento o al bucle reduce inmediatamente el campo de búsqueda.
Dónde invertir primero
Las capas se enumeraron de la más específica a la más general, pero se construyen primero de forma más general, o mejor dicho, comenzando por el mecanismo de aprovechamiento. Para un primer agente de programación autónomo, el orden es el siguiente.
- Marco de trabajo. Debe permitir la lectura y escritura de archivos, acceso a la shell, una forma de ejecutar pruebas y comandos de git. Un agente que no programa recibe en su lugar llamadas a API, consultas a bases de datos o mensajes; la idea es idéntica.
- Bucle. Incluso uno sencillo ayuda: ejecutar, verificar si las pruebas pasan, devolver el error si no es así, y detenerse después de tres intentos o al lograr éxito. Esto por sí solo aporta la mayor parte de los beneficios de la autonomía.
- Contexto. Al observar cómo funciona el agente en su bucle, se podrá ver qué le falta, ya sea código, errores anteriores o convenciones del proyecto. Adivinarlo de antemano suele ser una pérdida de tiempo.
- Preguntas guía. Con un marco de trabajo y un bucle funcionales, las preguntas necesarias suelen ser breves y sencillas. Para entonces, la parte más compleja de la ingeniería ya se ha resuelto en otro lugar.
Hay una excepción. Si el agente debe generar una salida con un formato preciso, como JSON estructurado para una API o convenciones específicas de Markdown, es importante trabajar temprano en las instrucciones, ya que es difícil corregir problemas de formato dentro del bucle. Eso es un caso especial, no la norma general.
Los principiantes suelen invertir el orden: pasan semanas diseñando instrucciones complejas para el sistema, mientras el agente aún no cuenta con herramientas, no tiene bucles y tiene los archivos incorrectos en su contexto.
Pasar de las instrucciones a la ingeniería del contexto implica reconocer que el material proporcionado al modelo es más importante que la forma en que se formula la solicitud. Avanzar hacia la ingeniería de aprovechamiento y bucles implica aún más: quien construye el sistema que rodea al modelo tiene más poder que quien interactúa con él.
Leer más
- Engineering de Contexto Agente: Una Guía Paso a Paso para Ingenieros de ML: Cómo diseñar lo que ve un agente LLM en cada paso: recuperación, contexto estructurado, memoria, compresión y evaluación, con un ejemplo de un agente de depuración de ML.
- De Zero-Shot a Autoconsistencia: Una Escalera Práctica de Técnicas de Prompting: Cómo elegir entre prompting de tipo zero-shot, few-shot, descomposición, bucles de crítica y razonamiento, con un ejemplo de un bot de soporte, y cuándo es mejor dejar la tarea al código puro.