Dual-Agent Collaboration, Reviewed: The Engineering Method Behind an AI-Built Site

The website you’re looking at right now was built step by step from an empty directory by two AI agents working in tandem. But this article is not an operations manual — for the full first-time experience and the cost ledger, I’ve already written that up in “A CyanLabs Prototype from Scratch in 30 Minutes for Only $0.20.” What I want to talk about here is the more durable stuff: what did a real AI-built site teach me about working with AI, in methods that transfer anywhere?

---

First, the question underneath: why build a site at all

Methods serve goals, so let’s start with the why. The decision to self-host instead of dumping content onto an existing platform came down to four reasons:

1. Multi-topic narrative — AI and local compute, photography and optics, quantitative trading, everyday saving. Content spanning this much ground needs an architecture where each topic stands on its own under one brand. Off-the-shelf platforms can’t give you that freedom.
2. Extreme page performance — a static site’s pages load almost instantly. For a content site, that’s a real reading-experience and traffic lever.
3. Near-zero maintenance — pure static content on free static hosting means no servers to tend. A personal project can coast indefinitely.
4. Content as code — articles managed as structured files with strong type validation mean a misspelled field is caught before publishing, not shipped as a silent accident.

But as an indie developer, my scarcest resource is time. So the real question wasn’t “should I build it,” but “how do I build it with minimal engineering effort while keeping quality that doesn’t embarrass me?” That’s where dual-agent collaboration entered — and only later did I realize the truly valuable output wasn’t the website. It was the method it forced me to develop for getting engineering-grade work out of AI.

---

Why one AI isn’t enough: the split between directing and doing

Almost everyone hits the same wall the first time they put AI to real work: the same AI trying to be both the brain and the hands usually does neither well.

Conversational AI is a superb consultant — ideas, reasoning, plans, all delivered confidently. But ask it to actually sit in the file system, dutifully create dozens of files, and run commands until they succeed, and it tends to feel “not wired for that.” Conversely, an agent that genuinely operates your computer and directories excels at head-down execution — but ask it to also hold the global architecture in mind, and it drowns in its own details.

This isn’t a flaw of any particular model. It’s that the two capabilities genuinely interfere: global planning requires standing high; fine execution requires digging deep. Crammed into one context, each becomes noise for the other.

The fix isn’t a stronger AI. It’s a split:

One agent as the “commander-in-chief”: architecture decisions, task orchestration, running the pipeline, accepting deliveries — it stands high and stays out of pixel-level implementation. Another agent as the “welder”: one clearly-scoped, detail-heavy task at a time, done to a high standard — it digs deep and never touches the global picture.

The best metaphor is captain and welder: the captain sets the course, the welder finishes the welds. If the captain welded every seam, the global picture would drift; if the welder set the course, it would obsess over the perfection of one plate and forget where the ship is going.

---

Method 1: Contracts as types — move “correctness” somewhere it can be checked automatically

The thing that most unsettles people about AI output is “looks right, actually wrong.” Rather than proofreading by hand after the fact, make it impossible for errors to hide.

The first lesson of this build: content isn’t a loose pile of Markdown — it’s structured data with a contract. Every article must declare fields like title, date and category, with their types and allowed values defined up front. Whoever violates the contract gets rejected by the build command in red — it never reaches the “live” stage at all.

That mindset transfers to any AI collaboration:

• Define what the deliverable must look like (structure, fields, boundaries) before briefing the AI — never a vague “write me something nice”
• Anything a machine can check (format, types, required fields) gets checked by the machine — keep human eyes only for the quality judgments you actually care about
• Define the contract early. Decide “what counts as done” before letting the AI start, and rework rates drop off a cliff

---

Method 2: Acceptance is a command, not a feeling

The most delicate relationship in dual-agent work is trust: when the AI says “done,” why believe it?

My answer: don’t trust its words — trust the exit code.

