Prompt engineering para agentes de IA

¿Qué es el prompt engineering para agentes de IA?

El prompt engineering para agentes designa la disciplina de ingeniería con la que un agente de IA muestra de forma consistente el comportamiento deseado a lo largo de varios turnos de inferencia. Mientras que el prompt engineering clásico (2022–2023) consistía en redactar una única cadena de instrucciones ingeniosa, en un agente la ventana de contexto ya no es un texto estático, sino un estado del sistema compuesto de forma dinámica: prompt de sistema, definiciones de herramientas, resultados de herramientas, historial de la conversación, fragmentos RAG recuperados, notas de scratchpad y estado estructurado.

Andrej Karpathy describió este cambio el 25 de junio de 2025 como Context Engineering, «the delicate art and science of filling the context window with just the right information for the next step», apenas una semana después de que el CEO de Shopify, Tobi Lütke, popularizara el término. Anthropic lo formalizó el 29 de septiembre de 2025 en «Effective context engineering for AI agents» como «la evolución natural del prompt engineering». Un matiz importante para situarlo: el Context Engineering engloba el prompt engineering, no lo sustituye. Un buen prompt de sistema sigue siendo condición necesaria; solo que ya no es suficiente.

Esta página central ofrece una visión general de los cinco componentes clave: prompts de sistema, descripciones de herramientas, bucles de planificación (ReAct), gestión de la ventana de contexto y evaluación.

Arquitectura del prompt de sistema

El prompt de sistema es la única parte del contexto que un agente ve en cada turno; es código: versionado, revisable y comparable mediante diff. En 2026, los prompts de sistema en producción se estructuran de forma consistente en cuatro capas:

Anthropic recomienda separar estas secciones con etiquetas XML o encabezados Markdown; el modelo interpreta los prompts estructurados con mayor fiabilidad. A la longitud adecuada Anthropic la llama «the right altitude»: los informes de profesionales convergen en 500–3.000 tokens para el núcleo (sin esquemas de herramientas). Los dos extremos perjudican: con prompts demasiado largos, de 47 reglas numeradas, el modelo aplica con menos frecuencia las últimas reglas (Lost-in-the-Middle dentro de su propio prompt de sistema); los prompts demasiado vagos («Eres un asistente útil») dejan demasiado en manos de la inferencia del modelo.

Un cambio central afecta a las reglas absolutas: la guía de OpenAI para GPT-5 (2026) advierte explícitamente que ALWAYS/NEVER solo deben usarse para invariantes reales; «for judgment calls, such as when to search, ask for clarification, use a tool, or keep iterating, prefer decision rules instead». En equipos de la región DACH (Alemania, Austria y Suiza) hay que hacer además dos cosas: fijar siempre de forma explícita el idioma de respuesta (de lo contrario, los modelos frontier tienden por defecto al inglés con contenido técnico) y fijar también la forma de tratamiento (Sie/Du) para evitar derivas de estilo dentro del bucle.

Descripciones de herramientas: donde fallan de verdad los agentes

Cuando un agente en producción actúa mal, según la propia experiencia de ingeniería de Anthropic la causa «en la mayoría de los casos» no está en el modelo, sino en la definición de la herramienta. La pregunta guía es: «If a human engineer can't definitively say which tool should be used in a given situation, an AI agent can't be expected to do better.»

Lo decisivo es que las descripciones de herramientas forman parte del presupuesto del prompt. Cada herramienta añade 100–300 tokens «always-on»; un catálogo de 10 herramientas cuesta 1.000–3.000 tokens por llamada. El componente más eficaz, y el que más se olvida, es la cláusula de cuándo no usarla: si search_web y query_internal_db coexisten, esta cláusula decide qué herramienta se elige. El solapamiento de herramientas, es decir, dos herramientas que podrían responder de forma plausible a la misma consulta, es el único problema que ningún prompt resuelve, por bueno que sea.

La evidencia empírica es clara. Con la herramienta tool_search de Anthropic y defer_loading: true para las herramientas poco usadas, la precisión en la selección de herramientas en evals internas de MCP subió en Opus 4 del 49 % al 74 % y en Opus 4.5 del 79,5 % al 88,1 % (Anthropic, noviembre de 2025), con un ahorro de tokens de alrededor del 85 %. A partir de unas 10 herramientas activas empieza una degradación medible. Por eso el patrón de producción es 3–7 herramientas siempre cargadas más Tool Search para el resto. La ejecución de código con MCP sigue otro camino: el agente se comunica con los servidores MCP mediante código y solo carga las definiciones de herramientas cuando las necesita.

