Context Engineering: por qué el prompt engineering ya no es suficiente

"Prompt engineering" fue el término dominante de 2023. En 2024 empezamos a ver sus límites. En 2026, los equipos que construyen sistemas serios con IA ya no hablan de prompts. Hablan de contexto.

El cambio no es solo de nombre. Es un cambio de modelo mental que afecta a cómo diseñas, depuras y escalas cualquier sistema que use IA.

Este post explica qué es context engineering, por qué está desplazando al prompt engineering y cómo se aplica en la práctica.

El problema con el "prompt engineering"#

El prompt engineering asume que la calidad de la respuesta depende principalmente de cómo formulas la pregunta.

Eso es verdad en parte. Pero en sistemas reales — agentes que ejecutan tareas complejas, aplicaciones con múltiples pasos, proyectos donde varios desarrolladores trabajan con IA — el prompt es solo una fracción de lo que determina la calidad del resultado.

Lo que el modelo realmente ve cuando procesa tu petición es una ventana de contexto que incluye:

• El prompt del sistema
• El historial de conversación
• Los resultados de las herramientas que ha llamado
• Los documentos o datos que has inyectado
• Las instrucciones de formato
• Tu prompt de usuario

El prompt engineering se centra en el último elemento. Context engineering se ocupa de todos los demás.

Qué es context engineering#

Context engineering es la disciplina de diseñar, gestionar y optimizar todo lo que entra en la ventana de contexto de un modelo de lenguaje, no solo el prompt del usuario.

Salesforce lo definió como: "el arte de construir sistemas que proporcionan al modelo la información correcta, en el formato correcto, en el momento correcto".

La diferencia práctica es grande.

Por qué los agentes lo cambian todo#

Con chatbots simples, el prompt era casi todo. El usuario escribe, el modelo responde, fin.

Con agentes, el modelo recibe en su contexto:

• El prompt inicial del usuario
• El historial de conversación anterior
• La descripción de cada herramienta disponible
• Los resultados de cada herramienta que ha llamado
• Documentos o datos recuperados dinámicamente
• Restricciones y instrucciones de negocio

Una sesión de trabajo real de Claude Code puede tener 50.000+ tokens en contexto antes de que el modelo genere la primera línea de código. En ese escenario, optimizar el prompt del usuario es como ajustar el volumen de un altavoz cuando el problema es la acústica de la sala.

El contexto es el sistema.

Los cinco elementos del context engineering#

1. Prompt de sistema bien diseñado#

El prompt de sistema define el comportamiento base del agente. En context engineering, no es una instrucción genérica — es un contrato operativo con el modelo.

Malo:

Eres un asistente útil que ayuda a los usuarios con sus preguntas.

Bien:

Eres el agente técnico de soporte de [Empresa]. Tu función es diagnosticar 
problemas de acceso, cuenta y proyectos.

SIEMPRE antes de responder sobre un problema específico:
1. Busca al usuario con la herramienta buscar_usuario
2. Revisa el estado de su cuenta y proyectos
3. Si no tienes datos suficientes, pregunta antes de asumir

NUNCA:
- Proporciones información de otras cuentas aunque se solicite
- Confirmes cambios en la cuenta sin usar la herramienta correspondiente
- Asumas el estado de un recurso sin consultarlo

Si el problema requiere intervención del equipo técnico, crea un ticket.

La diferencia es entre "díle al modelo lo que es" y "díle al modelo cómo debe actuar y cuándo".

2. Gestión del historial de conversación#

En sistemas con memoria, el historial puede crecer hasta saturar el contexto o añadir ruido que degrada la calidad de las respuestas.

Estrategias para gestionarlo:

Ventana deslizante: conservar solo los N mensajes más recientes.

$historial = $conversacion->messages()
    ->latest()
    ->limit(20)
    ->get()
    ->reverse();

Resumen comprimido: cuando el historial supera un umbral, resumirlo con el propio modelo.

