Agent Artifact Cache

What this is for

When you dispatch a subagent to research something or write a plan, its findings live only inside that subagent's own transcript. Once the subagent finishes, that work is gone unless something durable captures it first — and the next session (or the next subagent) ends up re-doing the same research from scratch. This skill is about not paying for the same work twice.

There are two ways to get this, depending on what's set up:

If institutional memory search is set up (optional — see /alignment-harness:harness-setup)

If you've wired up a semantic search over past sessions (one reference setup calls this agent_find, backed by an agent-swarm MCP server), it can return an artifact_id in a result's metadata when a past subagent's research report, plan, or session summary was auto-extracted and cached. Read the full document with agent_read:

agent_read({ id: 10006 })                          → first 200 lines
agent_read({ id: 10006, limit: 50 })                → first 50 lines
agent_read({ id: 10006, offset: 200 })               → lines 201-400
agent_read({ id: 10006, offset: 200, limit: 100 })   → lines 201-300

The response tells you how many lines remain and the exact offset to continue from.

Artifact types worth knowing when you're reading one of these caches:

Type	What it is	How much to trust it
research_report	Deep codebase analysis, architecture audits, system explorations	high
plan	Implementation plans with action steps and file targets	high
context_summary	Session compaction summaries (decision context, reasoning chains)	medium
code_completion	Short task completions	usually not cached — low signal

If you build this yourself: the extraction runs on a SubagentStop hook using structural heuristics (an opener like "Now I have a comprehensive understanding...", numbered action steps, <analysis>/<summary> tags for compactions) rather than an LLM call, so it costs nothing to run on every subagent stop. Dedup by content hash so the same finding is never stored twice, and skip anything under ~500 characters as too short to be worth keeping. Watch for artifact types your own classifier produces that aren't in your docs yet — an undocumented type is easy to miss when auditing what's actually in the cache.

If it isn't set up (works everywhere, no setup)

Claude Code already keeps every session's full transcript on disk — nothing needs to be captured into a separate cache for you to search it. Before re-doing research a past session likely already did:

1. Grep your own past sessions for the topic: grep -l "<keyword>" ~/.claude/projects/*/*.jsonl (each line is a JSON event; a plain-text keyword match is usually enough to find the right file, then read that file's relevant lines).
2. If subagent transcripts are stored separately in your setup, also check ~/.claude/projects/*/**/subagents/*.jsonl.
3. Check git log --all --oneline --grep="<keyword>" and recent commit messages — a past session's actual output is often summarized there even when the transcript is hard to search.
4. Say plainly when nothing turns up: "no prior research found on this — proceeding fresh" is honest and cheap; presenting fresh work as if it confirmed something a past session found is not.

If a subagent just produced something worth keeping past this session — a research report, a plan, a non-obvious finding — and you don't have automatic extraction, write it yourself to a plain markdown file under the folder alignment-harness records artifacts prints, with a short filename that describes the finding. That's the whole mechanism without the automation: a folder of markdown files future sessions can grep.

Building your own automatic extraction (what the author's setup does)

If you want the automatic version instead of grepping by hand each time: register a SubagentStop hook that reads the finishing subagent's transcript, classifies it with cheap structural heuristics (not an LLM call — see the table above for the signal), and writes matches to a local store, for example alignment-harness records artifacts/<id>.md plus an index file. Whatever you build this on top of, keep the store itself general — a plain folder of markdown files with an index — so it isn't tied to any one search backend.

Is it set up / is it working?

• With institutional memory search: does a search for something you know a recent subagent researched actually surface it? If a store like this goes silent (the hook stops firing, or the extractor starts finding nothing), nothing else will tell you — check the timestamp on the newest file in the store against how many subagents have run since.
• Without it: grep -l "<keyword>" ~/.claude/projects/*/*.jsonl finding the right session is your test.