How to Steer What Augment's Cosmos Experts Learn From Your Feedback (2026 Guide)

It is on by default, at a scope somebody else chose

Memory "lets an Expert retain useful context across sessions" and "stores scoped knowledge in the shared virtual filesystem (VFS), so future sessions can apply established preferences, conventions, and lessons without relying on the current conversation."

Scope is where the first mismatch happens: "An Expert's memory belongs to its team and is separated by a scope appropriate to the workflow. Repository-based Experts typically use one scope per repository, while other Experts can use a global, channel, project, or user-specific scope."

Five possible scopes, and the default is whatever fits the template. An Expert scoped globally when it should have been per-repository learns one team's conventions and applies them everywhere. One scoped per-repository when it should have been global relearns the same thing in every repo.

Two write paths, and only one of them waits

This is the mechanism worth understanding properly, because it determines how a single offhand comment affects everything afterward.

"Simple memory is the default. It writes explicit, high-quality human feedback directly to a curated knowledge file. This works well for preferences and standing rules that are authoritative on their own."

"Noisy memory uses an evidence log plus a curated knowledge file. It combines weaker signals over time and promotes a learning only after the evidence is strong enough."

And the part that explains why you cannot tell them apart from the outside: "Both models expose the same curated knowledge view to readers. The difference is how that view is produced: simple memory records trusted facts directly, while noisy memory distills repeated evidence before presenting it to future sessions."

So a readable knowledge file that looks identical may be backed by one comment or by twelve corroborating ones. If you are debugging why an Expert believes something, that is the first thing to establish.

Not everything you do is the same strength of signal

Code Review Memory runs the noisy model, and its documentation is unusually specific about weighting: "Explicit human feedback carries more weight than reactions or an inferred outcome, so strong feedback can become useful memory immediately while weaker signals must recur."

Three tiers, in effect. A written comment can land right away. A reaction on an agent finding, or the fact that a change was merged, needs repetition. The system also filters: "Routine acknowledgments, bot updates, and process-only comments are filtered out."

That is a sensible design. It also means a throwaway "yeah, fine" is not neutral — it is a weak signal being logged, and enough of them add up.

It tells you, and most people are not looking

There is a veto step and it is easy to miss: "In interactive sessions, it tells you when it remembers something so you can correct or veto it."

The word doing the work is interactive. Background Experts — and Code Review Memory is explicitly "a background Template Expert" — do their capturing when a pull request merges, with nobody in the loop to object.

It surfaces conflicts rather than resolving them

On the read path: "At the start of relevant work, the Expert loads memory for the current scope. It applies matching guidance and flags discrepancies when current evidence conflicts with a remembered rule."

Flagging is better than silently applying a stale rule, and it is not the same as fixing it. The stale entry stays until someone edits it, which is the general problem covered in detecting conflicts in AI memory.

Turning memory off. Available — you can tell the Advisor not to wire it in — and it throws out the useful part with the noisy part. The learning that comes from ongoing work is exactly what instructions cannot capture.

Putting everything in an Expert's instructions instead. Augment addresses this directly: "Use skills or Expert instructions for explicit workflows; use memory for context learned through ongoing work." And on the review side: "Code Review Memory is not the same as creating a skill for every repository. Skills provide explicit, reusable instructions and workflows. Memory is evolving, evidence-backed context that review Experts load automatically for the repository they are reviewing." Two jobs, and forcing one mechanism to do both makes it worse at each.

Using the widest scope so everything is available everywhere. The official guidance is the opposite: "Use the narrowest stable scope that matches the workflow, such as a repository for code review or a channel for feedback triage." A wide scope does not make an Expert better informed; it makes retrieval noisier.

Switching everything to noisy memory because it sounds more rigorous. Also counter to the documentation: "Prefer simple memory unless the workflow genuinely needs repeated, weighted evidence." Noisy memory delays learning by design. On a workflow where your feedback is authoritative, that delay is pure cost.

Treating what it remembered as settled. "Treat memory as evolving context, not an unquestionable rule. Experts should surface contradictions rather than ignore current evidence." A memory is a claim with a history, not a decision, which is the distinction behind memory provenance.

Assuming another team's Expert will pick it up. It will not: "Each Expert team owns and maintains its memory rather than modifying another team's curated knowledge." Ownership is a boundary, not an inconvenience to route around.

Step 1: Pick the narrowest stable scope for each Expert

Go through your Experts and write down, for each one, what the smallest scope is that still covers its work. The word stable is doing real work in Augment's phrasing — the goal is the narrowest scope that will not need widening next month, not the narrowest scope imaginable.

The documentation's own examples are the right instinct: "a repository for code review or a channel for feedback triage." A review Expert working one repository does not need global scope. A triage Expert watching one channel does not need project scope.

