You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
-`pkg/memory/scenario_identity.go` owns deterministic extraction, corpus statistics, pair scoring, and conservative candidate choice.
200
-
-`MemoryMerger.SaveOrMerge` drafts/upserts a scenario card for platform memory saves and fails closed if the card cannot be saved. It must not fall back to raw-memory insertion because that would reintroduce scattered notes.
200
+
-`MemoryMerger.SaveOrMerge` drafts/upserts a scenario card for platform memory saves and fails closed if the card cannot be saved. It must not fall back to raw-memory insertion because that would reintroduce scattered notes. Post-turn reflector saves created from a trace with successful non-memory/non-knowledge tool calls are marked `verified`; saves without execution evidence remain `draft` until a later successful run confirms them.
201
201
- Promotion is upsert-based. Personal → team and team → org promotion draft a scenario card in the target scope and merge it with any existing card that resolves to the same scenario; after a successful upsert, the source raw memory is deleted.
202
202
- Retrieval asks the underlying search for extra candidates, runs `memory.FilterPreferredScenarioResults`, prefers scenario cards, suppresses any transitional raw memories that are explicitly listed as `source_memory_ids`, and de-duplicates equivalent scenario cards as a safety net.
203
203
@@ -214,7 +214,7 @@ Memory Health returns reviewable, actionable recommendations, not automatic writ
214
214
- clean up raw source memories that are already represented by an existing scenario card
215
215
- merge duplicate scenario cards that deterministic identity resolution considers the same operational scenario
216
216
217
-
Each recommendation contains the proposed card, target scope, source memory IDs, and the diagnostic flags that explain why it was suggested. Duplicate-card recommendations also include `duplicate_card_ids`, `resolver_signals`, and a `match_score`; applying one first upserts the merged card and then deletes only those explicit duplicate scenario-card rows. Applying any recommendation uses the same scenario-card upsert endpoint as manual consolidation; after the card is saved or merged, incorporated raw source memories are deleted. Cleanup recommendations re-save the existing card metadata and delete the still-visible raw source rows. If the proposed card contains only the placeholder recipe, the raw inputs are discarded and no placeholder card is saved.
217
+
Each recommendation contains the proposed card, target scope, source memory IDs, and the diagnostic flags that explain why it was suggested. Duplicate-card recommendations also include `duplicate_card_ids`, `resolver_signals`, and a `match_score`; applying one saves the merged content in the target scope, preserves any existing non-duplicate card for the same resolved scenario, and then deletes only the explicit duplicate scenario-card rows. Applying any recommendation uses the same scenario-card upsert endpoint as manual consolidation; after the card is saved or merged, incorporated raw source memories are deleted. Cleanup recommendations re-save the existing card metadata and delete the still-visible raw source rows. If the proposed card contains only the placeholder recipe, the raw inputs are discarded and no placeholder card is saved.
218
218
219
219
`GET /api/memories/map` remains available as the advanced diagnostic report behind the Memory Health UI. It groups likely related memory chunks by a canonical topic key and flags conditions that make memory feel scattered or unsafe:
Copy file name to clipboardExpand all lines: docs/website/docs/agent/memory.md
+1Lines changed: 1 addition & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -109,5 +109,6 @@ memory:
109
109
- Use categories for organization (the agent does this automatically)
110
110
- In team deployments, publish useful memories to your team via Studio so colleagues benefit
111
111
- The agent automatically searches memory before responding — no manual retrieval needed
112
+
- In platform mode, durable operational knowledge is organized into scenario cards. Successful trace-backed recipes can be marked verified; unsupported notes remain draft until a later successful run confirms them.
112
113
113
114
See [Sessions](./sessions.md) for how session history differs from memory, and [Three-Tier Memory](../platform/three-tier-memory.md) for the full multi-tier system.
Copy file name to clipboardExpand all lines: docs/website/docs/platform/three-tier-memory.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -57,7 +57,7 @@ Personal ──publish──▶ Team ──promote──▶ Org
57
57
1.**Personal → Team**: any team member can publish a memory entry to their team via Studio. This makes it searchable by all team members.
58
58
2.**Team → Org**: a team admin or org admin promotes team knowledge to org level via Studio, making it available to every team in the organization.
59
59
60
-
The agent can also save knowledge directly during conversations using the `memory_save` tool. The tier is determined by the current context.
60
+
The agent can also save knowledge directly during conversations using the `memory_save` tool. The tier is determined by the current context. In platform mode, operational knowledge is stored as scenario cards when possible: trace-backed saves with successful external tool evidence are marked verified, while saves without execution evidence stay draft until a later successful run confirms them.
61
61
62
62
Promotion now performs a scenario-card upsert. When possible, the selected memory is distilled into an efficient successful-path card in the target tier and merged with an existing card for the same scenario. Scenario matching uses deterministic identity anchors such as system, service family, resource type, operation, environment, credential, endpoint host family, API family, HTTP method, and URL path; the canonical key is treated as an alias, not the only identity. After the card is saved, the original raw source memory is deleted; if it cannot form a useful card, it is discarded rather than kept as durable memory.
63
63
@@ -68,7 +68,7 @@ Here is how knowledge compounds in practice:
68
68
1.**Alice** debugs a tricky Kubernetes networking issue. The agent saves the resolution to her personal memory via `memory_save`.
69
69
2. Alice publishes the resolution to the **Backend team** via Studio. Now when any backend engineer hits a similar issue, the agent surfaces Alice's solution.
70
70
3. The team admin notices this resolution is relevant org-wide and **promotes it to org level** via Studio. If an org scenario card already exists for the same scenario identity, the new evidence is merged into that card instead of creating another duplicate memory.
71
-
4. If two cards were already created with different labels for the same scenario, **Memory Health** can recommend a duplicate-card merge, show the resolver signals, save the merged card, and delete only the explicit duplicate card rows.
71
+
4. If two cards were already created with different labels for the same scenario, **Memory Health** can recommend a duplicate-card merge, show the resolver signals, save the merged card into the target tier, preserve any existing non-duplicate card for that resolved scenario, and delete only the explicit duplicate card rows.
72
72
5.**Dave** on the Frontend team later encounters the same networking issue. The agent finds the org-level scenario card and guides him through the efficient path — even though Dave never interacted with Alice.
73
73
74
74
Each step is explicit. Knowledge does not leak upward automatically.
0 commit comments