Harness memory & meta-cognition
What the harness learns from your runs, per-role metrics, learned tips, observations, self-portrait.
Two stores, one purpose: capture what the harness has learned from your past runs, then use it to improve future ones.
Harness self-memory
Lives at ~/.cerevisor/memory/harness/. Auto-populated at end-of-run.
Three files:
self.md: human-readable retrospective. What's been working, what hasn't, recent run log.self.json: structured data: per-role success rates, average cost, recurring patterns, error frequencies.corrections.ndjson: append-only log of every time you corrected the harness ("don't auto-add reviewers", "use the cheaper model for this role").
Visible in Memory view → Harness tab. Read-only: the harness manages this itself.
What it captures
After every workflow run, run-finalization.ts writes:
- Per-role metrics: how often each role succeeded, average cost, average duration.
- Recurring patterns: "Researcher agents have been failing on EU-domain queries 3 times in a row."
- Run log entry: one line per run with workflow name, status, cost, duration, what worked / didn't work.
The harness later reads this to surface tips ("You've spent $40 on Opus in the last week; switching to Sonnet would have produced the same output for $5") and to drive meta-cognition.
Meta-cognition
Lives at ~/.cerevisor/memory/meta-cognition/. Computed at end-of-run from a diff of harness-self snapshots.
Two files:
observations.{md,json}: typed observations like "role X drift", "blind spot Y persistent", "pattern Z reversal", "run-log recurring theme".harness-self-portrait.{md,json}: a compiled reflective summary of "what I have learned about working with you."
Visible in Memory view → Reflection tab.
Observation kinds
| Kind | When emitted |
|---|---|
| role_metric_drift | A role's success rate dropped by ≥10% across runs. |
| role_metric_recovery | Recovered after a drift. |
| role_new | First-ever observation for a previously-unseen role. |
| pattern_growth / pattern_stale / pattern_reversal | Patterns in the run log changing over time. |
| blind_spot_persistent | Same failure mode in 3+ consecutive runs. |
| blind_spot_resolved | A previously-persistent blind spot stopped occurring. |
| run_log_recurring_theme | Themes appearing in multiple run logs. |
| baseline | First-ever observation (single emission on first run). |
The harness emits learned tips when a blind spot persists across 3+ runs. These show in the canvas as a badge on the affected agent or as a status-bar pill.
The self-portrait
The portrait has three sections:
- Learnings about user: 2-4 sentences describing what the harness has noticed about your preferences and patterns.
- Self-capabilities: 2-4 sentences on what the harness has been doing well lately.
- Enduring insights: up to 6 bullet-point insights that have repeated across runs.
The portrait is refreshed on every run by the same LLM call that writes the meta-cognition narrative, so no extra round-trip.
Toggling enrichment
Two related settings in Settings → Memory:
| Setting | Default | Effect |
|---|---|---|
| Meta-cognition enrichment enabled | On | Whether the optional LLM call runs to produce the narrative + portrait. Detectors + observations always run regardless. |
| Inject memory into prompts | Off | Whether the narrative + observations are injected into every agent's system prompt at run time. |
If you turn enrichment off, the harness still tracks observations; you just won't get the prose narrative. If you turn injection off, the data is still collected and visible in the Memory view but agents don't see it.
When meta-cognition skips
Meta-cognition skips its LLM call when:
- The current run's default provider is Codex CLI or Cursor Agent (no chat API).
- No provider is configured at all.
- No new observations were produced this run (nothing to narrate).
The reason is recorded so the Memory view can show why the portrait or narrative is stale.
Downstream consumers: the Situational Awareness pillar
The meta-cognition observations, the harness self-portrait, the disagreement records, and the per-role learnings are all read by Cerevisor's Situational Awareness pillar, which composes them into typed SituationSnapshot objects for the chat builder and the run drawer. SA does not duplicate this subsystem; it presents the same data through a different lens (taskwork / agent / teamwork slices, with belief attribution and context-freshness scoring).
In practice this means: when the harness-memory entries grow stale, drift across runs, or contradict each other, the SA panels will surface that explicitly (context-stale or fixation-risk state labels, "verifier rejected" badges on agents, open disagreements in the Teamwork slice). If you want to understand why an SA badge looks the way it does, the answer almost always lives in the memory artifacts described above.
Resetting
If the harness's learned state has drifted in a bad direction (e.g. you accidentally trained it toward something you didn't mean), you can reset:
- Open
~/.cerevisor/memory/harness/and~/.cerevisor/memory/meta-cognition/. - Delete the files (or move them to a backup folder).
- Restart Cerevisor.
The harness rebuilds from scratch on the next run.
Less drastic: use Memory History to restore a snapshot from a known-good earlier date.