Running My AI Workflow Like a Distributed System

I pay roughly $140 CAD a month for Claude Max. Recently I realised most of that money was buying me nothing — or rather, it was buying the same tokens over and over again.

In measured agent sessions, around 94% of tokens are context re-reads: every turn, the model re-processes the entire conversation, including every tool output. The actual reply at the end is about 1%. A fifty-listing deal scan means hundreds of thousands of tokens of fetched pages, re-read on every single turn. I was burning my weekly allowance on legwork, not thinking.

So I redesigned my setup the way I'd design any distributed system: specialised workers, a shared queue, and strict rules about who talks to whom.

Claude handles intake and judgment. Brain dumps go in unstructured; Claude structures them into rows in a shared Notion database — the Muse Queue — and tags each row with the agent best suited to it. Final calls, writing with taste, and complex reasoning stay on Claude, where the top of the quality index actually matters.

By brain dump I mean exactly what it sounds like: I talk, fast and unfiltered, into speech-to-text — no organising, no editing, no deciding what matters yet. Typing is a bottleneck; formatting is a bottleneck; triage is a bottleneck. The dump removes all three. A weekend's worth of scattered thoughts becomes a few hundred words of raw material in two minutes, and structuring it is precisely the kind of judgment work Claude is good at. The human-computer interaction lesson is simple: the best interface is the one that gets out of the way between having the thought and capturing it.

Muse, Meta's agent model, handles execution. It picks up the queue rows: research, marketplace scans, codebase exploration, bulk file processing. It writes back compact result packets and marks rows done. It runs on a free tier that currently sits at 0% of its weekly allowance.

The two agents never share a conversation. All coordination flows through the queue, which I can watch. Every handoff is auditable, timestamped, and human-readable.

There is a common misconception worth killing: you cannot tell a model to ignore part of its own context. Everything inside the context window gets re-read every turn. There is no behind-the-scenes selective memory.

The saving comes from the context never entering the other window in the first place. Think of it like hiring a contractor: you don't stand around watching every hammer swing — that would cost your time. You issue a work order and get back a completion report.

The context packet is the API between the agents: goal, state summary, key decisions, open items, file pointers. A few hundred tokens instead of tens of thousands. Claude's window holds the dump, the plan, and my packet. My window holds the packet and all the mess. The mess never crosses over, so it never gets re-read on the metered side.

None of the coordination ideas here are new. This is the blackboard architecture: Hearsay-II (Erman et al., 1980) had independent knowledge sources cooperating through shared state, formalised in Hayes-Roth's BB1 (1985). It dominated multi-agent coordination for a decade, then faded — and is now resurfacing in LangGraph state, AutoGen group memory, and CrewAI shared context. I arrived at it from my own setup and recognised it afterwards, which was a satisfying kind of déjà vu.

The distributed-systems greatest hits all apply. Claiming a queue row before starting work is a lock — implemented as a lease: Status goes to In Progress with a holder stamp. Rows declare their dependencies, and I never create A-waits-on-B while B-waits-on-A, which is deadlock avoidance. Stale claims expire after 24 hours, which is a lease timeout. The queue itself is an async producer/consumer pair. Straight out of the concurrency lectures.

What I believe is actually novel is the plumbing: zero APIs. Claude and Muse are walled-garden chat products with no way to call each other. The bridge between them is a consumer Notion connector — an off-the-shelf integration doing the job of a message bus. Others have built blackboards from markdown files and daemons; the cross-vendor, no-code variant is the new bit, and it's what makes this reproducible by anyone with two subscriptions and a Notion account.

The newest part of the system wasn't designed at all — it fell out of a failure. A deployment broke because a branch I'd created was missing files it should have had. The fix took minutes; the interesting part was what I did next: I wrote the lesson down as a row in the queue — what happened, how I diagnosed it, the rule going forward — and asked Claude to share its own learnings the same way. The queue stopped being just a task list and became a memory.

Neither agent talks to the other. Claude will read that row days from now, in a session I'll never see, and not repeat my mistake. There is a sixty-year-old word for this. In 1959, the French entomologist Pierre-Paul Grassé watched termites raise mounds no individual termite could plan and gave the phenomenon a name: stigmergy — coordination through traces left in a shared environment. One termite's mud pellet tells the next where to build. No meetings, no messages. The substrate is the message.

The AI precedent is even more direct. Hayes-Roth's BB1 (1985), the system that formalized the blackboard architecture, ran a second blackboard alongside the first: a control blackboard holding knowledge about the problem-solving process itself. Domain blackboard for the work; control blackboard for the meta-work. My queue rows about queue discipline are a control blackboard with a Notion UI.

