Prompt engineering vs context engineering: por qué el prompt perfecto no alcanza

Este artículo forma parte de la serie Capacitaciones IThreex: contenido derivado de las formaciones internas que damos a nuestro equipo de ingeniería e implementación de agentes IA sobre la plataforma ABLE.

El techo del prompt engineering

Escribir buenos prompts tiene un retorno enorme al principio: pasar de una instrucción vaga a un system prompt bien estructurado puede duplicar la calidad de un agente. Pero el retorno se aplana rápido. Llegado cierto punto, el problema deja de ser cómo se lo pido y pasa a ser qué información tiene disponible en el momento de responder.

Qué abarca el context engineering

Memoria e historial

Cuánto de la conversación anterior entra al contexto, cómo se resume, cuándo se corta. Un agente que arrastra todo pierde foco y presupuesto; uno que no arrastra nada repregunta lo que ya sabe.

Recuperación (RAG)

Qué documentos están indexados, con qué tamaño de chunk, con qué modelo de embeddings y qué se recupera para cada consulta. Un RAG mal configurado devuelve fragmentos correctos de documentos equivocados.

Herramientas y MCP

Qué puede consultar y ejecutar el agente contra sistemas reales: CRM, calendario, ERP, base de datos. Cada tool es una fuente de contexto en tiempo de ejecución.

Skills

Capacidades reutilizables que se cargan según el caso, en vez de un super-prompt que intenta cubrir todos los escenarios posibles.

La capa que casi todos olvidan: explicar para qué sirve cada dato

El agente recibe el resultado de tres tools distintas y no sabe qué representa cada uno. Si el system prompt no aclara "este dato es el saldo pendiente y se usa para decidir si aplicar la bonificación", el modelo va a improvisar una interpretación. A veces acierta. En producción, "a veces" no alcanza.

Un ejemplo concreto

Un agente que audita proyectos contra una norma ISO. El prompt engineering resuelve el tono, el formato del informe y la instrucción de no inventar requisitos. El context engineering resuelve lo verdaderamente difícil:

• La norma completa cargada como base de conocimiento.
• Conexión a Drive para recorrer carpetas y leer la evidencia real de cada proyecto.
• Un criterio de recuperación que trae el checklist correcto para el tipo de proyecto analizado.
• Ejecución programada para revisar los proyectos activos periódicamente y detectar desvíos antes de la auditoría.

Ese agente no es "mejor prompt". Es mejor arquitectura de contexto.

Por qué esto define quién escala y quién no

La mayoría de los pilotos de IA que se caen no se caen por el modelo. Se caen porque el agente no tenía acceso confiable a la información que necesitaba, o porque nadie definió cómo debía usarla. Es un problema de ingeniería de sistemas, no de redacción.