Memory candidates

A memory candidate is a queued row that says “this receipt + this positive outcome looks like something an agent would benefit from remembering.” A reviewer in lair turns useful candidates into patterns — reusable knowledge that rides into future calls via the patterns module.

No auto-promotion. Every promotion is a human decision.

Why we don’t auto-promote

A self-reported succeeded outcome is a noisy signal. Auto-promoting it would let agents fabricate their own memory, contaminate the patterns table, and erode trust. The reviewer step is the cheapest control that keeps the patterns table reliable.

V-27b will introduce an auto-promotion job with a confidence threshold; V-27c will introduce trusted-integration outcomes (signed-payload webhooks for source: webhook | automated_test). Until those ship, everything goes through the reviewer.

The flow

positive outcome  ──▶  memory_candidates row  ──▶  reviewer in lair  ──▶  patterns row
                                              │
                                              └──▶  rejected (status flipped; row kept)

Candidates are an honest paper trail of “we considered this.” Reviewers promote, reject, or leave for later.

Lair reviewer surface

lair.prxy.monster/dashboard/admin/memory-candidates has three tabs (Pending / Promoted / Rejected). Each pending candidate shows the joined receipt + outcome data inline:

Model, provider, region.
Cost, tokens, cache_status, policy_decision, module_chain.
Outcome kind, source, score, labels.
Agent and project attribution.
The hashed note (we never display raw notes).

Reviewer actions:

Action	Effect
Promote	Atomically writes a row to `patterns` and flips the candidate to `status: promoted`. The pattern is scoped to the owning tenant.
Reject	Flips the candidate to `status: rejected`. Row kept for the audit trail.

Receipts and outcomes themselves are never mutated by either action.

What ends up in `patterns`

A promoted candidate becomes a patterns row keyed by problem signature + tenant. The patterns module reads this table at request time and injects relevant entries into the system prompt for future calls — which is the closing of the compounding loop:

receipts → outcomes → memory_candidates → patterns → better future calls

What is not memory

Memory candidates are explicitly not:

A general user-content store. Cache modules, not the patterns table, hold response payloads.
A logging dump. Receipts are the audit trail; candidates are a curated learning queue.
A way to bypass the reviewer. Self-reported “I succeeded” never auto-promotes.

Tenant isolation

Promoted patterns are scoped to the owning tenant. Patterns from tenant A never leak into tenant B’s pipeline.