Our new short course with DeepLearning.AI, Building Adaptive AI Agents, is live today. It covers continual and adaptive learning: the different ways in which you can make an agent better over time, and how to do it on Oracle AI Database 26ai.
Key Takeaways
- Agents forget because what one session works out rarely survives into the next: some setups carry a little project context, almost none carry the reasoning behind it.
- The cheapest fixes live in the token space, turning yesterday’s traces into reusable skills and restructuring memory, with zero training.
- Structure beats keywords: we also explore Code Knowledge Graphs, a way to let agents find the correct context faster than simple regular expression matching.
- Weight-space adaptation (retraining or finetuning) is the expensive tier you reach for only when context injection, processing and manipulation stops generalizing.
- Best practice is an effort ladder: start cheap, and climb only when you must.
Why does your agent keep paying the same bill twice?
You ask your agent to add a field to the checkout flow. Before it writes a line, it greps for “checkout”, opens six files to work out where the data layer actually lives, and reads through your ORM setup. Twelve tool calls to build a map of a codebase that has not moved since Friday.
It builds that map again on Tuesday. And on Wednesday.
How much of last month’s token spend went on your agent rediscovering things it already knew?
The failure everyone braces for with coding agents is the wrong answer. That is not the one that costs the most. The one that costs the most is the right answer, worked out correctly, thrown away when the session closed, and then worked out again from scratch the next morning.
Watch it happen on something smaller
Your agent writes a query against your own schema and hits an error:
ORA-00904: "CREATED_AT": invalid identifier
So it reads the schema, figures out the column it actually needed is DATE_CREATED, fixes the query and moves on. Fine. That is the agent doing its job.
Then the next day it is queried again, and starts a fresh session with a blank context window. Nothing reminds the new conversation that CREATED_AT was wrong yesterday, so it figures it out all over again. Identical failure, identical token spend, and nothing learned, so you’re essentially wasting tokens and time on unnecessary tool calls, thinking budget, context window buildup, etc.
There is usually an absence of a feedback loop. The agent learned something valuable yesterday and then threw it away with the context window after it was done. Continual learning is the discipline of making an agent better over time, and it runs all the way from reusing yesterday’s traces up to retraining the model itself. This piece, and most of the available wins, sit at the cheap end of that range: feeding the traces back so the agent stops paying for the same work twice.
Nacho spent the past couple of months watching agents fail this way, and looking at how frontier labs fix it: finetuning models, building better agent harnesses, fresh training runs. All of it assumes compute most of us do not have, and all of it reaches for the most expensive item on the list to fix something that was rarely broken there in the first place.
So the question that started this course was a smaller one. “My agent is live and getting things wrong. What is the cheapest change that makes it better, and how do I do it?” Put another way: is there anything we can do with the data we already have?
Which kind of memory is your agent actually missing?
Every autonomous agent runs the same loop: perceive, decide, act, observe, repeat. Each turn through that loop leaves traces, and those traces land in one of four memory forms:
| Memory form | What it stores | AI agent example |
| Working | What the agent is thinking about right now | Scratchpad, AI agent notes, TODOs, etc. |
| Episodic | Specific past events | Previous agent conversations, errors that happened, etc. |
| Semantic | Stable facts | Domain knowledge about the company, private data, private database schemas, etc. |
| Procedural | How to do things | Skills, skill chains, workflows, notes to self, etc. |
The four forms decay at different speeds, and they have different degrees of permanence: working memory evaporates, episodic memory (usually) fades, semantic facts last years, and procedural skills are almost set in stone.
What your agent has at the end of Monday is episodic: the session where it grepped, opened six files and worked out where the data layer lives. What it needs on Tuesday is two other things. The map itself, which barely changes, is a semantic fact. How to find the next one is a procedural skill. Nothing in a default setup turns the episode into either, so it stays an episode and dies with the context window. Which form your agent is missing decides where in the course you should start.
We built Building Adaptive AI Agents with Andrew Ng and the team at DeepLearning.AI. Nacho Martinez and Casius Lee wrote it on the Oracle Developers side, and we are both genuinely happy about how this partnership came together. It goes through all four memory forms with the code: skill extraction from real agent traces, a Code Knowledge Graph built and queried, and LoRA adapters for the point where context injection stops generalizing.
It is live today. Your agent left the traces this morning and they are still sitting there.
Take the course on DeepLearning.AI
Frequently Asked Questions
What is continual learning?
Continual learning is the practice of feeding what an agent worked out in one session back into the next one, so it stops rediscovering things it already knew. It covers everything from turning yesterday’s traces into reusable skills, through restructuring how memory is retrieved, up to retraining the model itself.
What is the token layer vs the weight layer?
The token layer is everything you can change without touching the model: what goes into the context window, which skills and memories get retrieved, and how they are structured. The weight layer means changing the model itself, through retraining or finetuning. Token-layer changes are cheap, take effect on the next run, and are where most of the available wins are. Weight-layer changes are expensive, and they are for the case where no amount of context injection produces the behavior reliably.
When do I need structure-aware retrieval?
When the right memory exists but retrieval misses it: especially multi-hop questions where the answer lives two edges away from the query. Build the graph, seed anchors, and let a PageRank walk find what keyword search can’t.
When do I actually fine-tune the embedder?
When retrieval fails because the embedder doesn’t understand your domain’s semantics: an agent needs “the code it will use next,” not “the code that looks similar.” Fine-tune on graded retrieval traces.
When do I need to fine-tune the weights?
When the fix must generalize across a whole class of task and no context injection reliably produces it: removing a default behavior, installing a persona. In the course we explore the use of quantization and LoRA adapters, that can allow cheap finetuning.
What’s the cheapest first step?
Analyze the traces you already have as you’ve been using your agents (Claude, Codex, etc.). We’ll teach you how to make use of those traces your agent already leaves behind.
Resources
• Course: Building Adaptive AI Agents, a DeepLearning.AI short course built with Oracle, live 26 August 2026
• Agent memory: Oracle AI Agent Memory documentation and oracleagentmemory 26.6.0
• Database: Oracle AI Database 26ai: HNSW vector indexes, VECTOR_DISTANCE, and property-graph (PGQ) traversal