Dispatch Was the Right Thing to Build

In February I built a TypeScript CLI called Dispatch. It is public, archived now, and still sitting on npm as @pruddiman/dispatch. The README describes it pretty plainly: an AI agent orchestration CLI that parses work items from GitHub Issues, Azure DevOps, or local markdown, dispatches each unit of work to a coding agent like OpenCode, GitHub Copilot, Claude Code, or OpenAI Codex, and commits the results with conventional commits. It fetched issues, generated structured specs, planned and executed tasks in isolated sessions, optionally split planning from execution, managed branches and worktrees, pushed commits, and opened PRs that could auto-close the originating issue.

I built it on paternity leave, mostly while the baby slept, to understand what agentic software felt like. I wrote the glue myself: issue ingestion, the provider abstraction, the planner/executor split, the git lifecycle, and the uncomfortable part where a model says something is done and the surrounding system has to decide whether that claim has earned any trust. If you want to understand a class of systems quickly, building the awkward middle layer is still one of the fastest ways to get there.

It worked, and then the ecosystem moved fast enough that I archived it roughly six months later. I don't mean "worked" in the exaggerated startup-launch sense; I mean it in the way that it did the thing I built it to do, giving me a concrete way to turn issue trackers and markdown checklists into agent-executed work, route the work across coding agents, and force the output through something closer to a software-delivery loop than a chat transcript. It also taught me which parts of agent orchestration are genuinely hard and which parts only looked hard because the platform had not built them yet.

The useful lesson is that Dispatch's value was mostly glue: it connected sources of work to agents, converted vague work items into specs, sequenced planner and executor phases, isolated tasks in sessions and worktrees, routed to providers, and managed branch naming, commit messages, pushes, and pull requests. All of that was necessary in February if I wanted the workflow I had in my head, but necessary is not the same thing as durable. Sometimes you build scaffolding because the platform has not built it yet, and if the platform is moving quickly, the scaffolding should be expected to disappear.

The obvious comparison is build tooling, where plenty of teams wrote bespoke scripts before the ecosystem absorbed the common patterns. That did not make the scripts stupid; it made them correct for their moment. The danger is conflating "this is valuable because nobody else has built it yet" with "this will remain valuable after the platform catches up." In February, the gap between coding agents and a full work-dispatch loop was big enough to justify a CLI. By June, skills and maturing harnesses had eaten enough of that gap that the right abstraction changed.

The skills part is the important shift, because today's harnesses already know how to spawn agents, give them tools, preserve workspace boundaries, run tasks in parallel, capture outputs, and keep the human in the loop. Skills like /batch and /fleet can express the orchestration pattern directly: take a set of work items, split them across specialized subagents, assign different models where it makes sense, collect the results, review them, and keep the system moving without building another wrapper on top of the harness. What took a TypeScript CLI in February can now be expressed as a natural-language capability loaded into the harness that already owns the sessions, tools, model routing, and safety boundaries.

This changes more than the ergonomics, because a wrapper CLI has to fight the harness at the seams with provider adapters, process control, state files, auth assumptions, retries, and enough git logic to avoid wrecking the user's repo, while a skill lives inside the harness instead of around it. A skill can describe the whole job in plain terms: how to decompose the work, when to spawn subagents, which model should review versus execute, how to collect evidence, and when to ask the human before the final report goes out. The same orchestration idea becomes less code because the platform underneath it has become more capable.

The part I gloss over when I tell this story is that Dispatch was not the frugal option. The glue itself was cheap, because the deterministic code that did the routing, parsing, branch setup, state management, and PR mechanics cost almost nothing to run, but the glue is not where the money went. Every work item triggered its own deep dive: a spec generation pass, a planner pass, and an execution agent, each one spun up in an isolated session that re-read the repo and rebuilt its context from a cold start. On bigger projects, that per-task fan-out drove token costs into the thousands. When I move the same workflow into the harness as a skill, I get a nicer abstraction and usually a more capable result, and because the harness already owns the sessions, tools, and loaded context, the subagents can reason over shared state instead of each one paying full freight to bootstrap itself from scratch.

That shift helps even when the budget is tight, because the harness version usually does less redundant work, which ends up mattering more than the smaller codebase. The part Dispatch never had is a main agent that holds the context for the whole job and just takes updates back from the subagents as they finish, so progress accumulates in one place everyone can reason against, and that shared, already-loaded context behaves like a free cache. I care more about learning the shape of the frontier than shaving pennies off each run, but it is worth being honest that the smaller abstraction turned out to be the cheaper one to run, which was not the tradeoff I expected going in.

OpenClaw makes the same point in my own daily setup. I run a mesh of sibling agents that do different kinds of work: writing, research, coding, product growth, monitoring, and whatever else I decide is worth carving into a repeatable loop. The useful new skill I wrote after Dispatch does not rebuild Dispatch as another CLI. It lets the harness create model-specific subagents, have them reason over pieces of the problem, talk to each other when that is useful, compare outputs, and come back with a synthesized result, all without pretending I need a bespoke TypeScript application to sit above the agent runtime. The orchestration moved from code I had to maintain into a skill the agent can load.

There is a temptation to tell this as an obsolescence story, but that framing misses the part I actually care about. Dispatch was not a failure because the platform absorbed it; it was evidence that I was building near the right seam. If you build something and the ecosystem catches up six months later, that can mean you wasted time, but it can also mean you were standing on the pressure point early enough to learn the lesson before it became obvious. In this case, I got the lesson I wanted: agentic software is less about one magic model and more about decomposition, context, tool rights, verification loops, and the boring lifecycle around the model's output.

The harder question is what to build next when the platform layer moves this fast, because if the thing you are building is glue between immature pieces, you should assume it may be absorbed. That does not mean you should never build glue; glue is often how you learn the system, and sometimes the market pays for glue for a while because the official version is not ready yet. It does mean you should be honest about the category. Build-to-learn glue is almost always safe because the durable asset is your understanding, especially if you can afford the extra inference while you are learning. Build-to-sell glue needs a sharper reason to exist, because the platform has every incentive to eat the common workflow once enough people prove it matters, and because a token-hungry orchestration layer becomes a margin problem well before it becomes a moat.

The durable pieces are usually somewhere else, in the data the platform cannot conjure, the domain workflow that is too specific to generalize cleanly, the distribution channel, the trust relationship, the compliance boundary, or the taste required to know what should be automated in the first place. Dispatch was glue, and it got commoditized, which I am glad about. I built it to learn something, and I learned it, and the ecosystem moved the way you want it to if you care about agent tools getting better quickly.

That changes how I think about my own work. If I am building something to understand a new layer, I am not worried about whether the code lasts, but if I am building something I expect to be a business, I am suspicious of anything whose main value is orchestrating generic model calls in a generic workflow, because the platform is coming for that. The question I ask now is whether the thing creates knowledge, data, distribution, or domain-specific judgment that survives after the harness gets better. Dispatch did not pass that test, and that is fine, because I did not build it to pass it; I built it to find out where the line between my code and the platform actually sat, and then the platform moved the line. What the work left me with is a sharper version of the question: which parts of a system are worth writing as deterministic code, which parts are cheaper to hand to a harness that already holds the context, and which parts were only ever scaffolding for the next six months.