After every subtask is delivered, the commander doesn’t “eyeball the code and sense it’s fine.” It runs one unified automated acceptance pass — compile, checks, full-site build. Any failure sends the work straight back; only when everything is green does it count. The rule applies to both agents equally, the commander included.

This single principle is worth more than it sounds:

• “Done” gets an objective definition — neither the AI’s self-assessment nor human vibes count anymore
• Rework costs move earlier — errors are caught locally, not as broken pages in front of readers
• Agents gain a shared language — “did it pass or not” aligns everyone in one sentence, no code reading required

Let the machine be the referee, and people get freed from watching the process — left only with the judgments that genuinely need taste.

---

Method 3: Task briefs must translate “aesthetics” into “rules”

The most common failure mode of AI isn’t inability — it’s over-creativity: say “make a nice-looking card” and you get seventeen cards in seventeen styles.

The fix is dehydrating vague asks into verifiable hard rules. In this build, every precision component was dispatched with a brief that hard-coded checkable rules, not adjectives, for example:

• The main metric’s type scale and hierarchy — written as concrete specs
• How to band numeric health into good/medium/bad, and the color for each band — turning “healthy feel” into thresholds and hex values
• The drawdown threshold that flags red, and the symbol to add — turning “warning” into a condition
• What may be done with pure styling vs. what needs no extra dependencies — turning “lightweight” into a constraint list

Once rules exist, the welder starts with zero clarifying questions, and first-pass acceptance rates visibly climb. Whatever you care about, turn it into a checkable rule; whatever the rules don’t cover is where the AI gets to improvise.

---

Method 4: Small cuts, hard boundaries

Multi-agent collaboration’s worst fear is boundary-hopping — the welder quietly editing global config mid-task, the commander sneaking two style lines into a component. Each is trivial alone; accumulated, it’s architectural drift.

Three disciplines, learned the hard way and now habitual:

1. Keep task cuts small — one file, one component per execution turn; the pollution surface is capped at the source
2. Write permissions into the brief — explicitly state “touch only the target file, install no dependencies, change no global config”; overstepping means rework
3. Close every loop with regression — before any subtask merges, the commander runs the full-site acceptance once; anything substandard goes back

The essence is keeping every agent inside its radius of competence — the commander doesn’t write pixels, the welder doesn’t touch architecture. Boundaries held, the whole stays coherent.

---

Pitfalls hit & three pieces of advice

1. Don’t let the commander write pixels — mixing global decisions with local implementation is the biggest pitfall in dual-agent projects. Spell everything out in the brief, down to “only this technology is allowed, nothing else may be introduced.” Vagueness is the breeding ground of rework.
2. Define the contract before starting work — delivery standards (structure, types, acceptance commands) are the “law” for everything that follows. Defining rules as you go is like building on quicksand.
3. Make acceptance a single command — “done” is decided by nothing and no one except the automated acceptance exit code. This one rule rescues you, the AI, and the trust inside the collaboration at once.

---

Closing: the method outlives the website

Looking back, the biggest gain from this dual-agent build wasn’t “saving a few days.” It was validating a sustainable method for getting engineering-grade work out of AI: division of labor with a philosophy, deliveries with contracts, acceptance by command, boundaries with discipline. Every article and redesign on CyanLabs since has run on this system — and none of it is tied to any particular tool. Two complementary agents, a fast-and-cheap brain paired with a slow-and-careful one: anyone can set this up.

This site itself is living proof — the typography you’re reading, the dual theme, the skeleton of four pillars: all products of this workflow. As for the raw, first-time experience and that ridiculous cost ledger — that’s the companion piece:

Companion read: A CyanLabs Prototype from Scratch in 30 Minutes for Only $0.20, an AI enthusiast’s first real ride letting agents build from zero.

Website diary series: A video and an old blog post · The 30-minute prototype · The dual-agent method · Launch and indexing

---

Written by the “commander” side of a commander-and-welder workflow, filed under CyanLabs /ai.