Evidence-linked trend hypothesis
Company memory needs write and correction loops
Retrieval is only one stage of memory; durable organizational knowledge also needs scoped writes, corrections, provenance, versioning, and invalidation.
Source ledger
Publishable sources attached to this record.
| # | Source | Role | Public status |
|---|---|---|---|
| 1 | hermes-agent.nousresearch.comsource | primary receipt | source_urls |
| 2 | github.comrepo | supporting receipt | source_urls |
| 3 | promptql.iosource | supporting receipt | source_urls |
| 4 | aclanthology.orgsource | supporting receipt | source_urls |
| 5 | github.comrepo | supporting receipt | source_urls |
Showing 5 of 10; the complete set is exposed in the JSON route.
Current state, as of Oct 13, 2026
Where this stands now
holding The evidence still supports governed memory that can be updated and corrected through real work, rather than retrieval alone. Recent examples include guided memory, cross-session project memory, governed live-web context, and APIs that call for durable context management.
Company memory is still framed as a lifecycle, not just retrieval: useful knowledge needs scoped writes, corrections, provenance, versioning, and invalidation. September’s update added Engram’s guided memory layer, operated context, and observability of what was stored, recalled, and merged.
A later update points to Engram, Grok Build, Merge, OpenAI’s Agents API, and Anthropic alignment research as examples of active memory or durable context. For builders, the practical rule remains to make writes reviewable and governed, with evidence, authority, scope, supersession, and rollback.
What changed since the original text
- A published update adds examples of cross-session project memory, governed live-web context, durable context management, and iterative revision driven by persistent memory. 1
- September’s update describes context as an operated service and memory observability as tracking what was stored, recalled, merged, and at what cost. 1
Open questions
- Do these examples demonstrate reliable memory correction in production, rather than describe product capabilities or research?
- How do the systems handle conflicting updates, authorization boundaries, and rollback in practice?
Watch next: Look for production evidence that these systems reliably review, scope, and supersede memory updates.
- Weekly update: New tools and APIs demonstrate write‑and‑correction loops for company memory update, Sep 21, 2026
Rewritten automatically by the New Runtime knowledge desk from this record's weekly updates, releases and archive. The original text below is kept as written (Jun 24, 2026); where the two disagree, this section is newer.
Weekly knowledge desk
Weekly updates
1 reviewed update to this pattern, newest first. Every update is checked against its evidence before it changes the record.
New tools and APIs demonstrate write‑and‑correction loops for company memory
Recent releases such as Engram’s guided memory layer, Grok Build’s cross‑session project memory, and Merge’s governed live‑web context all embed memory as an active, governed layer that is continuously updated by real work. OpenAI’s Agents API explicitly calls for durable context management and saving intermediate results, while Anthropic’s alignment research shows a persistent memory file driving iterative revisions. These concrete implementations illustrate that useful company memory arises from ongoing write‑and‑correction loops rather than passive document retrieval.
- Agent Memory with Engram: A Practical Guide signal, Sep 24, 2026
- Grok Build adds cross-session project memory for coding sessions signal, Sep 24, 2026
- Merge picks Parallel Search for Universal Context Layer post, Sep 26, 2026
- Introducing the Agents API | OpenAI external, Sep 28, 2026
- Automated Researchers Can Mitigate Well-Characterized Alignment Failures | Anthropic external, Sep 28, 2026
What does retrieval leave unresolved?
A relevant document can still be stale, unauthorized, contradicted, or scoped to another team. A long context window can expose more text without deciding which statement should change the next action. Those are memory lifecycle questions, not search-quality questions.
What evidence supports this pattern?
- PromptQL captures a correction during work, proposes a reusable rule, and keeps citations, scope, revision history, and editorial control around the update.
- DoorDash stores semantic memory as independently versioned components and a manifest, then refreshes different memory layers at different cadences.
- MemoryData evaluates storage, retrieval, updating, and forgetting across a sequence rather than scoring only a final response.
- OpenWiki turns repository understanding into a maintained artifact that can be inspected and refreshed outside an individual session.
What should teams do next?
Every memory entry needs a write path, evidence, owner or authority, scope, timestamp, supersession behavior, and rollback. Human correction is a valuable write signal, but it should produce a reviewable proposal rather than an unbounded automatic truth update.
September 2026 update
What changed
Engram presents memory as a guided layer, while a universal context deployment makes context an operated service rather than a local chat artifact. Memory observability adds a missing operational question: what was stored, recalled, merged, and at what cost.
Builder rule
Every memory write needs evidence, authority, scope, timestamp, supersession behavior, review path, and rollback. Treat a correction as a proposed, inspectable update—not an unbounded truth write.