# ContextDB > Context and memory layer for AI agents. ContextDB helps voice, chat, support, > and workflow agents remember each customer across sessions and evaluate > action-relevant evidence before bookings, refunds, plan changes, or record > updates. Last reviewed: 2026-08-27 ## Agent discovery - Integration guide: https://contextdb.ai/for-agents - Machine integration guide: https://contextdb.ai/for-agents.txt - Repository agent rules: https://contextdb.ai/AGENTS.md - Service status: https://contextdb.ai/status - Memory API OpenAPI 3.1: https://contextdb.ai/openapi.yaml - Memory CI OpenAPI 3.1: https://contextdb.ai/evals-openapi.yaml - XML sitemap: https://contextdb.ai/sitemap.xml ## Site directory ### Core product - [Context and Memory Layer for AI Agents | ContextDB](https://contextdb.ai/): ContextDB gives AI agents cross-session customer memory and evaluates remembered evidence before the host books, refunds, or changes an account. - [AI Agent Memory With Action Checks | ContextDB](https://contextdb.ai/product): ContextDB forms, updates, retrieves, and tests customer memory, then returns act, ask, or abstain for the host to enforce before an action. - [Async Memory Formation for AI Agents | ContextDB](https://contextdb.ai/formation): Async Formation turns completed calls, chats, and workflows into reviewed or committed ADD, UPDATE, DELETE, or NOOP memory operations. - [AI Agent Memory Evolution | ContextDB](https://contextdb.ai/memory-evolution): Memory Evolution applies explicit ADD, UPDATE, DELETE, or NOOP operations with lineage and read-your-writes tokens for current agent memory. - [AI Agent Memory CI and Regression Tests | ContextDB](https://contextdb.ai/evals): Memory CI runs deterministic recall and action cases against a pinned baseline and returns distinct pass, regression, or operational exit codes. - [Managed Data Sources for Agent Memory | ContextDB](https://contextdb.ai/managed-sources): Managed Sources is in Private Alpha, with bounded preview, backfill, incremental reads, checkpoints, retries, and soft deletes for selected records. ### Use cases and guides - [AI Agent Memory Use Cases | ContextDB](https://contextdb.ai/use-cases): ContextDB supports memory checks before AI agents book, refund, schedule, update accounts, or mutate workflows. The host enforces every outcome. - [Voice Agent Memory for Bookings | ContextDB](https://contextdb.ai/voice-agents): Voice agent memory carries caller context across calls and evaluates current evidence before the host books, refunds, reschedules, or updates. - [Customer Memory for AI Support Agents | ContextDB](https://contextdb.ai/support-agents): Support agent memory carries selected customer history across channels and checks evidence before the host issues credits or changes accounts. - [Agent Memory vs RAG: Key Differences | ContextDB](https://contextdb.ai/agent-memory-vs-rag): RAG retrieves information from documents. Agent memory retains customer history across sessions. Use both when an agent needs both kinds of context. - [AI Agent Memory Management Guide | ContextDB](https://contextdb.ai/memory-management-for-ai-agents): Agent memory management governs what is stored, how it changes, what is retrieved, and what evidence an agent may use when taking action. ### Integrations - [AI Agent Memory Integrations | ContextDB](https://contextdb.ai/integrations): Connect ContextDB to agent frameworks, voice stacks, support tools, MCP clients, and data sources using documented starters and guides. - [Retell AI Agent Memory Integration | ContextDB](https://contextdb.ai/memory-for-retell): Add memory to Retell with caller recall, a backend action check, host enforcement, execution reporting, and sourced post-call writes. - [LiveKit Agents Memory Integration | ContextDB](https://contextdb.ai/memory-for-livekit): Add memory to LiveKit Agents by loading caller history at session start and checking evidence inside authenticated, host-owned action tools. - [Pipecat Voice Agent Memory Integration | ContextDB](https://contextdb.ai/memory-for-pipecat): Add memory to Pipecat by registering recall and action handlers, keeping identity in pipeline state, and saving sourced facts when calls end. - [PyAI Voice Agent Memory Integration | ContextDB](https://contextdb.ai/memory-for-pyai): Add memory to PyAI Omni with a backend tool that checks identity, host state, and memory policy before executing and reporting an action. - [Intercom Fin Customer Memory Integration | ContextDB](https://contextdb.ai/memory-for-intercom-fin): Add customer memory around Intercom Fin with backend checks for identity, account state, authorization, and remembered evidence before actions. ### Comparisons and data stack - [ContextDB vs Mem0: AI Agent Memory Compared](https://contextdb.ai/vs-mem0): Mem0 emphasizes automated extraction and personalization. ContextDB emphasizes provenance and evidence checks before host-enforced actions. - [ContextDB vs Supermemory: Agent Memory Compared](https://contextdb.ai/vs-supermemory): Supermemory combines memory, RAG, profiles, and connectors. ContextDB focuses on evidence policy before host-enforced agent actions. - [Snowflake and Databricks Agent Memory | ContextDB](https://contextdb.ai/with-snowflake-databricks): Snowflake and Databricks readers are contract-tested only. Selected records can become sourced memory evidence while hosts retain final writes. - [Agent Memory With Postgres and Supabase | ContextDB](https://contextdb.ai/with-postgres): Keep business truth in Postgres, Supabase, or Hasura while ContextDB stores cross-session memories and evaluates evidence before host writes. ### SDK, trust, and evaluation - [ContextDB SDK vs Cloud Alpha: What Runs Where](https://contextdb.ai/open-core): Use the Apache-2.0 SDK for portable memory semantics and local correctness. Use Cloud Alpha to evaluate managed multi-tenant coordination. - [MCP Server for AI Agent Memory | ContextDB](https://contextdb.ai/mcp): ContextDB exposes six scoped memory tools through a stateless, tools-only JSON-RPC MCP endpoint with no sessions, SSE, or server push. - [AI Agent Memory Trust and Action Policy | ContextDB](https://contextdb.ai/trust): ContextDB separates conversational context from evidence allowed to support an action. The host authenticates, authorizes, and enforces. - [ContextDB Pricing Preview: Proposed Cloud Rates](https://contextdb.ai/pricing): Early Access pricing is a preview, not a live offer: proposed Cloud rates start at $1.50 per active profile per year after the first 1,000. - [ContextDB API Reference and SDK Quickstart](https://contextdb.ai/docs): Use the ContextDB API reference to remember, evolve, recall, confirm, forget, evaluate actions, report execution, and run Memory CI. - [ContextDB Security Model and Current Controls](https://contextdb.ai/security): Review ContextDB credential, tenant isolation, PII, audit, worker, source-secret, backup, and current certification boundaries for Cloud Alpha. - [Enterprise AI Agent Memory Evaluation | ContextDB](https://contextdb.ai/enterprise): Evaluate enterprise agent memory across evidence, policy, host enforcement, receipts, erasure, security controls, and current operating limits. - [Enterprise AI Agent Memory Evaluation Guide | ContextDB](https://contextdb.ai/enterprise-ai-agent-memory-guide): Use this enterprise checklist to evaluate agent memory architecture, security, governance, action controls, erasure, and procurement readiness. ### Utility and discovery - [ContextDB Changelog and Capability Status](https://contextdb.ai/changelog): See dated ContextDB releases, capability status, bounded proof, and limitations without roadmap dates or unsupported availability claims. - [ContextDB Legal and Privacy Posture](https://contextdb.ai/legal): Review ContextDB's interim alpha terms, SDK license, trademark rules, privacy posture, acceptable use, and legal contact details. - [ContextDB Cloud Alpha Service Status](https://contextdb.ai/status): See current ContextDB component availability for the hosted alpha. No uptime percentage, incident history, or measured service record is claimed. - [ContextDB Integration Guide for AI Coding Agents](https://contextdb.ai/for-agents): Integrate ContextDB from server code with official SDKs, OpenAPI contracts, credential rules, action flow, and current Cloud Alpha limits. ## Documentation - API docs: https://contextdb.ai/docs - Memory API OpenAPI 3.1: https://contextdb.ai/openapi.yaml - Memory CI OpenAPI 3.1: https://contextdb.ai/evals-openapi.yaml - API base URL: https://api.contextdb.ai - MCP guide: https://contextdb.ai/mcp - Product: https://contextdb.ai/product - Asynchronous Formation: https://contextdb.ai/formation - Memory Evolution: https://contextdb.ai/memory-evolution - Hosted Alpha Memory CI: https://contextdb.ai/evals - Managed Sources: https://contextdb.ai/managed-sources - Trust rules: https://contextdb.ai/trust - Integrations: https://contextdb.ai/integrations - Enterprise: https://contextdb.ai/enterprise - Enterprise memory evaluation guide: https://contextdb.ai/enterprise-ai-agent-memory-guide - Python SDK: https://github.com/atomsai/contextdb - Cloud clients: https://github.com/atomsai/contextdb-clients - Memory Evolution client release: https://github.com/atomsai/contextdb-clients/releases/tag/cloud-clients-v0.2.0-alpha.2 - Python Cloud client: https://pypi.org/project/contextdb-cloud-client/0.2.0a2/ - TypeScript Cloud client: https://www.npmjs.com/package/@contextdb/cloud/v/0.2.0-alpha.2 - Memory CI PyPI package: https://pypi.org/project/contextdb-memory-ci/ - Memory CI Action release: https://github.com/atomsai/contextdb-clients/releases/tag/memory-ci-action-v0.1.0 - Memory CI CLI source: https://github.com/atomsai/contextdb-clients/tree/main/memory-ci/python - Memory CI contract source: https://github.com/atomsai/contextdb-clients/blob/main/openapi/evals-v1.yaml - OpenAI Agents starter: https://github.com/atomsai/contextdb-clients/tree/main/starters/openai-agents-python - LangGraph starter: https://github.com/atomsai/contextdb-clients/tree/main/starters/langgraph-python - Vercel AI SDK starter: https://github.com/atomsai/contextdb-clients/tree/main/starters/vercel-ai-sdk - LiveKit Agents starter: https://github.com/atomsai/contextdb-clients/tree/main/starters/livekit-agents-python - PyAI Omni starter: https://github.com/atomsai/contextdb-clients/tree/main/starters/pyai-omni - PyAI example: https://github.com/atomsai/contextdb-pyai-example - LiveKit example: https://github.com/atomsai/contextdb-livekit-example - Pipecat example: https://github.com/atomsai/contextdb-pipecat-example - Chat example: https://github.com/atomsai/contextdb-chat-example ## Core flow Canonical client action flow: recall -> remember -> evaluate_action -> confirm if required -> re-evaluate -> host action -> report_execution. The HTTP route and MCP tool behind evaluate_action are named recall_for_action. MCP has no gate tool. 1. Recall customer history when a call, chat, or agent session begins. 2. After a production call or chat, send structured turns to POST /v1/formation/jobs and poll GET /v1/formation/jobs/{job_id}. Use propose for review or commit for automatic validated writes. The synchronous POST /v1/extract_memories remains for short development flows. 3. Store explicit application-sourced details with POST /v1/remember. Use POST /v1/evolve for explicit ADD, UPDATE, DELETE, or NOOP operations. 4. Pass evolve's memory_version and primary_wal_lsn into an immediate recall when that read must observe the mutation. 5. Before a booking, refund, plan change, or business-record update, call POST /v1/recall_for_action. 6. Branch on the returned outcome. act permits the customer host to continue only after its own authentication, authorization, and current-state checks. ask means pause and seek clarification. abstain means do not act. Contested or policy-untrusted evidence cannot produce act. Confirmation is one trust signal, not the only path to act. 7. For ask, the customer host authenticates the end user and retains any end-user attestation before calling POST /v1/confirm for one exact user_id and memory_id. Re-run recall_for_action after confirmation. 8. Run the host action only after act, then call POST /v1/receipts with the decision_id and a stable Idempotency-Key. Report succeeded, failed, or skipped. 9. Use POST /v1/forget to erase and verify a complete user partition. Partition erasure requires typed confirmation and an Idempotency-Key. For remember, remember_many, confirm, and extract_memories commit requests, send a stable Idempotency-Key on retries. Evolve, Formation jobs, execution receipts, and partition erasure always require an Idempotency-Key. Reuse a key only for the exact same logical request. A different payload returns HTTP 409. Remember, batch remember, evolve, confirm, and forget return memory_version and primary_wal_lsn. Pass both as min_memory_version and min_primary_wal_lsn to a later ordinary recall when it must include that write. Token-bearing recall is primary-bound by default and returns 503 rather than silently serving below the requested floor. Opt into bounded replica waiting plus primary fallback only with read_consistency=replica_fallback. recall_for_action and lifecycle operations are always primary-bound. ## Hosted API The hosted API is currently alpha. Project keys are server credentials and must never be exposed in browser code. A project key determines the organization and project. user_id selects one isolated customer-memory partition. It is not end-user authentication. API and MCP confirmation record the authenticated project credential against one scoped memory. Console confirmation records operator context. The customer host owns end-user authentication and attestation. No confirmation proves objective truth. Current product status: - Open Python SDK: available under Apache-2.0. - Core hosted memory API and console: public alpha. - MCP endpoint: stateless tools-only Hosted Alpha. It accepts one JSON-RPC 2.0 object over HTTP and has no sessions, SSE, resumability, or server-initiated messages. - Memory Evolution: available in the Apache-2.0 SDK and Cloud Alpha. The 2026-08-24 bounded hosted proof passed direct ADD, UPDATE, NOOP, and DELETE. Gemini 2.5 Flash Formation chose UPDATE, NOOP, and DELETE. The proof also covered consistency, metadata-only lineage, evidence-ID Memory CI, privacy scans, signed audit, and zero mutable cleanup residue. This establishes the functional path, not sustained load, failover, availability, latency, COGS, or an SLO. - Asynchronous Formation submit and poll: public Hosted Alpha. One dedicated single-instance Formation process runs beside the gateway on the same app VM. PostgreSQL jobs, leases, attempts, encrypted stages/results, and bounded commit recovery are durable. - Memory CI API and Console: live Hosted Alpha. Enqueue is durable in PostgreSQL and returns 202. One dedicated single-instance Evals process runs beside the Console on the same app VM and uses leases, bounded attempts and deadlines, cooperative cancellation, pinned baselines, and content-free exports. On 2026-08-24, a bounded same-VM proof killed each worker, observed new systemd PIDs, advanced only the synthetic leases, and reached worker_lost-to-completed for real-provider Formation and worker_lost-to-passed for all 50 Evals cases. There is no HA, scale, multi-VM failover, natural lease-timing, backup/restore, worker-fleet, scheduling, or availability SLO claim. - Memory CI public distribution: Available under Apache-2.0. contextdb-memory-ci==0.1.0a1 was published through PyPI trusted publishing with attestations and passed a fresh isolated registry install, import, version, and --help check. The public memory-ci-action-v0.1.0 prerelease installs that exact package. Hosted execution remains Hosted Alpha. - Signed backups and restore drill: Operated Alpha. A daily timer captures one signed PostgreSQL + SQLite bundle under enforced public-access prevention, narrow bucket roles, and a rotating CMEK. A weekly timer verifies content in a disposable PG16 cluster on the DB host. One exact 2026-08-24 bundle passed row-count, supported audit-head, object-evidence, cleanup, and live-service checks before the old PG-only cron was disabled. This is not PITR, PostgreSQL role/password/ACL recovery, Secret Manager payload backup, failover, a natural RPO/RTO, or complete disaster recovery. - Managed Sources: design-partner alpha. Postgres has a bounded operated proof. Supabase uses the Postgres protocol without a separate production proof. BigQuery has bounded synthetic provider proof: on 2026-08-26, the production app VM read a temporary two-row dataset and table in the ContextDB GCP project, passing the dry-run byte gate, validation, actual query, key and timestamp mapping, and one soft-deletion row before dataset and artifact cleanup. It is not customer warehouse, scale, worker-crash, scheduled-sync, availability, or SLO evidence. Snowflake and Databricks remain no-network contract-tested only. None has customer warehouse proof or public access. BigQuery uses one dry-run plus one billed-byte-capped query per job. Databricks uses one bounded INLINE JSON SQL Warehouse statement with an 8 MiB result budget and rejects external links. Both use timestamp-and-key cursors with a five-minute lag. Polling is manual by default. Optional schedules run no more often than every 15 minutes. Hard deletes are not detected, and every mutation must advance updated_at. - Google and GitHub login: security implementation staged. Production provider applications are not configured. - GET /health - GET /ready - POST /v1/remember - POST /v1/remember_many - POST /v1/evolve - POST /v1/extract_memories - POST /v1/formation/jobs - GET /v1/formation/jobs/{job_id} - POST /v1/recall - POST /v1/recall_for_action - GET or POST /v1/pending_confirmations - POST /v1/confirm - POST /v1/forget - POST /v1/receipts - POST /mcp Memory CI uses a separate project-bound cbe_ evaluation token. It is shown once, stored hashed, accepted only under /evals/v1, and cannot call memory routes or Testbench case CRUD: - POST /evals/v1/projects/{project_id}/suites/{suite_id}/runs - GET /evals/v1/projects/{project_id}/runs/{run_id} - POST /evals/v1/projects/{project_id}/runs/{run_id}/cancel - GET /evals/v1/projects/{project_id}/runs/{run_id}/export/{format} Omit baseline_run_id to use the suite's pinned passing baseline. Safe status contains opaque IDs, status and regression enums, counts, progress, limits, timestamps, and a bounded terminal reason. JSON and JUnit exports omit suite names, case names, queries, assertions, raw failures, and memory content. ## Memory CI CLI and Action Install the exact public package: pip install contextdb-memory-ci==0.1.0a1 Use the pinned reusable Action: - name: Run ContextDB Memory CI uses: atomsai/contextdb-clients@memory-ci-action-v0.1.0 with: token: ${{ secrets.CONTEXTDB_EVAL_TOKEN }} project-id: ${{ vars.CONTEXTDB_PROJECT_ID }} suite-id: ${{ vars.CONTEXTDB_EVAL_SUITE_ID }} upload-artifacts: "true" CONTEXTDB_EVAL_TOKEN is a cbe_ evaluation token. Store it in CI secret storage. It cannot call memory routes or Testbench case CRUD. Project and suite IDs are non-secret workflow configuration. Omit baseline-run-id to use the suite's pinned passing baseline. The CLI and Action return exit 0 for passed plus unchanged, exit 1 for failed behavior or regression, and exit 2 for operational error, cancellation, timeout, malformed response, output failure, or a disallowed missing baseline. The Action uploads content-free JSON and JUnit artifacts by default. Shell and metadata tests cover the Action wrapper. No Action run inside GitHub against production is claimed. On 2026-08-23, the bounded production proof observed a passing pinned baseline. The packaged CLI returned exit 0 for unchanged behavior. It returned exit 1 for a deliberate memory regression. Queued cancellation reached cancelled. Trace-to-eval created no assertions while preserving PII processing. JSON, JUnit, and Evals control-state scans contained neither the synthetic marker nor the proof token. Cleanup left zero proof PostgreSQL rows, credentials, secrets, keys, memories, decisions, users, organizations, or projects. The proof did not kill the worker and does not establish scale, high availability, crash-resume availability, scheduling, an SLA, or human usability. On 2026-08-24, the dedicated-worker proof killed the Evals process and observed a new PID finish all 50 cases after advancing only the synthetic lease. The first attempts exposed gateway throttling. The worker now caches its project credential and honors bounded Retry-After. The passing run had no active attempt/case residue, kept JSON/JUnit content-free, and removed its GCP secret and every mutable synthetic row. This does not establish natural lease timing, multi-VM failover, or availability. The machine-readable request and response schemas are in https://contextdb.ai/openapi.yaml.