Skip to main content
The Context Engine adds bounded operational memory to an agent run without turning the external provider into the source of truth or loading an entire workspace into a prompt. Mandala owns synchronization, eligibility policy, tenant isolation, retrieval bounds, citations, and fallback behavior. The current external provider adapter is Supermemory; the provider can be turned off without changing the workflow contract.

​
Two separate pipelines

​
Indexing

Changed business records enter an outbox. Workers project only policy-approved fields into provider documents, lease jobs, send add, replace, or delete operations, and record completion in a durable ledger. The indexing system includes:
  • tenant-scoped document ids;
  • policy-version snapshots;
  • duplicate prevention;
  • batch admission and rate accounting;
  • retry, crash recovery, tombstones, and reconciliation;
  • provider health and processing status; and
  • safe cleanup when a workspace disables the provider.

​
Retrieval

During an eligible run, Mandala builds a bounded request containing the workspace scope, allowed record types, filters, result limit, and text-size budget. Retrieved items are validated, deduplicated, trimmed, and attached to the context packet with provenance. The final packet records provider, status, bounds, timing, fallback reason, and citations. This makes it possible to distinguish data the workflow loaded directly from operational memory added by Context Engine.

​
Safety rules

Context Engine retrieval is allowed only when all relevant gates pass:
  • the workspace selected a provider;
  • server-side retrieval is explicitly enabled;
  • the provider is operational and healthy;
  • the record and field policy permits indexing and retrieval;
  • the request is scoped to the selected workspace;
  • the current run mode is eligible; and
  • configured result and character limits are respected.
Secrets, credentials, authorization headers, raw prompts, system instructions, and other sensitive key patterns are rejected from index documents.
A record being indexed does not prove that a particular recommendation used it. Look for the work item’s operationalContext provenance and citations.

​
Degraded behavior

Provider failure does not silently become unbounded or uncited context. Mandala records a specific status and fallback reason, such as disabled context, provider unavailability, policy rejection, empty results, or budget limits. A workflow may continue using its directly loaded connector evidence when its skill and policy allow that fallback. If required context is missing, the recommendation blocks.

​
Workspace settings

Check status with:
The current provider options are off and supermemory. Changing the provider requires the current configuration version and an audit reason:
Selecting an external provider requires explicit confirmation because it changes the workspace’s data-processing posture.

​
Operations

Indexing is driven by the internal worker route at /api/internal/mandala/context-index/run, protected by CONTEXT_INDEX_WORKER_SECRET or the shared cron secret. Hosted environments also require SUPERMEMORY_API_KEY and CONTEXT_RETRIEVAL_ENABLED=true for retrieval. Use Context Engine readiness, provider health, ledger state, and work-item provenance as separate checks. A successful provider search outside Mandala is not enough to prove end-to-end use.