01
Dispatch
"One agent → all runtimes via OACP inbox."
Give your brainstorm prompt to a single agent — say, Claude. OACP routes it to every other runtime in your fleet. Each receives the prompt and works independently.
an open protocol · v1
One AI gives you one perspective.
Three give you the full picture.
An open protocol for multi-model brainstorming. Dispatch the same question to Claude, Codex, and Gemini. Direct each toward its strengths. Synthesize insights no single model produces alone.
one prompt · three responses · one synthesisexample · architecture decision · 17:02 — 17:06
"Should we use Postgres or DynamoDB for the new audit log service?"
Claudenuanced tradeoffs
·Postgres if you ever need joins, ad-hoc queries, or transactional consistency across the audit log and the rest of your data.
·DynamoDB if the access pattern is strictly append + read-by-id + scan-by-time-range. The cost shape is more predictable.
⚑Trap: people pick Dynamo for "infinite scale" then write a query layer that approximates SQL. Reverse-engineering Postgres in DynamoDB is the single biggest regret pattern I see.
→Default to Postgres unless you have a concrete reason. The "concrete reason" must be a write rate you have actually measured, not a forecast.
4 points · 1 flag · 1 recdirect →
Codexconcrete implementation
·Postgres logical replication + a partitioned audit_events table by month gets you 50k+ inserts/sec on commodity hardware. Operationally simple.
·DynamoDB needs a PK design now you cannot change — composite (entity#date, ts) is the usual answer.
⚑GSI math: every secondary access pattern doubles cost. Audit logs typically have 4–5 query shapes; that gets expensive fast.
→Concrete plan: Postgres + pg_partman + Barman backups. Migrate to a hybrid only when partitioning stops keeping up — which on audit data is rare.
4 points · 1 flag · 1 recdirect →
Geminiunconventional framings
·You may be solving the wrong problem. "Audit log" reads two ways: a regulator-facing append-only ledger, or an internal observability stream. They want different stores.
⚑If it is the regulator version, the durability question dominates the database question. WORM-compliant object storage + an index is a third option neither C nor C surfaced.
·If it is internal observability, treat it as a log pipeline — Kafka → S3 + Athena — and stop thinking about it as a database at all.
→Before picking Postgres vs Dynamo: name the consumer. The consumer pins the design.
4 points · 1 flag · 1 recdirect →
synthesis · 17:06
The decision.
Postgres, partitioned by month — Codex's concrete plan. But first, per Gemini, name the consumer: this is the internal observability log, not the regulator's ledger. Claude's "measure before you migrate" rule stays as the trigger for revisiting in 6 months.
· claude — measurement trigger· codex — partitioned PG plan· gemini — consumer reframing
How a brainstorm runs.
02
Direct
"Steer each model toward its strengths."
Push Claude on nuanced tradeoffs. Ask Codex for concrete risks. Get Gemini to surface unconventional framings. Follow-up messages route through OACP — no tab-switching.
03
Synthesize
"Merge the best of all three."
Pick the strongest points from each. Resolve contradictions. Flag blind spots. The synthesis template gives structure — agreed / disagreed / what each one missed.
why it worksEvery model has blind spots.
Every model has blind spots.
The union is the deliverable.
Claude excels at nuanced reasoning but can miss implementation risks. Codex is strong on concrete examples but may overlook strategic implications. Gemini surfaces unconventional framings neither catches.
naming brainstorm
One model caught a package-registry conflict that would have blocked launch. The other two missed it entirely.
competitive analysis
Different models found different competitors. The union was the complete picture; any single model gave a partial view.
product strategy
One model's framing — "hide the protocol, sell the workflow" — became the core positioning. The other models never surfaced it.
Brainstorming templates.
browse all on GitHub →Naming Decisions
Run a naming brainstorm across Claude, Codex, and Gemini. Each model proposes names with rationale, domain/registry availability checks, and risk flags. Different models have different aesthetic sensibilities — the union is always better.
view template →Competitive Analysis
Different models literally know about different companies. Dispatch the same competitive-analysis prompt and get a broader market picture than any single model provides. Covers features, pricing, moat, and "one thing to steal."
view template →Architecture Decisions
Get architecture proposals with tradeoff analysis, implementation complexity, operational burden, and migration paths. One model catches the scaling risk another misses. The combined risk surface is the real deliverable.
view template →Frequently asked questions.
How do I brainstorm with Claude and Codex?+
Start the brainstorm from one agent — give Claude the instruction and OACP automatically routes the question to Codex via inbox messages. Both agents work on it independently and respond through the protocol. Direct each one toward its strengths: push Claude on reasoning, ask Codex for concrete risks. Then synthesize the best from both. The brainstorm protocol gives you step-by-step structure and templates for common decision types.
Do I need special tools for multi-model brainstorming?+
You need OACP (free, open source) to get the automated dispatch — it routes your brainstorm prompt to every runtime via inbox messages and collects structured responses. Without OACP, you can still run the protocol manually with separate sessions. OACP is the recommended path: one instruction to one agent kicks off the entire flow.
How long does a multi-agent brainstorm take?+
A single-round brainstorm (dispatch + quick synthesis) takes about 30 minutes. Two rounds with interactive direction takes about 60 minutes. A full three-round brainstorm with signoff review takes about 90 minutes. Most decisions need one or two rounds. The time pays back immediately — you catch blind spots that would cost hours or days to fix later.
What decisions work best for AI brainstorming?+
Decisions with genuine tradeoffs and no single correct answer: architecture choices, naming, competitive analysis, strategy and positioning, pricing. Any problem where different perspectives surface different risks. Not needed for questions with known answers, simple code generation, or tasks where speed matters more than thoroughness.
Can I use models other than Claude, Codex, and Gemini?+
Yes. The protocol is model-agnostic — any LLM works. Claude, Codex, and Gemini are common choices because they have meaningfully different training data and reasoning styles, which maximizes diversity. Two models is often enough. The key is model diversity, not model count.
Better decisions are one prompt away.
Protocol, templates, examples — everything you need to run your first multi-model brainstorm with Claude, Codex, and Gemini.