ContextLattice is a local-first memory orchestration system for AI systems. It offers the following capabilities:
Health Check: Query the orchestrator's health status to verify it's operational.
Write Memory: Store new memory items by providing a project name, file name, content, and optional topic path for hierarchical organization.
Search Memory: Search contextual memory entries by project and query, with optional filters for agent ID, topic path, grounding info, and retrieval debug details.
Durable Storage: Orchestrates memory writes with outbox fanout to specialized sinks (e.g., Qdrant, Mongo, MindsDB, Letta) targeting 100+ messages/second throughput.
Intelligent Retrieval: Multi-source recall with result merging, ranking, and a learning loop for continuous improvement.
Code Context Enrichment: Reranks code context based on symbol overlap, file-path proximity, and recency.
Agent Task Management: Queue, route, and manage task lifecycles (create, status, replay, recover leases) for external/internal agent runners.
Context Expansion: Dynamically expands agent context with budgeted layers (factual snippets, topic rollups, raw file refs) and async deep escalation.
Telemetry & Maintenance: Access fanout/retention telemetry, clean up low-value memory, and purge telemetry data.
Security Controls: Enforce secret storage policies (redaction, blocking, or allowing) with API key authentication.
Web3 Integration: Supports Web3 messaging surfaces like IronClaw, OpenClaw, and ZeroClaw.
Models can reason. Harnesses can act. Neither reliably retains the mission when a chat, model, tool, account, or computer changes.
ContextLattice gives that work a durable, inspectable context layer. It reconstructs the active objective, selects the evidence that matters, carries it safely, and records what actually worked—without turning every prompt into a transcript dump or making cloud storage mandatory.
Capability | What changes |
Durable continuity | Reopen the objective, decisions, repository state, risks, proof, and next move as one bounded packet. |
Explainable retrieval | Rank evidence by impact per token and expose source coverage, omissions, opposition, degradation, and receipts. |
Portable context | Move signed, least-privilege continuation across agents and machines while keeping execution and transport caller-owned. |
Verified skill evolution | Discover skills without loading every file, evaluate repeated wins on holdouts, and require review before promotion. |
Privacy-bounded Aggregate Signal | Learn from explicitly opted-in, clipped statistics while raw memory remains local; production activation stays hard-blocked pending independent privacy and utility review. |
The CLI is the primary interface. The dashboard makes behavior and proof visible. HTTP and MCP are companion integration surfaces for applications and harnesses.
Related MCP server: copilot-memory-store
Stage | ContextLattice does |
01 · Reopen | Reconstructs the one active mission from durable checkpoints and current state. |
02 · Select | Retrieves high-signal evidence into a compact Context Pack with provenance. |
03 · Move | Carries signed, bounded context through Agent Packets, Passports, and encrypted continuation envelopes. |
04 · Earn | Records outcomes and promotes reusable behavior only after deterministic proof and human approval. |
05 · Compound | Improves future retrieval while preserving corrections, contradictions, freshness, and retirement semantics. |
ContextLattice does not replace your agent harness, choose goals from retrieved text, or execute imported context. Local tools remain execution surfaces; memory and remote content remain evidence.
Requirements: macOS, Linux, or Windows through WSL2; a Compose v2-compatible container runtime; and gmake, jq, rg, python3, and curl. The tested macOS baseline uses OrbStack through its explicit Docker context; see the container runtime decision.
git clone https://github.com/sheawinkler/ContextLattice.git
cd ContextLattice
cp .env.example .env
gmake quickstartgmake quickstart is the prescribed technical install path; installers are bootstrap alternatives. The command prepares environment wiring, asks for a runtime profile, launches the selected local stack, and validates initial readiness.
curl -fsS http://127.0.0.1:8075/health | jq
contextlattice doctor --pretty
contextlattice state status --pretty
contextlattice context "verify this ContextLattice installation" \
--project contextlattice \
--prettyHealthy containers are only the first check. The state command verifies the canonical gateway-owned storage inventory; the final command exercises the actual context path and reports source coverage, degradation, evidence, and next actions. Existing installs can use the explicit, reversible procedure in gateway state migration.
For a fuller lifecycle proof from the repository:
scripts/agent/agent-runtime-proof-pack --pretty
scripts/agent/agent-adoption-proof-matrix \
--skip-provider-smoke \
--progress \
--prettyRun integration from the repository that should use ContextLattice:
cd /path/to/your/project
contextlattice_adopt integrate \
--repo . \
--agents codex,claude-code,opencode,hermes-agent,hermes-ultra,omp,mercury-agent,pi,droid \
--pretty
contextlattice_adopt integrate \
--repo . \
--agents codex,claude-code,opencode,hermes-agent,hermes-ultra,omp,mercury-agent,pi,droid \
--check \
--prettyThe integration command writes bounded managed blocks while preserving existing instruction text. It does not install Codex, Claude Code, OpenCode, Hermes, OMP, Mercury, Pi, Droid, or another third-party agent harness.
External provider discovery is network-free. Provider execution remains explicit and caller-authorized; see the external-provider boundary.
If an agent is performing the installation, it should follow the quickstart directly, avoid cloning a second checkout when already inside one, report the exact failing command and path, and rerun the deterministic check after any repair.
# Confirm readiness when the environment is uncertain.
contextlattice doctor --pretty
# Retrieve scoped context before substantial work.
contextlattice context "debug the current release regression" \
--project contextlattice \
--pretty
# Save concise, durable progress.
contextlattice remember \
"Root cause verified; regression test added; focused checks pass." \
--project contextlattice \
--pretty
# Resume without replaying the transcript.
contextlattice resume --project contextlattice --pretty
# Repair stale or wrong recall without silently rewriting history.
contextlattice correct \
"The prior deployment record is stale." \
--category stale \
--project contextlattice \
--pretty
# Close the loop with the verified outcome.
contextlattice finish \
"Regression fixed and verified." \
--success \
--project contextlattice \
--pretty
# Project the next bounded move or bind a completed response to durable proof.
contextlattice_continuous_cognition status "prepare the next verified move" \
--project contextlattice --session-id <session-id> --agent-id codex_gpt5 \
--task-id <task-id> --objective-id <objective-id> --as-of <rfc3339> --pretty
contextlattice_continuous_cognition evaluate "verify the completed response" \
--project contextlattice --session-id <session-id> --agent-id codex_gpt5 \
--task-id <task-id> --task-identity-id <task-identity-id> --as-of <rfc3339> --pretty
# Prepare context for an external worker without exposing its one-shot claim.
contextlattice agent-fit context-prep-schedule --project contextlattice \
--session-id <session-id> --agent-id codex_gpt5 --payload-file prep-request.json --raw
contextlattice agent-fit context-prep-claim --project contextlattice \
--session-id <session-id> --agent-id codex_gpt5 --prep-id <prep-id> \
--worker-id <worker-id> --claim-token-file prep.claim --raw
contextlattice agent-fit context-prep-complete --project contextlattice \
--session-id <session-id> --agent-id codex_gpt5 --prep-id <prep-id> \
--claim-token-file prep.claim --payload-file prep-artifact.json --raw
contextlattice agent-fit context-prep-use --project contextlattice \
--session-id <session-id> --agent-id codex_gpt5 --prep-id <prep-id> \
--task-id <task-id> --effective-profile-digest <sha256-digest> \
--source-generation <generation> --rawContinuous Cognition is advisory-only: each invocation makes one bounded request, returns opaque evidence references, and never dispatches a runner or performs an external mutation. Context-preparation claims stay in an owner-only file and cross the completion/failure boundary only through the protected header; successful explicit use consumes the artifact once.
Find a capability without loading every skill body:
contextlattice_skills_index search "browser automation" --prettyThe active Skills Index scans configured Codex, Hermes, Hermes Ultra, and shared
agent roots read-only. It reports each harness and root inventory separately,
collapses byte-identical SKILL.md files by SHA-256 digest while retaining every
source path as provenance, and requires discriminating query-term coverage
instead of ranking generic words such as skill, index, or agent.
Quarantine discovery remains separate, read-only by default, and never
auto-promotes retrieved content.
The default local control path is:
Agent or application
│
▼
ContextLattice CLI / HTTP / MCP
│
▼
Gateway :8075
├── durable write and outbox fanout
├── scoped retrieval and source receipts
├── session, objective, graph, and outcome state
└── dashboard-visible proof and operationsWrites are validated and durably persisted before fanout. Retrieval merges the available sources, ranks bounded evidence, and reports missing or degraded coverage instead of hiding it.
The active application path is Go and Rust. Python remains in build, development, migration, and audit tooling rather than the live request path. The exact runtime and toolset choices are recorded in the v4 runtime decision and container decision.
The public local lane is account-free and useful on its own. It includes the CLI-first memory lifecycle, Context Packs, sessions, graph and claim surfaces, Skills Index discovery, Agent Packets, public Passport and Mesh contracts, and local proof tooling.
Paid artifacts add governed collaboration, protected activation, workspace operations, advanced analytics, and hosted distribution. They do not turn local memory into a mandatory cloud dependency.
See plans and distribution boundaries for the current contract.
macOS technical preview: unsigned DMG bootstrap launcher; expect Gatekeeper warnings until Developer ID notarization is configured, and prefer the source/CLI path.
Path | Best for | Status |
Source + | Technical users and terminal-capable agents | Recommended |
| macOS convenience bootstrap | Available |
Guided macOS bootstrap | Unsigned technical preview; expect Gatekeeper warnings | |
Guided Windows bootstrap | Available | |
Guided Linux bootstrap | Available |
Profile | CPU | RAM | Storage |
Hugging Face / Glama lite |
|
|
|
Local Lite core |
|
|
|
Local Lite advanced |
|
|
|
Local Full |
|
|
|
For heavier ingest, model storage, or the spike-lab adapters, read the installation and storage guidance before selecting a profile.
Local-first and account-free in the public local lane.
API-key protection for operational routes.
Deterministic secret-like content filtering at write ingress: redact by default, block when configured, and allow only by explicit operator choice.
Provenance and trust isolation on retrieved memory.
Signed portable context and encrypted continuation envelopes.
Dry-run-first graph repair, source backfill, and quarantine workflows.
No automatic execution of retrieved instructions or imported continuation content.
Security reports follow SECURITY.md.
Need | Start here |
Product overview | |
Installation | |
CLI and agent lifecycle | |
Harness and app integration | |
Architecture and scaling | |
Troubleshooting | |
Current behavior and release evidence | |
Roadmap | |
Agent hooks | |
Retrieval trust | |
Skills and verified learning | |
Portable context | |
Local inference | |
Full repository-backed manual |
The current release baseline is v5.0.2.
ContextLattice's public lane is licensed under the Apache License 2.0.
Run a non-destructive runtime health check before any memory tool call. Use this when a connection fails, startup seems incomplete, or you need readiness evidence before writes. Returns a JSON health envelope (for example: status/services/components/queue fields) as both text and structured JSON. If the orchestrator requires an API key and the bridge is not configured, this returns an auth failure instead of mutating state.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| ok | No | |
| queue | No | |
| status | No | |
| services | No | |
| components | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds value by detailing the non-destructive nature, the JSON envelope fields (status/services/components/queue), and the auth failure behavior. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each serving a clear purpose: stating the tool's nature, providing usage guidance, describing the return format, and noting an edge case. It is front-loaded and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a health check tool with no parameters and an existing output schema, the description explains the return format and distinguishes the auth failure case. It fully covers the necessary context given the tool's simplicity and the annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema description coverage is 100%. The description does not need to add parameter meaning. Baseline 4 for 0 parameters is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a non-destructive runtime health check, specifically for use before memory tool calls. It distinguishes itself from sibling tools (memory.search, memory.write) by focusing on readiness and connection validation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly specifies when to use: when a connection fails, startup seems incomplete, or readiness evidence is needed before writes. Also describes the auth failure scenario, indicating when not to expect a successful health check.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only contextual retrieval for pre-inference recall. Required: project + query. Keep project aligned with prior memory.write calls so ranking and topic continuity remain coherent. Parameter interactions: topic_path narrows scope and usually reduces noise/latency; if scoped reads return empty/degraded, retry once without topic_path. include_grounding=true adds citation-safe grounding with strict numeric copy behavior (numbers must be consumed verbatim). include_retrieval_debug=true adds source policy/timing/failure detail for diagnosis and can increase payload size. agent_id should stay stable across sessions so retrieval profile defaults (mode/sources/escalation) remain deterministic. Lifecycle handling: result_state can be ready/pending/degraded/empty; when pending/degraded, use warnings/source status and continuation metadata to re-read after cache warm. Do not use this tool for writes or health checks: use memory.write for persistence and health for startup/readiness checks. On auth/upstream failures this returns isError=true with structured error payload.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Natural-language retrieval query describing what context is needed now. Keep it specific to improve ranking and reduce continuation work. | |
| project | Yes | Project identifier to scope retrieval (for example: contextlattice, algotraderv2_rust). Unknown projects can return project_suggestions. | |
| agent_id | No | Optional stable agent identity used to apply retrieval profile defaults (mode/sources/escalation/query expansion). | |
| topic_path | No | Optional topic hierarchy for scoped retrieval (for example: runbooks/release). Omit for broader recall when scoped reads return empty/degraded. | |
| include_grounding | No | When true, response includes a grounding object with factual snippets and strict numeric copies for citation-safe reasoning. | |
| include_retrieval_debug | No | When true, response includes retrieval debug details (source policy, timings, staged continuation, failures/timeouts). |
| Name | Required | Description |
|---|---|---|
| results | No | |
| degraded | No | |
| warnings | No | |
| grounding | No | |
| retrieval | No | |
| result_state | No | |
| source_status | No | |
| source_summary | No | |
| retrieval_lifecycle | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds: read-only nature, lifecycle handling (result_state with ready/pending/degraded/empty), grounding behavior (strict numeric copy), debug payload size impact, auth failure returns isError. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections (parameter interactions, lifecycle handling). May be slightly verbose but every sentence adds value. Front-loaded with purpose and constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, description explains return states and error handling. Covers all parameter interactions, lifecycle, and failure modes. Complete for a complex retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%. Description adds significant context beyond schema: topic_path for scoped retrieval with retry guidance, include_grounding strict copy behavior, include_retrieval_debug diagnostic value and payload cost, agent_id for profile consistency. Greatly enhances parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'retrieval', specific resource 'memory', read-only nature stated upfront. Explicitly distinguishes from siblings: 'Do not use this tool for writes or health checks: use memory.write for persistence and health for startup/readiness checks.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use (pre-inference recall) and when-not-to-use (writes/health). Offers detailed guidance on parameter usage: aligning project with prior writes, retry logic for topic_path, agent_id stability. Directly names alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
State-changing durable memory write used for checkpoints, implementation decisions, and compact recall artifacts. Parameter interactions: projectName should match the project used by memory.search; fileName is the logical lineage key (stable fileName preserves continuity and dedupe behavior); topicPath controls retrieval partitioning and, if omitted, is derived from fileName. content should be concise and factual (avoid full transcripts; preserve numeric facts verbatim). Side effects: successful writes may trigger asynchronous fanout/indexing/rollup work. ok=true with event_id means the write was accepted, but per-target fanout can still be pending/retrying and is returned in fanout/warnings. Do not use this for retrieval or diagnostics: use memory.search for reads and health for readiness checks. On auth/upstream errors this returns isError=true with structured error payload.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | Memory payload to persist. Keep numeric facts verbatim. Secret handling follows server policy (redact/block/allow). | |
| fileName | Yes | Logical memory filename/path used for grouping and lookup (for example: notes/codex/xyz.md). Keep stable across updates to preserve continuity. | |
| topicPath | No | Optional topic hierarchy for retrieval scoping (for example: runbooks/runtime-hardening). If omitted, topic is derived from fileName. | |
| projectName | Yes | Project identifier for the write (must match intended retrieval scope and future search project). |
| Name | Required | Description |
|---|---|---|
| ok | No | |
| fanout | No | |
| deduped | No | |
| event_id | No | |
| warnings | No | |
| latest_hash_unchanged | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are sparse (only false hints), so the description carries the burden. It discloses asynchronous side effects (fanout/indexing/rollup), acceptance semantics (ok=true with event_id but pending fanout), and error behavior (isError=true with structured payload). This far exceeds the minimal annotation information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured into purpose, parameter interactions, side effects, usage exclusions, and error behavior. Every sentence contributes essential context, with no fluff or repetition. It is appropriately sized for a tool with async side effects and parameter interdependencies.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (state change, async fanout, error handling), the description covers purpose, parameters, side effects, when-not-to-use, and return semantics even though an output schema exists. It fully complements the structured information and leaves no significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaningful context: projectName must match memory.search project, fileName is the lineage key for continuity/dedupe, topicPath controls partitioning and derivation, and content should be concise/factual. This enriches the raw schema with actionable semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'State-changing durable memory write used for checkpoints, implementation decisions, and compact recall artifacts,' which clearly states the action (write), resource (durable memory), and intended use cases. It also distinguishes from siblings by explicitly directing to memory.search for reads and health for diagnostics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance for checkpoints, implementation decisions, and recall artifacts. It also gives clear when-not-to-use instructions: 'Do not use this for retrieval or diagnostics: use memory.search for reads and health for readiness checks.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v4.0.6memory.writev4.0.4memory.writeEach tool has a distinct purpose: health for diagnostics, memory.search for read-only retrieval, and memory.write for state-changing writes. No overlap in functionality.
Two tools use a 'domain.action' pattern (memory.search, memory.write), but 'health' is a standalone verb without a domain prefix, creating minor inconsistency.
Three tools cover the essential operations (health check, read, write) for a memory system. The scope is minimal but appropriate for the domain.
Core CRUD is covered (search/read and write/create/update), but there is no explicit delete or list tool, which could be a minor gap for managing stored data.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Persistent memory for AI agents — log and recall conversation context over MCP.
Persistent memory for AI assistants. Save once; recall from Claude, ChatGPT, or any MCP client.
AI Reasoning Cache & Consensus Layer with 11 MCP tools via Streamable HTTP.
Person-owned AI memory that learns, not just stores — portable context for any MCP client.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/sheawinkler/ContextLattice'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
