The InterviewerAgent MemoryGovernanceAugust 31, 2026

Agents Don’t Journal

The Interviewer — Caura’s reflective write path. Deliberate writes capture what an agent noticed; the Interviewer captures what it did.

Every memory system for AI agents carries an unstated assumption: that the agent will stop working long enough to write things down. Give agents a write tool, the theory goes, and the important lessons get recorded.

Here’s what actually happens. A coding agent runs autonomously for four hours. It makes a dozen decisions, hits three blockers, discovers that the integration tests only pass on Node 20, and learns that this team prefers small PRs with linked issues. Then the run ends — and the memory store holds exactly none of it, because the agent was busy doing the work.

This isn’t a badly prompted agent. It’s the normal one. Diligent journaling competes with the actual task for the same attention, and it loses — in agents for the same reason it loses in humans. Prompt harder and you get a different failure: dutiful, low-signal writes that bury the real lessons in noise. Across a fleet of hundreds, you can’t rely on every agent writing well, any more than a company can rely on every employee keeping a perfect lab notebook.

We call this the journaling tax: every deliberate memory write is paid for out of the agent’s task budget. Most memory products respond by exhorting the agent to pay it more reliably. Caura’s answer is to stop charging it.

Interview the trail, not the agent

Two write paths into the governed memory layer: deliberate realtime writes and the reflective scheduled Interviewer path

Fig 1. Two write paths, one governed layer. Deliberate writes capture what the agent noticed in the moment; the reflective path captures what it did — including everything it never thought to record.

Here’s the observation the Interviewer is built on: the record already exists. Every serious harness keeps a durable work trail — Claude Code writes transcripts to disk, Cursor keeps agent logs, a gateway plugin sees every event that passes through it. The knowledge wasn’t lost; it just was never promoted from trail to memory.

So on a schedule, the Interviewer reads a window of an agent’s own trail and asks an LLM one question, in effect: what here is worth remembering? The synthesis lands as ordinary Caura memories — typed, enriched, embedded, governed, recallable — exactly as if the agent had written them by hand. The agent never stops to journal. Its transcript is interviewed after the fact.

Two properties matter here. First, the Interviewer never re-runs the agent. It reads a trail that already exists; there is no re-prompting, no second execution, no chance of the reflection changing the work. Second, because it works from the real transcript, it’s grounded in actual activity — though LLM synthesis can still misread or overstate, which is why Interviewer memories are treated as a useful approximation of the run, not a verbatim record, and remain subject to the same corroboration and supersede mechanics as every other memory in the store.

What an interview produces

Each interview turns a window of activity into memories under six report sections, mapped onto Caura’s typed-memory enum:

Report sectionMemory typeCaptures
worked_onepisodeWhat the agent actually did in the window
decisionsdecisionChoices made, with rationale
outcomesoutcomeResults — success / failure / partial
blockerstaskWhat got stuck, as follow-up work
open_questionsfactUnresolved questions surfaced during the work
preferences_learnedpreferenceConventions the agent picked up

Notice what that list covers: it’s precisely the material agents don’t write deliberately. An agent will sometimes record a hard-won constraint. It will almost never record “I decided X over Y because Z” mid-flow, or “this stayed unresolved”, or “this team seems to prefer…”. Those are reflective observations, and reflection is exactly the step the task budget squeezes out.

A real-shaped example — one overnight Claude Code run through the Interviewer:

worked_on    → episode:    "Migrated payments service to the v3 client;
                            21 files touched, 4 test suites updated"
decisions    → decision:   "Kept the legacy retry wrapper — v3's built-in
                            retries don't honor our idempotency keys"
outcomes     → outcome:    "Migration complete (success); canary deploy
                            deferred (partial)"
blockers     → task:       "Staging credentials for the v3 sandbox expired;
                            renewal needed before canary"
open_questions → fact:     "Unclear whether webhook signatures change
                            between v2 and v3 — docs ambiguous"
preferences_learned → preference: "Repo convention: schema changes ship in
                            separate PRs from application code"

The next agent to touch that service recalls all six — including the retry-wrapper decision that would otherwise have been re-litigated from scratch. Event timestamps from the trail are preserved, so the memories carry real wall-clock time, not the time of synthesis.

