Scope Memory to the Task at Hand
Every memory record needs a scope — user, repo, session, or task. Get the scope wrong and the agent leaks one user's preferences into another's session, or worse, applies last week's plan to today's PR. This topic teaches you to bind memory to the smallest scope that still makes it useful.
Scope Memory to the Task at Hand
Memory without a scope is a bug waiting to happen. Every record an agent writes needs an explicit scope key that answers: who and when can read this? Get it wrong and you ship cross-tenant leaks, stale plans, or both.
The scope ladder
Pick the smallest scope that still makes the memory useful. Broader scopes are easier but corrupt faster.
| Scope | Key shape | Lifetime | Typical use |
| --- | --- | --- | --- |
| Global | () | Until you delete it | Truly universal facts (rare) |
| Tenant | (tenantId) | Tenant lifetime | Org-wide policy |
| User | (userId) | User lifetime | Personal preferences |
| Repo | (repoId) | Repo lifetime | Repo conventions, codeowners |
| Repo + path | (repoId, path) | Until path moves | Module-local rules |
| Session | (sessionId) | Session | Conversation state |
| Task | (taskId) | Task open → closed | Intermediate hypotheses, draft plans |
The exam likes "smallest correct scope" questions. If you can name a counter-example user, repo, or task where the fact would be wrong, your scope is too broad.
Why task scope matters
Task-scoped memory is the cleanest way to give an agent working memory without polluting its long-term store. When the task closes, you drop the record — no garbage collection drama, no contaminated future runs. Promote a record up the scope ladder only when you have evidence the lesson generalises.
A common multi-tenant trap
// BAD — implicit global scope
memory.set("preferred_style", "tabs");
// GOOD — explicit user scope
memory.set({ userId, key: "preferred_style" }, "tabs");
The first line works in a one-user demo and breaks the day you onboard your second customer.
Quick check
Quick check
An agent serves multiple users. A teammate proposes storing 'preferred code style' as a single global memory entry to keep the schema simple. What's the right pushback?
Where this shows up on the exam
Look for prompts that describe a multi-user or multi-repo setup and ask "where should this memory live?". The right answer is almost never "global"; it's the most specific scope that still makes the fact reusable.
Key terms
- Memory scope
- The boundary that decides who can read or write a memory record. Common scopes: global, tenant, user, repository, session, task.
- Scope key
- The identifier that pins a memory record to its scope — e.g. (userId, repoId) for a per-user-per-repo preference.
- Task-scoped memory
- Memory that lives only for the duration of a single task or work item and is discarded when the task ends. Sometimes called ephemeral or working memory.
- Cross-scope leak
- When a memory record written under one scope is read under a different one — the canonical multi-tenant bug for agents.
Common pitfalls
- Storing everything as global memory because it's easy. The first multi-tenant deployment will surface user-A facts in user-B's session.
- Using session-scoped memory for things the user wants to keep. The next session starts fresh and the user has to re-teach the agent every time.
- Mixing task-scoped scratch with long-term lessons in the same record. When the task ends and you delete the record, you also delete the lesson.