Project Memory

Project memory is where Mockarty keeps what your project knows: the
requirements people wrote, the decisions they took, the commits that implemented
them, the tests that checked them, the deployments that shipped them, and the
things that did not work along the way.

It fills itself. As missions run, as the autonomous coder works, and as people
settle things in rooms and messages, facts are recorded automatically. You can
also add a note by hand.

Two audiences read it, and they read exactly the same thing:

• You, on the Project memory page in the sidebar.
• Agents, through the project_memory_* tools, before they act.

Project Memory is part of the licensed A2A and autonomous-agent capability.
The page, REST API, and MCP tools are available on the Cloud or on-prem authority
that owns the workspace. Packaged Desktop does not expose or run a second local
Project Memory service; open the licensed workspace’s web interface to inspect
or curate its agent history.

Why it matters

An autonomous run is only as good as what it knew when it started. Without a
shared memory, every run rediscovers the same address, re-derives the same
decision and repeats the same mistake — and when something goes wrong, nobody
can say what the agent was looking at when it decided.

What a fact looks like

Every fact carries:

Trust: where authority comes from

Facts are not all equal, and the page says so on every line.

The last two are claims, not facts. They are useful, they are shown, and
they are labelled — but they never reach an agent as established truth.

State: what may be acted on

candidate → corroborated → reviewed → published, with disputed,
superseded, retracted and expired as the ways a fact stops being current.

Only a published fact is authority. A disputed one means two published
facts disagree, and both sides are always shown together — never one alone.

Labels on the page

Using the page

Open Project memory in the sidebar.

• Search and filter by kind, by minimum trust, or by the subject id.
• Click a fact to see its full detail: every revision, the relations around
  it, and any contradictions.
• Preview agent context shows exactly what an agent working here would
  receive — the same text, the same labels, the same citations, inside the same
  size limit. This is the fastest way to understand why an agent did what it did.
• Add note records something the project should remember.

Reviewing

A namespace owner can:

• Publish a fact — make it authority. It asks why, and the reason is kept.
• Retract a fact that turned out to be wrong. It leaves recall immediately;
  the history stays.
• Place a legal hold on evidence that must be preserved. A held fact cannot
  be removed by anything, including deleting the namespace.

Nothing is ever edited in place. A correction is a new revision, so what an
agent acted on last week is still readable exactly as it was.

The review queue

Facts waiting on a reviewer are listed at
GET /api/v1/project-memory/review-queue — candidates and corroborated facts,
oldest first. A reviewer takes a claim on one fact
(POST /api/v1/project-memory/facts/{id}/review/claim), keeps it alive with
…/review/heartbeat, hands it back with …/review/release, or ends it with
…/review/finalize and an explicit decision — publish or reject — plus a
reason. Three rules are enforced on finalize:

• the claim’s generation must be the live one — a reviewer whose claim
  expired and was taken over cannot publish over the new owner;
• the fact’s author cannot approve their own fact — an independent
  reviewer must decide;
• the decision applies to the exact revision reviewed — if the fact was
  revised meanwhile, the call conflicts and the current head must be
  re-reviewed.

Storage profiles

Memory that grows without a ceiling stops being useful and starts being a bill.
Each project has a profile:

The usage strip at the top of the page shows how much of the ceiling is in
use. When a project approaches it, unreviewed observations are refused with an
explanation — decisions, verdicts and deployment records are never refused.
The strip also reports what the two unit-priced background workers have spent
for this scope: summaryUnitsUsed (the summariser) and embeddingUnitsUsed
(the embedding authority), in the same units the ledger bills.

There is an early-warning line at 95% of the ceiling. A write admitted past it
still lands, and the response says so: the X-Project-Memory-Budget: degraded
response header plus an admission field ({"degraded": true, "reason": "soft_limit"}) in the body of the write result — including the
project_memory_record MCP tool. A client that sees it should record less:
shorter statements, fewer facts — not repeat the write.

Some things are never compacted away, whatever the pressure: decisions people
took, acceptance verdicts, deployment records, incidents, unresolved
contradictions, and anything under legal hold.

The opposite also holds: ephemeral working context — tool traces, run
observations, the steps of a mission in progress — is kept only while the work
is fresh and drops out of recall after 14 days.

Condensing history: the summary stage

Memory is maintained in passes, cheapest step first. The last step is the only
one allowed to use a language model: it takes a group of old, cold facts about
one subject that the cheaper steps could not fold, and asks the model to
condense them into one short statement. The group members keep their place in
history — they are marked as condensed and stay traceable through links — while
recall reaches for the summary first.

The stage is deliberately cautious:

• It runs only when a default model profile is configured on the install. An
  air-gapped installation with no model keeps a fully working, fully
  deterministic memory — every other step needs nothing but the database.
• A summary is stored as a model’s conclusion, the weakest trust class, and
  starts unpublished. Until a person reviews it, it never carries the authority
  of the facts it replaced.
• The model may answer that nothing is worth keeping. That is a normal outcome:
  no summary is written, and the group stays as it was.

The summary budget

Condensing costs money, so each scope has a separate summary allowance,
measured in units (roughly one unit per few tokens of material). The usage
strip shows both sides of it:

• maxSummaryUnits — the allowance the profile grants (zero on lean, which
  never spends on models);
• usedSummaryUnits — what the scope has actually spent.

Every model call is counted against the allowance before it is made. If the
next group does not fit, the pass simply stops condensing for this round — the
facts are untouched, and the work resumes on a later pass. The counter only
grows: a spent unit is never refunded, because a paid model call cannot be
recalled.

Payment is also crash-safe. Each group is paid for at most once: if the process
dies between paying for a group and receiving its answer, the next pass
recognises the already-paid group and skips it instead of paying a second time.
A group that gained or lost facts is a new group and is summarised on its own
merits.

For agents

Four tools, one per moment of a run:

project_memory_context, project_memory_search, and
project_memory_timeline require a token with the read action.
project_memory_record requires write. The context operation uses POST only
to carry a structured, size-bounded query; it does not change project memory.

What an agent records enters as a candidate observation attributed to it. It
does not become project authority until a person reviews it or an independent
source says the same thing.

Isolation and safety

• A fact belongs to exactly one namespace. Identical wording in two namespaces
  is two different facts, and neither is ever visible from the other.
• Credentials are refused. A statement, an attribute or a link that looks like a
  token is rejected rather than stored.
• Raw logs, whole transcripts and full files are not stored. A fact keeps a
  short quotation and a pointer to where the detail lives.
• Text stored in a fact cannot act as an instruction when an agent reads it.

See also

• Autonomous Missions
• Autonomous Coder
• Agent Rooms