Triple-Model Bid Prep.
Three CLIs write the same bid in parallel. A fourth agent triangulates and flags conflicts. This is the standing operating procedure the team uses for real client work, not a one-off trick. When the deliverable is going to a paying client and a wrong number costs you the relationship, you stop trusting any single model and start triangulating.
- A repeatable three-silo pattern Claude Code, Gemini CLI, and Codex CLI each draft the same artifact independently, then a fourth agent merges and flags conflicts.
- A trust signal you can defend to a client Three independent models converging on the same number is a different claim than one model saying it confidently. Convergence is the audit trail.
- An onboarding template for high-stakes builds When to spend the 3x compute, what to do when the silos disagree, and how to land a Finalized Source of Truth the client can sign.
Run a triple-silo pass with Claude.
Hand Claude the raw input for the deliverable you're about to ship. Claude spawns the three silos, runs the merge agent, and presents the Finalized Source of Truth for your approval. You see every disagreement before anything goes to the client.
How this fits in the OS.
Your CLAUDE.md (Stage 01), the placeholder credential pattern for Anthropic, Google, and OpenAI keys (Stage 01), sub-agents and parallel runs (Stage 04), and the cron or trigger pattern from The Morning Brief (Stage 06) if you want this to fire on a schedule.
Three command-line tools running in parallel: Claude Code, the Gemini CLI, and the Codex CLI. A fourth agent does the merge. Each silo runs in its own context, with its own model, against the same raw input.
Trust signals you can defend to a paying client. Once you've shipped one triple-silo deliverable, the same pattern applies to any high-stakes extraction: blueprints, contracts, research syntheses, anything where being wrong costs you the relationship.
Watch for the shape.
One input. Three independent silos. One merge step. One Finalized Source of Truth with every disagreement still visible. The point is not consensus voting. The point is triangulation. Three models converging on the same number is a different claim than one model saying it confidently. When you ship to a client, convergence is your audit trail.
This is not the everyday pattern. The default mode for daily work is one model, fast. Triple-silo is reserved for the deliverables where being wrong is expensive: client bids, contract clauses, blueprint extractions, anything you'd defend in a meeting.
The team's residential-plumber-to-commercial-bid build used this exact pattern. Nine PDFs of construction blueprints, 72 megabytes, converted to 102 cropped high-resolution images, then handed to Claude Code, the Gemini CLI, and the Codex CLI independently. All three arrived at the same measurements and fixtures. That convergence was the trust signal that unlocked the rest of the build. On a follow-on bid for a national pet-retail chain, the agent's number landed within roughly two percent of the client's hand bid on the same scope. The validation reframes the question from "does the agent look impressive in a demo" to "does the agent's number compare within rounding error of an experienced expert."
The three silos.
Each silo runs in its own context with its own model. They do not see each other's outputs. The whole pattern depends on that isolation. If you let one silo prime the others, you collapse three independent reads into one read repeated three times, and you lose the trust signal.
Claude Code (Opus or Sonnet)
What it is. Your primary harness. The same Claude Code session you use every day, here pointed at the deliverable's raw input with no awareness that two other silos are running the same job.
Why it's in the mix. Strong reasoning over long context, good at structured extraction from messy sources (PDFs, transcripts, scanned schematics). Default to Opus for the highest-stakes silo, Sonnet if you're cost-sensitive and the input is well-shaped.
What it gets. The raw input plus a single instruction: produce the deliverable. No mention of the other silos. No hint that the output will be merged.
Gemini CLI
What it is. Google's command-line tool for the Gemini models. Installable in minutes. Once it's wired, Claude Code can spawn it as a sub-process with its own credentials and its own context window.
Why it's in the mix. Different training data, different reasoning shape, different failure modes. When Gemini and Claude both arrive at the same fixture count on a blueprint, that's a meaningful signal. When they disagree, the merge agent has something concrete to flag.
What it gets. The same raw input as Silo 1. The same instruction. Nothing about Claude's output.
Codex CLI (OpenAI)
What it is. OpenAI's command-line agent harness. Same install pattern as the Gemini CLI: a binary on your computer, credentials in your password manager, callable from Claude Code as a sub-process.
Why it's in the mix. Third independent vendor. Third independent context. The whole point of three silos rather than two is that two-out-of-three convergence is meaningful when the third diverges. Two silos with a disagreement gives you no resolution. Three gives you a structured place to look.
What it gets. Same raw input. Same instruction. No awareness of the others.
The triangulation agent
What it is. A merge step, not a vote. The fourth agent reads all three outputs side by side and produces a single Finalized Source of Truth document with the convergence status on every load-bearing claim.
What it does, field by field:
- If all three converge on the same value, mark high-confidence and carry it forward.
- If two converge and one diverges, mark single-flag review. Surface the divergent claim with its source silo named.
- If all three diverge, mark human-verification-required. The number does not enter the deliverable until you say so.
The merge agent does not average. It does not pick a winner. It preserves the disagreement and surfaces it.
What the merge agent actually produces.
The Finalized Source of Truth is a structured document, not a smoothed-over summary. Every claim carries its convergence status. When you hand it to a client (or back to a domain expert for verification), they see exactly where to look.
| Outcome | What it means | What you do |
|---|---|---|
| CONVERGE | All three silos returned the same value (or values within an acceptable tolerance you defined up front). | Carry forward as high-confidence. This is the bulk of a well-shaped deliverable. |
| SPLIT | Two converge, one diverges. The merge agent names the diverging silo and surfaces its claim. | Review the divergent claim. Sometimes the outlier caught something the other two missed. Sometimes it hallucinated. You decide. |
| DIVERGE | All three returned different values. Three vendors, three reads, three answers. No automated resolution. | Human verification required. The claim does not enter the deliverable. Often this means the source material was ambiguous or the instruction was under-specified. |
A worked example: the bid that proved the pattern.
The team's residential-plumber-to-commercial-medical-facility build is the cleanest reference for what this looks like in production. The client texted on a Friday. The deliverable shipped over the weekend. The numbers below are from the Lightning Lesson retelling of the build.
What happened: Nine architectural PDFs, 72 megabytes, became 102 cropped high-resolution images. Claude Code, the Gemini CLI, and the Codex CLI each read the images independently. Each silo extracted measurements, fixtures, and plumbing lines. The merge agent triangulated. Every load-bearing number on the bid carried its convergence status into the Finalized Source of Truth that the client signed off on.
What the validation looks like: A month later, the same client ran a follow-on bid for a national pet-retail chain. He built his own bid by hand, the way he always does. The agent built one in parallel. The two numbers landed within roughly two percent of each other. That's the answer to "is the agent's output actually trustworthy" reframed in a way you can defend to a client.
On the same build, the agent's first read of the geological report raised an alarm about a problematic corner of the parcel. Instead of surfacing the alarm and moving on, the agent spawned a verification team to re-check whether the alarm applied to the specific dig location. The verification team disconfirmed: the problem corner was not where the dig was coming in from. The agent surfaced both the original concern and the disconfirmation. The agents that read the data are not the same agents that verify the agent's read. Worth porting to any high-stakes claim a future build needs to surface to a client.
When to spend the 3x compute.
Triple-silo costs more. Three context windows, three API bills, more wall-clock time to merge. Spend it deliberately.
- Client deliverables with money attached. Bids, contracts, blueprint extractions, anything where a wrong number costs you the relationship.
- Architecture decisions you can't easily reverse. Schema picks, vendor lock-in calls, infrastructure choices that future builds will inherit.
- Cross-source research syntheses where confidence on the load-bearing claims is the whole product.
- Not everyday work. Drafting a Slack message, writing a small skill, answering a question for yourself. One model, fast, is the right shape.
If you can't name a load-bearing claim in the deliverable, you don't need triple-silo. If you can name three, you probably do.
What changes for you.
The 3x compute is the obvious part. The harder shift is the one you'll feel two or three deliverables in:
- You stop saying "the model said". When you defend a number to a client, the number isn't from a model, it's from three models converging. That's a sturdier sentence to say out loud.
- You start designing deliverables around triangulability. Numbers, fixture counts, contract clauses, measurements. The load-bearing claims get isolated up front so the silos can be compared field by field, not paragraph by paragraph.
- You hand divergences to the client instead of smoothing them. The disagreements are interesting. A client looking at a SPLIT or a DIVERGE row often has the domain knowledge to resolve it in seconds. The merge agent surfaces it, you forward it, the expert decides.
The point isn't that the agents are right. The point is that the disagreements between them are where the real work lives.
Where to go next.
You have the pattern. The natural next moves: