Ingeniería de contexto: agentes de IA que no pierden el rumbo

Cuando un agente funciona en una demostración, pero pierde el rumbo al trabajar de verdad, conviene revisar qué información recibe el modelo antes de añadir más instrucciones. La ingeniería de contexto permite controlar 5 entradas en cada paso: instrucciones, herramientas, datos recuperados, memoria e historial. El objetivo es aportar pruebas suficientes para tomar la siguiente decisión correcta, sin arrastrar información irrelevante.

¿Qué es la ingeniería de contexto?

La ingeniería de contexto consiste en decidir qué ve un modelo cuando toma su siguiente decisión. Abarca la instrucción que escribiste, las herramientas que puede elegir, las pruebas que devuelven esas herramientas, los recuerdos que cargas y la conversación que conservas.

La ventana de contexto de un modelo es su espacio de trabajo para una solicitud. Un token es una unidad de texto u otro contenido que procesa el modelo. Un documento guardado en algún lugar del sistema es información disponible; su contenido solo pasa a formar parte del contexto activo cuando la aplicación o el agente lo carga.

Esta diferencia explica un fallo habitual en producción. Un agente puede tener acceso a la política correcta y aun así responder basándose en una conversación antigua, porque la política vigente no llegó al modelo en el momento de decidir. Del mismo modo, cargar todas las políticas puede introducir excepciones ajenas al caso y versiones obsoletas.

En su artículo de ingeniería del 29 de septiembre de 2025, Anthropic describe esta labor como «seleccionar y mantener el conjunto óptimo de tokens (información) durante la inferencia de un LLM». Distingue entre redactar instrucciones y gestionar el conjunto más amplio de información que se aporta durante la ejecución. Artículo de Anthropic sobre ingeniería de contexto.

El artículo de LangChain del 2 de julio de 2025 lo describe como «llenar la ventana de contexto con la información justa en cada paso del recorrido de un agente». Organiza el trabajo en escribir, seleccionar, comprimir y aislar: guardar el estado útil, recuperar el material pertinente, acortar lo que se conserva y separar las investigaciones independientes. Artículo de LangChain sobre ingeniería de contexto.

En la práctica, cambia lo que hay que diseñar. Un prompt puede permanecer fijo. La siguiente solicitud de un agente cambia cada vez que lee un archivo, recibe el resultado de una herramienta, completa una subtarea o descubre que una suposición anterior era incorrecta. Hace falta un criterio para componer esa solicitud a lo largo de toda la tarea.

Documentación verificada el 13 de octubre de 2026: el comportamiento de las herramientas que se describe a continuación se contrastó con la documentación vigente de Anthropic y OpenAI. El ejemplo desarrollado ilustra un diseño; no es una prueba de rendimiento en producción.

Ingeniería de contexto e ingeniería de prompts: ¿en qué se diferencian?

La ingeniería de prompts mejora la instrucción; la ingeniería de contexto mejora toda la solicitud que la rodea. Ambas siguen siendo necesarias.

En un agente de programación, la ingeniería de prompts podría sustituir «arregla el registro» por «averigua por qué los reintentos de registro envían correos de bienvenida duplicados; propone una corrección mínima y una prueba de regresión». La ingeniería de contexto decide entonces qué archivos de registro de usuarios, logs de reintentos, reglas del proyecto y hallazgos anteriores recibe el agente antes de proponer esa corrección.

Una instrucción impecable no compensa haber cargado los logs del entorno equivocado. Un fragmento de log bien elegido tampoco compensa una instrucción que no aclara si el agente debe diagnosticar, editar o desplegar.

La habilidad clave: decidir los límites del contexto

Para cada dato, decide cuándo debe entrar en el contexto y cuándo puede salir. Las reglas permanentes del proyecto, el estado temporal de la tarea y las pruebas sin procesar necesitan plazos de conservación distintos.

Una convención de programación corresponde a las instrucciones persistentes. «La rama de reintentos sigue sin probarse» corresponde al resumen para retomar la tarea actual. La respuesta completa de un proveedor debe quedar en un archivo de pruebas accesible, y sus campos pertinentes se cargan cuando influyen en la decisión.

Por eso la generación aumentada por recuperación, o RAG, es solo una parte del trabajo. RAG recupera material de apoyo para un modelo. Todavía hay que elegir las instrucciones, las herramientas, el historial que se conserva y el contenido que devuelve esa recuperación.

Ingeniería de contexto para agentes de IA: técnicas principales