Otras convenciones contrastadas: nombres verbo-sustantivo (get_user, send_email), descripciones a nivel de campo con su semántica, formatos de retorno y modos de fallo documentados, herramientas orientadas a la búsqueda en lugar de herramientas que lo listan todo, y límites estrictos de tokens en la respuesta (valor orientativo de Anthropic: ~25.000 tokens por retorno de herramienta). Práctica habitual en DACH: nombres de herramientas y parámetros en inglés (interoperabilidad), descripciones en el idioma en que trabaja el agente en tiempo de ejecución.

Bucles de planificación: ReAct y sus sucesores

La planificación es la estructura del bucle de decisión de un agente. En 2026 dominan cuatro patrones, con compromisos claros:

ReAct intercala razonamiento y acción (Thought → Action → Observation) y es la opción por defecto fiable para modelos sin razonamiento. Con los modelos de razonamiento el panorama cambia: el Interleaved Thinking (Anthropic Claude con Extended Thinking, serie o de OpenAI/GPT-5) permite al modelo replanificar entre llamadas a herramientas y, con ello, condensa muchas implementaciones clásicas de «ReAct-in-a-loop» en una sola llamada a la API. En la práctica, los agentes en producción usan híbridos: un bucle ReAct con un paso de planificación explícito al principio y verificación antes de acciones irreversibles.

Una terminación disciplinada es la salvaguarda más importante; los bucles infinitos fueron la clase de bug de producción más frecuente en 2025–2026. Los bucles fiables combinan un máximo de iteraciones (límite estricto, típicamente 10–30 en general, 50–100 para programación), un criterio de éxito (p. ej., una herramienta submit_final_answer), límites de coste, detección de estados repetidos contra el tool thrashing y una vía de escalado a una persona.

Gestión de la ventana de contexto

En 2026 hay ventanas de contexto largas disponibles (Claude Opus y Gemini, hasta 1M de tokens cada uno), pero no se pueden aprovechar de manera uniforme. El estudio «Context Rot» de Chroma (julio de 2025, 18 modelos frontier) lo demuestra: todos los modelos se degradan a medida que aumenta la longitud de la entrada. Tres mecanismos se refuerzan entre sí: Lost-in-the-Middle (Liu et al., Stanford/TACL 2024; los modelos prestan atención al principio y al final, y poca al medio), la dilución de la atención y la interferencia de distractores. Como heurística, la capacidad efectiva se sitúa en el 30–50 % de la nominal para tareas intensivas en razonamiento y en el 60–80 % para tareas intensivas en recuperación. Si llenas por completo una ventana de 1M, desperdicias tokens y empeoras la calidad.

Lance Martin (LangChain) acuñó para ello la taxonomía canónica de cuatro pilares, que han adoptado Anthropic y Manus:

• Write: persistir la información fuera de la ventana (scratchpads, todo.md, almacén de memoria)
• Select: traer los tokens adecuados en cada paso (RAG, filtrado de herramientas, despacho a subagentes)
• Compress: conservar solo los tokens relevantes para la tarea (resúmenes, Context Editing de Anthropic)
• Isolate: repartir el contexto entre subagentes y campos de esquema

