"The personal daemon was a semi-autonomous piece of software that lived in your system and acted as your agent, going out into the Cloud to do things for you." — Neal Stephenson, Fall, or Dodge in Hell

I have been quietly drowning in feeds for years. Not in a productive way — in the "I have 47 tabs open and three of them are arXiv" way. AI research, cloud infrastructure, smart-grid news. Each domain moves fast enough on its own; together they generate more credible signal than any one human can absorb.

The conventional answers all failed me in the same direction:

  • RSS turned into a noise factory the moment I subscribed to anything I actually cared about.
  • Google Alerts matched keywords without nuance — I'd get press releases and SEO sludge alongside the one paper I needed to read.
  • Manual curation worked, sort of, until any week got busy.
  • Paid intelligence services were generic and expensive, optimized for the median enterprise customer, not me. And - you know: $paid$

So a couple of weeks ago I started building a thing. I called it the Research Curation Daemon because I had been thinking about Stephenson's "personal daemon" idea for years, and the name fit: a small piece of software that lives on my machine and goes out into the cloud to do work on my behalf.

This is the first post in a series about how it came together. The thing I want to talk about first is the decision that has shaped everything since: why I built it as an MCP server instead of a script.

The deliberate detour

I started on a Sunday — September 27 — by writing prose. Not code. The first commit in the repo is a README and a CLAUDE.md and nothing else. The next day, September 28, I committed what I called the "baseline manual pipeline": prompts for each stage, a weekly-cycle document, and Python wrappers that mostly served as glorified copy-paste with logging.

The pipeline had four stages, each anchored to a tool I already used:

  1. Perplexity Pro as scout — saved queries against the domains I cared about, plus Collections to keep the results.
  2. Claude as synthesizer — credibility-weighted analysis, consensus and dissent extracted from the raw scout output.
  3. ChatGPT as orchestrator — cross-domain digest assembly, weekly cadence.
  4. NotebookLM as narrator — turn the digest into a podcast my future self would actually listen to on a dog walk or in the car.

I want to be clear about something: the manual phase wasn't an MVP I was ashamed of. It was deliberate. Doing every handoff manually forced me to write down what each stage actually needed from the previous one. Every prompt got versioned. Every credibility tier got documented. The weekly cycle got a checklist. By the time I stopped pasting things between VS Code tabs, I had a specification.

That spec is why what happened next took a day instead of a month.

The pivot

The same Sunday — September 28, 2025 — I committed Refactor claude_scout.py for dual-mode use and add MCP server scaffolding. By that evening I was on overhaul mcp_server. The next day, async job tracking. By Monday morning the manual workflow was effectively dead.

The thing that flipped was a small idea about abstractions. I had been thinking about the pipeline as a script that I would eventually run on a cron. Stage 1 produces files; stage 2 reads files; stage 3 reads files; somebody publishes the result. That mental model is fine, but it has a ceiling: the script automates me running the pipeline. I am still the dispatcher. The moment something breaks, I'm back at my keyboard.

MCP — Anthropic's Model Context Protocol — gave me a different abstraction. I appreciate their analogy describing MCP as "like USB-C for LLMs" - and I had just completed their introductory workshop on building a simple MCP client and server.

Instead of a script that I run, I could expose each pipeline stage as a tool that an LLM agent could invoke directly. The agent gets the same agency I have. I can say "run today's scout" in a chat window and the model picks the right tool, fills in arguments, calls it, watches the job, and tells me what happened. The orchestrator stops being me-and-my-script and starts being me-or-the-model, depending on which of us is paying attention.

That's the entire pitch. It's not really about MCP-the-protocol — it's about what it costs to give a chat agent cleanly-defined interfaces into the system. The protocol is just the mechanism that makes that cheap.

What the first three tools looked like

The initial server exposed exactly three tools:

  • trigger — kick off a Perplexity batch against today's query rotation.
  • scout — feed a day's exports through Claude with the credibility-weighting prompt.
  • synthesize — produce per-domain summaries from the scout output.

All three were async with job IDs from the start. This was non-negotiable, for a reason that's obvious in hindsight: a Perplexity deep-research query takes several minutes, and you cannot have a chat agent stalled on a synchronous call for that long. Whatever the agent calls returns immediately with a job ID; the agent calls back later to check status.

That single design choice — async-first — quietly turned out to be the foundation everything else was built on. Once jobs were first-class, I could add telemetry without surgery, run multiple stages concurrently, and eventually sit in my backyard and ask my phone how the pipeline was doing. But that's a later post.

What I'd tell someone considering this

If you're staring at a workflow you've automated with Python scripts, and you find yourself wondering whether a chat-driven version would feel different: yes, it does, and not in the way you expect. The win isn't fewer keystrokes. It's that the system stops being something you operate and starts being something you converse with. You stop dispatching and start delegating.

The cost of the shift is small if you've already worked out the process flow. If you haven't, do that first. The week I spent writing prompts and documenting handoffs by hand was the most leveraged week of the project.

What's next

This is post one. The threads I'd like to pull next, in roughly the order they'd be useful to someone building their own daemon:

  • Two pipelines, one source. Why I ran an analytical and a news pipeline off the same scout data, and what comparing their output revealed.
  • The day my Anthropic credit auto-reloaded silently. How I learned to treat FinOps as a first-class concern in a hobby project.
  • The daemon moves out. When MCP turns out to be the wrong host for a long-running stateful pipeline, and what changes when you extract the agent into its own process with its own HTTP front door.

The daemon is real now. It is running on a Mac Studio in my office, generating weekly briefings I actually use. The rest of the series is about how it got there, and what it cost to make each leg of the journey work.