ConceptoContext engineeringPara entenderActualizado el 28 sept 2026

Qué es context engineering

La disciplina de decidir qué recibe un modelo de IA junto con la instrucción, y por qué importa más que el prompt en sistemas con agentes.

Respuesta corta

Context engineering es el trabajo de decidir qué entra en la ventana de contexto de un modelo de IA, en qué orden y con qué límites. Prompt engineering se ocupa de la instrucción. Context engineering se ocupa de todo lo que el modelo recibe junto con ella: documentos, historial, reglas, herramientas y salidas de otros agentes.

Por qué el prompt no alcanza

En un chat, la instrucción es casi todo lo que el modelo lee. En un sistema con agentes, es una parte pequeña. El resto es contexto: archivos cargados, historial de la sesión, descripciones de herramientas, reglas del proyecto y lo que otros agentes produjeron antes.

Más contexto no significa mejor resultado. El CL-Bench, citado en el experimento #007, indica que el 76% del contexto cargado en los LLM se ignora. El problema rara vez es falta de instrucción. Casi siempre es exceso de material.

24 usado76 ignorado
De cada 100 partes de contexto cargadas, 76 son ignoradas por el modelo (CL-Bench).

Las cuatro formas en que falla el contexto

  1. Envenenamiento. Una información errónea entra al contexto y pasa a tratarse como verdad en las respuestas siguientes.
  2. Distracción. El volumen de contexto es tan grande que el modelo pierde de vista la tarea actual.
  3. Confusión. Material irrelevante cambia la respuesta, aunque no tenga relación con el pedido.
  4. Conflicto. Dos partes del contexto dicen cosas distintas, y el modelo elige una sin avisar.

Las cuatro se validaron en el mismo experimento, a partir de un estudio con Gemini 2.5. Cada una pide una corrección distinta, así que conviene saber cuál está ocurriendo antes de tocar nada.

Qué tiene un contexto bien diseñado

  1. Solo lo que la etapa necesita. Si la respuesta no cambia sin un ítem, se va.
  2. Contexto separado por agente. Cada agente trabaja con su propio contexto, y un error no contamina el resto del sistema.
  3. Reglas como límites. Decir qué nunca hacer suele sostener más que listar qué hacer siempre.
  4. Verificación fuera del modelo. Lo que tiene que estar bien lo revisa una prueba, no la opinión del propio modelo.

Cómo aparece esto en mis sistemas

En ATHENA OS, cada agente ejecutor corre con su propio contexto. En el squad de context engineering del experimento #007, la regla de arquitectura fue "los agentes piensan, las skills ejecutan": menos agentes, cada uno con sus frameworks completos y sin referencias externas. En el experimento #009, un único archivo de voz con límites explícitos mantuvo a 10 agentes escribiendo con la misma voz en 9 páginas.

Preguntas frecuentes

¿Context engineering reemplaza a prompt engineering?

No. La instrucción sigue importando. Pasa a ser una parte del contexto, no el todo.

¿Una ventana de contexto más grande lo resuelve?

No por sí sola. Más espacio permite cargar más material, y la distracción y el conflicto crecen con el volumen.

¿Por dónde empiezo en un sistema que ya existe?

Lista todo lo que el modelo recibe en una tarea y pregunta, ítem por ítem, si la respuesta cambia sin él. Lo que no cambia nada, sale.

¿Quieres aplicar esto en tu operación?

La primera conversación es un diagnóstico de una hora, gratuito.

Esto es semanal.

Un email por semana con los experimentos más densos, filtrados y comentados. Sin duplicar lo que está en el portal: el contexto que no cabe en un registro.

Sinal

Señal, no ruido.

1 email por semana. Lo mejor del laboratorio, filtrado y comentado.

Cómo es Sinal

Hablemos

Escríbeme directo. Respondo personalmente, normalmente el mismo día.

WhatsApplozanojoaog@gmail.com
WhatsApp