An agent checking an order may need several kinds of information. It needs the current order details, the approval that allowed the purchase and perhaps a previous interaction with the customer. Those records serve different purposes. The current order says what the business holds now. The approval helps explain why an action was allowed. The previous interaction provides context that may or may not apply to this request.
Keeping these distinctions clear is part of the memory design in Synedrix OS, the governed operating layer for agentic business systems. The system needs to know which information is authoritative, who may use it and how it became part of the record. Putting everything within reach of an agent would leave those questions unanswered.
Synedrix OS calls the combination of its stores and memory controls the memory fabric. The platform is in active development. This article explains the architecture and the checks an implementation must provide, rather than claiming that arranging the databases proves those checks work.
The kind of memory and the place it is stored
The architecture distinguishes what a record means from where it is stored. A memory tier describes the kind of information. A store is the system that holds the record or a copy used to find it.
There are eight tiers. Working memory holds temporary information used during a run. Episodic memory records something that happened, such as a completed interaction. Semantic memory holds an assertion derived from recorded events, while procedural memory describes a reusable method. Profile memory contains information about a particular subject. Relational memory holds business records and their current state. Graph memory captures relationships and causes. Temporal memory holds measurements over time.
These distinctions help explain the order example. The current order belongs to business state. A recorded interaction is an episode. A customer preference derived from that interaction is a separate assertion about the customer. The system needs to preserve the connection between the assertion and the evidence behind it, rather than treating both as equally established facts.
The same distinction applies to a reusable procedure. A successful customer interaction is an event. A method derived from several interactions is a different kind of record, and it needs to remain connected to the experiences that support it. Otherwise, a one-off success can become a general instruction without anyone being able to examine how that conclusion was reached.
The tiers do not require eight separate databases. Several kinds of memory share a store, and a record can have copies that make it easier to retrieve. The architecture identifies which store holds the authoritative record and which copies can be rebuilt. That distinction matters when a copy is missing, out of date or inconsistent with its source.
What the stores are responsible for
Five stores belong to the Memory & Data Layer, Layer 7. Redis holds temporary working state. Supabase Postgres holds authoritative business records and several durable memory tiers, including episodes, assertions, procedures and profiles. QuestDB holds time-series measurements. Neo4j holds graph relationships, while audit-bearing lineage remains authoritative in Postgres. Qdrant holds the vector indexes used to retrieve records by similarity.
An index helps an agent find relevant information. It must not become the only surviving copy of a durable fact. In this design, rebuilding a retrieval index should preserve the authoritative records behind it. Likewise, losing temporary working state must not destroy the durable information needed to reconstruct a run.
For example, a customer preference can be authoritative in Postgres while Qdrant holds an index entry that helps find it. Searching by meaning is useful when the request uses different words from the original conversation. Finding a similar record, however, does not establish that it is current or appropriate for this customer. Its scope, source and validity still need to be checked.
This also explains why copying information between stores needs a defined purpose. A retrieval index should point back to the record it represents. A graph can make relationships easier to follow without taking over ownership of the audit evidence. The useful question is which record settles a disagreement and how the other copies relate to it.
Langfuse and PostHog provide related evidence about the system. Langfuse records model traces and prompt information; PostHog records behavioural analytics. Both are mapped to Layer 10, the Observability Layer. Their records help examine system behaviour, but they do not replace the authoritative business and memory records.
Different stores support different access patterns. A time-series query asks how a measurement changed. A graph query follows relationships. A similarity search looks for relevant records without requiring the same words. The storage choices support those jobs, while permissions and recorded evidence govern how the results may be used.
Check access before returning information
An agent's memory profile declares the memory it may access and the scope of its requests. That profile needs to be checked when the agent asks for information. Merely writing down a permission does not enforce it.
Memory recall is an authorised tool call in Synedrix OS. The Memory Access Broker Agent (os-agt-012) checks the requested scope against the agent's permitted scope before retrieval. The resulting restrictions are applied in the store query. Information outside that scope must not enter the agent's process and then be filtered out afterwards.
For an illustrative customer request, an agent might need information about one customer. Being allowed to use a memory tool does not give it permission to retrieve records about every customer. The request still needs the right tenant and subject scope. Returned records also carry their source information and validity period, so the agent has evidence about where the information came from and when it applies.
Consider what happens if the request is broader than the task needs. A customer-service agent might ask about delivery preferences while naming both profile memory and a memory tier it is not permitted to read. The access check must handle that as a permission problem. It cannot rely on the agent ignoring anything it should not have received.
The returned information also needs a time context. A preference that was valid when an order was placed may have changed since then. Normal recall should use information valid for the requested time and exclude records that have been superseded or erased. Reconstructing a past state for an audit is a separate, restricted operation. Those are different requests, even when they concern the same customer.
This is how Principle 5 (Shared context with scoped access) becomes a concrete requirement. Agents can share useful context while access remains limited to their assigned work. A database can enforce different permissions within the same system; the number of databases alone does not establish this boundary.
Separate proposing a memory from saving it
Reading information and creating a durable record are different responsibilities. An agent may propose something worth remembering, but that proposal must pass through the memory controls.
The Memory Access Broker Agent (os-agt-012) checks access on every recall and write proposal. Only the Memory Curator Agent (os-agt-010) commits durable memory. The Consolidation & Reflection Agent (os-agt-011) can recommend changes, such as combining related records.
Consider a customer who gives a delivery preference during one conversation. That event may justify a proposed memory, but the system still needs to preserve its source, decide its scope and establish how long it applies. A preference mentioned for one order should not silently become an unrestricted instruction for every future order.
The requesting agent must describe the information it wants to retain so the Broker can check whether the proposal is within its permitted scope. A recommendation to combine several records remains a recommendation until it passes through that controlled path. The agent that suggests a change gains no permission to commit it.
Each record also needs provenance, meaning the information that connects it to its source. In this example, that includes the interaction that produced the proposed preference and the records used to derive any broader assertion. This connection allows a reviewer to ask whether the saved statement was supported by what the customer actually said.
When a record moves between memory tiers, the architecture requires a governed promotion event. That makes the transition part of the recorded process, so the system can explain how an episode became a more general assertion or a reusable procedure.
Handle a changed preference without losing its history
Suppose the customer later asks for deliveries to arrive on a different day. That is a change to information about the customer, and the system needs to distinguish the new preference from the one that applied to earlier orders.
The architecture uses supersession for this: a new record identifies the record it replaces, and the old record's period of validity closes. Normal recall can then use the current preference. An authorised review of an earlier decision can still establish which preference applied at that time. Overwriting the old value would make that explanation harder, because the current record would no longer show what the agent could have known.
Conflicting records need different handling from a confirmed update. Two interactions might contain different instructions without establishing that either replaces the other. The memory controls must surface that disagreement for resolution rather than silently discard the inconvenient record. Keeping evidence of both statements helps the responsible agent or person decide whether the difference is a correction, a limited exception or a mistake.
Erasure is another distinct operation. When approved, the content must be removed from the authoritative store and its projections. Deleting only the search entry would leave the source intact; deleting only the source could leave a retrievable copy elsewhere. A tombstone records that the memory existed and was erased under approval, while its content is no longer available.
That record preserves accountability without allowing normal recall to recover the erased information. Records derived from the erased source also need review; they are not automatically all deleted, because the consequences depend on what each derived record contains. The architecture assigns the recommendation to review those dependencies separately from the authority to erase content.
Keep the evidence needed to explain a decision
Returning to the order, reviewing an outcome requires more than finding the current record. The reviewer needs to establish which information was available, which agent requested it, whether that access was permitted, and which action followed. That supports Principle 7 (Explainability and audit by design).
The memory design helps by preserving sources, access boundaries, and responsibility for durable changes. It still depends on the runtime enforcing those controls and retaining the required evidence. A diagram showing separate stores cannot demonstrate that on its own.
There is an operational cost to maintaining these boundaries. Stores, indexes, and permissions must remain consistent, and failures between them need a defined response. The value of the design is that those responsibilities are explicit: a retrieval result has a source, access has a scope, a durable write has an owner, and a change leaves evidence. Those are the properties to examine when testing the implementation, rather than treating the choice of databases as sufficient proof.
The next step is to follow a request through its checks: what the agent declares, what the platform permits, and what happens before an action proceeds.
Related reading
- The 12 layers of Synedrix OS: a complete mental model — places memory, governance and observability within the wider architecture.
- The 12 principles that make agentic systems trustworthy — explains the shared-context and audit requirements behind this design.
Documentation
- Memory Fabric Spec: the memory tiers, storage responsibilities, and rules for recall, promotion, and erasure.
- Memory Runtime Integration Guide: how memory requests pass through access checks and the agents responsible for saving records.
- Agent Spec: the memory profile and permissions declared as part of each agent's definition.
Synedrix OS — memory fabric
