Context Engineering: lo que reemplaza al prompt engineering en 2026 (guía para agentes de WhatsApp)

El mes pasado un cliente me llamó frustrado. Había invertido tres semanas reescribiendo el prompt de su agente de WhatsApp: cambios de tono, ejemplos, instrucciones de marca, hasta un párrafo completo de “lo que nunca debes decir”. El bot seguía respondiendo con información desactualizada y alucinando precios. Cuando le pregunté cuánto de su contexto (documentos cargados, memoria habilitada, herramientas conectadas) había revisado, me dijo: “Nada, solo el prompt”. Ahí entendí que tenía que escribir esta guía.

El prompt engineering no está muerto. Pero en 2026, en producción, es solo una de las cuatro patas de la mesa. La disciplina que importa se llama context engineering, y es la diferencia entre un agente que funciona en demo y uno que sostiene 1.000 conversaciones al día sin derrumbarse. El 91% de las interacciones de IA conversacional ya pasan por WhatsApp según el reporte 2026 de Infobip, así que esta conversación ya no es opcional para nadie que atienda clientes por ahí.

TL;DR

• El prompt engineering optimiza una instrucción. El context engineering optimiza todo lo que el modelo ve en cada paso. La primera vive dentro de la ventana; el segundo decide qué entra en ella.
• En producción, los cuatro pilares son: Instructions, Retrieval (RAG), Memory y Tools (cada vez más vía MCP).
• Las cuatro palancas operativas, popularizadas por LangChain, son: Write, Select, Compress, Isolate. Si no controlas las cuatro, el modelo se degrada antes de llenar la ventana.
• No hay que implementar todo de golpe. En mi experiencia, Instructions + Retrieval sólidos resuelven el 70% de los problemas. El resto se agrega por capas según crece el volumen.
• En 2026, el agente confiable no es el que tiene el mejor prompt: es el que tiene el mejor contexto.

Por qué el prompt engineering se quedó corto

El prompt engineering fue la primera disciplina seria para trabajar con LLMs. Y sigue siendo útil. Pero tiene un límite claro: vive dentro de la ventana de contexto, y solo controla el texto de la instrucción. Cuando tu agente tiene que decidir entre 20 intenciones de cliente, decidir si llama a una API, recordar lo que dijo el usuario hace tres turnos y citar la política correcta de devoluciones, optimizar el prompt deja de ser el cuello de botella. El cuello de botella es todo lo demás.

Hay tres señales que, en mi experiencia, te confirman que ya pasaste del prompt engineering al context engineering:

Señal 1 — Mejoras en el prompt dejan de mover métricas. Cambias el tono, agregas ejemplos, divides el system prompt en secciones… y la tasa de alucinación se mueve 1 o 2 puntos. Antes, el mismo cambio movía 10. El problema ya no es el texto.

Señal 2 — El modelo “se olvida” de cosas que sí están en la conversación. Le dices al cliente su número de pedido, él responde, y tres turnos después el bot le pregunta de nuevo. Eso no es un problema de prompt. Es un problema de gestión de memoria y compactación.

Señal 3 — Cada vez que agregas una herramienta o una fuente de datos, la calidad baja. Sumas RAG sobre un nuevo sistema, sumas una API de logística, sumas un sub-agente, y de pronto el bot responde peor que antes. No es que la nueva fuente sea mala. Es que no controlas cómo entra al contexto.

Tobi Lütke, CEO de Shopify, lo dijo en 2025: el context engineering “describe la habilidad central: el arte de proveer todo el contexto para que la tarea sea plausiblemente resoluble por el LLM”. Desde entonces el término se consolidó y la conversación en toda la industria (Anthropic, OpenAI, LangChain, Sourcegraph) gira alrededor de lo mismo: qué entra, qué no entra, y cómo lo decides en cada paso.

Los cuatro pilares del context engineering

Cuando un agente responde, lo hace en función de cuatro tipos de información. Si alguno está mal diseñado, el agente falla. Los cuatro pilares, en el orden en que recomiendo revisarlos:

Pilar 1 — Instructions (system prompt). El rol, las restricciones, el formato de salida, las reglas de marca. Es donde vive el prompt engineering clásico. Pero debe ser compacto y enfocado, no un tratado. Un system prompt de 3.000 tokens no es “más completo”: es ruido que desplaza hechos importantes que sí necesitan estar en la ventana.

Pilar 2 — Retrieval (RAG y búsqueda grounded). Aquí entran los documentos, los registros de la base de datos, los chunks de la base de conocimiento. La regla en 2026: nada de instrucciones hardcoded que podrían ser documentos. Si una política cambia cada trimestre, va como documento recuperable, no como párrafo en el prompt. Y retrieval no es solo RAG vectorial. Es también SQL estructurado, búsqueda exacta, lectura de archivos, MCP servers. La fuente que recupera debe ser la más estrecha posible, no la más completa.

