Agent Knowledge and Memory
Vincent Depassier · September 1, 2026
An agent has three ways of knowing something, and they are easy to confuse. Getting them right is the difference between an agent that answers from your material and one that improvises.
| Where it lives | Who controls it |
Instructions | On the agent | You write it |
Knowledge packs | In the workspace, bound to agents | You curate it |
Memory | On the agent, per agent | It accumulates |
Instructions are the brief. They are versioned, and every run records which version it used — so a change in behaviour can always be traced to a change in the text.
Knowledge packs are the reference material. Written once, shared by every agent you bind them to.
Memory is what the agent picked up along the way. Useful, and the one you should audit.
Knowledge packs
A pack is a named piece of reference material with a type that says what kind of thing it is: a workspace policy, a standard operating procedure, a template, an FAQ, a manual, a linked data view, or a reference to an entity.
The type does not change how it is used. It exists so that a workspace with forty packs stays navigable, and so a reader can tell a binding rule from a how-to at a glance.
Packs come from different sources — static text you write, a document, a view over your data, an entity, or an external reference — and each carries an estimated token count.
Watch that token count. Everything bound to an agent is material that can be pulled into its context, and context is both finite and billed. Ten large packs bound to one agent is a slower and more expensive agent, and usually a less accurate one, because the relevant paragraph is competing with everything else.
A pack has to be published to be usable. An unpublished pack shows as a draft: bound, listed, and not in play. If an agent is ignoring material you are sure you gave it, check this first.
Binding
Packs are bound to agents, and one pack can serve many. That is the point: write the refund policy once, bind it to every agent that answers customers, and change it in one place when it changes.
Bind narrowly. An agent that only classifies tickets does not need the brand style guide, and giving it one makes every one of its runs a little worse.
Memory
Memory is per agent, and each entry records where it came from:
Type | Origin |
Auto-extracted | The agent inferred it from a conversation |
User-stated | Somebody told it directly |
System-derived | Derived from workspace activity |
Entries can be deactivated without being deleted, and each one records when it was last referenced.
The trap is auto-extracted memory. The agent decides on its own that something is worth remembering, and it can be wrong — it can record a one-off exception as a standing rule, or something a single customer said as a fact about your business. Once stored, it colours later answers, and nobody notices because it never appears as a step in a run.
Two habits handle this: review auto-extracted entries periodically, and when an agent starts giving an answer that is confidently wrong and nobody changed the instructions, look in memory before anywhere else. Deactivating the entry is the fix; it is reversible, so you can do it while you are still unsure.
Last-referenced dates make the review tractable — an entry nothing has touched in months is a good candidate for deactivation.
Next
Agents Overview
Agent Access and Tools
Agent Runs and Usage
Agent Tasks and Teams
Agent Models and Providers