Agent Memory Architecture: A Practical Five-Layer Design

A practical five-layer agent memory architecture separates active context, source references, current work state, approved decisions, and lessons from experience. These are five responsibilities you can design around, rather than a universal standard or a requirement for five databases.

The point is to tell an assistant what it is doing, what evidence it can use, what people agreed, and what earlier attempts taught you. fenbs can hold the explicit project decisions, tasks, and progress that a connected assistant reads before working. It does not supply the model or build a memory engine inside your application.

Is a five-layer design an industry standard?

Treat this layout as a design aid. Different systems divide memory differently, and their categories can overlap. The CoALA research paper↗ (opens in a new tab) proposes modular memory components alongside actions and decision processes; it does not make the five responsibilities below a mandatory architecture.

Likewise, LangChain’s memory overview↗ (opens in a new tab) distinguishes conversation-scoped memory from information saved across conversations. It also discusses facts, experiences, and procedures. Those distinctions help explain what information does, while this five-layer approach asks who maintains it and how it affects the next action.

For the broader design choices, read the agent memory architecture guide. Here, use the five responsibilities to inspect one concrete workflow and find missing or conflicting records.

What should each of the five layers hold?

Active context is the information available to the model during its current response. Its context window is the amount of input and output the model can work with at once. Select relevant records for that space instead of treating the entire archive as something the model must read every time.

Sources preserve a route back to evidence. Work state preserves the difference between planned, attempted, and verified. Decisions carry human authority, while lessons carry experience that may help another task. A lesson can suggest a better method without silently becoming a rule everybody must follow.

The introduction to agent memory explains the underlying idea. For this design, the useful question is whether a record has a clear job and a way to be corrected.

How does information move between the layers?

Say a small design studio asks an assistant to revise a client intake form. The source layer points to the approved design. The decision layer says a person chose to remove an unnecessary question. The work state says the revised form exists but message delivery has not been checked.

At the start, the assistant reads those selected records into active context. It can then work on the delivery check without reopening an approved design choice. Afterward, it saves the actual result to work state and links any evidence someone needs to reproduce the check.

1. Read the current rules and the task’s latest saved state.
2. Select the reference material relevant to this attempt, including its version.
3. Work within the approved scope and keep tool results distinct from interpretation.
4. Save what changed, what was checked, and the next step.
5. Propose a reusable lesson when the result teaches something beyond this task.

Do not promote every generated sentence into saved memory. “The client probably prefers shorter forms” stays an assumption until somebody checks it. In fenbs’s project context, explicit decisions and Where we left off give the next assistant a record to read rather than a conclusion to infer from an old conversation.

What makes a saved memory authoritative?

Give consequential records a source, a scope, and a status. A draft design, an approved design, and an assistant’s summary of that design should not look interchangeable. When two records disagree, the assistant needs a way to identify the current approved answer or stop for clarification.

Separate permission to read from permission to change. An assistant may need the approved form requirements without being allowed to replace them. Access control must be enforced by the service holding the record; a sentence asking the model to behave carefully is not an access boundary.

Keep instructions from people separate from text found inside reference material. A document can contain a request to ignore earlier instructions, but that does not give the document authority over the project. Our agent memory security guide covers that separate concern in more detail.

How can you test that the layers work together?

Use a fresh session and ask a question that depends on more than one record. For the studio, ask whether the revised form is ready to use. A useful answer should identify the approved design change and the unfinished delivery check, then avoid calling the task complete.

Test a correction, too. Replace an earlier project choice through your normal approval process and ask which answer now applies. Keep the old record available as history, but make the current answer unambiguous. A system that finds an old sentence quickly can still give the wrong guidance.

• Continuity: can another assistant identify the next action without the old chat?
• Evidence: can a person open the source supporting a saved finding?
• Authority: does a proposed change stay separate from an approved decision?
• Uncertainty: does an unchecked result remain visibly unchecked?

Repeat these checks after changing how you select or summarize saved information. Compare whether the assistant used the correct record and reached the right stopping point. A polished answer alone cannot tell you whether it followed the project’s actual state.

How to do this with fenbs

1. Create a free account, then add a project for one real piece of work.
2. Add the current tasks and record the choices people have made in Decisions and rules. Leave unanswered choices open.
3. Put source references in Links and listings and save concise, checked project facts as AI context notes.
4. Connect your supported assistant using the integration guides. Ask it to read Rules and Where we left off before starting.
5. Before stopping, save task progress and the project’s next step. Add a lesson when an observed result gives future work a useful check.

fenbs is free for one person, no credit card. It is not the right fit when you need a database and retrieval engine embedded in your own AI product; it keeps the shared work record your connected assistants can read and update.

Do the five responsibilities need separate systems?

No. Begin with clear record types and a reliable start-and-save routine. A single project can hold tasks, decisions, reference links, and lessons while the AI app manages the active conversation. Separate infrastructure becomes useful only when access, volume, or maintenance needs justify it.

Keep the design explainable to the people maintaining it. They should know where to correct a source, update unfinished work, and record a new decision. The context engineering hub collects related guidance for choosing what reaches an assistant at the moment it needs it.