編寫智能體前，先設計四張記憶資料表

It is easy to write the agent loop first and treat storage as a bucket for leftovers. Richmond Alake, Director of AI Developer Experience at Oracle, says a top failure mode is that engineers are not thinking memory first. He argues that once you think that way, every piece of information is something to remember or forget, and that changes the attributes on your data model.

Agent memory is what an agent keeps and reuses beyond a single turn. A bare model drops it. The short-term kind is working memory. The long-term kinds he maps from human memory are semantic, episodic, and procedural, kept in an external store the agent can write and later read by relevance or id. The agent memory topic page collects the conversations behind that split. I'd put four tables on paper before I chose a model.

What belongs in each table?

Working memory is the scratch pad: small, temporary, whatever is in hand right now. A basic chatbot runs mostly on it. Without the other kinds, that context is gone when the chat ends. Some consumer assistants now carry saved context into new chats, Claude among them. That steps toward the semantic and episodic layers. Richmond also allows working memory as an external scratch pad, which is the form this sketch stores.

Semantic memory is the facts the agent reuses: policies, docs, the institutional knowledge on the shelf. He calls that the knowledge base. Episodic memory is time-stamped past interactions, the diary that lets an agent refer to an earlier decision instead of starting every session from zero. Procedural memory is how to do the task: skills and routines, including the standard operating procedures it can run without re-reasoning the task every time. He treats skill MD files as one form. In production he wants those files in a database table, with the file content stored, a vector stored for similarity search, and room for how one skill relates to another. He still gives files a place when you are demoing work that was requested the day before. Once the system is in front of customers and has to scale, he wants the database, because once you add file locks and the logic to keep files consistent, you are rebuilding a database anyway.

What writes a row, and what reads it back?

Before the loop, Richmond says you mostly read. You pull conversation memory, the knowledge base, and the other relevant rows. Inside the loop, you mostly write, updating storage with what the turn just produced. Create, read, and update stay. His rule is don't delete, forget. Hard-deleting drops the audit trail. That matters in regulated industries, and he calls out finance, where audits arrive regularly. The sketch leaves the row in place and sets forgotten_at so ordinary reads skip it.

For example, a single developer can't train a GPT 4-5 like model, right? But a single developer can build a memory system that can remember better than a chat GPT.

Richmond Alake, Director of AI Developer Experience at Oracle, on Chain of Thought ep 53

The mapping below sketches the four kinds he names, as a starting point for a design pass.

# Sketch only. Not a schema from Richmond Alake or any product.

TABLES = {
    "working_memory": {
        "columns": ["id", "session_id", "content", "created_at"],
        "writes": "the loop, while this session still needs the scratch pad",
        "reads": "the same session, loading that scratch pad back",
    },
    "semantic_memory": {
        "columns": ["id", "content", "embedding", "source_ref", "forgotten_at"],
        "writes": "ingestion of policies, docs, and other facts you will reuse",
        "reads": "a similarity search when the task needs a fact",
    },
    "episodic_memory": {
        "columns": ["id", "session_id", "content", "occurred_at", "forgotten_at"],
        "writes": "the loop, after a turn is worth keeping",
        "reads": "a lookup by time or id from a later session",
    },
    "procedural_memory": {
        "columns": ["id", "name", "content", "embedding", "forgotten_at"],
        "writes": "saving a routine, including the text of a skill file",
        "reads": "a similarity search to choose a routine for this task",
    },
}

How does a read find the right row?

In this sketch, working rows are read by session id and episodic rows by time or id, because that table is a diary. Semantic and procedural rows are read by comparing meaning. An embedding turns text into a vector so similar meanings sit near each other. Richmond's advice for procedural memory matches that: store the skill text and a vector, then retrieve with similarity search. He also keeps the relationship of one skill to another when the read is a relationship lookup. He measures relevance with vector search, using cosine or Euclidean distance, and he names IVF and HNSW as ways to run that search. There is no industry standard for forgetting, so this sketch only reserves forgotten_at, and normal reads skip a row once that timestamp is set.

His AFSA demo used synthetic data for a wealth management assistant held in Oracle AI Database. One convergent search took a client id, found connected accounts by their relationship, looked up nearby clients, and retrieved risk research by vector similarity. He presents that mixed search as a tool the agent can call. In the same demo the window is partitioned: the agent is told the purpose of a memory segment, then given the content. I would keep that purpose in the table definition so each read stays distinct. When a store or a read path needs more than this sketch, I would open the best episodes on agent memory.

Checklist

• Draw four tables first: working, semantic, episodic, and procedural.
• Write working rows only for the current session. Write episodic rows when a turn should survive that session.
• Write semantic rows from reusable facts. Write procedural rows from routines, including skill file text.
• Read working memory by session, episodic memory by time or id, and semantic or procedural memory by vector similarity.
• Forget by setting a timestamp. Keep the row if an audit trail may matter.

The longer explainer, with the episode clips, is on Chain of Thought. It draws on this episode.

Subscribe to the Chain of Thought newsletter for new episodes and write-ups like this one.

Drafted with AI assistance from the episode transcripts.