Two questions resolve most cases. Would knowledge learned here be wrong somewhere else? If yes, narrow it. Would you have to teach this same thing again in three other places? If yes, that is a sign the knowledge is not really Expert-specific — hold that thought for Step 3.

Also settle visibility while you are here, since it travels with scope: "Memory can be shared with an organization or kept within a user's VFS, depending on the Expert's visibility."

Step 2: Match the memory model to how reliable your signals are

One question per Expert: is the feedback this Expert receives authoritative on its own?

If a human types a correction and that correction is simply correct, use simple memory. Preferences, standing rules, conventions you have already decided. It writes "explicit, high-quality human feedback directly to a curated knowledge file," and the immediacy is the feature.

If the signals are mixed — reactions, merge outcomes, inferences, comments of varying seriousness — use noisy memory and let the evidence log do its job. Code Review Memory is the reference case, and the reason is stated: "review comments, reactions, agent observations, and change outcomes carry different levels of confidence."

Then apply the second official filter, which is about volume rather than mechanism: "Save information only when it could change a future decision or area of focus." An Expert that records everything produces a knowledge file nobody reads, and a knowledge file nobody reads is where stale entries live.

For the review path specifically, know what is being watched so you can be deliberate in reviews: it "records useful human comments, reactions to agent findings, addressed change requests, and the outcome of the change." Your reaction on an agent finding is training data. Treat it that way.

Step 3: Read the knowledge file, and move the facts that are not Expert-specific

Two habits, and the second one is the structural fix.

First, actually read it. Memory is written "as readable Markdown under its own VFS directory," and on the review side the storage split is explicit: "A raw breadcrumb log preserves the evidence collected from reviews, while a curated knowledge file contains the concise guidance consumed by review Experts." Read the curated file to see what your Experts believe; read the breadcrumb log when you want to know why. Schedule it — once a month is enough — because background Experts capture without the interactive veto step, and this is the only review that happens.

Second, notice what keeps appearing in more than one Expert's file. Your architectural decisions. Your domain vocabulary. Which service owns what. Why a deprecated thing still exists. That knowledge is not what a particular role learned through its own work — it is what your organization knows, and per-Expert scoping means every Expert learns it separately or gets it wrong.

Augment's scoping advice is correct for the knowledge it is about, and it does not have an answer for the knowledge that is genuinely shared. That belongs in a layer no Expert owns. MemoryLake sets up in three steps.

Step 1: Create an API key

Sign in and generate an API key from your dashboard. It is not scoped to an Expert, a team, or a repository, which is the property that matters for facts that are true regardless of which Expert is asking.

Step 2: Upload your first memories

Put in what you found repeating across Expert files: architectural decisions and their reasons, domain terms, service ownership, standing constraints, the answers you keep giving in review.

Leave the learned-through-work material where it is. An Expert's record of the false positives it has stopped flagging in one repository is exactly what should stay scoped to that repository.

Step 3: Connect your AI & agents

Point your agents at the store. A new Expert starts from your organization's facts rather than from zero, and a correction to a shared fact lands once instead of once per Expert — which is the point of setting up shared AI memory for a team.

The first change is that narrow scoping stops costing you coverage. Right now, narrowing an Expert's scope means it knows less about your organization. When shared facts come from elsewhere, narrow scope only means a cleaner history.

The second is that the model choice becomes easy. Simple for authoritative feedback, noisy for mixed signals — and neither has to carry background facts, which is what pushes people toward wide scopes and over-saving.

The third is that the review habit becomes tractable. A curated file limited to what an Expert genuinely learned is short enough to read monthly, which is the difference between auditing what your AI remembers and intending to.

• Assume it is already on. All Template Experts have it, and the Advisor adds it to custom Experts by default.
• Use the narrowest stable scope. A repository for code review, a channel for triage — Augment's own examples.
• Prefer simple memory. Switch to noisy only when signals genuinely vary in confidence.
• Save only what could change a future decision. The official volume filter, and the one that keeps files readable.
• Watch your reactions in reviews. Comments, reactions, addressed requests, and outcomes are all captured, at different weights.
• Do not expect the veto step in background work. It appears in interactive sessions; Code Review Memory runs in the background.
• Read the curated file monthly, the breadcrumb log when surprised. One shows conclusions, the other shows evidence.
• Respect the ownership boundary. Each Expert team maintains its own memory and does not edit another team's.

Augment gives you more control over agent memory than most tools expose at all: five scopes, two write models with genuinely different semantics, a documented signal hierarchy, and readable files you can inspect.

Use the controls the way the documentation recommends — narrow, simple by default, sparing about what gets saved — and then handle the one case scoping cannot: the facts every Expert needs. Those are not one role's learning, and keeping them in a shared layer is what lets the per-Expert memory stay as tight as it should be.