# The DeepLearning.AI and Oracle Agent Memory course: keep the thinking, swap the database layer

> Two Oracle staff teach the course's two hours of video. What a forward deployed engineer should take to a client is the design of the memory pipeline. The database can be swapped out.

Original: https://fdetimes.net/en/books-courses/deeplearning-ai-oracle-agent-memory-course/

The introduction to Agent Memory: Building Memory-Aware Agents on DeepLearning.AI opens with a problem anyone who has put an agent into production will recognise. Most agents work well within a single session, then forget everything once it ends. Users have to repeat every instruction they gave before.

Forward deployed engineers rarely see this failure in the demo. It tends to appear in the second week, when real users start asking the agent why it has forgotten what they told it yesterday.

The course goes straight at that problem, but it was made with a company that sells databases. So the useful question is what to learn from it, and what to leave out when your client does not run Oracle.

## Who teaches it, and who is it for?

This is a short course made jointly by DeepLearning.AI and Oracle. The instructors are Richmond Alake, Director of AI Developer Experience at Oracle, and Nacho Martínez, Principal Data Science Advocate at Oracle. The vendor wrote the material, and the stack it uses is Oracle AI Database, LangChain and LLM-driven pipelines.

That does not make the course less useful, but it should be watched with the eye of someone who has to deploy on a client's infrastructure. The course page says it is for developers who have already built agents and want to go beyond single-session interactions. The only prerequisites are Python and a basic understanding of LLMs. No Oracle knowledge is needed.

## Seven videos, three that matter most

The course has 7 videos. The header of the course page gives a total running time of 2 hours 2 minutes, while some search results show 1 hour 57 minutes. The three longest lessons are also the most hands-on, and each comes with sample code: Memory Manager (22 minutes), Memory Operations (23 minutes) and Memory Aware Agent (20 minutes).

Take them in order, because the last one is a capstone: an agent that keeps its state across sessions and reloads earlier context as soon as it starts. If you only have one evening, spend most of it on the three code lessons, and type the code out yourself rather than just watching.

## Idea one: memory is infrastructure, not a chunk of prompt

The course calls its approach memory engineering: treating long-term memory as core infrastructure that sits outside the model. That change in thinking matters more than any line of code in the course.

**Key point:** An agent's memory is infrastructure you design, not something the model comes with.

Once memory counts as infrastructure, you start asking an infrastructure engineer's questions. Where does the data live, who can read it, when does it expire, and how do you correct it when it is wrong? The client's security team will ask you the same things.

## Idea two: remembering is a pipeline, not an insert statement

One of the course's stated goals is to build a Memory Manager that handles several types of memory, together with a three-step pipeline: extract, consolidate and write. The middle step is the one most often skipped.

Picture an internal support agent. In session 1, a user says their team uses Postgres. In session 3, they say the team has moved to Snowflake.

If the pipeline only extracts facts and writes them straight to the store, the agent keeps both "facts" and may answer from the old one. The consolidation step has to spot that the two records conflict and update the old one instead of adding a second.

A minimal sketch of this step looks like the code below. It is an illustration, not code from the course:

```python
def consolidate(new_fact, store):
    # Look for an existing record for the same user and topic (e.g. "team database")
    old = store.find(user_id=new_fact.user_id, key=new_fact.key)
    if old is None:
        store.insert(new_fact)                      # something new: add it
    elif old.value != new_fact.value:
        store.update(old.id, value=new_fact.value)  # changed mind: overwrite, don't append
    # identical to the old record: skip it to avoid duplicates
```

The hard part in practice is generating a stable `key`, so that "we use Postgres" and "we've moved to Snowflake" land under the same topic. At a client site, the first thing to do is write a few change-of-mind scenarios like this one as tests, before you even choose a database.

## Idea three: the tool list can be retrieved too

A 17-minute lesson covers semantic tool memory, a way to increase the number of tools an agent can use. It is a retrieval pattern and works with any vector store.

Say a client has hundreds of internal APIs. Stuffing every description into the prompt wastes tokens and leads the model to pick the wrong one. A better approach is to embed each tool's description and, on each turn, pass in only the few tools closest in meaning to the request.

## What to drop when the client does not use Oracle

The Oracle-specific part is fairly contained. It sits in the langchain-oracledb package and its OracleVS vector store, and the python-oracledb driver is installed along with it. Hybrid search alone requires Oracle Database 26ai. If the client does not run Oracle, this is the layer you replace.

The rest still works because of how LangGraph is already organised. LangGraph's documentation keeps short-term, thread-scoped memory separate from long-term memory, which stores user- or application-specific data across conversations.

For short-term memory, LangGraph recommends a database-backed checkpointer in production. Long-term memory is a separate store, but it is still just a storage layer. Both layers can run on the database the client already operates.

So in the first discovery session, ask which database the client runs and who manages it. The answer decides where the memory pipeline lives. The design of the pipeline stays the same.

## How to put this skill on your CV

When reading FDE job descriptions, look for phrases such as stateful agent, long-term memory or multi-session. When you see them, have a concrete example ready for the interview of how you dealt with an agent losing context between sessions.

A course completion certificate says little. A small repo carries more weight: rebuild the capstone on a database other than Oracle, with a test suite for the change-of-mind scenarios. It shows an interviewer that you can separate an idea from its vendor, which is something FDEs do every week.

The course teaches an agent how to remember. Deciding where that memory lives in the client's infrastructure remains the FDE's job.

**Try this week:**

- Watch the Memory Manager, Memory Operations and Memory Aware Agent lessons, then rewrite the code using the database you already work with instead of Oracle.
- Pick an agent you have built, write down three facts a user might state in session 1 and then change in session 3, and check whether the agent overwrites them correctly or just piles up new records.
- Read LangGraph's Add memory page, then split your demo into two layers: a database-backed checkpointer for per-thread state, and a separate store for long-term memory across sessions, both on the database you already use.

## Sources

- [✨ New course! Enroll in Agent Memory: Building Memory-Aware Agents](https://community.deeplearning.ai/t/new-course-enroll-in-agent-memory-building-memory-aware-agents/890523)

- [Agent Memory: Building Memory-Aware Agents - DeepLearning.AI](https://www.deeplearning.ai/short-courses/agent-memory-building-memory-aware-agents/)

- [Oracle AI Vector Search: Vector Store - LangChain docs](https://docs.langchain.com/oss/python/integrations/vectorstores/oracle)

- [Add memory - LangGraph docs (LangChain)](https://docs.langchain.com/oss/python/langgraph/add-memory)