"Ingeniero de prompts" nunca fue un título de trabajo preciso, pero durante un tiempo no necesitó serlo. Si tu trabajo consistía enteramente en obtener una buena respuesta de una sola llamada de inferencia, un único conjunto de habilidades bastaba: redactar bien la instrucción, dar un par de ejemplos, quizá añadir algo de texto recuperado, y listo. Ese conjunto de habilidades sigue siendo importante. Pero ya no cubre lo que significa "construir un agente" a mediados de 2026, y la brecha se manifiesta como un fallo específico y reconocible: agentes que funcionan de maravilla en una demo y luego se degradan silenciosamente, se contradicen o olvidan lo que el usuario les dijo dos sesiones atrás.
Un artículo reciente de Machine Learning Mastery nombra esta brecha directamente, y vale la pena detenerse en él porque encaja perfectamente 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é se registra 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, caduca) para que no se degrade. Según ese artículo, los fallos que aparecen en flujos de trabajo de agentes largos y multisesión suelen remontarse a confundir estos dos trabajos, o a saltarse 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 está justo delante de él o debe obtenerse del almacenamiento.
Por qué confundirlos es el verdadero problema, 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 delante del modelo ahora mismo, 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 coherente a medida que llega nueva información, y responder a una pregunta mucho más difícil: no "qué es relevante para este prompt" sino "qué merece la pena conservar, y por cuánto tiempo".
Son problemas de diseño distintos con modos de fallo distintos. Un error de ingeniería de contexto empeora una respuesta. Un error de ingeniería de memoria se acumula: las escrituras defectuosas se van sumando, los datos obsoletos se recuperan como si fueran actuales, y nadie se da cuenta hasta que el agente repite con total confianza algo que se corrigió tres sesiones atrás. Si una sola persona (o una sola plantilla de prompt) hace silenciosamente ambos trabajos 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 se sobrecargaría una ventana, o tratar la recuperación como un problema de ranking de relevancia cuando en realidad es un problema de curación 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 impresionantes en una sola sesión y poco fiables a partir de la quinta.
Cómo es cada trabajo en el día a día
Si estás intentando averiguar cuál de estos dos ya estás haciendo, o hacia cuál te gustaría orientarte, el trabajo cotidiano es lo bastante distinto como para diferenciarlos:
La ingeniería de contexto, en la práctica: consiste en decidir qué subconjunto de la información disponible (documentos, salidas de herramientas, turnos anteriores) realmente pertenece a esta llamada; elegir en qué lugar del prompt va, ya que la posición afecta a cómo el modelo la pondera; escribir pasos de compresión o resumen para que un rastro largo de una herramienta no consuma todo el presupuesto; y ajustar todo esto según la tarea, ya que un agente de depuración y un agente de escritura quieren formas de contexto distintas incluso con el mismo modelo subyacente.
La ingeniería de memoria, en la práctica: consiste en definir una política de escritura (qué merece la pena persistir después de una sesión, que no es todo); elegir una capa de almacenamiento (una base de datos 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, gestionar contradicciones cuando el usuario cambia de opinión. Esa última parte, el mantenimiento, es la que la gente más se salta, porque no se hace visible hasta que un agente lleva semanas funcionando.
Se puede ver cómo la industria empieza a separar estas cuestiones de forma estructural, no solo conceptual. El recorrido 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 hay dentro de él: el mismo instinto, aplicado a otra costura. Y las nuevas funciones de "Managed Agents" de la API Gemini de Google (ejecución en segundo plano, renovación de credenciales entre interacciones) son, en la práctica, el proveedor de la plataforma admitiendo que el estado persistente entre sesiones es ahora infraestructura que hay que diseñar, no un efecto secundario de una ventana de contexto suficientemente larga. Alguien tiene que responsabilizarse 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 una etapa temprana o intermedia de tu carrera y "ingeniero de prompts" o "ingeniero de IA" figura en tu currículum, vale la pena preguntarse de cuál de estos dos trabajos puedes realmente mostrar pruebas, porque los roles generalistas de agentes de IA están empezando a fragmentarse en otros más específicos, del mismo modo en que "webmaster" acabó dividiéndose en frontend, backend y DevOps. Eso es una cobertura, no un titular: todavía no he visto datos de contratación sólidos que confirmen "ingeniero de memoria" como un título independiente, así que trátalo como una lectura de hacia dónde se dirige el trabajo, no como una afirmación de que las bolsas de empleo ya están organizadas así. Pero la presión subyacente es real y rastreable hasta el resumen mencionado antes: los equipos de agentes están topándose con un fallo específico y nombrable (la degradación multisesión) que tiene una causa específica y nombrable (confundir dos disciplinas), y esa combinación suele ser lo que convierte un rol difuso en dos roles nítidos.
El movimiento práctico no es inventarte un título. Es poder responder, en concreto, a qué problema has resuelto realmente. ¿Has entregado 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 un fallo en el límite de recuperación, en el que un agente necesitaba algo del almacenamiento y o no lo obtuvo o obtuvo la versión equivocada? Esas son afirmaciones verificables que puedes hacer en una entrevista, respaldadas por un repositorio o un post-mortem, y dicen algo que un genérico "escribo buenos prompts" no dice: que entiendes la diferencia entre mejorar una respuesta y hacer que un agente sea fiable con el tiempo.
Una advertencia
No te reetiquetes como "ingeniero de memoria" solo por haber añadido una base de datos vectorial a un proyecto una vez. La disciplina que señala la investigación incluye la mitad poco glamorosa (mantenimiento, caducidad, gestión de contradicciones), y esa es la mitad que realmente evita el fallo descrito antes. Si tu pieza de portafolio es un sistema que escribe en la memoria pero nunca poda ni corrige nada, has construido la mitad del trabajo de un ingeniero de memoria, y el problema de fallar a partir de la tercera sesión sigue esperándote en la otra mitad.