Pilar 3 — Memory. Hay dos tipos y hay que tratar distinto. Memoria de sesión: el historial de la conversación, las herramientas ya llamadas, los resultados intermedios. Aquí la palanca clave es la compactación: cada N turnos, resumir lo resuelto y descartar el detalle. Memoria persistente: preferencias del cliente, idioma, pedidos anteriores, decisiones tomadas en conversaciones previas. Esto vive fuera de la ventana (Postgres, vector store, archivos) y se trae por retrieval, no se carga completo nunca.

Pilar 4 — Tools. La superficie de funciones que el agente puede invocar: consultar estado de un pedido, abrir un ticket, agendar una cita, enviar una plantilla de WhatsApp, leer una factura. Cada tool tiene un schema con descripción, parámetros y respuesta. Y aquí hay una decisión crítica: cuántas herramientas dejas disponibles a la vez. Mi regla: nunca más de 15 herramientas activas por agente. Más de eso, el modelo pierde precisión eligiendo cuál llamar.

El Model Context Protocol (MCP) es ya el estándar de facto para conectar herramientas. Stacklok reportó en 2026 que el 41% de las empresas de software ya tienen MCP servers en producción limitada o amplia, y el registro oficial pasa de 9.600 servidores públicos. Si tu agente en WhatsApp debe hablar con tu CRM, tu logística o tu ERP, lo correcto en 2026 es un MCP server, no integraciones a medida por cada cliente.

Las cuatro palancas operativas: Write, Select, Compress, Isolate

Los cuatro pilares responden qué entra al contexto. Las cuatro palancas de LangChain responden cómo entra. Se complementan. Un agente sin las palancas bien afinadas termina gastando presupuesto de tokens en lo que no importa.

Palanca 1 — Write. Persistir contexto fuera de la ventana activa. La metáfora que más me sirve: la ventana es RAM, no disco duro. Si un agente descubre un dato importante en el turno 3, lo escribe en un scratchpad externo. En el turno 8, lo recupera por referencia, no lo rederiva. Esto solo vale la pena a partir de conversaciones multi-tarea de más de 5 turnos.

Palanca 2 — Select. Traer al contexto solo lo necesario en ese paso. El error más común: hacer retrieval con k=10 “para que tenga opciones”. El agente recibe 10 documentos, ignora 9, y los 9 igual costaron tokens. Mi experiencia: k=3 a k=5 por sub-pregunta, con un reranker al final. Más de eso es ruido.

Palanca 3 — Compress. Resumir lo que ya no aplica. Cuando un ticket se resuelve, el historial compactado dice “caso de devolución #4523 resuelto, cliente recibió guía de envío el 12/07”. No incluye los 14 turnos textuales. Esto mantiene la ventana limpia para el siguiente tema. Anthropic lo llama “compilación”: la sesión cruda es la fuente, el contexto de trabajo es el output compilado.

Palanca 4 — Isolate. Dividir en sub-agentes con ventanas separadas. En vez de un agente gigante que hace intake, lookup, redacción y aprobación, separas. Cada sub-agente tiene su ventana propia. El orquestador solo pasa resúmenes entre ellos. Esto reduce contaminación cruzada y hace cada paso auditable por separado. Pero ojo: no empezar con multi-agente desde el día uno. Lo he visto fallar más veces de las que ha funcionado. Crece por capas.

Cómo aplicarlo a un agente de WhatsApp real

Bajemos a tierra. Si estás montando (o arreglando) un agente de WhatsApp en 2026, esta es la secuencia que yo seguiría, validada en producción con clientes de TecnoChat.

Paso 1 — Audita qué le pides al modelo hoy. Antes de añadir nada, entiende qué información entra ya a la ventana de tu agente. Cuántos tokens de system prompt, cuántos de historial, cuántos de RAG, cuántos de tool definitions. Si tu system prompt pasa de 1.500 tokens, casi seguro tiene grasa. Recórtalo.

Paso 2 — Separa instrucciones de conocimiento. Las instrucciones que cambian poco (rol, tono, restricciones duras) van en el system prompt. Las que cambian (precios, políticas, inventario) van como documentos recuperables. Si tu operador actualiza un precio, no debería tener que tocar el prompt.

Paso 3 — Pon un límite explícito al retrieval. Nada de “traer todo lo relevante”. Limita a 3-5 documentos, con un umbral de similitud mínimo (0.7-0.75 en la mayoría de los embeddings comerciales). Documentos por debajo del umbral = abstención, no inclusión forzada.

Paso 4 — Activa memoria de sesión con compactación. Después de cada turno resuelto (cliente confirmó pedido, ticket cerrado, pregunta respondida), compacta el historial. Guarda el resumen en la sesión, descarta los turnos crudos. Si el cliente vuelve 3 semanas después, recupéralo por ID de conversación, no por texto completo.

