AI Engineer World's Fair 2026
From Context to Memory: Your Agents Need a Real Memory Layer — Anders Swanson, Oracle
Slide chapters
20 slide and demo groups · Timestamps are approximate.
Read the talk
From Context to Memory: Your Agents Need a Real Memory Layer
Anders Swanson explains how to turn useful agent experience into managed state: form compact memories, retrieve them through several search methods, and use governance and feedback to keep yesterday’s knowledge useful tomorrow.
From a talk by Anders Swanson
At a glance
Ideas worth remembering
Useful experience becomes memory when it survives the session as managed state that another session can retrieve and reuse.
Redact before enrichment and embedding, preserve provenance through linked episodes, and enforce scope on both writes and reads.
Hybrid recall combines semantic, lexical, relational and graph lookup with time and feedback signals, then selects a compact context card with scored evidence.
A memory’s relevance does not establish its validity or usefulness. Lifecycle management, conflict review and downstream feedback keep persistent knowledge from repeating persistent mistakes.
The next support ticket starts from zero
A support agent reads documents, runs queries, reproduces a failure and finds its root cause. The investigation produces something more valuable than an answer: a procedure another agent could reuse. But if that procedure disappears when the session ends, the next similar ticket starts the investigation again. Anders Swanson, a developer advocate for Oracle AI Database, opens with this distinction between information available during a run and experience that survives it.
“Context windows are not memory.” A context window supplies the current run’s input; persistence lets a later run benefit from earlier work. In the support example, losing the procedure means searching documents and running queries again. Each repeated step consumes time and creates another opportunity for an incorrect inference. The useful transition happens when the investigation’s result becomes managed state that a future session can retrieve.
A larger context window does not make that transition happen. More tokens can keep more material in the current session, but long sessions still accumulate irrelevant information and undergo compaction. Markdown scratch pads, wikis and prompt files do preserve some knowledge. Their limitation is the work required to make recall selective, scoped and manageable across many users. Grep can find text; it does not supply the combination of search methods and governance this memory layer needs.
Swanson’s database-vendor perspective gives the argument its blunt punch line: keep adding retrieval, access controls and management to a file hierarchy, and eventually you are building a database. “You could just use a database.” The rest of the talk explains what that database-backed system must do beyond keeping text on disk.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Preserve the useful result, then learn from its reuse
The proposed pattern has four connected jobs:
- Formation: distill experience into structured facts rather than save an undifferentiated transcript dump.
- Recall: combine search methods to recover information relevant to the new task.
- Evolution: consolidate duplicates, resolve conflicts and track when a memory remains valid.
- Evaluation: measure how memories are used and feed those outcomes back into the system.
Governance applies throughout this cycle. Secrets and personal information must be redacted before entering the memory layer. Access must be scoped to the relevant agent, workflow, team or user, especially when multiple tenants share infrastructure. Review, administrative approvals and suppression provide ways to keep stale or poisoned records from continuing to influence agents.
Return to the support investigation. During or after the session, the agent creates a fact from the useful work. The system redacts it, enriches it and stores it. A later session with related context retrieves that fact into a context card—the selected information supplied to the agent for its next task. The observable change is that the later agent can start with the earlier result rather than repeat all the discovery. If reuse succeeds, feedback updates the memory’s score and records its renewed use.
Where does one session’s work become another session’s starting point? The cycle below makes the handoff visible. Persistence carries the fact across sessions; retrieval selects it for the new task; feedback changes how the stored fact should be treated next time. Saving the fact opens the loop, but recording the result of reuse closes it.
A support investigation becomes reusable experience
Read the diagram as text
- Investigate a support ticket. Read documents, run queries, reproduce the failure and find its root cause.
- Form and store a memory. Create a useful fact, redact it, enrich it and persist it.
- Reconstruct later context. Retrieve the fact for a related session so the next agent can reuse prior work.
- Record the outcome. Update feedback scores and information about the memory’s use.
- Investigate a support ticket → Form and store a memory: Distill useful work.
- Form and store a memory → Reconstruct later context: Retrieve for related context.
- Reconstruct later context → Record the outcome: Observe successful use.
- Record the outcome → Form and store a memory: Update the stored memory.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Give the runtime an API and memories a type
Memory is a function the agent runtime invokes. Hooks, MCP, skills or other integration methods connect the runtime to an API that exposes reads, writes, feedback and administrative operations. That API then talks to persistent storage. These are separate responsibilities: the runtime decides when memory is useful, the memory layer manages its operations, and the database stores and queries the records.
A multi-model database offers a practical consolidation: rows, columns, embeddings, full-text search, relational entities and graphs can live behind one database connection. This lets different retrieval methods query the same collection of episodes and facts. Swanson favors that arrangement because it keeps the ingredients of hybrid search together; it is an architectural preference presented here, rather than a comparison of measured outcomes across database designs.
Typing the records helps determine what to store and how to retrieve it:
- Episodic memory: a specific past event or a slice of an agent transcript.
- Semantic memory: facts about workflows, user preferences or other entities.
- Procedural memory: reusable instructions for a task or routine, such as a build step.
- Working state: what the agent is currently doing, potentially valid only for a short period and later promotable to another memory type.
These categories loosely borrow from human memory, but their purpose here is operational. A reusable procedure and temporary working state should not automatically share the same lifetime or lookup strategy. Separating them creates room to choose a search method appropriate to the information the next task needs.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Build lookup paths—and redact before creating them
The storage model is a typed object plus ways to find and interpret it. A memory has an ID, text content, JSON tags and document data. An embedding and vector index support similarity search; a text index supports keyword search. Graph links connect related memories or entities so retrieval can follow relationships beyond a single matching record.
Time and audit history belong in the schema too. When is the memory valid? When was it last used? Who created it, and what was it used for? These fields describe whether the record is still appropriate and preserve its history. A content field alone cannot answer those questions, even if its text looks relevant.
Formation starts by deciding the memory’s lifetime, scope, relationships and metadata. The first processing step is redaction, before enrichment or embedding. That order matters: removing personal information and secrets first keeps them out of the material used to create the memory’s derived representations.
The remaining content can then be enriched with relationships and metadata, scoped to its agent, team or organization, and embedded. Scope reduces the chance that an unrelated workflow receives a confusing memory. Organization-specific policies apply before the record is saved. The point is to make a deliberate write, with enough information to manage the record later.
Compact memories need not lose their supporting context. The system can filter an agent transcript for useful episode candidates, save the distilled record and link it back to the relevant episode. A relational link provides that association; a graph can support broader traversal among related records. This keeps the reusable fact small while preserving a path to the experience that produced it.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Several search branches produce one context card
Recall is a query problem: which stored information should enter the current context? Vector similarity provides the results that look most similar under the embedding model. That can help recover related experience, but it does not cover every lookup. A fact about a known entity may be better retrieved by an exact ID match.
Hybrid search combines complementary signals:
- Vector similarity: find content with similar meaning.
- Lexical search: find matching words through full-text search or a contains operation.
- Relational lookup: find facts associated with known entities or IDs.
- Graph traversal: follow relationships to connected memories and additional context.
- Temporal and feedback signals: consider recency, importance and prior usefulness when choosing results.
The query branches produce candidates that the system fuses, filters with thresholds and reranks. Branch weights can be tuned, and their contributions can be merged into an overall score. A top-K selection then supplies the context card; Swanson uses the top three results as an illustration. The card can retain scored evidence, including that a memory ranked highly on vector search but lower on lexical search, so the agent receives information about how the result was found.
How can semantically related experience and an exact fact both reach the same agent? The flow below shows independent lookup branches converging on a shared selection step. Their contributions remain distinguishable even though the agent receives one context card. The recording sketches weighting and fusion without specifying a score-normalization method or a particular ranking formula, so those choices remain implementation work.
Hybrid recall combines lookup methods before selecting context
Read the diagram as text
- Vector search. Lookup branches — Retrieve semantically similar content.
- Lexical search. Lookup branches — Retrieve keyword matches.
- Entities and graph links. Lookup branches — Look up exact facts and traverse related records.
- Time and feedback. Ranking signals — Supply recency, importance and usefulness signals.
- Fuse and rank. Weight contributions, merge results, apply thresholds and rerank.
- Context card. Return top-K memories with scored evidence about retrieval.
- Vector search → Fuse and rank: Similarity candidates.
- Lexical search → Fuse and rank: Keyword candidates.
- Entities and graph links → Fuse and rank: Facts and connected context.
- Time and feedback → Fuse and rank: Additional ranking signals.
- Fuse and rank → Context card: Select top-K results.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Relevant memories can still be wrong, unsafe or overwhelming
Persistence creates a new problem: yesterday’s useful instruction can become today’s mistake. In the talk’s example, a project once uses NPM and later switches to another build system. The old build memories remain searchable. If recall returns them without accounting for the change, the agent may follow an obsolete procedure. Evolution therefore includes consolidation, lifecycle management and ways to suppress stale facts.
Other failures require different controls:
- Bad scope: a memory reaches the wrong user or workflow. The analogy is opening your account and seeing someone else’s message history. Scope checks must apply on both write and read.
- Poisoned memory: an untrusted source plants a persistent instruction, allowing a prompt injection to survive into later sessions. Review, guardrails and administrative controls must address what is allowed into memory and what remains available.
- Conflicting memory: two records describe incompatible ways to perform the same task. Both can rank highly because both are relevant. Detection and review must resolve the conflict; scope may explain cases where different procedures are valid in different settings.
More memories can also recreate the oversized-context problem. Over-recall fills the context card with weak matches, crowding out useful information. Irrelevance is subtler: a memory scores highly because its meaning resembles the query, yet it does not help with the actual task. Both require attention to what gets written and how retrieval is tuned.
The talk also calls out unexpected data entering the memory system, which careful distillation and enrichment should prevent. As the collection grows, retrieval can drift without an obvious failure event. The contrast between a thousand records and fifty thousand or a million is an illustrative warning about scale, not a measured capacity limit: a search configuration that works on a small collection may return increasingly strange results on a larger one.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Measure what happened after retrieval
Feedback is what makes memory adaptive. Retrieving a candidate does not prove that it helped. The agent might use it, reject it or follow it into a failure. The memory layer needs to record whether the result was helpful, stale, irrelevant or harmful, then feed that information into ranking and lifecycle decisions. Harmful use should lower its standing; useful experience may justify promotion.
This adds a second question to evaluation. Did retrieval find an appropriate memory, and did that memory improve the downstream task? A highly ranked record can fail the second test. Tracking both connects search quality to the work the agent actually performs, rather than treating retrieval scores as the final measure of success.
The intended payoff is practical: agents resume work, reuse prior experience and repeat fewer mistakes. In the support example, the retained procedure saves a later agent from rediscovering what the earlier investigation learned. Faster execution, lower token use and better success rates are the goals of the design; the recording does not quantify those gains for this system.
For implementation, Swanson points to Oracle’s Python SDK for Agent Memory and a Python notebook walkthrough, describing the SDK as built on database primitives. He also directs builders to the Oracle AI Developer Hub for samples showing how a multi-model database fits into AI development. The closing invitation follows the architecture: implement formation and recall on persistent storage, then make governance, evolution and feedback part of the same working system.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
Related talks
- Beating RL With Reflection: GEPA and Optimize Anything
Its repository-skill examples show another way to carry knowledge from an agent trajectory into future attempts, while its reflective optimization loop develops the role of actionable feedback.
Read the complete timestamped transcript
20 slide groups. Extracted from the recording; expand builds to follow changes. Timestamps are approximate.
- 0:12
Hey, so I'm Anders. Um, I'm a developer advocate for Oracle AI Database, and I'm talking about how we can approach agent memory as a systems problem, how we can take context and turn it into a real memory layer that is going to help your agents work better. Um, when we're talking about agent memory, we're talking about composing memory retrieval, memory formation, and the persistent storage that's backing these memories. Um, and
Agent memory
Anders Swanson frames agent memory as a systems problem combining retrieval, formation, and persistent storage.
Text in image
Agent memory: composing memory retrieval, formation, and persistent storage.
- 0:42
we've probably all used different agents at this point, agents like Claude Code or Codex, and we've seen them work on a task and reread the same files over and over again, and this, this is because they have no knowledge of what has happened in the past. Context windows are, are not memory. Um, they are the input for the current run and not a persistent experience. If I have some agent session, let's say he's working on customer support tickets. He reads a bunch of documents. He runs a bunch of
A context window is not memory
Session A reproduces a failure and finds its cause, but without persistence, Session B guesses and repeats the search. Useful experience must become managed state to carry forward.
Text in image
A context window is not memory Context is input for the current run, not persisted experience. Agent Session A 1 state failure reproduced 2 cause root module found No persistence! Agent Session B ? state guessed again ? cause search repeated Memory can’t begin until these experiences are transformed to managed state
- 1:12
queries. He reproduces a failure, finds root cause, and does all this, like, great, valuable work that synthesizes a useful procedure. What happens at the end of the session? It's tossed away, and this is because there's no persistence. Uh, you know, a long, a long later, another, another agent comes on, and he works on a similar task, and he has to repeat all of the same work. So he's, he's searching more documents. He's running more queries, and this is more opportunity for failure, more opportunity for hallucinations,
- 1:42
and, and ultimately, uh, less fidelity. And memory really cannot begin until these useful experiences from our agents are transformed into managed state. Uh, larger context windows are also not the solution. We end up throwing more and more tokens. The session grows longer. Compaction occurs. The useful signal that occurs for our agents is lost in a slew of other irrelevant information. Likewise, scratch pads are workarounds.
Large context windows
Swanson argues that as sessions grow and compaction occurs, useful signal can get lost among irrelevant information. The diagram places buried information between logs and noise.
Text in image
Large Context Windows More context doesn’t fix the problem, and throwing tokens at a problem isn’t usually the best solution memory != bigger prompt prompt logs buried information noise docs follow-up signal is buried in large context windows
Scratchpads are workarounds
Swanson argues that markdown files, wikis and prompts help, but don't provide governed recall. He says files also don't scale in large multi-tenant environments.
Text in image
Scratchpads are workarounds.
Scratchpads are workarounds
Markdown notes, temp files, and prompt instructions feed an agent’s current context. Swanson argues they don’t provide governed recall, and that files and grep struggle to scale in large multi-tenant environments.
Text in image
Scratchpads are workarounds. Files, wikis, prompts help, but don't fully govern recall. Markdown notes AGENTS.md, etc. temp files prompt instructions agent loop using current context not real, governed recall. Files don’t scale. grep isn’t recall. Why build your own database?
- 2:13
So things like markdown files. We start building large hierarchies of files, uh, wikis, prompts. These do help, but this is not governed recall. Uh, files do not scale in large multi-tenant environments. Uh, tools like Grep are extremely useful for finding data, but they also don't scale well, and it is not complex hybrid retrieval. And I feel like if we continue the logical conclusion of trying to build a
- 2:43
memory layer on top of files, we're gonna be building our own database, and I don't-- You could just use a database. Uh, in this presentation, this is unpacking the lessons that we've learned as a database vendor working with customers who are developing agent memory, customers who are solving real problems with agents and needing recall. And where we're seeing modern agent memory systems converge is there's, there's a pattern that's implementing memory
Lessons from developing agent memory
Swanson draws on his experience as a database vendor working with customers building agent memory for real problems that require recall.
Text in image
This presentation unpacks lessons we’ve learned working with customers developing agent memory
Where modern agent memory systems converge
Agent memory stores distilled facts, combines retrieval signals, and evolves through consolidation and feedback. Temporal tracking and governance controls help keep memory usable and scoped.
Text in image
Where modern agent memory systems converge The common pattern implements memory formation, recall, evolution, and evaluation. 01 Memory formation Store distilled experiences and structured facts, not raw transcript dumps. 02 Hybrid retrieval Fuse vector, lexical, entity, graph, temporal, recency, and feedback signals. 03 Consolidation Merge duplicates, resolve conflicts, and evolve memories over time. 04 Temporality Track creation time, access time, and validity windows. 05 Regular evaluation & feedback Measure use, provide feedback. 06 Governance controls Redact secrets, scope writes, require approvals, and suppress stale or poisoned memory. production memory = controlled writes + controlled recall + controlled evolution
- 3:13
formation, memory recall, evolution, and evaluation. So when we form memories, these are, these are distilled experiences, structured facts. This is not a raw transcript dump. When we're recalling memories, hybrid retrieval is emerging as a dominant method. This is, this is a form of retrieval that fuses different types of search, so vector similarity search, lexical search, entity search over relational objects, graph traversals, and different signals over temporal data, recency,
- 3:43
and feedback. We also need consolidation in these systems, so duplicates can emerge. We need to resolve conflicts. The system needs to evolve over time, otherwise it becomes stale, irrelevant, and useless. Memories need element of temporality. So when was this created? When was it accessed? How long is it valid for? It may only be valid for a certain time window. And this all needs to come into regular feedback and evaluation. If I'm not measuring use, I'm not sending feedback into the memory layer,
- 4:14
it's all gonna fall over. Um, another important piece is the governance controls. So secrets, personal information, that needs to be redacted before it hits the memory layer. Rights need to be scoped, scoped to the agent, scoped to the workflow, the team, the user. This is especially important in multi-tenant environments. We need appropriate admin approvals, review, and ability to suppress stale or poison data. When we walk through the memory loop, we
Walk the agent memory loop
A session creates a fact, which is enriched, redacted, and stored. A later run recalls it in related context; feedback and new data help the memory adapt for future runs.
Text in image
Walk the agent memory loop A useful fact should propagate from local session data to the memory layer and persistent storage. 1 Run During a session, a useful fact is created. 2 Record Enrich, redact, and record the fact. 3 Recall Related context recalls the fact on the next run. 4 Adapt Fact evolves with related data and temporality. Next run Prior evidence. Contract first. No repeated dead end. Adaptation feeds the next run record -> retrieve -> govern -> evolve -> repeat
- 4:44
have an agent session. It does some work, reads documents, run queries, synthesizes useful data. After that session or during that session, a fact is created. We record that fact through redacting, enriching, storing it in the persistence layer. And then when another session comes along with related context, it can retrieve that fact and use it for context card reconstruction. So it's using that fact that came from a prior arc to make the next task easier. That's less work for the
- 5:14
next agent to do. And if that agent uses the fact successfully, we can add feedback scores to that memory. So we're adapting over time. We get related data and new temporality. We access it again, we're-- we did something with it.
Memory read/write/storage layers
The agent runtime invokes a memory API through hooks, MCP tools, skills and other interfaces. The API manages memory operations and connects to storage for rows, embeddings, search, graphs and facts.
Text in image
Memory read/write/storage layers Memory is invoked as a function, so it needs operational infrastructure and APIs. Agent runtime reasoning + tools Memory layer (API) write policy recall assembly redaction + review feedback + eval Storage Platform Database(s) memory rows vector embeddings full-text search entities + graph episodes + facts hooks / MCP tools / skills / REST / gRPC: add | recall | forget | rebuild context
- 5:30
Now, memory, it's invoked as a function by the agent runtime. So it needs read, write, and storage layers. Your agent runtime can invoke the memory layer through things like hooks, MCP, skills, or other methods. And the memory layer API is exposing these, the read write, the feedback, administrative APIs, and then talking to the storage platform or databases.
- 5:56
The choice of database here, uh, I, I think multi-model databases are especially useful because- They allow you to not work, work with your rows, columns, vector embeddings, full text search, relational entities, graphs, episodes, and facts all in one place. So your memory can live in a consolidated place with one database query connection. I can do all sorts of hybrid search and return that data back.
What does memory look like? Typed.
Agent memory can be grouped into past events, facts, reusable routines, and working state. Working state captures current work and may only be valid for a time window.
Text in image
What does memory look like? Typed. This model comes from human memory, and may be loosely applied to agents Episodic Specific past events episode_id, message_id, evidence_spans Semantic Facts, preferences, entities memory_type=fact, preference, entities Procedural Validated routines, reusable rules processes, codebases, operations Working State current work and temporal facts valid_from, valid_to, observed_at
- 6:23
Uh, what does the memory look like? Uh, it's gonna be typed, and this ... You may have seen this model at different presentations or some form of it. Um, this loosely comes from human memory, it can be applied to agents. So we have episodic memory. This is specific past events or slices of transcripts that the agents worked on. We have semantic memory. Um, these are specific facts about our workflows, user preferences, and other entities. We have procedural memory. This is, like, how we did a specific task or routine, maybe a build
- 6:53
step. These are reusable rules the agents are gonna wanna pull up again and again if they are repeating similar work. And we have working state. Working state is like short-term memory. It's what are we, what are we current- currently working on, and that, that temporal data. It may only be valid for a certain time window, and we may promote it to a different type of memory. This helps us bucket into different areas, and we can use different search techniques on these types of memory.
What does a storage schema look like?
A memory schema pairs typed objects with indexes for semantic and keyword search, graph links, temporal facts, and audit events. The lookup path adds filtering and an audit log around retrieval.
Text in image
What does a storage schema look like? Think of memory storage as typed objects plus lookup paths: semantic search, keyword search, graph links, time windows, and audit events. developer-facing model type Memory = { id: UUID content: string metadata: Json tags: Array<string> embedding: Float32Array … } type Fact = { time: Interval sourceMemoryId: UUID … } memory object ids, content, tags embedding index similarity search text index keyword recall graph links relatedTo, causedBy temporal facts valid + observed time audit events actor, scope, metadata runtime lookup path memory.search({ text, tags, asOf }) ask — request embed — vector retrieve — top-K filter — tags/time audit — log 01- 7:18
Uh, what does the storage scheme look like for memory? Um, so memory are typed objects plus lookup path. So our, our memory object is gonna have some ID, like a primary key. It'll have its text content, JSON tags, document data. It'll have a vector embedding, uh, with a vector created over the content, with a vector index for similarity search. Ideally, we'll also have a text index to facilitate full text keyword search. That combines with vector search. Uh, we can have graph links to different
- 7:48
edges. Memories can be related through an entity graph, so this memory is connected to this memory, which is connected to that memory. This additional context that we can pull back during the search stage. We can also have temporal facts. When is this memory valid to? What was the last time that we used it? And then also, super importantly, audit events. Who, who created this memory? What did they use it for? Uh, the log of, of, of, of how it's been used and associated metadata. Um, this should all be part of your storage schema
- 8:18
when we're working with memories. And when we create memories, we want to intentionally form them. Good memories are very intentional, so we need to decide the life cycle, the scope, the different relationships, and associated metadata. When an agent runtime decides to create a memory, we should first start with redaction. Uh, redaction's very important as a first step because before I do embeddings, before I do enrichment, I want to strip out PII. I don't want secrets or, or, uh, irrelevant, weird information slipping into the memory layer. That's a recipe for
Good memories are intentionally formed
The write path redacts sensitive or irrelevant information first, then enriches and scopes the memory, creates an embedding and source episode, applies policy, and saves it.
Text in image
Good memories are intentionally formed. We decide memory lifecycle, scope, relationships, and metadata. A memory persistence workflow redact → enrich → scope → embed → episode → policy → save redacted = redactWrite(content, metadata, tags); enriched = enrich(redacted.content(), ...); layer = resolveWriteLayer(userId, metadata); metadata.put('status', 'active'); metadata.put('content_hash', hash(redacted.content())); episode = prepareEpisode(...); save(request, embedding); Redaction happens before embeddings, enrichment, and persistence.- 8:48
disaster. So we do redaction first. Then we can enrich the memory. What is the mem- w- what is the memory related to? What is the metadata of the memory? We can apply the scope to it. Uh, what is the agent that worked on this memory? What's the team? What's the organization? This helps bucket into specific areas, so I'm not getting memories in other sessions that are associated with other agents or workflows, which adds confusion. We do the embedding, so we create the vector of the content, and then we can form what's called the episode. These are the slices of the
- 9:17
transcript that created the memory. This is good for provenance and additional context. Um, any organization-specific policies here can also be applied, uh, whatever you need for your specific use case, and then we can save down to the storage layer. Um, when we create memory, the individual memories can be quite compact, so we take the transcript and we distill it down to that content and metadata and embedding and, and, and related stuff, but we can also ... We create these episodes. So we take the agent transcripts,
Episodic memory preserves source evidence
A compact memory record links back to an extracted transcript episode, preserving evidence and context. Candidates are de-duplicated or merged before writing.
Text in image
Episodic memory preserves source evidence. An individual memory is compact; but the system may trace back to the episode that created it. On ingestion, preserve source evidence: 1. Store a memory row with compact content and metadata. 2. Create an extracted episode containing a slice of the source transcript and evidence metadata. 3. De-duplicate/merge candidates before write. Transcript messages → Extract episode candidates → Memory record → Episode link
- 9:47
we filter them, find candidates for these episodes, save the memory record, and link it back. You can do this with, uh, relations, just straight-up database relationships. You can do it with graphs. I particularly like graphs because they allow a, a broader search here.
Scratchpads are workarounds
Swanson argues that markdown files, wikis and prompts help, but don't provide governed recall. He says files also don't scale in large multi-tenant environments.
Text in image
Scratchpads are workarounds.
- 10:04
Uh, when we're talking about memory recall, that is, how do we remember something, this is a retrieval problem, so a query problem on the storage layer. Um, and with, with retrieval or recall, hybrid search is emerging as the dominant method of context reconstruction, and this, this form of retro- retrieval can fuse different search methods. So I can take vector similarity search, I can take a full text keyword search, I can take relational entities, I can do
Hybrid search for context reconstruction
Hybrid search fuses candidates from multiple signals, then applies thresholds and reranking to produce a context card with scored evidence and provenance.
Text in image
Retrieval: Hybrid search aimed at context reconstruction. Retrieval fuses semantic, lexical, entity, graph, recency, importance, and feedback signals; yielding more comprehensive results than standalone vectors. 1 Hybrid query Ranked fusion vector text entity graph recency importance feedback candidate fusion + thresholds + reranking context card scored evidence with provenance 2 Context reconstruction Synthesize effective context from query results
- 10:34
graph traversal, I can take other feedback signals like importance, uh, uh, usefulness of the memory to yield more comprehensive revo- results than one specific query branch alone. Like, if I was only doing similarity search, I only get the most similar results according to the embedding model that I'm using. Um, and in general, this has not been enough, so we have all these different query branches, um, different types of memory. You can decide which ones you wanna do, things like facts. You might not want similarity. You might just
- 11:04
wanna do, like, an exact ID match on a fact. Um, we can take these results, we can fuse them, apply thresholds, do re-ranking, and then we get a context card with scored evidence. So we can say, this memory, it rate- it rated very well on vector search and a little bit lower on lexical search. Um, that's the provenance of the memory, where it came from, how we got it. That's important, too.
Hybrid search and ranked fusion
Weighted vector, text, graph, entity, and fact matches merge by memory ID. Positive base scores receive recency, importance, and feedback adjustments; fact lookup filters for currently valid, non-invalidated facts.
Text in image
Retrieval: Hybrid search, ranked fusion Explore memories from vector, text, entity, temporal fact, and graph query branches, each with applied weights. VECTOR DISTANCE — embedding = COSINE CONTAINS — Text SCORE(1) entity_hit — normalized entities fact_hit — temporal data GRAPH TABLE — linked memory expansion candidate fusion Search Hit merged by memory id double baseScore = vectorWeighted + textWeighted + graphWeighted + entityWeighted + factWeighted; double score = baseScore > 0.0 ? max(0.0, baseScore + recencyWeighted + importanceWeighted + feedbackWeighted) : 0.0; • VECTOR_DISTANCE(..., COSINE) finds semantically similar memories. • CONTAINS(content, ?, 1) / SCORE(1) finds lexical text matches. • GRAPH_TABLE expands from seed memories to related memories. • Entity overlap finds memories linked to normalized entities. • Fact lookup finds active, non-invalidated facts relevant to the query. WHERE invalidated_at IS NULL AND valid_from <= SYSTIMESTAMP AND (valid_to IS NULL OR valid_to > SYSTIMESTAMP) ORDER BY fact_matches DESC, confidence_score DESC- 11:27
Um, as we, as we walk through hybrid search, uh, vector distance, useful for, for semantically similar, things like contains operator, very good for lexical search, uh, graph table, temporal data, all this stuff. We take these branches, we apply weights to them. We can weight differently as needed. This is something that can be tuned in your, your hybrid search algorithm. The m- the results are merged to an overall score from the different query branches, and then we can take the top K of the overall results to say, "Hey, these are
- 11:57
the top three best results from our hybrid search algorithm." And that's loosely how you could implement hybrid search in a multi-model da- uh, database, a database that is capable of providing all of these different search methods from one pane of glass here.
Scratchpads are workarounds
Swanson argues that markdown files, wikis and prompts help, but don't provide governed recall. He says files also don't scale in large multi-tenant environments.
Text in image
Scratchpads are workarounds.
- 12:13
Now memories, it's not just a repository where we push data in and we pull data out. Memories need to evolve over time to be truly useful. We also don't want to just shove all our data in every time, otherwise we get tons of memories. Um, so and this is where we can kind of close the memory loop with consolidation and error handling. Uh, stale memory can occur when, say, my, my project uses NPM at one time, and then we decide to switch to another build system. But what
Consolidation and error handling
When a project changes, old memories can still rank highly and steer an agent toward the wrong action. Redaction-before-write, scope checks, and review help control what gets stored and recalled.
Text in image
Consolidation and error handling The system should expect stale facts, over-recall, and quiet drift. stale memory Current state changed; old lesson still ranks high. poisoned memory Untrusted source plants a durable instruction. bad scope Private task state leaks into repo/org recall. conflicts Duplicate facts disagree without lifecycle state. Countermeasures: redaction-before-write, scope checks, review queues, lifecycle states, feedback, audits, and memory evaluation fixtures.
- 12:42
happens to all the memories that were related to NPM? If an agent recalls those, it's, it's gonna be a little tricky, and it may try to do the wrong thing. Uh, so the system, it needs to expect stale facts over recall quiet drift. Bad scope can occur where, hey, we're not appropriately, ap- appropriately scoping memories in the right context. This is like if you log into your ChatGPT account and you get someone else's message history. Um, if you're not applying scope properly, you can have some really bad data leaks. So this needs to
- 13:12
happen on write and on read. Uh, poison memory is when a untrusted source plants a durable instruction in your memory layer. This is kind of the worst case scenario, like a, a prompt injection happened, you didn't have the appropriate guardrails, you didn't have the appropriate review, redaction, controls on memory and, and some really nasty stuff got in there and all your data got exfiltrated. So, uh, be very sure to avoid these kind of things through the proper guardrails and administrative actions. Uh, a memory
- 13:42
conflict is when I have two different memories. One says, "Hey, we do the task this way," and the other says, "Well, actually, we do it this way." Because they're both about the same task, they're gonna rank very highly on retrieval, so you'll probably get these same conflicts in your context card. And when the agent consume that, it's like, "Well, you know, you told me the restaurant's to the right, and it's actually to the left. I don't know what to do." Um, so detection review here is very important for conflict resolution. Uh, scoping as well, sometimes there
- 14:12
are different ways to do the same task. Um, over-recall and irrelevance happen as your memory system grows. Um, if we're just shoving all of our data in there and not really thinking about what we're writing, um, we can get into the situation of over-recall, where we have so many different weak matches, they're crowding out the context card. This is the same problem with the very large context window, where we try and smoosh in as much data as possible. It's just confusing. Irrelevance, uh, semantically close, memories that
- 14:42
rank highly on hybrid search, but it's not actually about the task. It just, it rated highly. So these, these are problems of, of management and your search algorithm tuning. Data leakage is when we get weird, unexpected data that enters the memory system. This is a less serious version of poison memory. Um, proper enrichment and distillation of the memory records on the right path is the way to solve leakage. Uh, over time also, we get silent drift. This is where the memory system grows. Maybe it works
- 15:12
freaking awesome at, like, a thousand records, but then when I have fifty thousand or a million or more, it's-- I'm getting all these weird results and it's not really working. So it's very, very important to apply the proper countermeasures, the redaction before write, the scope checks, review, life cycle, and most importantly, feedback. Feedback is what closes the loop for memory. Memory quality needs to be measurable. We need to have correct retrieval. We need to account for stale or harmful memories, and ultimately, the downstream usefulness of the
Feedback and evaluations close the memory loop
An agent retrieves a candidate memory and uses or rejects it. Feedback on whether it helped or caused harm updates its score and informs ranking and lifecycle decisions.
Text in image
Feedback and evals close the memory loop. Memory quality is measurable: retrieval correctness, stale/harmful memories, and downstream usefulness should feed ranking and lifecycle decisions. retrieve candidate memory agent uses or rejects feedback updates score memory systems aren’t just repositories: they can store whether memories were helpful, stale, irrelevant, or harmful.
- 15:42
system, it needs to feed back to these ranking and life cycle decisions. So if an agent retrieves a candidate memory, it'll use it, it'll reject it. Maybe if it uses it, everything goes haywire and it crashes. Like, that feedback needs to come back, and if, if the memory was harmful, the feedback should go down. If it was useful, maybe we promote it. So it's not just a repository, it needs to store-- your memory layer needs to store whether memories were helpful, stale, irrelevant, harmful, et cetera.
Design for measurable recall and governed memory
Governed memory aims to help agents resume work, reuse prior results, and reduce repeat failures. The proposed lifecycle is to record, retrieve, govern, and evolve memory.
Text in image
TAKEAWAY Design for measurable recall, and governed memory formation built on a multi-model storage platform Without memory restart recreate repeat mistakes With governed memory resume reuse reduce repeat failures record -> retrieve -> govern -> evolve
- 16:13
Um, and we really, we want to design for measurable recall with governed memory formation built on a mul- multi-model storage platform. So without memory, these agents are more likely to restart the same tasks, they're gonna recreate over and over again, they're gonna read the same files, they're gonna run the same queries, they're gonna waste tons of time, tons of tokens, um, be much slower, and much more, much more failure-prone. They're gonna repeat the same mistakes. If it doesn't know about prior art, it's gonna do the same thing over again, and if that
- 16:43
thing was wrong, it'll be wrong again and again. And with governed memory, the agents can resume where they left off, they can reuse what came before them, and ultimately reduce repeated failures. This is, this is the true goal of recording, retrieving, governing, evolving. Um, we want to improve the success rate. We wanna do it faster, we wanna do it cheaper, we wanna do it better.
Oracle Agent Memory
Oracle’s Python SDK connects agent frameworks, memory integrations and model providers to Oracle AI Database. The QR code leads to a notebook demonstrating the SDK.
Text in image
AGENT MEMORY SDK Oracle Agent Memory Agent Frameworks LangGraph OpenAI Agents SDK Private Agent Factory Memory Integrations Mem0 Zep SimpleMem Model Providers OCI GenAI OpenAI HuggingFace Oracle AI Agent Memory (Python SDK) Memory APIs Search Scoping Context Retrieval & Summarization Oracle AI Database Vector JSON Relational Graph Oracle Agent Memory Sample
- 17:07
Um, if you are hands-on, um, I recommend checking out our Python SDK for Agent Memory. This code will take you to a GitHub link with a Python notebook that walks through how to do this using our SDK. The SDK is buil- built on database primitives. Um, everything that we talk about here lives in the database. Um, you-- We also have our developer hub. If you're an AI engineer, you're a builder, you're curious, like, how does a modern multi-model database fit into AI
Oracle AI Developer Hub
The Developer Hub collects working AI application examples with source code, deployment configurations, and documentation. Swanson points builders to the samples to explore how a multi-model database fits into AI development.
Text in image
Oracle AI Developer Hub This repository contains technical resources to help AI Developers and Engineers build AI applications, agents, and systems using Oracle AI Database and OCI services alongside other key components of the AI/Agent stack. What You'll Find This repository is organized into several key areas: Apps (/apps) Applications and reference implementations demonstrating how to build AI-powered solutions with Oracle technologies. These complete, working examples showcase end-to-end implementations of AI applications, agents, and systems that leverage Oracle AI Database and OCI services. Each application includes source code, deployment configurations, and documentation to help developers understand architectural patterns, integration approaches, and best practices for building production-grade AI solutions. Name | Description | Link FitTracker | Gamified fitness platform built with Oracle 26ai JSON Duality Views (FastAPI + Redis), created live during a webinar. | View App agentic_rag | Intelligent RAG system with multi-agent Chain of Thought (CoT), PDF/Web/Repo processing, and Oracle AI Database 26ai integration | View App finance-ai-agent-demo | Financial services AI agent with Oracle AI Database as a unified memory core for vector, graph, spatial, and relational queries | View App oci-generative-ai-jet-ui | Full-stack AI application with Oracle JET UI, OCI Generative AI integration, Kubernetes deployment, and Terraform infrastructure | View App tanstack-shoe-store | AI chat app using TanStack Start and Oracle 26ai Select AI to query a shoe store database with natural language | View App Interface text: [illegible]e-devrel / oracle-ai-developer-hub Issues Pull requests 7 Agents Actions Projects Wiki oracle-ai-developer-hub Public main 41 Branches 1 Tag Go to file jasperan Merge pull request #125 from oracle-devrel/dependabot/npm_and_yarn[illegible] .github/workflows .vscode apps guides notebooks workshops .gitignore .pre-commit-config.yaml .prettierignore .prettierrc README.md SETUP_PRE_COMMIT.md pyproject.toml requirements-dev.txt
- 17:37
development, this is the place to go to check out our samples, um, see what's possible, and maybe even inspire you to build something cool, uh, with a very awesome database. Uh, again, I'm Anders, um, Anders Swanson. If you want to chat or connect with me, I'll be over at the Oracle booth. Um, and thank you so much. I hope this was useful to you guys and, uh, helpful as you're, you're building awesome things. Thank you so much.