The Interviewer
A third way memories enter Caura — a scheduled reader synthesizes an agent's own durable work trail into typed memories, so nothing important is lost just because the agent forgot to write it down.
Most memories arrive because an agent chose to write them —
memclaw_write on a decision worth keeping. That's the realtime path, and
it's the right one for anything the agent recognizes as important in the
moment. But agents forget. A long autonomous run makes a dozen decisions,
hits three blockers, and learns a preference about the codebase — and
writes down none of it, because it was busy doing the work.
The Interviewer is the reflective path. On a schedule, it reads an agent's durable work trail — the transcript or event log the harness already keeps — and asks an LLM to synthesize what happened into structured, typed memories. The agent never has to stop and journal; its own trail is interviewed after the fact.
The Interviewer never re-runs the agent — it reads a trail that already exists and summarizes it. Because it works from the real transcript rather than re-prompting the model, it is grounded in actual activity — but LLM synthesis can still mis-read or overstate events, so Interviewer memories should be treated as a useful approximation, not a verbatim record.
Why it exists
- Coverage. Realtime writes capture what the agent noticed. The Interviewer captures what it did — including the decisions and blockers it never thought to record.
- No agent burden. Diligent journaling competes with the actual task and usually loses. The Interviewer moves that cost off the agent and onto a scheduled background job.
- Reaches harnesses without a plugin. A Claude Code or Cursor workstation has no Caura gateway — but it already keeps a durable transcript on disk. The Interviewer reads it directly.
- Fleet-scale honesty. Across hundreds of agents you can't rely on every one writing well. A scheduled reader is uniform: every agent's work gets the same reflective pass.
What it produces
Each interview turns a window of activity into memories under six report sections, mapped onto Caura's typed-memory enum:
| Report section | Memory type | Captures |
|---|---|---|
worked_on | episode | What the agent actually did in the window |
decisions | decision | Choices made, with rationale |
outcomes | outcome | Results (success / failure / partial) |
blockers | task | What got stuck, as follow-up work |
open_questions | fact | Unresolved questions surfaced during the work |
preferences_learned | preference | Conventions and preferences the agent picked up |
These land as ordinary memories — enriched, embedded, governed, and
recallable exactly like a hand-written memclaw_write. Event timestamps
from the trail are preserved, so the memories carry real wall-clock time.
How activity reaches the Interviewer
The synthesis is identical everywhere; only how the trail is captured differs by harness. Two families ship today:
- Plugin-buffer — the OpenClaw plugin keeps a durable, node-local buffer of events and submits windows to the server. No separate install; it rides the plugin you already run.
- Disk-parser — a small read-only CLI (
memclaw-interviewer, shipped in thememclaw-clientPyPI package) reads a harness's own on-disk transcript and submits windows. This is how Claude Code and Cursor workstations participate, with no plugin and no gateway.
Both families speak the same submit protocol and share the same crash-safe watermark, so the server treats every source identically.
The server side has its own half: an hourly interviewer-schedule tick in
the operations service queues an interview_request command for every node
whose last interview is older than the tenant's period_hours — Collectors
capture, the scheduler decides when. The
protocol page covers the cadence and its
limits.
Harness support
| Harness | Capture family | Status |
|---|---|---|
| OpenClaw | Plugin-buffer (push) | ✅ Shipped |
| Claude Code | Disk-parser (~/.claude/projects) | ✅ Shipped |
| Cursor | Disk-parser (~/.cursor/…/agent-transcripts) | ✅ Shipped |
| Hermes | Disk-parser (state.db) | 🚧 Planned — TBD |
| Codex & others | Disk-parser / API-puller | 🚧 TBD |
See Setup for how to enable each one.
Opt-in and off by default
The Interviewer is opt-in per tenant and off by default. It stays
completely inert until you set interviewer.enabled = true in the tenant's
org settings — no trail is read and no memory is written before that. The
capture side is a second switch: the OpenClaw plugin also needs
MEMCLAW_INTERVIEWER=true, and the disk-parser CLI only harvests projects
you explicitly allowlist. Both the client scrub and the server mask strip
credential-shaped strings before anything is stored.
Two independent switches by design: enabling a tenant does nothing until a capture source is also turned on, and a capture source does nothing until the tenant is enabled. Neither half acts alone.
Where to go next
- Setup — enable a tenant, then wire each harness (OpenClaw, Claude Code, Cursor), plus the CLI, triggers, and the privacy allowlist.
- Protocol — the technical flow: windows, the forward-only watermark, masking, chunked map-reduce, and idempotent writes.
- Memory Pipeline — what happens to a memory once the Interviewer writes it.
Where to look in the source
- Submit endpoint + seq validation:
core-api/src/core_api/routes/interview.py - Interview synthesis (masking, chunked map-reduce, section map, watermark, scheduler):
core-api/src/core_api/services/interview_service.py - Disk-parser CLI (
memclaw-interviewer):clients/python/src/memclaw_client/interviewer/ - OpenClaw plugin buffer + submit:
plugin/src/heartbeat.ts
Reference
One-page reference for Skill Factory — config keys, statuses, auto-gates, endpoints, the skill schema, and the plugin target env var.
Setup
Enable the Interviewer on a tenant, then wire each harness — the OpenClaw plugin, or the memclaw-interviewer CLI for Claude Code and Cursor workstations.