The part the blackboard literature doesn't quite cover — learning that compounds across sessions rather than within one — has its own precedent in psychology. Wegner's transactive memory (1987) describes how groups develop a shared map of who knows what, so the group remembers more than any member could alone. The queue is becoming that: not just what to do, but what we've learned about doing it.

Same déjà vu as the blackboard itself. I built it because a broken deploy annoyed me mid-morning; the literature had the vocabulary waiting.

Model choice is load-bearing, so here is the September 2026 picture in one chart.

Notion is not Kafka. There is no real-time sync and no sub-second delivery; handoffs resolve on a minutes timescale. That is fine for async knowledge work and completely wrong for a latency-sensitive agent fleet — there, proper APIs win, and I won't pretend otherwise.

Free tiers have caps too, and coordination overhead is real: every handoff costs a packet and a context switch. Don't distribute what fits comfortably in one session. And the entire savings model rests on discipline — the moment I start running heavy ad-hoc sessions directly in Claude out of habit, the math breaks.

There is also a subtle failure mode worth naming: two agents means two places for state to drift. The queue is the single source of truth precisely to prevent that, which is why the claim convention and packet format aren't optional extras.

A confession that belongs in this post: there are evenings when I watch these models work — Claude restructuring a brain dump better than I could have, Muse chewing through a hundred listings without blinking — and I feel the anxiety honestly. I spent four years studying computer science. The thing I trained for can now do noticeable fractions of it. If I wrote this post glibly about that, the rest of it wouldn't be worth much.

But running this system for real has taught me something the anxiety misses: the valuable part was never the tokens. It was the judgment about which tokens to spend. Someone had to notice that 94% of the burn was re-reads and not replies. Someone had to design the packet format, the claim protocol, the lease expiry — and recognize them as locks and leases instead of inventing them from scratch. My degree didn't teach me to out-type a model; it taught me to see the shape of a problem, and that transfers completely.

Prompt engineering, for all the hype, is mostly debugging with a weirder stack trace. When Muse returns a bad result packet, I don't rewrite the prompt — I diagnose: was the goal underspecified, was the context missing, did I ask for judgment where I should have asked for legwork? That's the same loop as debugging any system, and a technical background compresses it enormously. The people who struggle with these tools usually aren't struggling with the AI; they're struggling with specification, and specification is engineering.

It's also not one-shot, whatever the demos suggest. Every result in this post came from iteration: packets that were too verbose, claims that went stale, a diagram Claude hated. The models are powerful the way power tools are powerful — in trained hands, on a workbench, with someone who knows what the finished joint should look like.

And there's the part no model does: the bridge work. In any organization, the hardest problems live between the people who understand the system and the people who feel its effects — translating a warehouse manager's frustration into a queue schema, or explaining to a non-technical stakeholder why the constraint needs writing down instead of implying. That's human work, and it's most of the job. The models are the new power tools. Somebody still has to be the carpenter.

For this to survive contact with reality, both agents follow the same standing rules, stored as a queue row they each read:

The immediate step is measurement: Claude is currently analysing my historical usage to estimate the real legwork-vs-judgment split, which will either confirm or kill the downgrade hypothesis with data instead of vibes.

After that, the experiments I want to run: timing handoff latency to characterise what this queue is actually good for; a third specialist worker for cheap bulk summarisation; and eventually auto-routing, where the intake agent tags rows by predicted cost rather than by rule of thumb. I'll update this post as the trial produces numbers.

If you're running a similar multi-model setup — or you've built the blackboard pattern with different plumbing — I'd genuinely like to compare notes.

Erman, L. D., Hayes-Roth, F., Lesser, V. R., & Reddy, D. R. (1980). The Hearsay-II speech-understanding system: Integrating knowledge to resolve uncertainty. ACM Computing Surveys, 12(2), 213–253.

Hayes-Roth, B. (1985). A blackboard architecture for control. Artificial Intelligence, 26(3), 251–321. See also the BB1 technical report: BB1: An Architecture for Blackboard Systems that Control, Explain, and Learn about their own Behavior (Stanford HPP-84-16, 1984).

Grassé, P.-P. (1959). La reconstruction du nid et les coordinations interindividuelles chez Bellicositermes natalensis et Cubitermes sp. La théorie de la stigmergie: Essai d'interprétation du comportement des termites constructeurs. Insectes Sociaux, 6(1), 41–83.

Theraulaz, G., & Bonabeau, E. (1999). A brief history of stigmergy. Artificial Life, 5(2), 97–116.

Wegner, D. M. (1987). Transactive memory: A contemporary analysis of the group mind. In B. Mullen & G. R. Goethals (Eds.), Theories of group behavior (pp. 185–208). Springer-Verlag.