Agent memory is now a product feature, and someone has to own it

An Agent Memory and Personalisation Engineer builds the layer that lets an agent remember people across sessions and act on it. That means deciding what is kept, how it is stored, when it comes back and when it is forgotten.

The work is changing because memory has moved from a research idea to a shipped feature. Vendors now sell it as a managed service, and large platforms have built their own. The plumbing is getting easier to buy. The judgement about what an agent should remember is not.

What agents already do

Most agents still lose everything when a session ends. Microsoft describes the gap between short-term session memory and continuity over days or weeks, and offers a pattern for memory scoped to each user.

The mechanical parts of the pipeline are increasingly automated. Twilio's Conversation Memory extracts what matters from conversations across channels, ties it to a persistent customer profile and handles threading, identity resolution, vectorising, reconciling and recalling. A single call retrieves the relevant context.

Decagon's user memory keeps conversation history so a customer can return days later without re-explaining, and pulls out signals such as feature requests, sentiment and stated preferences as structured metadata. Storage is opt-in and has expiry controls.

Agents also decide for themselves what to save. Coherence describes memory scoped to the user, the account and the platform, and its agent saves what matters during a run. LinkedIn's Cognitive Memory Agent stores and retrieves relevant information without users specifying it, and its agents can fetch earlier preferences and resolve conflicts between them.

Where agents help and a person decides

Agents can propose what to remember. A person decides what is worth remembering and what is out of bounds.

Automatic extraction will happily capture a sentiment or a preference. Whether that fact should be stored, for how long, and who may see it is a design call. The same goes for conflict handling. An agent can flag that two stored facts contradict. Choosing whether the newer one wins, whether to ask the user, or whether to let the fact decay is a rule someone has to write and defend.

Scope is another shared area. Writer argues that enterprise memory should capture the work, meaning tasks, requirements and team conventions, and not only personal facts. Choosing which model of memory fits the product is an engineering judgement that tools do not make for you.

Storing a fact is cheap. Deciding it should have been forgotten is the job.

What still needs a person

Privacy and deletion. Persisting memory raises questions of privacy, data isolation and governance, as Microsoft notes, especially when many users share an agent. A deletion request has to reach raw data, summaries, embeddings, caches and logs. Legal and security need to sign off, and someone has to be accountable for it.

Evaluation. Memory can help or it can feel stale, wrong or intrusive. Showing which is happening needs test sets, comparisons with and without memory, and checks for harm. Demos and opinion do not count as evidence.

Debugging wrong recall. When an agent brings up the wrong thing, someone has to trace why. Multi-agent setups make this harder. One practitioner talk reports that multi-agent systems can contradict each other and are hard to debug, which is why shared memory has to stay transparent.

Fit with the rest of the system. Memory has to feed tool use and planning, so the engineer works closely with application and orchestration colleagues.

What this means for who you hire

The profile gaining value is the engineer who treats memory as a behaviour problem. They combine retrieval skill, an understanding of how agents act on what they recall, and privacy engineering. They can explain a failure as readily as a design.

The profile losing value is the one whose skill is wiring up a vector store and a retrieval call. That work is now a managed service or a library. If a candidate talks only about vector search and never about forgetting, consent or evaluation, the gap will show in production.

Be honest about scarcity. Almost nobody carries this title, and the work often sits inside application, search or platform roles, so CVs rarely signal it. Real production experience tends to sit at consumer products, and those people are rarely looking.

How to spot a strong candidate

Describe a memory system you built. What did it store, and what did you choose not to store?

A good answer names concrete memory types and gives reasons for the exclusions, weighing privacy and usefulness together. Worry if everything is stored by default.

A user asks the agent to forget something. Walk me through what happens across your system.

A good answer traces raw data, summaries, embeddings, caches and logs, and mentions verification. Worry if deletion touches only one store.

Also ask where their system failed. Strong candidates describe wrong recall, stale facts and contradictions, and what they changed.

Where to find them

Start with application engineers, workflow automation builders and systems integrators who have moved into agent work. Search, ranking and recommendation engineers are the strongest adjacent pool, though check whether they have worked with language model agents. Privacy engineers who have handled data retention are worth a conversation.

Most come from consumer AI products and assistant teams, where long-term memory became a real problem first. Expect titles such as backend engineer, ML engineer or applied AI engineer. Job adverts for the work already pair memory with retrieval, personalisation and evaluation, for example in this senior listing, which asks for offline and online evaluation of memory quality.

Our own analysis, drawn from the role profile in our job families library and recent public reporting on how agents are used in this work. Titles and practice vary by company.