Show HN: Agent-historian – let your AI agent search its own past sessions Agent-historian, a new open-source CLI tool, lets AI coding agents search their own past conversation history from the command line, enabling them to recover prior research, commands, errors, and decisions instead of repeating work. The tool supports multiple agents like OpenCode and Claude Code, is read-only, and uses a progressive-disclosure workflow to minimize context window usage. English | 简体中文 /adlternative/agent-historian/blob/main/README.zh-CN.md Search and read your past AI coding-agent conversation history from the command line — so your agent can recover earlier research, commands, errors, and decisions instead of repeating work. Ships a small CLI ochist and an Agent Skill so agents like OpenCode https://opencode.ai and Claude Code https://www.anthropic.com/claude-code can check history before doing fresh research. Multi-agent. Reads OpenCode opencode.db and Claude Code ~/.claude/projects/ .jsonl out of the box, plus additional locally detected agents. Pluggable: add a new agent by implementing one interface. Project- or global-scoped. Searches default to the current project current directory and below ; --global widens to everything. Read-only. Never modifies any data store. Context-friendly. Plain, pipe-friendly output. Agents page with grep / head / wc / jq instead of dumping whole sessions into context. Zero runtime dependencies. Uses Node's built-in node:sqlite Node ≥ 22.5 . No native modules. AI coding agents are mostly stateless across sessions . Every new chat starts from zero, so the agent happily redoes investigation it already finished yesterday — re-reading the same files, re-running the same commands, re-deriving the same conclusions. That wastes your time, your tokens, and your patience. agent-historian gives the agent and you a cheap, local way to ask: "Have I solved this before? What command did I run? Which file did we change? What did we decide, and why?" It deliberately does not try to summarize sessions with brittle heuristics regex-based "accomplishment extraction" breaks on non-English text and on any phrasing it didn't anticipate . Instead it lets the agent read the real text on demand , using a progressive-disclosure workflow locate → orient → scan → read so only the relevant lines enter the context window. Developers who switch between projects and sessions and want their agent to remember prior work instead of starting over. AI coding agents OpenCode, Claude Code, Qoder, … that should check history before doing fresh research — wired up via the bundled Agent Skill. Tool builders who want a small, dependency-free, read-only way to query local agent transcripts across multiple tools through one interface. There are several ways to give an agent "memory." agent-historian is deliberately the simplest one — it doesn't build a memory, it reads the ground truth you already have on disk . | Approach | What it stores | Retrieval | Cost / setup | Faithfulness | |---|---|---|---|---| agent-historian | nothing — reads existing transcripts | lexical grep/substring , on demand | zero index, zero deps, read-only | exact original text | Memory layers mem0, OpenMemory, MemGPT, "memory tools" | LLM-distilled facts/summaries it decides to save | semantic recall of summaries | needs a store + write step; can drift/hallucinate | lossy — a model's paraphrase | RAG / embeddings vector DB over chat logs | chunked text + embedding vectors | semantic vector similarity | embedding model + vector DB + reindex pipeline | exact chunks, but needs infra & re-indexing | Built-in --resume / --continue | the agent's own session files | reload one whole session into context | free, but no search | exact, but all-or-nothing | Auto-summary recall regex/heuristic "what did I accomplish" | extracted bullet points | keyword over summaries | cheap | brittle; breaks on non-English / unusual phrasing | Use when you want to agent-historian find and re-read what actually happened — the exact command, error, diff, or decision — across past sessions and across multiple agents, with no infra and no risk of a model rewriting history. It's a search tool over real transcripts , not a memory. Add a memory layer mem0, etc. when you want the agent to carry forward distilled preferences and durable facts "the user prefers pnpm", "deploys go through staging" that should persist as structured knowledge. Use RAG/embeddings when you need semantic recall over a large corpus and can afford an embedding model + vector store + re-indexing. They're complementary: agent-historian answers "show me the real thing I did," memory/RAG answer "recall the gist of what I know." Many setups use both — historian for exact recall, a memory layer for distilled facts. No embeddings, no index, no background process — search is plain lexical matching that runs on demand, so there's nothing to build, sync, or keep warm. Read-only — it never writes a "memory," so it can't drift from or corrupt the source of truth. Progressive disclosure — instead of stuffing summaries into context, the agent pages through results locate → orient → scan → read and pulls only the exact lines it needs. This started as an MCP server, then deliberately moved to a CLI ochist plus an Agent Skill . Reasons: The agent already has a shell. With a CLI, the agent composes ochist grep … | head , | wc -l , | grep -i error , | jq itself. An MCP server would have to anticipate and hard-code every such option as tool parameters. The shell is the query language. Context control belongs to the agent. Paging/filtering with head / grep lets the agent pull only what it needs. An MCP tool tends to return a fixed blob; you re-implement pagination server-side and still over- or under-fetch. Zero resident cost. An MCP server is a long-lived process attached to the session and its tool schemas occupy context every turn . The CLI runs only when invoked — no daemon, no idle token overhead. A Skill teaches MCP exposes when and how . capabilities ; it doesn't tell the agent the workflow. The bundled skill encodes "check history before re-researching" and the locate → orient → scan → read recipe — guidance MCP can't carry. Portable & inspectable. One binary works in any agent that can run shell commands, plus humans can run the exact same commands and see the exact output. No transport, no protocol, no per-client wiring. Easy to extend. Adding an agent or a flag is a normal code change; there's no tool-schema/permission round-trip. MCP is a great fit for capabilities an agent can't otherwise reach remote APIs, privileged actions . Here the data is local files the agent can already read with a shell , so a CLI + Skill is simpler, cheaper, and more flexible. agent-historian mostly exists to fill a gap: agents persist rich session data locally, but don't expose a first-class way to search and read it back . OpenCode has session list no message/part reader ; Claude Code only has interactive --resume ; Qoder's SDK can resume/continue but not read history. The cleanest end state is for the agents themselves to ship this: - A read command, e.g. opencode message get