Module 7 — The AI Agent: Using It · Lesson 7.5
Agent Memory and Context
What it remembers, what it looks up, and where standing facts about your business should live
~11 min
What you'll learn
- Distinguish looked-up data from remembered facts from standing context
- Store a durable fact so it survives the conversation
- Use conversation history and saved conversations
- Choose the right home for a fact: memory, knowledge base, profile or charter
The question people ask about any agent is 'will it remember this?' The honest answer here is 'that depends where you put it', and the choices are genuinely different. Getting this right is the difference between explaining your situation once and explaining it weekly.
Three kinds of knowledge
Looked-up data is everything in the workspace: tasks, projects, clients, deals, mail, calendar, documents. The agent does not remember these — it queries them when asked. That is why the answers are current, and why there is no point telling it about a task instead of creating one.
Remembered facts are things it has been explicitly told to remember, held in a persistent memory. These survive across conversations. 'Remember that Marcus is our only person who can sign off on infrastructure changes' is a memory-shaped fact: it is durable, it is not derivable from any record, and it will be relevant repeatedly.
Standing context is what it reads every time regardless — your profile, the workspace charter, the workspace's shape. You do not tell it these; you write them where they live and they are always present.
Where a fact should live
The most useful decision procedure in this lesson.
If the fact is about YOU — your role, timezone, skills, how you work — it goes on your profile. It travels into every conversation automatically.
If it is a boundary — something the workspace will not do — it goes in the charter, where it is enforced rather than merely known.
If it is documentation — how something works, why a decision was made, what a term means — it goes in the knowledge base, where humans can read it too and the agent can retrieve it.
If it is a durable operational fact that fits none of those — a preference, a relationship, a constraint about a person or a client — that is what agent memory is for.
And if it is about a specific piece of work, it goes on that work: the task description, the task comments, the deal notes.
The common mistake is putting everything in memory. Memory is the residual category, not the default one, because a fact in the knowledge base is visible to your team and a fact in memory is not.
The waiting-on ledger
There is a specific memory-adjacent capability worth knowing: the agent keeps a ledger of things it is waiting on.
When you ask it to chase something, or when it takes an action whose outcome arrives later — a reply to an email, a response from a colleague, an external approval — it can record that it is waiting, and follow up.
This is what makes 'ask them and let me know when they answer' a real instruction rather than a fire-and-forget. It is also what stops the specific failure where an agent does something helpful and then never mentions the outcome.
Conversations
Past conversations are searchable and retrievable. The agent can look back at what it discussed with you before, which means 'what did we decide about the pricing page' is answerable even if the answer never made it into a document.
But do not rely on that as a filing system. A conversation is a record of a discussion, not an organized artefact, and finding something in one is slower and less reliable than finding it in a document.
The better habit is the one the agent will do for you: when a conversation produces something significant — a plan, a model, agreed terms, an external draft — save it to the knowledge base. That converts a thread into a document, which is findable by everyone rather than by search of a conversation you have to remember happened.
Put context where it belongs
- 1
Move three standing facts to their right homes
About you → profile. A boundary → charter. Documentation → knowledge base. Only what fits none of those → memory.
- 2
Tell the agent one durable operational fact
Something true across conversations and not derivable from any record. Then start a new thread and check it survived.
- 3
Ask it to follow up on something
'Chase this and tell me when they reply.' That is the waiting-on ledger, and it is what stops outcomes disappearing.
- 4
Save a valuable conversation to Knowledge
Converts a thread into a document your team can find without knowing the conversation happened.
What to watch
- Re-explanation rate
- How often you find yourself telling the agent something you have told it before.
- Healthy signal: Falling to near zero. Every repetition is a fact that belongs in a durable home and is not in one.
- Memory versus knowledge split
- How much standing context lives in agent memory rather than in the shared knowledge base.
- Healthy signal: Knowledge-heavy. Memory is private to the agent's context; the knowledge base is readable by your team.
- Waiting-on closure
- Share of things the agent recorded as waiting on that eventually got closed.
- Healthy signal: High. An open waiting-on ledger nobody closes is a to-do list in disguise.
Key takeaways
- ·Looked-up data is queried, not remembered — do not describe a task instead of creating one.
- ·Facts about you go on your profile; boundaries go in the charter; documentation goes in Knowledge.
- ·Agent memory is the residual category for durable operational facts that fit nowhere else.
- ·The waiting-on ledger is what makes 'chase this and tell me' a real instruction.
- ·Save significant conversations to Knowledge — a document is findable, a thread is not.
Module 8 is the other half of the agent: the machinery that decides what it may do on its own, and how to widen that safely.