It started with Twitter. Patrick had been using Birdclaw, Peter Steinberger's local Twitter cache. Birdclaw keeps a copy of your Twitter data on your own machine, so you can search and query it without sending yet another request to X and bumping into rate limits. That turned out to be really handy. His own Twitter data was suddenly something he could actually use.
Which raised the obvious next question. If a local copy of one source is useful, what about a local copy of everything? Email, calendar, Twitter, browser history, the stuff he was reading, what was going on around his home lab. His phrase for the goal was something close to "as much context as I would receive as a human." Hand that to an agent and maybe it gets a feel for what he's been seeing lately.
That idea became Spool.
Spool got built: source plugins, a local event store, queries, monitors, agent tools, even a system that grouped events into stories. What never showed up was a good reason to use it. The data was noisy, the groups were noisy, and in the end a separate bot plugin took over the job by asking the sources directly when it needed something.
Birdclaw, but for everything
Birdclaw has a nice, tight boundary: it's about Twitter. It pulls records into a local SQLite database and gives you search and a few other workflows over that one pile of data. Birdclaw's project page covers the local cache, archive import, and rate-limit-aware sync. You have questions about your Twitter activity, and now you can answer them locally without waiting on X.
Spool kept that pattern and widened the source list. The first version of the code had connectors for Birdclaw, RSS, and email. Later ones added browser history, GitHub activity, local files, webhooks, calendar data, messages, and home lab events. A source plugin publishes an observation (a saved tweet, a page visit, a calendar entry, a server event) and Spool stores it with a source, type, key, time, title, and JSON payload in a local SQLite store.
Here's a made-up record in that shape:
{
"source": "github",
"type": "release.published",
"key": "demo:release:1",
"title": "Agent tool version 2.1 released",
"observedAt": "2026-09-24T04:00:00Z",
"payload": { "repository": "example/agent-tool", "version": "2.1" }
}
The GitHub plugin is the only thing that has to know what a GitHub release is. Anyone reading the stream can filter on source and type without ever touching GitHub's API. A browser visit or a saved tweet fits in the same shape.
That's the nice part. The catch is that a common format makes everything equally accessible. It doesn't make everything equally important. Keep that in mind, because it comes back.
The pitch was to stop redoing integration work. Collect a source once and let lots of things use it. A person could browse the stream. A script could follow new events. An agent could pull recent context. A monitor could fire off a new event when a saved rule matched.
A conceptual diagram of Spool's publisher and subscriber model, drawn for this article. It contains no personal data and is not a screenshot of the app.
There was a fair amount of plumbing under that diagram:
- Repeated observations were deduplicated by source and key.
- Consumers could replay history, subscribe to new events, and save a checkpoint so they knew where they left off.
- The store kept a rolling window. Older rows were exported to local JSONL backup files, then deleted.
- Every source started disabled and had to be turned on explicitly.
That last one matters more than it sounds. When the possible sources include private messages and browsing history, collection should be something you choose, not something that just happens.
Then there's the question of how you actually look at all this. One early conversation asked what a Bloomberg terminal for tech and AI would look like: dense screens, charts, keyboard navigation, fast ways to poke at a stream. Patrick tried desktop and terminal interfaces. The current version has a browser UI where you can inspect events and check on sources and consumers. The UI work was real work. But a denser screen full of observations still leaves you staring at it asking, okay... now what am I supposed to do with this?
One stream, two jobs
Spool was trying to do two different things.
Job one: help an agent understand Patrick. Some sources fit this well. The posts he liked or bookmarked, the sites he visited, the messages he sent, the meetings on his calendar. Even these are only clues though. A browser visit doesn't mean he read the page. A tweet in his timeline doesn't mean he saw it. Spool's own source guidance spells this out, because a row in a database can't tell you whether anyone was paying attention.
Job two: watch for things he'd miss. This one looks more like event monitoring. A service falls over, a new release ships, some news item is worth knowing about even though Patrick never came across it. Spool had saved monitors and derived events for exactly this. Think Datadog more than personal memory: sources send events, a consumer decides when to alert or summarize.
Both jobs run on events, but they ask very different questions:
- "What has Patrick been looking at?" needs a careful account of what he was actually exposed to.
- "What changed while Patrick wasn't looking?" needs relevance, priority, and some idea of what to do about it.
Dumping news sites, Twitter, Reddit, email, browser history, and home lab activity into one store doesn't answer either question for the agent. Mostly it takes several different flavors of noise and puts them in the same bucket.
This is where the Birdclaw comparison starts to fall apart. The Twitter cache was useful because Patrick already had questions about Twitter. A cache of everything doesn't come with questions attached. In his words, "I didn't have a solid use case" for all of that data. The collection machinery could be perfectly fine while the reason for collecting stayed fuzzy.
Looking for signal in the pile
Search alone wasn't going to cut it, so Patrick tried grouping events to see if patterns would pop out.
Spool has a clustering tool with two modes: a local lexical one, and a hybrid one that can use embeddings. You point it at some sources and a time window, it scores how similar the events are, and it returns groups with references back to the events inside them. A separate Briefing plugin can take selected groups and turn them into a rolling editorial page.
The clustering isn't naive either. It accounts for duplicate items that show up inside digests, keeps its candidate windows bounded, and tries not to glue two unrelated stories together just because they share one word. The briefing step can reorder stories, merge them, drop them, and attach evidence links.
Agents got in through a Spool MCP server and a BB plugin that explains the query tools and their limits.
A staged capture from Patrick's public BB Spool plugin. It shows how a BB agent could be given read-only access to Spool. It is a setup screen, not evidence that the resulting briefings were useful.
And the clusters? Noisy.
Better grouping code can't fix what goes into it. External feeds could flood the system with news that was only sort of relevant. Personal activity and server events mean completely different things. A group of similar-looking items isn't the same as something Patrick wants to know about, and it certainly doesn't show that the agent understands why he'd care.
To be clear, the clustering worked in the sense that it was built and it ran. Patrick's complaint is about whether it was useful. The groups didn't help him make a decision or notice a pattern he'd otherwise miss.
What replaced it
Meanwhile, Patrick was building a separate bot plugin. He had a channel for updates and briefings, and the agents in it each watched a specific area. When they needed information, they went and got it from the underlying systems. No standing copy of everything required.
For what he wanted those bots to do, that was just simpler. The goal all along was agents that stay informed and tap him on the shoulder when something is worth noticing. A bot with a defined area to watch could fetch the right thing at the moment it needed it. Meanwhile the big cache was still asking to be paid for: collecting, storing, cleaning, and interpreting everything ahead of time. For his use, Spool was obsolete.
How that bot plugin works deserves its own article, so that's all about it for now.
Where Spool still fits
This is about Patrick's use, not a verdict on event streams. Spool's event machinery could still do a real job with a known source and a known consumer. Where it went sideways was collecting personal context first and hoping a purpose would show up later.
Birdclaw solved a problem Patrick already had, with one source that made sense on its own. Spool could swallow lots of sources, but the bigger pile never gave him an answer that useful.
Before hooking up another source, Patrick would need a job for its records. An agent briefing him on a specific area can fetch from that source when it needs to. A cache earns its keep when repeated access, rate limits, replay, or event timing call for one. Collecting everything up front didn't give his agents better judgment. It gave them more to sift through.