How Ulter built the first production‑ready AI council
Everyone in the industry has demoed multiple models talking to each other. Nobody had shipped it to real users, at consumer scale, without making them wait. Here is how the Okran Council went from an idea to the default way thousands of people ask questions.
Why a council at all
Every frontier lab will tell you their model is the best. The honest answer is that each one is the best at something. In our own routing data, the model that writes the cleanest code is not the model that gives the fastest everyday answers, and neither is the model you want translating a contract into French.
Single‑model products resolve this tension by pretending it doesn't exist. Router products resolve it silently, behind the curtain — you ask, something answers, and you're never told what or why. We wanted a third way: put the disagreement on stage. Let the models deliberate over your question, visibly, and let the best‑suited one take it.
Multiple minds. One answer. The Council isn't a feature bolted onto a chatbot — it's a different posture for what an AI product owes its users: transparency about who is answering and why.
The members
The Council seats four frontier models, each with a distinct role:
GPT‑5
Takes the chair for deep multi‑step reasoning: mathematics, research‑grade analysis, long documents and anything with attached files.
DeepSeek‑V3.2
The Council's engineer. Code, debugging, algorithms, SQL and structured technical work land here first.
Gemini 3.1 Pro
The linguist. Translation and multilingual conversations route to Gemini's cross‑language strength.
Grok 4.3
The sprinter. Everyday questions and anything needing current real‑world knowledge get an instant, grounded answer.
The hard part: making deliberation free
The naive way to build a council is sequential: send the question to every model, wait for all of them, have them debate, then synthesize. It produces lovely demos and a product nobody would use — every answer costs four model calls and thirty seconds of staring at a spinner.
The insight that made the Council shippable is that selection and deliberation are separable. Choosing who should answer doesn't require running four frontier models; it requires understanding the question. Presenting why — the deliberation itself — doesn't have to happen before the answer. It can happen alongside it.
So a Council turn works like this:
The roster convenes instantly
The moment you send a message, the Council appears — all four members, live. No waiting state, no queue.
The answerer is chosen with zero added latency
A classification layer reads the question — its domain, its language, its attachments, its requested thinking depth — and seats the best‑suited member immediately. This costs no more time than normal routing: the answer stream starts at once.
The deliberation streams in parallel
While the answer is already streaming, the Council's discussion — who argued for what, and why the chosen member took the question — is generated concurrently by the fastest member and streamed alongside. The debate costs you no waiting time at all.
Every member stands behind the answer
If the chosen model fails or degrades mid‑answer, a fallback chain re‑targets the question to the next‑best member automatically. The Council never returns an empty chair.
There is also a Voting mode for when you want the full ceremony: each member casts a visible vote on who should take the question, and the tally decides. It's slower by design — and it exists because sometimes watching four frontier models argue about your homework is exactly the point.
What "production‑ready" actually means
Demo‑ready and production‑ready are separated by a long list of unglamorous engineering. Shipping the Council to real users meant:
- Latency discipline. The Council adds no round‑trips to the answer path. Selection is synchronous and cheap; deliberation is concurrent. A Council answer begins as fast as a single‑model answer.
- Failover as a first‑class citizen. Four providers means four ways to have a bad day. Every Council turn carries an ordered fallback chain, so a provider outage downgrades gracefully instead of failing loudly.
- Honest presentation. The deliberation you see reflects the actual routing decision and the actual reason for it — the interface shows which member answered, always. We wrote a case study on platforms that hide what model is really responding; the Council is our answer to that industry pattern.
- Cost sanity. Deliberation is generated by the fastest, cheapest member — not by all four — so the Council is sustainable at free‑tier scale. Free users get real Council access every day, not a bait‑and‑switch.
- Safety at the core. Council conversations run through the same Graduated Response Framework as every Okran conversation — detection and gentle redirection of unhealthy dependency, built in, not bolted on.
What we learned
The Council changed how people ask. When users can see that a question will be weighed by four minds, they ask harder questions — more research, more multi‑part problems, more "compare these and tell me which is right." Transparency didn't just build trust; it upgraded the conversations themselves.
It also sharpened our conviction about where AI products are going. The future isn't one model that wins; it's orchestration you can see. Unified intelligence — with the seams shown, not hidden.