Paso 5 — Empieza con una herramienta bien hecha, no con diez. Conecta primero lo más usado (consultar estado de pedido, por ejemplo). Haz un MCP server aunque tu volumen no lo justifique todavía. La disciplina de tener schemas limpios paga después cuando agregues la quinta, sexta, décima herramienta.

Paso 6 — Mide la degradación por crecimiento de contexto. Cada vez que sumes un documento, una herramienta, una fuente de datos, vuelve a correr tu set de preguntas trampa. Si la precisión baja más de 3-4 puntos, la nueva fuente está robando atención a lo que ya funcionaba. Ajusta selectivamente o reconsidera si vale la pena.

Errores comunes que veo una y otra vez

Llevo dos años afinando agentes en producción. Estos son los cinco errores que más se repiten, en orden de frecuencia.

Error 1 — System prompt inflado. Equipos que vuelcan todo en el prompt “para que el bot lo sepa”. El resultado: cuando llega un documento recuperado importante, queda en la cola baja de atención del modelo. Recorta tu prompt a lo esencial. El resto va en RAG.

Error 2 — Retrieval con k alto. “Mejor que sobre a que falte”. El modelo igual ignora los últimos 5 de 10 documentos. Y los paga en tokens y en latencia. k=3 a k=5, siempre.

Error 3 — Memoria de sesión cargada completa. “Para que el bot recuerde todo”. No. La ventana no escala. Lo que el cliente dijo en el turno 1 probablemente ya no aplica en el turno 15. Compacta.

Error 4 — Todas las herramientas activas a la vez. “Para que el bot pueda hacer de todo”. El modelo no decide bien entre 25 opciones. Lo he medido: con más de 15 herramientas activas, la precisión de selección cae entre 8% y 18%. Agrupa en MCP servers por dominio (ventas, soporte, logística) y solo carga el grupo relevante según la intención detectada.

Error 5 — Confundir “tener RAG” con “tener context engineering”. RAG es uno de los cuatro pilares. Si los otros tres están mal, RAG solo no salva al agente. He visto bots con RAG excelente caer al 60% de precisión porque el system prompt era un muro de 4.000 tokens y no había compactación de memoria.

Plan de acción de 7 días

Si tu agente de WhatsApp ya está en producción y sospechas que el prompt ya no es el problema, este plan te lleva del síntoma a la solución estructurada.

Día 1 (1 hora): Lista todo lo que entra a la ventana de tu agente hoy. System prompt, cuántos tokens. Cuántas herramientas, cuántos documentos por retrieval promedio, cuánta memoria de sesión. Esa es tu línea base.

Día 2 (2 horas): Recorta el system prompt a menos de 1.000 tokens. Lo que sobra, mándalo a un documento. Pasa el mismo set de pruebas. Compara.

Día 3 (3 horas): Ajusta el retrieval. k=5, umbral de similitud explícito, reranker si tu presupuesto lo permite. Pasa el set de pruebas. Compara.

Día 4 (2 horas): Implementa compactación de memoria de sesión. Cada vez que se resuelve un tema, genera un resumen de 2-3 oraciones y descarta los turnos crudos. Pasa el set de pruebas. Compara.

Día 5 (2 horas): Agrupa herramientas por dominio. Carga solo el grupo relevante según la intención. Si no tienes MCP server, evalúa si vale la pena migrar una herramienta como piloto.

Día 6 (1 hora): Documenta el nuevo flujo: qué entra al contexto, qué se descarta, qué se compacta, qué se persiste. Este documento es el que va a evitar que el siguiente dev junior revierta todo en un mes.

Día 7 (1 hora): Mide de nuevo las métricas de producción (tasa de escalación, muestreo semanal, set de preguntas trampa). Compara con la línea base del día 1. En mi experiencia, los bots bien afinados por este proceso bajan la tasa de alucinación entre 30% y 50% en producción sin cambiar de modelo.

¿Y si mi agente no está en TecnoChat?

Todo lo de esta guía aplica a cualquier agente, sea cual sea la plataforma. Los principios son los mismos. La diferencia es cuánto control te da la plataforma sobre cada pilar.

Si estás evaluando una plataforma de agentes de IA para WhatsApp, las cuatro preguntas que importan son: (1) ¿puedo editar el system prompt sin límite y versionarlo? (2) ¿puedo controlar k, umbral y reranker de mi retrieval, o es caja negra? (3) ¿la memoria de sesión se compacta automáticamente o la pago completa en tokens cada turno? (4) ¿puedo conectar herramientas vía MCP o me obligas a integraciones a medida?

Si la respuesta a cualquiera es “no”, no es una plataforma de producción. Es un demo glorificado. Y en 2026, un demo en WhatsApp hablando con tus clientes es un riesgo que no vale la pena correr.

¿Atascado diagnosticando por qué tu agente alucina o “se olvida” de cosas? Escríbeme a [email protected] y lo revisamos juntos. He visto suficientes agentes rotos para saber qué falla y por qué, casi siempre es uno de los cuatro pilares.