AI Memory and Curated Context
What is organisational memory for AI?
Personal AI memory tracks what you prefer and what you've said before. RAG retrieves documents from a corpus when an agent needs a fact. Both are useful. Neither captures the knowledge that actually drives most organisational decisions — and neither was designed to.
What Actually Breaks
Here's the failure mode that plays out when organisations deploy agents without it.
An agent is given a system prompt. The prompt covers the task. It doesn't cover the reasoning behind the constraints — because that reasoning lived in a leadership conversation six months ago and was never written down. The agent makes decisions that are technically within scope but wrong in ways that are difficult to articulate, because articulating them requires context the agent was never given.
When the decision needs explaining — to a client, a board, a regulator — the organisation goes looking for the record of what the agent was working from. What exists is logs of what it did, not the basis on which it decided. Reconstructing that basis from Slack threads, prompt files, and Git history takes time, produces an approximate answer, and often reveals the constraint the agent should have known about was never formally recorded anywhere.
That's not a retrieval failure. The document didn't exist to retrieve. It's an authorship failure — the knowledge was never captured in a form an agent could work from.
What RAG Doesn't Reach
RAG retrieves what's been written down. That's genuinely useful for policies, product specs, support articles — anything that exists as a document. But the knowledge that shapes how an organisation actually operates often wasn't written down to begin with.
The trade-off accepted in a product decision. The constraint agreed between two teams that everyone knows but nobody formalised. The goal that shifted last quarter and the reason it shifted. This knowledge lives in people — and when those people are unavailable, or when an agent is deployed to act on their behalf, it isn't in the document corpus for retrieval to find.
What Organisational Memory is
Organisational memory, in an AI context, is the authored record of what your organisation has decided, what it's committed to, and what its agents are permitted to know and do — built deliberately, before agents are deployed to act on it.
Organisational memory is a property of a system, not a specific data structure. How it's implemented will vary. Two things define it regardless of implementation:
It's authored, not extracted. The knowledge is put there intentionally by the people who hold it. Extraction pulls from documents written for other purposes. Authorship captures what extraction misses: the reasoning, the nuance, the things that matter but never made it onto a page.
It carries temporal context. When something changes, the change is recorded alongside what it replaced and why. An agent that knows a constraint changed last month and the reason it changed behaves differently from one that only knows the current state.
A third consideration follows from these two: the authored record should be portable — owned and controlled by the organisation, not locked inside any provider's runtime. This is a design principle worth insisting on, but how it's achieved depends on the implementation.
What This Makes Possible
An agent working from organisational memory doesn't start from scratch. It starts from what the organisation actually knows — the decisions that shaped current constraints, the goals that define what good looks like, the reasoning that would otherwise exist only in someone's head.
More importantly, it starts from a record that existed before it acted. When something goes wrong, the question isn't "what did the agent do?" — logs answer that. The question is "what was it working from?" That answer should be retrievable, not reconstructed. It should exist as an authored record, established before execution began.
Engramic's approach
How Engramic Builds it
There are multiple ways to implement organisational memory. This is one approach.
Engramic represents organisational memory as a typed knowledge graph. Topics are categorised as Goals, Constraints, Gaps, Decisions, Discoveries, or Artefacts — because a Constraint carries different weight for an agent than a Discovery, and the distinction matters at decision time. Relationships between topics are also typed: Depends on, Relates to, Blocks, Blocked by. That structure lets an agent navigate the graph without being told explicitly where to look — it follows the relationships.
Ownership is built in at the same level of granularity. Each topic, goal, and agent has roles and responsibilities assigned to it — not at process level, but per item, modelled around RACI. For any given Constraint, there's a named person who owns it, a named person who should be consulted when it changes, and named people who should be informed. When something goes wrong, the question "who was accountable for that knowledge being accurate?" has an answer in the graph before the question is asked.
The difference from a flat policy repository or decision log isn't only what is stored — it's how it's structured and made navigable at decision time.
A Useful Comparison
A good consultant doesn't walk into a new client and start recommending changes on day one. They ask structured questions first — designed to surface the reasoning behind how things work before they touch anything. Each answer either confirms something they can rely on, or reveals a gap that needs filling.
That process builds a record as it goes. The questions surface the knowledge. The answers become the brief. And the brief is what makes subsequent decisions governable — and explainable when the question comes.
Agent onboarding works the same way. The questions aren't a better prompt. They're a structured process for authoring the knowledge an agent needs, before it acts.