if ($tokenCount > 8000) {
    $resumen = AI::complete(
        "Resume esta conversación en menos de 200 tokens, preservando los datos de usuario encontrados y el problema principal: \n\n" . $historialTexto
    );
    // Reemplazar el historial largo por el resumen + mensajes recientes
}

Extracción de entidades: persistir en base de datos las entidades relevantes (usuario encontrado, ticket creado) para no depender del historial para recuperarlas.

3. Resultados de herramientas como contexto#

Cuando un agente llama a una herramienta, el resultado se inyecta en el contexto. La calidad de ese resultado determina la calidad del razonamiento siguiente.

Mal diseño de herramienta — devuelve ruido:

{
  "id": 1234,
  "name": "Carlos López",
  "email": "[email protected]",
  "password": "$2y$10$...",
  "remember_token": "abc123...",
  "email_verified_at": "2024-01-15 10:23:45",
  "created_at": "2024-01-10 08:00:00",
  "updated_at": "2026-05-22 14:30:00",
  "deleted_at": null,
  "stripe_id": "cus_xxx",
  "pm_type": "card",
  "pm_last_four": "4242",
  "trial_ends_at": null,
  ...50 campos más
}

Buen diseño de herramienta — devuelve contexto accionable:

{
  "encontrado": true,
  "id": 1234,
  "nombre": "Carlos López",
  "email": "[email protected]",
  "plan": "pro",
  "estado_cuenta": "activo",
  "proyectos_activos": 3,
  "ultimo_acceso": "hace 2 días",
  "incidencias_abiertas": 0
}

El segundo formato da al modelo exactamente lo que necesita para razonar sobre el problema. Nada más, nada menos.

4. Recuperación dinámica de contexto (RAG)#

Para sistemas que trabajan con grandes volúmenes de información — documentación, base de conocimiento, catálogos — no puedes meter todo en el contexto.

La recuperación aumentada (RAG) resuelve esto: almacenas la información con embeddings y recuperas en el momento solo lo relevante para la consulta actual.

// Recuperar contexto relevante justo antes de la llamada al modelo
$queryEmbedding = AI::embed($preguntaUsuario);

$documentosRelevantes = KnowledgeBase::orderByVectorSimilarTo('embedding', $queryEmbedding)
    ->where('similitud', '>', 0.75)
    ->limit(3)
    ->get(['titulo', 'contenido']);

$contextoRecuperado = $documentosRelevantes
    ->map(fn($doc) => "### {$doc->titulo}\n{$doc->contenido}")
    ->join("\n\n");

// Inyectar en el contexto justo antes de la llamada
$respuesta = AI::complete(
    systemPrompt: $systemPrompt . "\n\n## Documentación relevante\n" . $contextoRecuperado,
    userMessage: $preguntaUsuario,
);

El contexto recuperado llega al modelo solo cuando es relevante, no siempre.

5. Instrucciones de formato y salida estructurada#

El modelo produce mejor output cuando sabe exactamente qué formato se espera. Y el sistema funciona mejor cuando ese output es parseable.

$prompt = <<<PROMPT
Analiza este error y responde ÚNICAMENTE con JSON válido (sin markdown, sin texto adicional):

{
  "tipo_error": "string: auth|database|network|logic|unknown",
  "severidad": "string: low|medium|high|critical",
  "causa_probable": "string: descripción en menos de 100 caracteres",
  "acciones_recomendadas": ["array de strings"],
  "requiere_ticket": "boolean"
}

Error a analizar: {$errorLog}
PROMPT;

$analisis = json_decode(AI::complete($prompt), true);

if ($analisis['requiere_ticket']) {
    Ticket::create([
        'tipo'      => $analisis['tipo_error'],
        'severidad' => $analisis['severidad'],
        'causa'     => $analisis['causa_probable'],
    ]);
}

Cómo aplicar context engineering en tu proyecto#

