This post is about how the Subfolio Anthropic + DeepSeek fan-out works, how the pipeline came to exist, and it didn’t start with a framework. It started with me doing subagent orchestration by hand, because I need to understand things before I use them. This is deprecated I will update it later.
Learning it by hand first
Before I could trust any harness to coordinate agents for me, I ran the orchestration manually. The setup was simple and deliberate: Claude (Opus 4.8) was the architect, the orchestrator, and the verifier. It wrote the architectural contracts, decided which tasks were mechanical enough to delegate, and reviewed what came back. DeepSeek got the easy, high-volume tasks: the work that needs instruction-following, not judgment.
On the Subfolio port, that meant Opus never touched the PHP theme views one by one. It defined the component contract and a reference implementation, then I fanned the per-file analysis and translation of the PHP and legacy code out to DeepSeek, work that ran on DeepSeek’s own API, not against the allotment Anthropic gives a $20/month plan. That’s the quiet superpower of the whole arrangement: the frontier model stays free for architecture and review, the volume work goes to a backend built for throughput, and the $20 plan accomplishes far more than it was ever supposed to.
That split has a name: the Gate and the Wave. Opus wrote the gate, meaning the architectural contract, the component prop API, and one reference component built end-to-end and never offloaded. DeepSeek’s waves followed it: parallel, mechanical tasks that imitate a decided pattern rather than make decisions. The gate is what made delegation safe, and nothing fanned out until it existed.
Doing this by hand was the point. Splitting tasks myself, watching where DeepSeek excelled (mechanical translation once the pattern was decided) and where it failed (it kept treating Astro like PHP when allowed near architecture, writing template expressions inside style blocks that fail the build) taught me what an orchestrator actually has to do before I ever handed that job to software.
The launcher that wires it together
The plumbing deserves its own mention, because Claude helped me build it and I now run it every day: deepclaude-launchagent, a macOS launcher I wrote for the open-source DeepClaude proxy. The proxy itself is someone else’s project. The launcher is deprecated. It runs the proxy as a macOS LaunchAgent with keys pulled from 1Password, points Claude Code at it, and pulls the wrong models. Oh well.
The gates, proven on real work
Phase 01 of my current build program ran the full cycle: 6 numbered plans, each producing a
PLAN.md before any code changed and a matching SUMMARY.md once it did. The verify stage
didn’t take the executor’s word for anything. Closing the phase meant re-running the test
suite, re-running the install-smoke TypeScript check, and reading the deployed Cloudflare
Worker’s own evidence files. The result: 5 of 5 success criteria confirmed, with the specific
evidence file cited for each one.
The code-review gate earned its keep the same way. Across 23 reviewed files it found 2 critical and 6 warning-level issues, including a live-request abort-signal wiring gap and a fallback path that could leave the UI stuck in an error state. Both critical findings were fixed in a follow-up commit, and the later verification pass confirmed the fixes were actually present in the code, not just claimed fixed in a commit message.
That’s the manual lesson, systematized: the orchestrator doesn’t trust the worker’s summary. It checks.
The source map behind every claim
Every number above, the plan counts and the review findings, traces to a real
file or a real git command, listed row by row in a companion source map
(docs/source-maps/2026-07-multi-agent-pipeline.md in the site’s repo). Two of my case studies
already carry the same kind of file, so the discipline is standing practice, not a one-off.
The rule cuts both ways. An earlier draft of this piece wanted to claim that different pipeline roles route to different underlying models, and couldn’t: no artifact showed it, so it stayed out. Then this task’s own plan and summary recorded exactly that split in their metadata, and only then did the claim get written. A sentence had to wait for its evidence.
What this buys, and what it costs
The upside is work that can be checked, not just trusted, and a $20 plan that behaves like a much bigger one, because the frontier model only ever does frontier work. The cost is real: writing a plan before a small fix, keeping a source map current, running a verification pass that re-checks the work instead of skimming a summary. For one person shipping solo, that overhead is the entire point. It’s the checkpoint a second engineer would otherwise provide, and I understand every layer of it, because I ran every layer by hand first. This is about maxing out moving session and weekly limits.