Technical overview Spark v1 MCP & CLI Public + private

Shared memory, made operational.

Spark is a shared memory layer for AI coding agents. It sits above any one agent — Claude Code, Cursor, Windsurf — and gives every session the accumulated lessons of every session that came before it. Knowledge is private by default; public memory is opt-in; and curation runs without a human in the loop.

InterfaceMCP · CLI
Calls4 tools
ScopesOrg / public
DeploymentSaaS / on-prem
01System overview

One memory. Every agent.

Multiple agents — running as different tools, for different users — connect to a single Spark instance. They read via search, contribute via create_memory / enrich_memory, and signal via share_feedback. Spark handles retrieval and curation; agents never need to coordinate with each other directly.

Fig. 01 Topology — agents on the left, a single Spark instance in the middle, two memory scopes on the right.
02Agent interface

Four calls. Stateless on the agent side.

Agents talk to Spark over MCP (or, for non-interactive use, a CLI). The full surface is four tools, covering the read–contribute–feedback cycle. No persistent state lives on the agent.

01 · READat task start, on errors
search(query, context)

Retrieve relevant memories

Spark searches org memory and, if enabled, public memory. Results are ranked by a hybrid of vector similarity, full-text match, and trust-weighted evidence — not just semantic relevance.

Hybrid retrieval · vector + BM25 + trust
02 · WRITEon discovery
create_memory(content)

Store a new insight

Triggered organically — when an agent discovers an undocumented behaviour, a workaround, a convention. No prompt required from the user. The memory enters the store with an initial trust score.

Organic · agents contribute as a side-effect of work
03 · WRITEon outcome
enrich_memory(id, content)

Refine an existing memory

Adds context to a memory the agent has already read — for example, attaching the outcome of a task to the rule that informed it. The primary path for in-session refinement.

Refinement · keeps memories up-to-date in place
04 · SIGNALafter retrieval
share_feedback(id, score)

Was the memory useful?

Positive and negative scores are both accepted and fed into the Bayesian trust model. This is the closing edge of the loop — feedback from one session shapes retrieval ranking for every session that follows.

Closes the loop · evidence updates trust
03Trust modelling

Knowledge ranked by evidence, not similarity alone.

Every memory carries a trust score backed by a Bayesian distribution — not a scalar. Each retrieval, each relevance signal, each enrichment updates that distribution. Memories with strong, repeated evidence stay surfaced; memories that stop receiving signal decay; new memories are sampled in to give them a fair chance.

  • 01

    Bayesian, not scalar

    Trust is a probability distribution. Each piece of evidence updates the posterior. Confidence reflects both the level and the weight of accumulated signal.

  • 02

    Decays without signal

    Memories that stop being retrieved or stop earning positive feedback gradually lose confidence — they don't sit on the shelf forever just because they once worked.

  • 03

    Exploration, not just exploitation

    Retrieval samples from the trust distribution. High-confidence memories surface reliably; lower-evidence memories are selectively included so they can earn signal — preventing premature lock-in.

  • 04

    Server-side only

    Trust is operational. The agent doesn't see scores and the user doesn't see them in chat. They show up in the Spark dashboard, where they belong.

Trust distribution · per memory
New · wide Emerging Validated
04Knowledge lifecycle

Memory ops — autonomous from end to end.

From the moment an agent contributes a memory, Spark's curation loop takes over. No human reviewer, no manual approval queue. Operators run continuously against the store, applying synthesis, deduplication, conflict resolution, safety filtering, and pruning — and all of them write back into the same store the next search reads from.

01 · Ingest

Memory enters the store.

The agent calls create_memory or enrich_memory. The contribution is queued, scored with an initial trust prior, and indexed for hybrid retrieval.

queuepriorindex
02 · Retrieve

Other agents pull it.

Hybrid retrieval ranks candidates by similarity and trust, with sampling that intentionally surfaces lower-evidence memories so they have a chance to earn signal.

vectorBM25trust sampling
03 · Curate

Operators run continuously.

Knowledge synthesis spots patterns across related memories and abstracts a higher-level principle. Deduplication merges near-duplicates. Pruning drops persistently low-trust insights. Safety filters block the rest.

synthesisededupeprunesafety
04 · Update

Feedback re-scores.

Every share_feedback updates the Bayesian posterior for the memory in question. Tomorrow's retrieval is shaped by today's signal — and the loop closes.

posteriorre-rank
04 — Update 02 — Retrieve · the loop never breaks
05Memory scopes

Private by default. Public only if you ask.

Spark maintains two memory scopes, isolated at the storage layer and ranked separately at retrieval time. Organisation memory is what your team's agents have learned. Public memory is the community pool — and it's strictly opt-in.

● Default · always on

Organisation memory.

Everything your agents contribute lands here. It never leaves your tenant. Other organisations cannot read it; Memco cannot read it.

  • Scoped to your team and your tenant only.
  • All four calls (search, create, enrich, feedback) operate against it by default.
  • Not shared, not aggregated, not used for model training.
Isolation · per-tenant data and compute
○ Opt-in · per organisation

Public memory.

A community knowledge pool covering widely-used libraries, frameworks, and common patterns. You choose to read from it; your private writes never flow into it.

  • Read-only from your tenant unless you explicitly contribute.
  • Ranked alongside your org memory at retrieval time.
  • Toggle is a per-org configuration — disabled until you flip it.
Boundary · public reads are always crossing a firewall you control
06Deployment

Two ways to run it. Same interface.

Both deployment models maintain full isolation of organisation memory. Both expose the same MCP and CLI surface, so agent-side integration code never needs to change between them. Migration is a config flip, not a rewrite.

Option AFully managed

Private tenant on Memco.

A dedicated Spark instance provisioned in Memco's cloud, isolated at the data and compute level from any other tenant. Agents connect via secure HTTPS from behind your firewall. Fastest path to deployment.

HostingMemco cloud
Org memoryPer-tenant isolated
Public memoryAvailable · opt-in
Time to deployHours
Option BSelf-hosted

On-premises in your own infra.

A private Spark instance runs entirely behind your firewall. All organisation memory stays on customer-controlled infrastructure. Public memory is external by definition — it crosses the firewall only if you explicitly enable it.

HostingCustomer-controlled
Org memoryStays on-prem
Public memoryOpt-in feed across firewall
InterfaceIdentical · MCP & CLI
07Empirical results

Compounding, not linear.

On controlled SWE-bench runs, the first task is a cold start. Every task after that benefits from accumulated knowledge. These are the steady-state numbers we measure — and the variance reduction is, in our view, the most important of them.

−40%
LLM costs at steady state
SWE-bench · steady-state
−34%
Wall-clock time per task
end-to-end
−31%
Agent steps to completion
averaged across tasks
½×
Outcome variance — outcomes get more predictable
cost variance · halved