"Prompt engineer" nunca fue un título de trabajo preciso, pero durante un tiempo no hizo falta que lo fuera. Si todo tu trabajo consistía en obtener una buena respuesta de una sola llamada de inferencia, un solo conjunto de habilidades bastaba: redactar bien la instrucción, dar un par de ejemplos, tal vez agregar algo de texto recuperado, y listo. Ese conjunto de habilidades todavía importa. Pero ya no cubre lo que significa "construir un agente" a mediados de 2026, y esa brecha se está manifestando como un modo de falla específico y reconocible: agentes que funcionan de maravilla en una demo y luego se degradan silenciosamente, se contradicen, u olvidan lo que el usuario les dijo dos sesiones atrás.
Un artículo reciente de Machine Learning Mastery nombra la brecha directamente, y vale la pena detenerse en él porque se corresponde claramente con dos trabajos distintos para los que en realidad podrían contratarte. La ingeniería de contexto es lo que ocurre dentro de una sola llamada de inferencia: decidir qué entra en la ventana de contexto, en qué lugar de la estructura va, y qué se comprime o se descarta para que el modelo no se ahogue en tokens irrelevantes. La ingeniería de memoria es un problema distinto que solo existe entre llamadas: qué queda registrado después de que termina una sesión, dónde se almacena, cómo se recupera la próxima vez, y cómo se mantiene (se actualiza, se deduplica, expira) para que no se pudra. Según ese artículo, las fallas que aparecen en flujos de trabajo de agentes largos y de múltiples sesiones suelen rastrearse hasta la confusión entre estos dos trabajos, o hasta omitir uno de ellos, especialmente en lo que llaman el "límite de recuperación", el momento en que un agente tiene que decidir si algo que necesita ya está frente a él o si tiene que buscarlo en el almacenamiento.
Por qué confundirlos es el verdadero error, no un detalle
Piensa en qué está optimizando cada disciplina. La ingeniería de contexto optimiza una ventana única, acotada y desechable: poner el fragmento correcto de información frente al modelo justo ahora, para este único intercambio, y luego descartar el resto. La ingeniería de memoria optimiza un almacén duradero que tiene que sobrevivir entre sesiones, mantenerse consistente a medida que llega nueva información, y responder una pregunta mucho más difícil: no "qué es relevante para este prompt", sino "qué vale la pena conservar, y por cuánto tiempo".
Son problemas de diseño distintos con distintos modos de falla. Un error de ingeniería de contexto empeora una sola respuesta. Un error de ingeniería de memoria se acumula: las escrituras defectuosas se van sumando, los hechos obsoletos se recuperan como si fueran vigentes, y nadie se da cuenta hasta que el agente repite con total confianza algo que ya se había corregido tres sesiones atrás. Si una sola persona (o una sola plantilla de prompt) está haciendo ambos trabajos en silencio sin distinguirlos, la capa de memoria tiende a heredar hábitos de ingeniería de contexto que no debería: sobrecargar el almacenamiento igual que sobrecargarías una ventana, o tratar la recuperación como un problema de ranking de relevancia cuando en realidad es un problema de curaduría y mantenimiento. Esa es la confusión que señala el resumen de investigación, y coincide con algo que los profesionales ya describen de forma anecdótica: agentes que impresionan en una sola sesión y resultan poco confiables para la quinta sesión.
Cómo es realmente cada trabajo en el día a día
Si estás tratando de averiguar cuál de estos dos ya estás haciendo, o hacia cuál te gustaría orientarte, el trabajo del día a día se ve lo suficientemente distinto como para diferenciarlos:
La ingeniería de contexto, en la práctica: decidir qué subconjunto de la información disponible (documentos, salidas de herramientas, turnos anteriores) realmente pertenece a esta llamada; elegir en qué parte del prompt va, ya que la posición afecta cómo el modelo la pondera; escribir pasos de compresión o resumen para que un registro largo de una herramienta no consuma todo el presupuesto; y ajustar esto según la tarea, ya que un agente de depuración y un agente de escritura quieren formas de contexto distintas incluso sobre el mismo modelo subyacente.
La ingeniería de memoria, en la práctica: definir una política de escritura (qué vale la pena persistir después de una sesión, porque no todo lo vale); elegir una capa de almacenamiento (una base vectorial, una base de datos estructurada, archivos planos, algún híbrido) y ser honesto sobre las contrapartidas de cada una; construir la estrategia de recuperación que decide qué vuelve a salir y cuándo; y realizar mantenimiento continuo: podar, fusionar hechos duplicados, manejar contradicciones cuando el usuario cambia de opinión. Esa última parte, el mantenimiento, es la que la gente más suele omitir, porque no se nota hasta que un agente lleva semanas funcionando.
Se puede ver que la industria empieza a separar estas cuestiones de forma estructural, no solo conceptual. El tutorial de Lenny's Newsletter sobre cómo construir un arnés de depuración con el Claude Agent SDK trata los permisos, los adaptadores de herramientas y el "arnés" circundante como una superficie de ingeniería propia, distinta del prompting que ocurre dentro de él: el mismo instinto, aplicado a otra costura. Y las funciones más nuevas de "Managed Agents" de la API de Gemini de Google (ejecución en segundo plano, renovación de credenciales entre interacciones) son, en efecto, el proveedor de la plataforma admitiendo que el estado persistente entre sesiones ya es infraestructura que hay que diseñar, no un efecto secundario de una ventana de contexto suficientemente larga. Alguien tiene que hacerse cargo de ese diseño. Ahora mismo, en muchos equipos, nadie lo hace explícitamente.
Por qué esto importa para tu título de trabajo, no solo para tu código
Si estás en un punto temprano o intermedio de tu carrera y tienes "prompt engineer" o "AI engineer" en tu currículum, vale la pena preguntarte de cuál de estos dos trabajos puedes realmente mostrar evidencia, porque los roles generalistas de agentes de IA están empezando a fragmentarse en otros más específicos, de la misma forma en que "webmaster" terminó dividiéndose en frontend, backend y DevOps. Esto es una salvedad, no un titular: todavía no he visto datos duros de contratación que confirmen a "memory engineer" como un título independiente, así que tómalo como una lectura de hacia dónde va el trabajo, no como una afirmación de que las bolsas de empleo ya están organizadas así. Pero la presión de fondo es real y se puede rastrear hasta el resumen mencionado antes: los equipos de agentes están topándose con una falla específica y nombrable (la degradación entre múltiples sesiones) que tiene una causa específica y nombrable (confundir dos disciplinas), y esa combinación suele ser justo lo que convierte un rol difuso en dos roles nítidos.
La jugada práctica no es inventarte un título. Es poder responder, en concreto, qué problema resolviste realmente. ¿Has lanzado algo en lo que diseñaste una política de escritura, una regla sobre qué confía un agente a la memoria y qué descarta? ¿Has depurado una falla en el límite de recuperación, en la que un agente necesitaba algo del almacenamiento y o no lo buscó o buscó la versión equivocada? Esas son afirmaciones verificables que puedes hacer en una entrevista, respaldadas por un repositorio o un postmortem, y dicen algo que un genérico "escribo buenos prompts" no dice: que entiendes la diferencia entre mejorar una sola respuesta y hacer que un agente sea confiable a lo largo del tiempo.
Una advertencia
No te reetiquetes como "memory engineer" solo por haber agregado una base de datos vectorial a un proyecto una vez. La disciplina que señala la investigación incluye la mitad poco glamorosa (mantenimiento, expiración, manejo de contradicciones), y esa es la mitad que realmente evita el modo de falla descrito antes. Si tu pieza de portafolio es un sistema que escribe en la memoria pero donde nunca se poda ni se corrige nada, has construido solo la mitad del trabajo de un memory engineer, y el problema de fallar después de la tercera sesión sigue esperándote en la otra mitad.