Tres palancas dominan la economía. El Prompt Caching es la más importante: las lecturas de caché de Anthropic cuestan el 10 % de la tarifa de entrada estándar, y menos en algunos modelos actuales (a octubre de 2026: 5 % en Opus 5.5 y Sonnet 5.5, 2,5 % en Fable 5.1 y Mythos 5.1). OpenAI cobra también el 10 % en la familia GPT-5, el 25 % en GPT-4.1 y el 50 % en GPT-4o. Un estudio de arXiv (febrero de 2026, «Don't Break the Cache») mide en cargas de trabajo agénticas unos costes de API entre un 41 y un 80 % menores y un time-to-first-token entre un 13 y un 31 % más corto gracias a un control estratégico de los bloques de caché. La poda elimina turnos antiguos y resultados de herramientas obsoletos. La compactación comprime al llegar al 70–85 % de la capacidad, en Claude Code por ejemplo mediante /compact. Según Anthropic, así se conservan «architectural decisions, unresolved bugs, and implementation details» y se descartan los outputs redundantes de herramientas. El despacho a subagentes funciona como primitiva de compactación: un subagente explora en su propia ventana y devuelve solo un resumen de 1.000–2.000 tokens.

Evaluación: si no mides, no has hecho nada

La conclusión más cruda para los tech leads es esta: los cambios de Context Engineering se validan con evals, no con intuición. El consejo más citado de Hamel Husain, «Look at your data», significa en concreto: leer entre 50 y 100 trazas reales de producción, etiquetar los fallos libremente, agruparlos en una taxonomía, escribir para cada modo frecuente una eval de código o una eval LLM-as-Judge e integrarlas en CI y monitorización.

Eso sí, Husain advierte contra el desarrollo puramente eval-first: «Write evaluators for errors you discover, not errors you imagine.» El término medio practicable empieza con una pequeña eval end-to-end (10–50 tareas representativas), itera y construye sub-evals específicas para modos de fallo reales. Una conclusión aleccionadora y demostrada empíricamente: muchos consejos de prompting populares («Eres un experto», «Think step by step», «I'll tip you $200») muestran en evals rigurosas una mejora mínima o nula; en los modelos de razonamiento, «think step by step» ya es el comportamiento por defecto y, añadido a mano, a menudo resulta contraproducente.

Estar listo para producción significa: las evals se ejecutan automáticamente con cada cambio en el contexto, las herramientas o el retrieval; la eval de PR (20–50 tareas) bloquea el merge, la eval previa al despliegue (200–2.000 tareas) bloquea el despliegue y la eval posterior al despliegue sobre trazas de producción se encarga de detectar la deriva. Forzar salidas estructuradas cierra el círculo: OpenAI Structured Outputs en modo estricto (disponible de forma general desde agosto de 2024) y Structured Outputs de Anthropic con uso estricto de herramientas (desde noviembre de 2025) imponen la conformidad con el esquema mediante decodificación restringida y sustituyen el antiguo «parsear el JSON y cruzar los dedos». La documentación de Anthropic menciona expresamente las excepciones: rechazos, cortes al alcanzar el límite de tokens y, en ocasiones, mayúsculas y minúsculas distintas en valores enum y const.

Contexto DACH y cumplimiento normativo

Para los equipos DACH se suman tres restricciones de ingeniería estrictas. Primero, la tokenización del alemán: los sustantivos compuestos y la flexión generan entre un 30 y un 50 % más de tokens que el inglés para un contenido equivalente. Así, una ventana de 200K solo admite tanto contenido en alemán como el que en inglés cabría en unos 130–150K tokens. Eso implica costes más altos, pero también un mayor ROI del caching, porque el descuento de la caché se aplica a un número mayor de tokens.

Segundo, la disciplina RGPD en la ventana de contexto: los datos personales no deben entrar en ella sin filtrar. Los patrones habituales son la seudonimización antes de inyectar el contexto (resolver los nombres reales solo en la capa de herramientas), una capa de redacción de PII antes de la inyección RAG y un reseteo auditable del estado de sesión. Tercero, el registro según el art. 12 del Reglamento de IA para sistemas de alto riesgo: con el ómnibus de IA (Reglamento (UE) 2026/1744), se aplica a los sistemas del anexo III a partir del 2 de diciembre de 2027 y a los productos del anexo I a partir del 2 de agosto de 2028. Para los equipos suizos, el RGPD y el Reglamento de IA solo se aplican si hay vínculo con la UE. El RGPD se aplica, según el art. 3, apartado 2, cuando el equipo ofrece bienes o servicios a personas en la UE o hace un seguimiento de su comportamiento. El Reglamento de IA se aplica, según el art. 2, cuando el equipo introduce sistemas de IA en el mercado de la UE o cuando su output se utiliza en la UE. A nivel nacional rige desde el 1 de septiembre de 2023 la Ley Federal de Protección de Datos revisada (revDSG). Esta clasificación es informativa y no constituye asesoramiento jurídico. En términos de ingeniería, la obligación de registro implica que la versión del prompt de sistema, la versión del catálogo de herramientas, los documentos recuperados (o sus ID + hashes), el input del usuario, las llamadas a herramientas, los resultados de las herramientas y el output final deben persistirse de forma auditable y, al mismo tiempo, borrable conforme al RGPD, idealmente por cada llamada a herramienta con un ID de correlación de ejecución.

Perspectivas y consejo práctico

En 2026, el prompt engineering para agentes no es folclore ni un simple cambio de nombre, sino la respuesta al paso de las llamadas one-shot a bucles agénticos de varias etapas. Si construyes un agente para producción, ya practicas esta disciplina; la única pregunta es si lo haces de forma consciente y reproducible o inconsciente y frágil. Varios campos siguen en movimiento y conviene leerlos como una «instantánea actual»: las convenciones de los modelos de razonamiento, la heurística multiagente frente a agente único (el trabajo en paralelo con mucha lectura funciona, con mucha escritura no) y los frameworks de optimización de prompts como DSPy, que sirven para subtareas acotadas, pero que todavía no constituyen un estándar de producción para bucles de agente completos.

Empezar en la práctica no tiene nada de dramático y está bien documentado: sacar el prompt de sistema del playground del proveedor y versionarlo en Git, validar el esquema de cada output, activar el Prompt Caching en las partes estables, fijar límites de coste estrictos y leer cada semana 20 trazas reales. El principio rector de Anthropic resume el objetivo completo con más precisión que cualquier debate sobre herramientas: «Find the smallest set of high-signal tokens that maximize the likelihood of your desired outcome.» Eso es ingeniería. Y después: look at your data.