Most multi-agent posts show you a demo. This one shows you a product you can open right now: writehive.netlify.app. It's a full word processor — WriteHive — and we built and shipped it with Claude in a single working session. Not a prototype that "will be productionized later." The thing that went live that day is the thing taking payments.
This is a field report on how the build actually ran: how we split a word processor across six Claude agents working in parallel, why they finished with zero integration conflicts, and the one architecture decision that made the whole thing boring in the best possible way.
Why a word processor
A word processor is a brutal test for AI-driven development, which is exactly why we picked it. It's not a to-do app. It has a rich-text editing surface, file format work that punishes hand-waving (DOCX is zipped OOXML — you either produce valid XML inside a valid zip or Word refuses your file), import parsing across half a dozen formats, local persistence, licensing, and — because we wanted a reason for the "Hive" in the name — a wireless multi-device document server.
It's also a product category with a very visible incumbent charging $179.99 for a standalone license, which gave us a clear commercial target: ship a real alternative at a one-time price, no subscription, and see if one session of coordinated Claude agents could produce it.
The contract comes first
The failure mode of parallel agents is well known: two agents touch the same file, or agent B builds against an API that agent A decided to rename an hour ago. Merge hell, but faster.
So before any agent wrote a line of feature code, we wrote the interface contract — a short document that defines, for every module: the file it lives in, the single global it exposes, the exact function signatures on that global, and the custom events it emits and listens for. The contract is the only shared artifact. It looked like this (excerpted):
// CONTRACT — every module obeys this, nobody edits another module's file
window.WHEditor = { getHTML(), setHTML(html), getSelectionText(), insertAtCursor(html) }
window.WHDocs = { list(), load(id), save(doc), del(id) } // IndexedDB inside
window.WHExport = { toDocx(doc), toPdf(doc), toMd(doc), toHtml(doc), toTxt(doc) }
window.WHImport = { fromFile(file) -> {title, html} } // docx/pdf/txt/md/html/rtf
window.WHSkills = { run(skillId, text, apiKey) -> Promise } // BYOK, browser -> Anthropic
window.WHLicense = { isPro(), activate(key) }
// Events, not calls, for anything cross-module:
document.dispatchEvent(new CustomEvent('wh:doc-saved', { detail: { id } }))
document.dispatchEvent(new CustomEvent('wh:doc-loaded', { detail: { id } }))
document.dispatchEvent(new CustomEvent('wh:pro-changed', { detail: { pro } })) Each agent got the full contract, its own module assignment, and one hard rule: you own your file, you implement your global exactly as specified, and you never reference another module's internals — only its contract surface.
Six agents, six modules, one session
The split fell out of the contract naturally:
- Editor agent — the contentEditable editing surface, toolbar, formatting commands, fonts.
- Storage agent — document CRUD on IndexedDB, so everything is local-first and works offline.
- Export agent — the hard one. Real OOXML: it builds
document.xml, the relationship parts, and the content types manifest, zips them, and produces a DOCX that Microsoft Word opens without a repair prompt. Plus PDF, Markdown, HTML, and plain-text export. - Import agent — DOCX, PDF, TXT, Markdown, HTML, and RTF in; normalized HTML out, per the contract's
{title, html}shape. - Skills agent — 12 AI writing skills powered by Claude, called straight from the user's browser with their own Anthropic API key. BYOK means the product never sees the user's text and never marks up their tokens. No middleman server to build, secure, or pay for — which is also why this module could be built in parallel with zero backend coordination.
- Hub agent — the Hive Hub: a 0.6MB zero-dependency Node script that turns any PC into a wireless document server. Every laptop on the same Wi-Fi opens one address and gets the full app plus a shared, live-syncing document drive — SSE for live updates, ten-version history per document, and an optional mirror folder for automatic second-copy backup to a USB drive or NAS. No switch, no server rack, no cable to every machine.
Stripe licensing rode along with the skills/licensing surface: a free-forever tier, and a Pro unlock at a one-time price with a plain license key — no account required.
Integration, the part that normally eats a day, took one pass: load the six files, click through the flows. Zero conflicts. Not "a few small ones we fixed quickly" — zero, because the architecture made the collision class structurally impossible. No two agents ever had a reason to edit the same file, and every cross-module touchpoint had been frozen before the build started.
The insight: globals + events don't collide
Here's the part worth stealing, and it's going to sound like 2011: modules as window globals, coordination through custom DOM events.
Modern JS instinct says use a bundler, use ES modules, share typed imports. That's right for human teams iterating on one codebase over months. It's wrong for parallel agents in one session, because imports create compile-time coupling: the moment agent A's export shape drifts, agent B's module breaks at build time and someone has to arbitrate. You've reintroduced the merge conflict one level up.
Window globals with a frozen contract invert this. Each module is a self-contained script that attaches exactly one object to window. The contract is enforceable by inspection — you can diff an agent's output against the contract in seconds. And custom events give you cross-module reactions with zero knowledge of who's listening: the storage agent fires wh:doc-saved without knowing or caring that the UI updates a saved-indicator when it hears it.
This is the same principle behind microservices and API-first teams, compressed into a single HTML page. Agents are extremely good at implementing a precisely specified surface and extremely expensive to supervise when the surface is fluid. Freeze the surface, and supervision drops to "check the contract, click the buttons."
What actually shipped
Same-day, live at writehive.netlify.app:
- A full editor with local (IndexedDB) documents that works offline.
- Imports: DOCX, PDF, TXT, Markdown, HTML, RTF.
- Exports: real Word-compatible DOCX, plus PDF, Markdown, HTML, and TXT.
- 12 Claude-powered writing skills, BYOK — your API key, your text, no middleman, no markup.
- The Hive Hub LAN document server (free tier covers 2 devices).
- Stripe licensing: free forever tier; Pro at $44.99 one-time — exactly 75% under Word's $179.99 standalone license — with a 30-day refund promise.
Honest caveats, because field reports that skip them are ads: one session got us to shipped, not to finished — a word processor accretes polish forever. The contract pattern also has real limits: it fits products that decompose into modules with narrow surfaces, and it trades away the type-safety and tree-shaking a bundled codebase gives a long-lived human team. We'd make the same trade again for any one-session, parallel-agent build. We would not run a fifty-module codebase on window globals.
The takeaway
The lesson isn't "Claude can write a word processor." The lesson is that parallel agents are an architecture problem, not a prompting problem. Write the interface contract first, give each agent a file it owns and a surface it must honor, coordinate through events instead of imports — and the scariest part of multi-agent development, integration, quietly disappears.
If you want to try the workflow before betting a product on it, start where we make you spend nothing: the free context-budgeter skill is a complete, working ClaudeFarm crop given away so you can judge the quality of the paid ones — and the Skill Farmer's Toolkit ships the production skills our own agents ran during this build. One payment, no subscription. Same as WriteHive.