Empieza por la mayor fuente de contexto irrelevante en el paso que falla. No introduzcas todos los mecanismos a la vez. Un agente de depuración saturado de logs necesita una primera corrección distinta de la de un asistente que olvida continuamente las restricciones del proyecto.

Compacta el historial en torno a decisiones, no solo a temas

Claude Code, el agente de programación de Anthropic, ofrece /context para inspeccionar el uso del contexto y /compact para acortar una conversación. Su gestión automática elimina los resultados antiguos de las herramientas y, si hace falta, resume después la conversación. La documentación advierte expresamente que pueden perderse instrucciones detalladas de mensajes anteriores. Gestión del contexto en Claude Code.

Dale un propósito a la compactación. En la investigación del correo de bienvenida, usa /compact Preserve the current goal, change boundaries, relevant file paths, observed evidence, failed hypotheses, and the next unresolved question. Es un comando con indicaciones específicas para la tarea, no una garantía de que se conservarán todos los detalles.

Antes de continuar, comprueba que el resumen siga distinguiendo entre lo observado, lo inferido y lo que no se ha comprobado. «Se investigaron los reintentos de correo» solo identifica un tema. «Se sabe que el proveedor aceptó el envío; falta inspeccionar la ruta de confirmación local» describe un estado que permite avanzar.

La compactación pierde información. Mantén accesibles las pruebas originales y conserva las reglas permanentes en las instrucciones del proyecto, para que un paso posterior pueda recuperar el detalle que necesite.

Recupera las pruebas cuando hagan falta

Consulta la fuente que responde a la siguiente pregunta y amplía la búsqueda solo si el resultado no basta. El artículo de ingeniería de Anthropic describe este enfoque como conservar referencias ligeras y utilizar herramientas para cargar la información cuando se necesita. Contexto justo a tiempo.

En Claude Code, las herramientas de lectura de archivos y de shell permiten trabajar así. Pídele que localice la función que gestiona los reintentos, lea esa función y el código que la llama, e inspeccione la secuencia de errores correspondiente. Cuando está habilitada la herramienta específica Grep, puede devolver rutas de archivos, contenido coincidente o recuentos en lugar de archivos completos. Referencia de herramientas de Claude Code.

En tu propio agente, devuelve una referencia a la fuente, un fragmento pertinente y metadatos suficientes para establecer su ámbito: entorno, identificador del registro, versión o fecha de vigencia. Otra llamada a una herramienta puede abrir después el material que rodea ese fragmento.

La recuperación puede pasar por alto pruebas relevantes. Define un criterio para ampliar la búsqueda. Si una búsqueda acotada no encuentra nada, cambia el ámbito o la consulta antes de concluir que el dato no existe. Si el fragmento no permite determinar si se aplica una excepción, carga la sección que lo contiene.

Recorta los resultados de las herramientas antes de incorporarlos a la conversación

Devuelve el resultado necesario para la siguiente decisión, junto con una forma de recuperar los detalles omitidos. Anthropic recomienda filtrar, paginar, seleccionar rangos y truncar la salida de las herramientas que devuelven demasiado contenido, con indicaciones útiles cuando se acortan los resultados. Recomendaciones de Anthropic para diseñar herramientas.

Claude Code aplica una versión concreta de este patrón a las salidas extensas de comandos de shell que terminan correctamente: cuando superan el límite de contenido incluido en la conversación, proporciona la ruta de un archivo guardado y una vista previa, para que el agente pueda buscar en el archivo o leerlo cuando sea necesario. El tratamiento documentado de los comandos que fallan es distinto; no des por hecho que todo error truncado incluye una ruta desde la que se pueda recuperar su contenido. Tratamiento de la salida de shell.

Para el agente que investiga el registro de usuarios, un resultado útil del log contiene el evento correspondiente, la operación anterior, el error y la ubicación de la fuente. Las solicitudes repetidas que se completaron correctamente pueden quedarse en el archivo de log. Conserva con exactitud el código de error y el identificador del evento; una descripción como «algo agotó el tiempo de espera» puede borrar la pista que determina la corrección.

Truncar sin criterio puede eliminar la excepción decisiva. Haz visible la omisión y proporciona una consulta de seguimiento o una referencia al archivo. Recorta el ruido repetido antes que las pruebas que contradicen la hipótesis.

Usa subagentes sin historial heredado para investigar desde cero

