Ask your agent: have we worked on this before?
Capacitor gives the agent five MCP tools — search past sessions, summarise one, walk it turn by turn, drill into the exact turn — so prior decisions show up in this conversation instead of getting re-litigated.
The agent only knows this chat.
You ask a question that touches a decision your team already made. The agent has no idea it has been argued.
Should we put a queue in front of the rate-limiter, or call it directly?
A queue would give you backpressure and retry semantics — usually the safer default. I’ll sketch a Redis-backed queue.
Without recall, every new session re-opens decisions your team has already closed.
The prior decision shows up in this chat.
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.
Should we put a queue in front of the rate-limiter, or call it directly?
Priya already ran this. The 24h shadow at direct call stayed within p99 budget, so the team chose direct over a queue. Revisit if shed rate climbs above 1%.
With recall, the agent cites the prior call instead of starting the argument over.
The kcap mcp sessions server gives the agent five chained tools: search_sessions, get_session_summary, get_session_transcript, list_turns and get_turn. It’s repo-aware by default and respects the same visibility rules as the dashboard. See Session recall.
Stop re-deciding what you already decided.
Start free and wire recall into Claude Code or Codex — bring a repo with a few months of agent history.
Fix flaky auth-token refresh test
Tried mocking the clock first — abandoned after the race persisted. Root cause: token cache TTL rounding. Patched in auth/cache.ts, added regression test. Two approaches rejected, one shipped.