Workflow Systems

A self-updating research thesis on multi-agent cost economics, built by a pipeline that watches YouTube talks and papers and extracts the evidence for me.

OngoingHigh priority
The problem

The problem

Every team building multi-agent systems right now hits the same unexamined choice: what model do you put in each seat? The default instinct is to run the frontier model everywhere, because that’s the safest-feeling option, and it quietly triples or quadruples the bill. The opposite instinct — downgrade everything to save money — risks losing the judgment calls that actually matter. Nobody was collecting the evidence on which parts of an agent pipeline actually need the expensive model and which don’t; it was all folklore and vibes from whoever’s Twitter thread you read last. That’s a real cost-control problem for any org running agents in production, not just a personal curiosity, and it only gets more expensive as agent fleets scale from one orchestrator with a few workers to dozens of parallel workstreams.

The approach

The approach

This project is a living thesis, not a one-off note: “spend model intelligence on orchestration and planning, not execution, and the execution fleet can be much cheaper with almost no quality loss.” What makes it more than an opinion is how it’s assembled. It runs inside CogitOS, a research pipeline I built with a real dashboard (a Textual TUI) that scans curated YouTube channels and dropped links, pulls transcripts, and runs an LLM idea-extraction pass that turns a 40-minute talk into discrete, evidence-cited claims — each one keeps a pointer back to the source video and timestamp. A second pass (the dashboard’s “auto-route bag ideas” action) reads each new claim and decides, heuristically plus one LLM call, whether it belongs to an existing project thesis or should flag a new one; ideas that match get filed as attached context, never as a task, so the project accumulates evidence without accumulating busywork. The workflow-systems project is what that pipeline produced after routing 16 sources — 14 talks plus one arXiv survey — that all converged on the same design principle from different angles.

What’s actually in it: concrete, named case studies, not abstractions. Fable orchestrating Sonnet sub-agents matched Fable orchestrating Fable sub-agents in quality, at a fraction of the cost. A team running Kimi K3 as a $24-total orchestrator directing GLM, MiniMax, and DeepSeek workers to build a 24,000-line app, where the orchestrator itself had the lowest per-model spend on the team. A three-tier architecture (orchestrator, team leads, workers) with flat peer-to-peer communication instead of a single relay bottleneck. A jury-of-analysts-plus-judge pattern for decisions with no single correct answer. A fraud-detection system that fans a decision out to two specialist agents and a verdict agent rather than trusting one agent’s solo read. Each case is a distinct instantiation of the same underlying bet, and the project folder keeps them all traceable back to their original source, so I — or anyone else — can go re-verify any specific claim rather than trusting my paraphrase of it.

What I learned

What I learned

The headline finding holds up every time it’s been tested head to head: an expensive orchestrator paired with cheap workers gets you nearly the same quality as an all-expensive fleet, at a fraction of the cost, because the hard part of agent work is decomposing the problem and catching failure — judgment calls — while most of what workers actually do (call an API, write a file, summarize a chunk) is mechanical. The corollary that surprised me more: orchestration itself should be the cheapest line item on the token bill, not the most expensive, because a good orchestrator does short reasoning passes and dispatches — it’s the execution layer that burns the tokens. The meta-lesson, about the pipeline itself, is that letting an LLM auto-route new evidence to the right existing thesis, instead of me manually filing it, is what made this collection possible at all — I wasn’t going to manually cross-reference 16 talks against a growing set of project theses, and the auto-router did it correctly without me hardcoding any matching rules.

Where this could go

Where this could go

The direct next step is testing the thesis on my own pipelines — right-sizing which of CogitOS’s own LLM calls actually need a frontier model versus a cheap one, using the same evidence I’ve collected here. But the pattern generalizes past my own workflow: any engineering org running agent-based automation at scale — a platform team building an internal agent framework, an AI-ops group setting model-routing policy, a company deciding whether to standardize on one frontier model everywhere — faces exactly this cost-allocation question, and most are still deciding it by instinct rather than evidence. The receipts pattern that shows up in one of the collected talks, where every workflow step produces a signed, verifiable artifact, points at where this goes next for teams that need to trust agent output across organizational boundaries, not just within one pipeline. And the collection mechanism itself — watch sources, extract atomized evidence-cited claims, auto-route to the right thesis — is a pattern any team doing continuous competitive or technical intelligence could run on their own inputs: support tickets, sales call transcripts, internal postmortems, not just public YouTube talks.

Takeaway

Takeaway

The interesting part isn’t just the conclusion about cheap execution fleets — it’s that I have a pipeline that keeps finding new evidence for or against it without me doing the reading, which means the thesis gets stress-tested continuously instead of being written once and left to go stale.

Text summarized and optimized using Anthropic’s models and reviewed by a human.