Los subagentes de Claude Code pueden realizar una investigación acotada en una ventana de contexto independiente y devolver un resultado. Un subagente sin bifurcación de la conversación parte de su definición y de la tarea que recibe; una bifurcación de la conversación hereda el historial del agente principal. Ambos separan el trabajo posterior, pero solo el primero empieza con un contexto limpio. Subagentes y bifurcaciones.

Delega una tarea como esta: «Inspecciona la ruta de reintentos de correo. No edites archivos. Devuelve las rutas pertinentes, las pruebas de entrega duplicada, las explicaciones alternativas y la siguiente comprobación». Incluye las restricciones que necesita el subagente, en lugar de suponer que conoce la conversación principal.

Acota la respuesta para que resulte útil: hallazgos, referencias a las pruebas e incertidumbres. Un subagente que devuelve todo su historial de lectura simplemente traslada el exceso de información a la conversación principal.

Los subagentes hacen sus propias solicitudes y consumen recursos. Pueden repetir trabajo si las instrucciones de la tarea omiten una decisión que el agente principal ya había establecido. Úsalos cuando la investigación se pueda separar y sus resultados intermedios se puedan descartar. Mantén unido el razonamiento cuyas partes dependan estrechamente entre sí. Los detalles de configuración están en subagentes de Claude Code.

Asigna a los archivos de memoria una función pequeña y estable

CLAUDE.md es un archivo de instrucciones del proyecto, no un lugar donde pegar cada conversación terminada. Claude Code también dispone de memoria automática para las notas que aprende. Su documentación distingue ambos mecanismos de la configuración que impone restricciones: escribir una prohibición en un archivo de memoria no vuelve técnicamente imposible una acción. Memoria de Claude Code.

En un equipo pequeño de producto, conserva en el archivo permanente las reglas propias del repositorio, los comandos reales de compilación y pruebas, los límites de los cambios y las referencias a documentación más detallada. Guarda el estado temporal de la investigación en una nota de tarea aparte. Consulta memoria de equipo con CLAUDE.md para ver la estructura del archivo.

Hay una limitación sutil: importar un documento largo en CLAUDE.md también carga su contenido. Mover texto a archivos importados puede mejorar la organización sin reducir el contexto activo. Para las instrucciones que solo hacen falta en una parte del repositorio, considera las reglas por ruta que describe la documentación. En los flujos de trabajo reutilizables, las skills de Claude Code normalmente muestran primero sus descripciones y cargan las instrucciones completas cuando se invocan. Importaciones de memoria y reglas por ámbito, carga de skills.

Los archivos persistentes pueden conservar suposiciones obsoletas con la misma eficacia que conocimientos útiles. Elimina las incidencias resueltas y los comandos sustituidos. Registra una fuente o una revisión para los datos que cambian. Para entender mejor la diferencia entre una sesión, el contexto de trabajo y el almacenamiento duradero, consulta cómo funciona la memoria de los agentes.

Cómo aplican estas técnicas Claude Agent SDK y Codex

Estas herramientas ya ofrecen los mecanismos; tu aplicación sigue eligiendo las pruebas y los límites de la tarea. La gestión automática del contexto no puede decidir qué dato del negocio olvidó recuperar tu flujo de trabajo.

Claude Agent SDK: integra el ciclo del agente en tu aplicación

Claude Agent SDK pone las herramientas, el ciclo del agente y la gestión del contexto de Claude Code a disposición de aplicaciones Python y TypeScript. Úsalo cuando integres un agente en un producto o una automatización que operes. Descripción general de Agent SDK.

El SDK compacta automáticamente el historial antiguo cuando la ventana se acerca a su límite y emite un evento de sistema compact_boundary. Registra ese evento junto a los resultados de las tareas para detectar fallos que aparezcan después del resumen. Los subagentes del SDK sin bifurcación conservan su trabajo intermedio en sus propias conversaciones y devuelven su mensaje final. Ciclo del agente en el SDK, subagentes del SDK.

Define de forma explícita cómo se cargan las instrucciones del proyecto. Las opciones predeterminadas actuales de query() habilitan las fuentes de usuario y de proyecto. Si proporcionas settingSources en TypeScript o setting_sources en Python, incluye project cuando necesites el CLAUDE.md del proyecto; un arreglo vacío impide que se cargue. Esto se controla mediante las fuentes de configuración, no al elegir el preajuste de prompt de sistema claude_code. Carga de instrucciones en el SDK.

Por capaz que sea el ciclo del agente, sigue necesitando una política de recuperación propia de su ámbito. Un agente de soporte necesita que definas cuál es el cliente actual, qué política se aplica y qué pruebas debe reunir antes de actuar.

