Read time: ~6 minutes · Series: Analyst advanced · Previous: Reference docs: where to put large references
First, tell these apart: this analysis vs long-term metrics
| Where it goes | What it's for | Example |
|---|---|---|
| Plan | Assumptions, time windows, and checkpoints for this one analysis | "For this 618 promo, 6/1–6/20, the denominator is users who placed an order" |
| Project Knowledge | Short rules and [Ref: …] indexes that stay valid for this project long term |
"GMV in this project always excludes refunds" |
| Reference file | Large mapping tables and full dictionaries (loaded on demand) | A 50-row status-code lookup → see Reference docs |
| User Knowledge | Your cross-project preferences and terminology | "Reply in Traditional Chinese," "active = 90-day window" |
| Queued Knowledge | Proposals not yet approved | Agent or background-extraction suggestions—they don't take effect until you Apply |
Common mistake: writing a "one-time 618 time window" into User Knowledge, so that three months later the Agent still defaults to the 618 window in every project.
How Queued Knowledge works
Agent Memory can be turned off by default; once enabled, two paths feed proposals into Queued Knowledge (the pending-approval queue):
- Background extraction after a conversation ends (requires separately enabling Automatic suggestions) — proposes suggestions from recent user messages (must include evidence)
- The Agent proactively calling
propose_knowledge— proposing when it decides during analysis that a metric is reusable (this follows Enabled only, not Automatic suggestions)
Turning off Automatic suggestions does not stop the injection of already-approved knowledge.
Before approval:
- Not written into the formal knowledge files
- Not injected into the Agent's next prompt
How to approve:
- The User / Project / Dismiss cards in the conversation
- Apply / Dismiss in the Agent Memory panel
At the top of the left side of Agent Memory is User Knowledge (Global), and below it each project's Project Knowledge; the currently focused project has a green Eye icon next to its row, making it easy to confirm the apply target.
An analyst's daily habit: decide as soon as you see the card—is this a permanent metric, or is it fine to keep in this Plan? If unsure, Dismiss first and write it into the Plan, where it's more explicit.
What should go into Memory, and what shouldn't
Good candidates for Memory (after approval):
- Stable column definitions ("
paid_atis the successful-payment time") - Business rules the team agrees on ("trial users are not counted in ARPU")
- Your output preferences (language, level of detail)
Not suitable for Memory:
- Pitfalls of a single SQL query (these belong in the Query Step Ledger / conversation steps, not polluting the long-term store)
- Whole blocks of SQL or cache table names
- Metrics not yet aligned with PM / finance that may still change
Collaboration with Plan annotations
- Plan annotation = a revision to this version's analysis contract
- Memory Apply = background carried into every future analysis
If the PM annotates the Plan with "GMV excludes refunds" and this is a company-wide long-term rule, the analyst can write it into Project or User Knowledge after approval; if it's only a rule for this campaign, keep it in the Plan / Report.
For the governance perspective from a PM, see Memory governance.