The Tools Behind the Blog Curator

July 24, 2026 / waniwira / #opencode#agents#tools

In my previous post, I built a blog-curator agent — a specialized editor that analyzes session logs and generates blog drafts through collaborative discussion. That post covered the agent's workflow, persona system, and interactive design.

But it didn't cover how the agent actually reads session data.

That's what this post is about. And how two simple tools turned out to be more powerful than I expected.

New here? Start with the blog-curator-agent post for context on what the agent does.

Why the Blog Curator Needed Tools

The blog-curator's job is simple: analyze a session, find interesting topics, and help write a blog post about them.

But to do that, it needs to read session data. Not just the current session — any past session. Sessions with hundreds or thousands of parts. Sessions that have been compacted multiple times.

The challenge: how do you give an agent access to that data without blowing up its context window?

If you load everything, the agent drowns in information. If you load too little, it misses the story.

I needed tools that let agents scan smart — wide at first, then zoom in where it matters.

The Python Days

The first version was a Python script. Three modules:

tools/db_query.py — query the session database
tools/log_parser.py — extract patterns from conversation logs
tools/content_generator.py — format research into blog drafts

It worked. But it was fragile.

sys.path hacks everywhere. Every entry point had to do sys.path.insert(0, parent_dir) to import from the tools directory. A common Python problem — and a common source of bugs.

No type safety. A wrong parameter type would only surface at runtime. In a script that runs once, that's fine. In a tool that agents call repeatedly, it's a liability.

Shell-out overhead. OpenCode doesn't expose Python modules as native tool calls. The agent had to run python -c "..." to invoke the tools. Every function call became a subprocess spawn.

Not reusable. The tools were coupled to the blog-curator's workflow. Adding another agent meant re-implementing the same logic.

The lesson: tools should be shared infrastructure, not one-off scripts.

The Native Tools

The solution was to build two native OpenCode tools: oc_session_db and oc_session_log.

Source code: wiradharma/opencode-session-tool — Apache-2.0 licensed, ready to install.

I wasn't the first to think of this. There are several existing plugins that query the OpenCode session database. Some have 18+ tools for searching, summarizing, and analyzing sessions.

What I wanted was different: not just reading session data, but analyzing it. The raw query tools are useful, but the real value is in the extraction layer — turning conversation logs into structured insights.

No subprocess. No imports. No hacks. Just call the tool.

`oc_session_db` — Query the Session Database

Nine actions for reading session data:

Action	What it does
`search_sessions`	Find sessions by keyword
`get_sessions_list`	List sessions with pagination
`get_session`	Get session metadata
`get_session_parts`	Get conversation parts (with offset/limit)
`get_session_overview`	Get summary stats (part counts, types)
`get_todos`	Get agent task tracking
`get_events`	Get system events (timing, token usage)
`get_session_input`	Get user prompts
`get_project_info`	Get project metadata

`oc_session_log` — Analyze Conversation Logs

Four actions for understanding what happened:

Action	What it does
`parse_session`	Parse full session into structured turns
`extract_conversation_flow`	Extract the back-and-forth between human and AI
`extract_decisions`	Find key decisions made during the session
`extract_collaboration_patterns`	Analyze how human and AI worked together

That's it. Thirteen actions total. Enough to read any session, analyze any conversation, and find any story.

How the Agent Uses Them

The key insight is strategy, not implementation. You don't need to read everything. You need to read smartly.

Here's the pattern I use:

Step 1: Know What You're Dealing With

Start with get_session_overview. It tells you:

How many parts the session has
What types of parts (text, reasoning, tool calls, compactions)
The time range

This takes one tool call. Now you know if you're dealing with a 50-part session or a 2,600-part monster.

Step 2: Scan Wide, Load Light

Use extract_conversation_flow with offset and limit. This returns a summarized view of the conversation — the back-and-forth between human and AI — without loading every tool call and reasoning trace.

By hopping through with different offsets, you can scan a 2,600-part session in 5-6 tool calls. You'll see the topics, the flow, the key moments.

Step 3: Zoom In Where It Matters

Only when you find something interesting do you use get_session_parts to load the raw details. This is the expensive call — so use it sparingly and with small windows.

The Pattern

Overview (1 call)
  → Flow scan (5-6 calls with offsets)
    → Targeted parts (2-3 calls for specific sections)
      → Done (8-10 calls total)

A 2,682-part session. Fully analyzed. In under 10 tool calls.

What I Didn't Expect

When I built these tools, I had a simple goal: let the agent read session data. I didn't expect to find more.

Compaction Doesn't Destroy Data

OpenCode sessions get compacted — the conversation history is summarized to save context window space. I assumed compaction meant the original data was gone.

It's not.

The original conversation parts are still in the database. Compaction adds a summary message but doesn't delete anything. The agent can still read the full, unabridged conversation from any compacted session.

This means agents can work with sessions that are "old" or "compacted" — the data is always there.

Sessions Are Analyzable at Scale

I didn't expect the tools to work this well at scale. A 2,682-part session felt like it would be too big to process efficiently.

But with the scan-wide-then-zoom strategy, it's not a problem. The tools are designed for pagination. The extraction tools give you summarized views. You only load the heavy data when you need it.

Events Contain Hidden Gold

The get_events action returns system events — things like message creation, tool calls, part updates. I didn't expect much from it.

But inside those events is timing data (when each part started and ended), token usage (input, output, reasoning, cache per step), and tool call details (what was called, with what input, what output).

This means you can analyze not just what happened in a session, but how efficiently it happened. How many tokens did the AI use per step? Which tool calls were the most expensive? Where did the AI spend most of its reasoning budget?

These weren't designed features. They're just what happens when you have good data access.

Why This Matters

This isn't a revolutionary idea. Others have built similar tools — some with more features and more stars.

What I found useful is the analysis layer. Raw session data is noisy — thousands of parts, tool calls, reasoning traces. The extraction tools turn that noise into structure: conversation flow, decisions, collaboration patterns.

Any agent that needs to understand past work could use this approach. A video-curator could analyze sessions where videos were discussed. A code-reviewer could find sessions where specific files were changed. A project-manager could track decisions across multiple sessions.

The session database keeps growing. Every conversation, every tool call, every decision — it's all there. The question is whether agents can make sense of it.

These tools are one answer to that question. Not the only one — but a useful one.

The plugin is available on GitHub if you want to explore the implementation or use it in your own agents.

This post is part of a series. See the blog-curator-agent post for the agent workflow and design.