Codex: separa las instrucciones del repositorio de la conversación en curso

Codex, de OpenAI, lee las instrucciones de AGENTS.md antes de trabajar. Combina las indicaciones globales con los archivos del proyecto, desde la raíz del repositorio hasta el directorio de trabajo; las indicaciones posteriores tienen precedencia y AGENTS.override.md tiene prioridad en su directorio. Instrucciones de proyecto en Codex.

Aprovecha esa jerarquía para conservar las reglas generales de compilación en la raíz y las reglas especializadas cerca del trabajo correspondiente. Codex CLI también ofrece /compact para resumir la conversación visible y /init para crear una estructura inicial del archivo de instrucciones. Contrasta esa estructura con tu repositorio antes de darla por válida. Comandos de Codex.

Un archivo de instrucciones del repositorio no registra automáticamente la tarea en curso. Guarda por separado el objetivo actual, los hallazgos confirmados, el trabajo pendiente y la ubicación de las pruebas. Tras un reinicio o una compactación, la siguiente solicitud debe poner ese estado de la tarea a disposición del agente sin reproducir toda la investigación.

Ejemplo de ingeniería de contexto: de la saturación a lo necesario

Recorta el material que rodea la decisión y conserva aquello de lo que depende. Imagina un agente de programación al que se le pide investigar correos de bienvenida duplicados tras reintentos de registro. Los nombres de archivos y las pruebas que siguen ilustran el diseño; no son resultados de un sistema desplegado.

Su paquete inicial, sobrecargado, contiene todo el manual de ingeniería, volcados amplios del repositorio, logs de servicios ajenos al problema, cada intercambio previo de depuración y herramientas para tareas administrativas sin relación. Su trabajo real es más acotado: encontrar la ruta que duplica el envío, proponer el cambio más pequeño e identificar una prueba de regresión. Los cambios de esquema quedan fuera del alcance.

1. 1

   Conserva la tarea activa y las restricciones permanentes

   Sustituye las solicitudes que compiten entre sí en la transcripción por el objetivo actual y los criterios de aceptación. Mantén visible la restricción sobre el esquema. Ofrece las herramientas del repositorio necesarias para este trabajo y deja fuera de esta ejecución las definiciones de herramientas administrativas ajenas a la tarea. Mueve las convenciones estables del repositorio al archivo de instrucciones del proyecto que corresponda; deja las observaciones temporales en la nota de tarea. No incluyas todo el manual en una importación que se cargue automáticamente.

2. 2

   Sustituye los archivos completos por un mapa de pruebas

   Conserva referencias a signup-handler.ts, welcome-job.ts, la prueba de reintentos y el archivo de log pertinente. Esos nombres son ilustrativos. Lee el código que gestiona el registro y el proceso que ejecuta el envío cuando respondan a la siguiente pregunta, e inspecciona sus dependencias cuando haga falta. El mapa permite acceder a las pruebas; no sustituye su lectura.

3. 3

   Filtra el resultado de la herramienta en torno al fallo

   Solicita el evento de registro afectado y su secuencia de reintentos. Supongamos que el registro hipotético muestra que el proveedor aceptó el envío, que falta la confirmación local y que hay otro intento en cola. Conserva esa secuencia, el identificador del evento y la ubicación de la fuente. Deja las solicitudes correctas ajenas al caso en el log original. Mantén explícita la incertidumbre sobre si el segundo intento llegó a entregar el correo.

4. 4

   Aísla una búsqueda acotada

   Encarga a un subagente sin bifurcación que encuentre dónde se implementa la prevención de envíos duplicados. Proporciona el alcance de la tarea y las rutas pertinentes. Pide ubicaciones y pruebas, incluida una declaración explícita si la búsqueda quedó incompleta. Devuelve ese hallazgo al agente principal y mantén fuera de su contexto las lecturas exploratorias del subagente.

5. 5

   Compacta la investigación en un resumen que permita retomarla

   Conserva el objetivo actual, las pruebas conocidas, las explicaciones descartadas, la pregunta pendiente y la siguiente acción. Mantén la diferencia entre un reintento en cola y una entrega duplicada confirmada. Archiva la transcripción original para que el agente pueda recuperar un detalle en lugar de adivinarlo.

