Operational memory with governance, evidence flow, and workload-level knowledge isolation.
- Per-tenant memory namespaces, never mixed across clients or matters
- Audit ledger of every prompt, retrieval, action, and model call
- Sovereign, private, and hybrid deployment options
- Evidence flow integrated with Carbon Ledger and compliance reporting
Agent memory without governance creates risk at every isolation boundary
The memory problem in enterprise AI is not persistence - it is isolation, governance, and defensible evidence at scale.
Shared vector stores leak context across isolation boundaries
Shared vector stores leak context across isolation boundaries
Standard vector databases store embeddings in shared indices. Without per-tenant namespace isolation, retrieval operations can surface content from adjacent tenants, matters, or departments. This is not a configuration problem - it is a structural one.
Agent memory is not audited at the level compliance requires
Agent memory is not audited at the level compliance requires
AI Act obligations, legal professional responsibility rules, and financial sector regulations require documented evidence of what an agent knew, when, and from which source. Shared memory stores with no audit ledger cannot produce this.
Retention and deletion are ungoverned by default
Retention and deletion are ungoverned by default
GDPR and data minimization obligations require that personal data in agent memory is retained only as long as necessary and deleted on request. Standard vector stores have no policy-driven retention or deletion audit trail.
Agents repeat questions because memory has no continuity model
Agents repeat questions because memory has no continuity model
Without structured operational memory, agents re-ask for context that should persist across sessions. This produces inconsistent outputs, degrades user trust, and wastes inference compute on context reconstruction.
Memory access is not attributable to specific agent actions
Memory access is not attributable to specific agent actions
When an agent makes a decision, there is no record of which memory retrievals contributed to that decision. Decision provenance required for AI Act high-risk systems cannot be reconstructed from standard memory systems.
Cross-environment memory is not supported
Cross-environment memory is not supported
Enterprise AI deployments span private cloud, public cloud, hybrid, and edge. Memory systems that only work within one environment create silos that prevent organizational knowledge from accumulating across the full deployment surface.
How Cortex compares to alternative memory systems
Against shared vector databases, provider-native memory, session-based context, and custom RAG pipelines.
| Cortex | Shared vector DB | Provider-native memory | Session context only | Custom RAG pipeline | |
|---|---|---|---|---|---|
| Per-tenant namespace isolation | - | Limited | N/A | Partial | |
| Audit ledger of all operations | - | - | - | - | |
| Policy-driven retention and deletion | - | - | - | - | |
| Sovereign and air-gapped deployment | - | - | - | Partial | |
| Memory across sessions | - | Limited | - | ||
| GDPR erasure request handling | - | - | N/A | - | |
| Carbon-aware memory operations | - | - | - | - | |
| Integration with Carbon Ledger | - | - | - | - |
How Cortex operational memory and governance flow work
Eight stages from memory write through governance flow to evidence output - with isolation enforced at every stage.
Technical deployment surface
Cortex deploys as a sovereign memory service alongside your agent runtime with private, hybrid, and edge options.
Per-tenant namespace isolation
Each tenant, client, matter, or department gets a dedicated memory namespace with storage-layer isolation. Namespace boundaries are enforced at write and retrieval time - not at query filtering. Cross-namespace retrieval is architecturally impossible.
Sovereign and private deployment
Cortex runs inside your VPC, on-premises, or in an air-gapped environment. Memory storage never leaves your declared sovereignty boundary. Hybrid deployment replicates within jurisdiction constraints.
Audit ledger
Append-only audit ledger recording every memory write, retrieval, update, policy change, and deletion with full provenance. Ledger is signed, versioned, and exportable per tenant. Tamper-evident by design.
Policy-driven retention and deletion
Retention schedules defined per tenant, per data category, or per namespace. Deletion operations execute on schedule or on request with documented evidence. GDPR erasure requests trigger structured deletion workflows with audit output.
Carbon-aware memory operations
Embedding refresh, index rebuild, and compaction scheduled into clean-grid windows using GREENPOW signal feeds. Carbon attributed to memory operations with evidence labels matching other GREENPOW products.
Integration with agent runtimes
SDK integration for Python and TypeScript agent frameworks. REST API for custom integrations. Compatible with LangChain, LlamaIndex, CrewAI, and custom agent orchestration frameworks. Memory retrieval adds typically under 30ms.
How organizations use Cortex operational memory
Legal AI with per-matter memory and defensible audit trail
The legal AI agent has access to a shared vector store containing documents from multiple client matters. Retrieval operations cannot guarantee per-matter isolation. The firm cannot produce an audit trail of what the agent knew during a specific matter.
Cortex provides per-matter memory namespaces. Retrieval is scoped to the requesting matter ID. The audit ledger records every retrieval with the document source, relevance score, and agent identity. The evidence pack is exportable per matter for client review.
Enterprise copilot with organizational knowledge accumulation
The enterprise copilot answers questions from scratch every session. Organizational knowledge - decisions, precedents, preferences, terminology - is not persisted. Users repeat themselves. The copilot cannot compound knowledge over time.
Cortex accumulates organizational knowledge across sessions within per-department and per-team namespaces. The copilot retrieves relevant context from memory without re-prompting. Knowledge compounds over time and stays within declared isolation boundaries.
Regulated financial AI with GDPR-compliant memory governance
The financial AI has personal data in its memory store with no documented retention policy, no deletion audit trail, and no way to respond to subject access or erasure requests with documented evidence.
Cortex applies policy-driven retention schedules per data category. Deletion requests trigger documented deletion operations with audit evidence. Subject access requests are answered with a structured memory export scoped to the requesting subject's data.
Multi-environment AI with sovereign memory across private and public cloud
The enterprise AI deployment spans private cloud for regulated workloads and public cloud for non-regulated ones. Memory stored in the public cloud environment is not accessible to agents running in the private cloud, creating knowledge silos.
Cortex supports hybrid deployment with sovereign memory replication across environments respecting jurisdiction rules. Agents in the private cloud environment access only memory that satisfies their jurisdiction constraints. Cross-environment silos are eliminated within compliance boundaries.
Technical questions
How does Cortex enforce per-tenant isolation at the storage layer?
Cortex uses dedicated storage namespaces per tenant with cryptographic separation at the storage layer. Query operations are issued within a namespace boundary enforced before query execution - not as a post-query filter. There is no configuration mode that permits cross-namespace retrieval.
Can Cortex run in a fully air-gapped environment?
Yes. Cortex is designed for sovereign and air-gapped deployment. Memory storage, retrieval, audit ledger, and policy engine all operate without external API dependencies. Carbon intensity data for memory operation scheduling can be ingested from pre-loaded signal packages.
How does the audit ledger work and how is it protected?
The Cortex audit ledger is an append-only log with cryptographic chaining. Each entry includes: timestamp, agent identity, tenant namespace, operation type, content hash, and policy rule applied. The ledger is signed per entry and versioned. Tamper attempts are detectable from any archived entry. Ledger export is per-tenant and available via API or scheduled export.
How does Cortex handle GDPR erasure requests?
Erasure requests trigger a structured deletion workflow: identify all memory entries in the subject's scope, execute deletion with soft-delete followed by hard-delete at the next retention cycle, generate a deletion evidence record with timestamps and entry identifiers. The evidence record is exportable for DPA reporting.
What agent frameworks does Cortex integrate with?
Cortex provides SDK integration for Python and TypeScript with native support for LangChain, LlamaIndex, CrewAI, and AutoGen. REST API available for custom integrations. Memory retrieval latency is typically under 30ms for standard namespace sizes.
How does Cortex memory relate to the Carbon Ledger?
Cortex memory operations (embedding refresh, compaction, index rebuild) are scheduled using GREENPOW signal feeds and produce carbon attribution records with the same evidence label framework as the Carbon Ledger. Carbon from memory operations is attributable per tenant and per operation type, and can be included in tenant-level CSRD reporting.
When to pick a sibling product instead
See Carbon Ledger evidence and Cortex governance in action
Tell us your agent workload, isolation requirements, and compliance constraints. We scope a memory architecture that satisfies all three.