"Prompt engineer" was never a precise job title, but for a while it didn't need to be. If your whole job was getting a single good response out of a single inference call, one skill set covered it: word the instruction well, give a couple of examples, maybe add some retrieved text, done. That skill set still matters. But it no longer covers what "building an agent" means in mid-2026, and the gap is showing up as a specific, recognizable failure mode: agents that work great in a demo and then quietly degrade, contradict themselves, or forget what the user told them two sessions ago.
A recent piece from Machine Learning Mastery names the gap directly, and it's worth sitting with because it maps cleanly onto two different jobs you could actually be hired to do. Context engineering is what happens inside one inference call: deciding what goes into the context window, where it goes structurally, and what gets compressed or dropped so the model isn't drowning in irrelevant tokens. Memory engineering is a different problem that only exists across calls: what gets written down after a session ends, where it's stored, how it's retrieved next time, and how it's maintained (updated, deduplicated, expired) so it doesn't rot. Per that piece, the failures that show up in long, multi-session agent workflows most often trace back to conflating these two jobs, or skipping one of them — especially at what they call the "retrieval boundary," the moment an agent has to decide whether something it needs is sitting in front of it or has to be fetched from storage.
Why conflating them is the actual bug, not a detail
Think about what each discipline is optimizing for. Context engineering is optimizing a single, bounded, disposable window — get the right slice of information in front of the model right now, for this one exchange, then throw the rest away. Memory engineering is optimizing a durable store that has to survive across sessions, stay consistent as new information arrives, and answer a much harder question: not "what's relevant to this prompt" but "what's worth keeping at all, and for how long."
Those are different design problems with different failure modes. A context-engineering mistake makes one response worse. A memory-engineering mistake compounds — bad writes accumulate, stale facts get retrieved as if they were current, and nobody notices until the agent confidently repeats something that was corrected three sessions ago. If one person (or one prompt template) is quietly doing both jobs without distinguishing them, the memory layer tends to inherit context-engineering habits it shouldn't: over-stuffing storage the way you'd over-stuff a window, or treating retrieval as a relevance-ranking problem when it's really a curation-and-maintenance problem. That's the conflation the research digest is pointing at, and it lines up with something practitioners already describe anecdotally: agents that are impressive in a single session and unreliable by session five.
What each job actually looks like day to day
If you're trying to figure out which of these you're already doing, or which one you'd want to build toward, the day-to-day work looks different enough to tell apart:
Context engineering, in practice: deciding what subset of available information (docs, tool outputs, prior turns) actually belongs in this call; choosing where in the prompt it goes, since position affects how models weight it; writing compression or summarization steps so a long tool trace doesn't eat the whole budget; and tuning this per task, since a debugging agent and a writing agent want different context shapes even on the same underlying model.
Memory engineering, in practice: defining a write policy (what's worth persisting after a session — not everything is); picking a storage layer (a vector store, a structured database, plain files, some hybrid) and being honest about the tradeoffs of each; building the retrieval strategy that decides what comes back out and when; and doing ongoing maintenance — pruning, merging duplicate facts, handling contradictions when the user changes their mind. That last part, maintenance, is the one people skip most often, because it's not visible until an agent has been running for weeks.
You can see the industry starting to separate these concerns structurally, not just conceptually. Lenny's Newsletter's walkthrough of building a debugging harness on the Claude Agent SDK treats permissions, tool adapters, and the surrounding "harness" as their own engineering surface distinct from the prompting inside it — the same instinct, applied to a different seam. And Google's newer Gemini API "Managed Agents" features — background execution, credential refresh across interactions — are effectively the platform vendor admitting that session-persistent state is now infrastructure that has to be designed, not a side effect of a long enough context window. Someone has to own that design. Right now, on a lot of teams, nobody explicitly does.
Why this matters for your job title, not just your code
If you're early or mid-career and "prompt engineer" or "AI engineer" is on your resume, it's worth asking which of these two jobs you can actually point to evidence of doing — because generalist AI-agent roles are starting to get pulled apart into more specific ones, the same way "webmaster" eventually split into frontend, backend, and DevOps. That's a hedge, not a headline: I haven't seen hard hiring data confirming "memory engineer" as a standalone title yet, so treat this as a read on where the work is heading, not a claim that job boards are already sorted this way. But the underlying pressure is real and traceable to the digest above: agent teams are hitting a specific, nameable failure (multi-session degradation) that has a specific, nameable cause (conflating two disciplines), and that combination is usually what turns a blurry role into two sharp ones.
The practical move isn't to invent a title for yourself. It's to be able to answer, concretely, which problem you've actually solved. Have you shipped something where you designed a write policy — a rule for what an agent commits to memory and what it discards? Have you debugged a retrieval-boundary failure, where an agent needed something from storage and either didn't fetch it or fetched the wrong version? Those are checkable claims you can make in an interview, backed by a repo or a postmortem, and they say something a generic "I write good prompts" doesn't: that you understand the difference between making one answer better and making an agent trustworthy over time.
A caution
Don't relabel yourself "memory engineer" on the strength of having added a vector database to a project once. The discipline the research points at includes the unglamorous half — maintenance, expiry, contradiction handling — and that's the half that actually prevents the failure mode described above. If your portfolio piece is a system that writes to memory but nothing ever gets pruned or corrected, you've built half a memory engineer's job, and the failing-after-session-three problem is still waiting for you on the other half.