6. 6

   Compón la siguiente solicitud con lo que queda

   Carga la tarea, las reglas permanentes, el fragmento pertinente del código de registro, la secuencia filtrada de eventos y el hallazgo del subagente. La siguiente acción es inspeccionar la ruta de confirmación y de prevención de duplicados, y proponer la prueba de regresión. Carga más pruebas si esa acción lo requiere; no vuelvas a adjuntar todo el archivo de la investigación por costumbre.

La nota de tarea resultante podría decir:

Objetivo: Explicar los correos de bienvenida duplicados tras los reintentos de registro y proponer una corrección mínima con una prueba de regresión.
Restricción: Mantener los cambios de esquema fuera del alcance.
Pruebas: La secuencia seleccionada del log muestra la aceptación del proveedor, la ausencia de una confirmación local y otro intento en cola. Conservar la referencia del evento y la ubicación del log original.
Por determinar: Si el reintento en cola entregó el correo y dónde se aplica la prevención de envíos duplicados.
Siguiente comprobación: Inspeccionar las rutas de confirmación y de prevención de duplicados en el código de registro y en el proceso de envío referenciados.

Esta nota hipotética deja la incertidumbre a la vista. Al realizar el diagnóstico, el modelo recibe junto a ella el fragmento que la sustenta.

El resultado es un inventario de contenido más pequeño, sin afirmar una reducción de tokens. El recuento exacto de tokens depende de la solicitud real y del tokenizador. Para afirmar que baja el gasto o mejora la tasa de finalización hay que medirlo; este ejemplo establece qué eliminar y qué conservar.

Una plantilla de ingeniería de contexto para retomar el trabajo

Usa una nota de tarea con estos campos, completados con pruebas reales de la ejecución:

• Objetivo y condición de finalización: la solicitud actual y qué se consideraría haberla completado.
• Restricciones: los límites que debe conservar el siguiente paso.
• Hechos establecidos: cada hallazgo junto a la ubicación de su fuente y la revisión o el ámbito pertinente.
• Incertidumbre: lo que sigue siendo una inferencia, presenta contradicciones o no se ha inspeccionado.
• Siguiente acción: la próxima comprobación y dónde se pueden recuperar las pruebas necesarias.

Actualiza esta nota cuando cambie un hallazgo. Añadir cada nueva idea sin revisar las anteriores reproduce el problema original en un archivo más pequeño.

Tamaño del contexto y costo: cifras que hay que evaluar por separado

Optimiza el costo de un resultado aceptado, no la longitud de una solicitud. Una conversación principal más pequeña puede coexistir con más llamadas a subagentes, solicitudes de recuperación o intentos fallidos.

Dos límites documentados para las instrucciones muestran por qué importan las unidades. El límite predeterminado de Codex para el conjunto de documentos del proyecto es de 32 KiB, es decir, 32 × 1,024 = 32,768 bytes. Es un límite en bytes, no un presupuesto de tokens. Claude Code recomienda mantener cada CLAUDE.md por debajo de 200 líneas; es una recomendación de redacción, no un límite estricto de la ventana de contexto. Ninguna de esas cifras permite predecir ahorros. Límite de instrucciones de Codex, recomendaciones de redacción de Claude Code.

En un flujo de trabajo en producción, registra el costo del agente principal, los subagentes, la compactación, la recuperación y los reintentos. Después calcula:

Costo por tarea aceptada = costo total del flujo de trabajo en todos los intentos ÷ tareas que cumplen los criterios de aceptación.

Para un presupuesto mensual, suma los cargos por uso del modelo a los de herramientas, recuperación, almacenamiento y alojamiento. No existe un precio mensual único para la ingeniería de contexto ni se puede justificar un ahorro en dólares sin conocer tu carga de trabajo y las tarifas aplicables del proveedor.

La caché complica la comparación. La caché de prompts de OpenAI reutiliza los prefijos coincidentes de las solicitudes ya compuestas. La compactación puede cambiar ese prefijo y reducir la reutilización de la caché, aunque la solicitud sea más corta. Mantén estables las instrucciones reutilizables cuando sea posible y compara el costo total antes y después del cambio. Una menor tasa de aciertos de caché, por sí sola, no demuestra que la optimización haya fallado. Caché de prompts de OpenAI.

Consulta el diagnóstico de la caché de prompts de GPT-6 para distinguir los problemas causados por cambios de prefijo de los que provoca el contenido innecesario. Una caché abarata el procesamiento de entradas repetidas; no decide si esas entradas son pertinentes para la tarea.

Buenas prácticas de ingeniería de contexto: qué cambiar primero

