CortexDB is the long-term memory layer for AI agents. The platform uses deployment profiles as policy gates to control which enterprise features remain active in a given deployment.
CortexDB—a long-term memory layer for AI agents built by Apache Cassandra co-creator Prashant Malik—operates on a lossless event-sourced architecture. Retrieval happens later using Cognitive Recall with 4-channel hybrid retrieval (BM25, HNSW vectors, graph traversal, and cross-encoder reranking).
Why do deployment profiles matter for AI agents?
AI agents require persistent context to function across multiple sessions. Production deployments for these agents span a wide range of operational sophistication.
Most teams attempt to solve memory by building their own custom access logic within their agent frameworks. A team launching their first AI feature does not need complex data-residency controls and legal-hold workflows from day one, but an enterprise rolling out across regulated jurisdictions needs all of them immediately.
Alternative memory layers attempt to store lived experience differently. Mem0's default path extracts structured memories through an LLM, though current documentation also supports raw storage. Zep builds temporal knowledge graphs from chat and business data. CortexDB takes a different approach by treating every incoming interaction as an immutable event protected by standardized deployment profiles.
CortexDB separates the durable log from the derived views. The raw event remains the source of truth, and deployment profiles dictate how tightly that truth is governed. Summaries, embeddings, and knowledge graphs function as derived artefacts built asynchronously. We built this architecture to ensure teams can scale their compliance controls smoothly as they grow.
How does CortexDB manage deployment profiles?
CortexDB relies on four deployment profiles to define the default control surface. The startup profile blocks enterprise controls by default. The growth profile allows a smaller operated subset like backups and rate limiting. The enterprise profile enables the full enterprise control surface natively. The custom profile expects explicit deployment.features.* overrides for bespoke requirements.
A control activates only when both the profile allows it and the control's own config is explicitly enabled. This two-condition model means the profile is necessary but not sufficient alone.
Administrators execute verification checks using the GET /v1/admin/enterprise/status endpoint. The response reports the active deployment profile, the effective feature gates, and which runtime services are actually active.
What do deployment profiles enable?
Three consequences matter most for infrastructure teams.
Incremental compliance allows early-stage teams to use CortexDB without absorbing heavy governance overhead. The startup profile strips away complex enterprise requirements until they become strictly necessary.
Predictable rollouts rely on the live Docker validation runner. The testing suite exercises every profile against the same image so operators can validate behaviour changes before applying them in production.
Customized governance supports enterprise teams with bespoke compliance needs. The custom profile allows operators to explicitly enable or disable individual features through precise configuration overrides.
Frequently asked questions
What is a deployment profile in CortexDB?
A deployment profile is a policy gate controlling which enterprise features can be active. Four profiles (startup, growth, enterprise, custom) define the default control surface. A control activates only when the profile allows it and its own config enables it.
What is the difference between the four profiles?
The startup profile blocks enterprise controls by default. The growth profile allows backup and rate limiting. The enterprise profile allows the full enterprise control surface. The custom profile expects explicit per-feature overrides.
How is a control activated?
CortexDB requires two conditions: the deployment profile must allow the control, and the control's own config must be enabled under the security.* or compliance.* namespace. Either condition alone remains insufficient.
How do I verify which controls are active?
Call GET /v1/admin/enterprise/status. The response reports the active deployment profile, effective feature gates, and which runtime services are actually active to serve as the single source of truth.
Can a deployment change profiles after launch?
Yes. The profile functions as a standard configuration setting and can be modified by an operator at any time.
What is the custom profile for?
The custom profile serves deployments with bespoke control requirements. Each feature is explicitly enabled or disabled through deployment.features.* overrides while maintaining the dual-activation model.