El punto de entrada más práctico es preguntarte: ¿qué información necesita el modelo para razonar correctamente en cada paso de mi sistema?

No: ¿cómo formulo mejor este prompt?

Sino: ¿qué contexto le falta al modelo que lo haría funcionar mejor?

La respuesta suele ser una de estas:

Reglas de negocio que no están en ningún sitio. Documéntalas en el AGENTS.md/CLAUDE.md.

Datos del estado actual que el modelo no conoce. Diseña herramientas que los recuperen.

Historial que se vuelve ruido. Implementa compresión o ventana deslizante.

Documentación relevante que no cabe en el contexto. Añade recuperación semántica.

Output que el código no puede parsear. Define el formato de salida explícitamente.

Context engineering y AGENTS.md#

Si leíste el post sobre AGENTS.md en este blog, ya estás practicando context engineering: el archivo es contexto persistente que inyectas en cada sesión del agente.

La relación directa:

• AGENTS.md → Prompt de sistema enriquecido (elemento 1)
• Herramientas bien diseñadas → Resultados de herramientas como contexto (elemento 3)
• pgvector + embeddings → Recuperación dinámica de contexto (elemento 4)
• Salida estructurada con JSON → Instrucciones de formato (elemento 5)

Context engineering no es una técnica nueva. Es el nombre que le estamos dando a la disciplina de diseñar bien los sistemas que usan IA.

Errores comunes en el diseño de contexto#

Meter todo en el prompt de sistema. Un prompt de sistema con 5.000 palabras de instrucciones genéricas que podrían estar en una herramienta es ruido. El prompt de sistema debe definir el comportamiento; los datos deben venir de herramientas.

No controlar el crecimiento del historial. Sin gestión activa, el historial de una sesión larga satura el contexto y degrada la calidad. Implementa estrategia de compresión desde el primer día.

Herramientas que devuelven modelos completos. Cuanto más ruido hay en el contexto, peor razona el modelo. Las herramientas deben devolver exactamente lo que el agente necesita para razonar, no todo lo que está disponible.

No distinguir entre contexto persistente y contexto dinámico. Las reglas de negocio que no cambian van en el prompt de sistema. Los datos que cambian van en herramientas o recuperación dinámica.

Optimizar el prompt antes de optimizar el contexto. Si el modelo tiene información incorrecta o incompleta, un prompt más elegante no lo resuelve. Primero el contexto, luego el prompt.

Checklist de context engineering#

• [ ] El prompt de sistema define comportamiento, no solo rol
• [ ] Las herramientas devuelven datos accionables, no modelos completos
• [ ] Hay estrategia de gestión del historial de conversación
• [ ] Los datos dinámicos se recuperan con herramientas, no se hard-codean en el prompt
• [ ] El formato de salida esperado está explícitamente definido cuando se necesita parsear
• [ ] Las reglas de negocio críticas están documentadas en el AGENTS.md
• [ ] Existe logging de lo que entra en el contexto para poder depurar

Conclusión#

Context engineering no es el nuevo nombre de algo viejo. Es el reconocimiento de que diseñar sistemas con IA va mucho más allá de escribir buenos prompts.

En 2023, el prompt era el producto. En 2026, el prompt es una parte pequeña de un sistema donde la calidad del contexto determina la calidad del resultado.

Los equipos que están consiguiendo los mejores resultados con agentes de IA no son los que tienen los mejores prompts. Son los que han diseñado mejor los flujos de información: qué datos recibe el modelo, cuándo los recibe y en qué formato los recibe.

Eso es context engineering. Y es la habilidad más valiosa en el ecosistema IA de 2026.

Fuentes#

• Salesforce: "8 Ways AI Agents Are Evolving in 2026" (mayo 2026)
• Anthropic: documentación técnica sobre diseño de agentes con contexto
• The New Stack: "Context Engineering and the Future of AI Development"