A business system fields a strange mix of questions in a single afternoon: what is the current status of an order, what last quarter's volume looked like against the same month a year ago, which entities in the account graph touch a support ticket, and what an agent concluded when it approved a transaction and on what basis. Most platforms try to answer all of it from one database, because that is what a database is built to do. Synedrix OS answers each question from a different store. Not because one store would be slower. Because one store would be ungoverned.
Memory is not a bucket. It is a memory fabric: a set of specialised stores, each answering one kind of question, each governed by its own access rules. Conflating different kinds of truth into a single datastore is not a shortcut. It is an architectural mistake, and the cost of it does not show up in a benchmark. It shows up months later, when someone has to prove exactly what an agent was allowed to read and write, and finds that the boundary was never real to begin with.
Seven questions, seven kinds of truth
Synedrix OS names seven memory classes, and each one answers a single kind of question.
- Working memory (Redis) holds ephemeral hot state: coordination signals, deduplication windows, idempotency keys, heartbeats. It answers what is true right now, in this instant, and it is allowed to forget.
- Canonical memory (Supabase Postgres) holds the authoritative transactional record: business entities, policies, approvals, audit trails. It answers what is authoritative and durable, and it is not allowed to forget.
- Temporal memory (QuestDB) holds time-series facts: trends, seasonality, event windows. It answers what happened over time and how it moved.
- Graph memory (Neo4j) holds relationships and lineage. It answers how one entity is connected to another.
- Semantic memory (Qdrant) holds embeddings for similarity retrieval. It answers what is similar to this.
- LLM trace memory (Langfuse) holds prompt versions, traces, and cost attribution. It answers what a model actually did, and what it cost.
- Behavioural memory (PostHog) holds workflow and user analytics. It answers how people and workflows behave in aggregate.
That separation is not a taxonomy exercise. It is a design principle Synedrix OS calls layered truth: memory access is scoped by truth layer and by purpose, as an explicit invariant of the platform, not a convention teams are trusted to follow.
A profile, not a permission toggle
The seven stores would just be an interesting taxonomy if nothing enforced who could touch which one. That enforcement is the memory profile: a declared, versioned part of every agent's definition, sitting alongside its authority and its contracts.
A memory profile does not grant an agent broad read or write access to a store. It grants scoped intent, expressed as compound declarations rather than a single toggle. Here is the profile for the Ops Policy Guard Agent, an agent responsible for validating high-impact operational actions before they execute:
working_memory: scoped-session
canonical_memory_access: read-approvals,read-policy-records,write-decision-log
semantic_memory_access: read-policy-cases
graph_memory_access: read-lineage
temporal_memory_access: read-recent-incidents
audit_memory_access: write-audit-events
retention_policy: os-default-high-impactRead that profile closely and it says something precise. This agent may read approvals and policy records, and write only to a decision log. It may read policy cases for precedent, and lineage for context. It may read recent incidents. It may write audit events. It may not touch anything else, in any store, for any reason, and that restriction is enforced by the platform rather than assumed by the team that built the agent.
A single undifferentiated bucket cannot express that sentence. You cannot declare "read approvals, write decision log, nothing more" against one table that also holds session state and embedding vectors and time-series metrics, because the table has no way to distinguish which rows belong to which kind of truth. The memory profile is only possible because the fabric underneath it already separated the truths it is scoping.
One bucket cannot hold four jobs
Separation would still be optional if a single well-built database could do all seven jobs at once. It cannot, and the reason is not a matter of degree.
An audit trail has to be append-only. Every invocation record has to remain exactly as it was written, because a mutable record cannot support a reliable answer to what happened, why, and under whose authority. A coordination bus has to be the opposite: fast, ephemeral, expiring writes measured in single-digit milliseconds, with old state discarded on purpose. Build both on the same table and one requirement has to lose. Either the audit trail stops being immutable, or the coordination bus stops being fast.
The same tension repeats across the other pairs. A time-series store tuned for trend queries over months of data has different retention and indexing needs than a similarity index built for nearest-neighbour lookups over embeddings. A relationship graph answers connectivity questions that a relational table answers poorly, and a relational table answers transactional questions that a graph answers poorly. These are not tuning problems to solve with a bigger instance. They are contradictions, and the fabric exists because contradictions do not resolve themselves.
Separation is a security boundary
Once truth is layered instead of pooled, a property falls out of the architecture for free: memory scope becomes a security boundary.
Observability truth, the traces in LLM trace memory and the analytics in behavioural memory, sits in its own layer and can never be touched by an operational write, because there is no shared table through which that write could reach it. Audit records in canonical memory are structurally isolated from the mutable business state they describe, so an approval cannot be quietly edited after the fact by a process that only had permission to update an order.
None of that depends on a reviewer noticing the right thing at the right time. It depends on the fabric making the wrong access impossible to express, which is a stronger guarantee than any review process has ever offered.
A memory profile is a declaration. It states what an agent may touch, in which store, and for what purpose, and the fabric makes that declaration meaningful by keeping the truths apart in the first place. But a declaration is not yet an enforcement. Something still has to check that declaration before an action is taken, hold the line when an agent asks for more than its profile allows, and escalate when the answer is no. That check is where governance stops being a design property of memory and starts being a property of execution itself, and it is the next question this architecture has to answer.
Synedrix OS is in active development. If you are interested in co-founding or investing, the door is open.
Related reading
The 12 layers of Synedrix OS: a complete mental model โ that post drew the Memory & Data layer as a single box and said directly that it should not have been; this post is the box opened.
Next in the series: Governance before execution โ Post 11 introduces the check that enforces what a memory profile only declares, with the Ops Policy Guard Agent as its runtime enforcer.
Synedrix OS โ memory fabric
