Agent Memory

Overview

Agent memory is how an ArchAstro agent keeps useful information across conversations and over time.

• memory is not "save everything forever"
• memory is "keep the few things this agent should continue to know"

Good memory makes an agent feel consistent and useful. Unfocused memory makes it harder to review and less predictable over time.

---

What memory is actually for

Use memory when an agent should continue to know something without rediscovering it every time.

Good examples:

• a user's standing preferences
• recurring project facts
• durable context that affects future responses
• patterns that help the agent do the same job better next week than it did today

Poor examples:

• every message the system has ever seen
• temporary details that stop mattering quickly
• sensitive information with no clear reason to retain it
• internal operational noise that makes future decisions harder instead of better

The best memory is selective. It keeps the future useful, not just larger.

---

A concrete example

Imagine a delivery agent that helps a customer team roll out a product.

Useful things to remember:

• the customer prefers weekly written updates
• the rollout is happening in three phases
• the security review must be completed before production cutover

Things that should not become durable memory:

• every one-off scheduling discussion
• transient debugging details from last Tuesday
• sensitive details that were only needed for one narrow task

Memory should preserve stable, high-value context, not random residue from past work.

---

Memory design guidelines

A good memory setup is:

• narrow enough that a human can explain it
• durable enough to matter across conversations
• aligned with the agent's actual job
• reviewable if something goes wrong

The test is straightforward: if a teammate asked "what does this agent remember and why?", you should be able to answer clearly in a few sentences.

From the CLI, the first operational inspection loop is:

archastro list agentworkingmemory --agent <agent_id>
archastro list agentworkingmemory --agent <agent_id> --search rollout

This is the fastest way to confirm whether a memory item is actually present before you blame the model or the thread.

---

The three questions that matter

When deciding whether something belongs in memory, ask:

1. Will this still matter later?
2. Does retaining it make the agent meaningfully better at its job?
3. Would a human reviewer expect the agent to keep this?

If the answer to any of those is unclear, the item does not belong in memory.

---

Memory boundaries

Memory persists across conversations, so it deserves the same attention you give any durable data store.

Be intentional about what goes into memory:

• personal data should only be retained when it serves the agent's job
• confidential company information should follow your existing data handling policies
• temporary task details belong in conversation history, not memory
• if a reviewer would question why the agent kept something, it should not be in memory

The platform gives you full visibility into what an agent remembers (archastro list agentworkingmemory), so you can audit and clean up at any time.

Selective memory produces better agents. Agents with focused, relevant context are more predictable and more helpful than agents carrying everything they have ever seen.

---

Good first uses of memory

Strong early use cases include:

• support agents remembering durable customer preferences
• delivery agents remembering long-running project facts
• internal operations agents remembering standing environment constraints

Weak early use cases include:

• broad "remember everything" experiments
• retaining large amounts of thread content by default
• storing information with no clear future decision value

Memory in the operator workflow

Memory becomes most useful when you pair it with the other operating surfaces:

• use Impersonation to inspect the agent's current local context
• use agentworkingmemory to inspect what durable facts are present
• use threads and messages to compare what the agent recently saw against what it still remembers

That combination is how teams debug "why does this agent keep repeating the same assumption?" without turning the answer into prompt folklore.

---

Practical rule

If you cannot say exactly why the agent should remember something later, do not put it in memory.