Kapacitor/Session recall
Kapacitor gives the agent three MCP tools — search past sessions, summarise, drill into the exact turn — so prior decisions show up in this conversation instead of getting re-litigated.
Without recall
You ask a question that touches a decision your team already made. The agent has no idea it has been argued.
A queue would give you backpressure and retry semantics — usually the safer default.
I’ll sketch a Redis-backed queue with an inline worker.
Without recall, every new session re-opens decisions your team has already closed.
With recall
The agent searches every session you can see, defaults to the current repo, and chains search → summarise → drill in until it has the actual turn.
Priya already ran the call against this rate-limiter. The 24h shadow at direct call stayed within p99 budget, so the team chose direct over a queue.
The condition to revisit is shed rate above 1%. Want me to check the last week’s shed rate before we change course?
With recall, the agent cites the prior call instead of starting the argument over.
How it works
The kapacitor mcp sessions stdio server gives the agent three chained tools: search_sessions over titles and full transcripts, get_session_summary to orient, and get_session_transcript to drill into the exact event. It’s repo-aware by default and respects the same visibility rules as the dashboard — the agent can’t see what you can’t. Ask “check all our repos” to broaden the search. Read the mechanics in Session recall and Visibility & sharing.
Kapacitor is in private preview. Bring us a repo with a few months of agent history and we'll wire recall into Claude Code or Codex.
Rather start a conversation? Talk to the team — we’re building with teams that already use coding agents.
Built by the team behind KurrentDB — event streams in production are what we do. Coding agents just produce a new kind.