Actúa cuando la traza muestre un fallo de contexto y elige la intervención más pequeña que lo resuelva. Una traza es la secuencia registrada de solicitudes, llamadas a herramientas y resultados, incluida la información que vio el modelo antes de cada decisión.

Para quienes desarrollan, la clave es inspeccionar el paso inmediatamente anterior a la acción incorrecta. Si faltan pruebas, corrige la recuperación. Si están enterradas en resultados repetidos, filtra la salida de la herramienta. Si una discusión anterior desplaza la tarea actual, corrige el estado de la tarea y el resumen para retomarla. Si una investigación que se puede separar inunda la conversación principal, aíslala.

Para quienes operan el sistema, define qué resultado se considera aceptado y conserva fallos representativos para evaluarlo. Compara la calidad de finalización, las afirmaciones sin respaldo, los reintentos, la latencia y el costo total sobre las mismas tareas. Cambia una sola política de contexto a la vez para poder interpretar el resultado. Usa trazas existentes para diseñar casos de evaluación fuera de producción.

Para quienes compran, pregunta si el producto permite ver el contexto y los resultados de herramientas que sustentan una respuesta, conserva las referencias a las fuentes después de resumir y deja controlar las instrucciones persistentes. Una función de «memoria» que no permite saber qué se carga resulta difícil de diagnosticar.

Espera antes de añadir más mecanismos si un flujo de trabajo breve y acotado ya funciona de forma fiable. Puede que baste con una instrucción más clara o un mejor mensaje de error de la herramienta, sin un servicio de memoria ni una red de subagentes. Si el fallo se debe a permisos incorrectos, errores en la lógica de la aplicación o datos de origen no disponibles, corrige directamente esa causa; seleccionar mejor el contexto no basta para repararla.

¿Qué se exagera sobre la ingeniería de contexto?

Una ventana de contexto más grande, más memoria y más agentes amplían la capacidad; no demuestran que las decisiones sean mejores. La pregunta útil es si ayudan a que este flujo de trabajo lleve la información correcta al siguiente paso.

«Pon todo en el prompt» evita tener que elegir, pero introduce material que compite entre sí. «Resume todo» selecciona con demasiado rigor si borra la excepción que importa. «Que lo resuelva un subagente» solo ayuda cuando la tarea puede cruzar ese límite sin perder decisiones esenciales.

El error más caro es confundir una solicitud más corta con un sistema validado. Un agente que responde a bajo costo basándose en la política equivocada sigue equivocándose. Una buena política de contexto debe facilitar la verificación de la respuesta: la regla aplicable está visible, las pruebas que la sustentan tienen una fuente y la incertidumbre pendiente sigue siendo explícita.

Preguntas frecuentes cuando un agente pierde el rumbo

¿La ingeniería de contexto puede corregir un agente que funciona en una demostración, pero falla en producción?

Puede resolver la falta de pruebas, las instrucciones obsoletas, los resultados excesivos de herramientas y la pérdida del estado de la tarea. Primero inspecciona la solicitud que falla. Una herramienta defectuosa, una lógica de aplicación incorrecta o una tarea que supera las capacidades del modelo necesitan su propia solución. Evalúa el cambio por los resultados aceptados en tareas representativas.

¿Necesito una base de datos vectorial o un framework multiagente para empezar?

No. Empieza por instrucciones explícitas del proyecto, recuperación precisa de archivos o documentos, resultados acotados de herramientas y un resumen para retomar la tarea. Añade búsqueda semántica cuando encontrar el material pertinente lo requiera, o un subagente cuando una investigación independiente se beneficie de un contexto separado.

¿Cómo sé si he recortado demasiado?

Comprueba si la siguiente decisión sigue contando con la regla que la rige, las pruebas de apoyo, el ámbito aplicable y las excepciones importantes. Si el agente tiene que adivinar un dato eliminado, el contexto es insuficiente. Conserva una fuente que se pueda recuperar y amplía la lectura cuando el fragmento no resuelva la pregunta.

Para empezar el lunes: toma una ejecución fallida que ya tengas e inspecciona la solicitud anterior a su primera acción incorrecta. Clasifica su contenido en instrucciones permanentes, estado de la tarea activa, pruebas necesarias ahora o material que puede quedarse almacenado. Aplica el cambio más pequeño que corresponda y compara después el resultado y el costo total del flujo de trabajo sobre los mismos casos de evaluación.

Suscríbete al boletín para recibir guías prácticas sobre cómo desarrollar y operar agentes útiles.