Read time: ~6 minutes · Series: Product Manager practice · Previous: The quality bar · Next: Pilot and rollout
Two systems, two purposes
| Plan / Report | Agent Memory | |
|---|---|---|
| Answers | What this analysis should do and what the conclusion is | What the Agent knows by default every time going forward |
| How it's changed | Annotation, Execute, a new Plan | Queued → written in only after you Apply |
| Review point | Review the Plan before Execute | Review each proposal before Apply |
| Cost of misuse | One analysis is wrong | Every later analysis carries the wrong definition |
A Plan is a one-off contract; Memory is long-term background. Don't write activity-specific assumptions into Memory, and don't leave a company-wide definition buried in a single Plan without ever distilling it (if it really should be standardized across the whole team).
Queued Knowledge: the heart of governance
Everything that enters long-term memory goes through Queued Knowledge (the pending-approval queue) by default:
- Conversation-context extraction — suggestions drawn from user messages, with evidence attached
- Agent
propose_knowledge— the Agent proactively proposes reusable rules during analysis
Nothing is injected into the Agent before approval—behavior doesn't change silently.
What the PM should do:
- Decide who has the right to Apply (usually the analysis owner + the PM for Project-level rules)
- Distinguish User (personal preferences) vs Project (project definitions)
- Dismiss uncertain items—better to write them into the next Plan
Compliance and switches
- Agent Memory can be turned off entirely (Enabled off)—once off, there's no background extraction and no injection, which suits sensitive projects or a trial period
- Automatic suggestions can be turned off separately—this only stops post-conversation background extraction; already-approved knowledge is still injected, and manual maintenance plus Agent proposals still work
- It does not feed entire conversations into a vector store by default; queuing has rate control and evidence validation
- Sensitive-data scenarios: first turn off Memory + restrict folder contents, then evaluate whether to enable it
For detailed steps, see USER_GUIDE §15.
Common governance decisions
| Content | Suggested home |
|---|---|
| "GMV excludes refunds" standardized company-wide | Project or User Knowledge (after Apply) |
| "This 618 event only counts 6/1–6/20" | Plan / Report only |
| "Analyst A prefers replies in Traditional Chinese" | User Knowledge |
| A join pitfall in one particular SQL query | Not in Memory; keep it in that analysis's step log |
Relationship to the PM pilot
Early in a pilot, we recommend turning Memory off or applying strictly at first, then enabling it once the team is comfortable with Plan / Execute—otherwise it's easy to hit "the Plan hasn't been reviewed yet, but the background rules have already drifted."
For analyst-side operational detail, see Plan vs Memory.