Stop losing what your agents learn overnight.
One governed memory layer, two write paths — deliberate and reflective. Self-hosted or managed, MCP-native, free to start. Start free →

Reaching harnesses that have no plugin at all

The Interviewer capture pipeline: plugin-buffer and disk-parser collectors feed windows to synthesis, producing six typed memories

Fig 2. The synthesis is identical everywhere; only trail capture differs by harness. Collectors capture; the server’s scheduler decides when.

The synthesis is the same everywhere. What differs per harness is how the trail gets captured, and 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 — caura-interviewer, shipped in the caura-client PyPI package — reads a harness’s own on-disk transcript and submits windows. This is the interesting one: it’s how Claude Code (~/.claude/projects) and Cursor workstations participate with no plugin and no gateway. If the harness keeps a transcript, the fleet’s memory can learn from it.

Both families speak the same submit protocol and share a crash-safe, forward-only watermark, so the server treats every source identically and never double-writes a window. On the server side, an hourly scheduler tick queues an interview for every node whose last interview is older than the tenant’s configured period — collectors capture, the scheduler decides when.

HarnessCapture familyStatus
OpenClawPlugin-buffer (push)✅ Shipped
Claude CodeDisk-parser (~/.claude/projects)✅ Shipped
CursorDisk-parser (agent transcripts)✅ Shipped
HermesDisk-parser (state.db)🚧 Planned
Codex & othersDisk-parser / API-puller🚧 TBD

Off by default, by design

Reading work trails is powerful, which is exactly why the Interviewer ships opt-in per tenant and off by default. It is completely inert until the tenant flips interviewer.enabled = true — no trail is read, no memory is written. And that’s only half the switch: the capture side has its own — the OpenClaw plugin requires its own environment flag, and the disk-parser CLI only harvests projects you explicitly allowlist. Neither half acts alone; enabling a tenant does nothing until a capture source is also turned on, and vice versa.

Before anything is stored, credential-shaped strings are stripped twice — a client-side scrub and a server-side mask. The trail is the agent’s work, not its secrets.

Two write paths, one principle

In How Agents Share Knowledge we argued there are only five architectures for sharing knowledge between agents, and that only a governed memory layer compounds it. All five share one more assumption we didn’t dwell on: someone deliberately shares. Even the governed layer, used naively, depends on the agent choosing to write.

The Interviewer removes that assumption for the fifth architecture. Deliberate writes remain the right path for anything the agent recognizes as important in the moment — a caura_write at the point of discovery is unbeatable for precision. The reflective path covers everything else: what the agent did but never flagged. Coverage, without the journaling tax.

There’s a broader principle here, and it’s the one we build everything around: the memory layer should absorb burden, not impose it. Every requirement a memory system places on an agent — journal diligently, tag correctly, remember to remember — is a requirement that fails at fleet scale. The systems that win are the ones where doing the work is the integration.

FAQ

Does the Interviewer re-run or re-prompt my agents?

No. It reads a durable trail the harness already keeps — a transcript on disk or a plugin’s event buffer — and synthesizes it after the fact. The agent’s execution is untouched, and the reflection can’t alter the work it reflects on.

What stops hallucinated memories from polluting the store?

Three things. The synthesis is grounded in the real transcript, not a model’s recollection of it. The output is treated as an approximation, not a verbatim record — subject to the same corroboration ladder and supersede mechanics as any hand-written memory. And everything is attributed: an Interviewer memory is inspectable, traceable to its window, and overridable the moment an agent or operator knows better.

Is this surveillance of my agents’ workstations?

It’s off by default and double-gated: a tenant-level switch and a per-source switch, with an explicit project allowlist for the disk-parser. Nothing is read until both are deliberately enabled, and credential-shaped strings are scrubbed client-side and masked server-side before storage.

Getting started

The Interviewer ships with Caura — Apache 2.0, self-hosted or managed, MCP-native. Enable it on a tenant, wire a capture source, and the next scheduled tick starts turning trails into memory: Setup covers each harness, Protocol covers windows, watermarks, and masking, and the engine is on GitHub if you’d rather read the source.


Related reading: How Agents Share Knowledge · What Is Agent Fleet Memory?