What can a founder actually copy from Basis's model-routing and reviewability story?

Basis's interesting decision is not “use multiple agents.” It is to make routing and review part of the accounting product.

That is a more useful lesson for a founder than copying a list of model names.

What Basis says it built

In OpenAI's Basis customer story, Basis is described as an accounting-agent company handling work such as reconciliations, journal entries, and financial summaries. The page says firms using Basis report up to 30% time savings and more capacity for advisory work.

That number is a company-reported claim in an OpenAI-selected customer story. It is not an independent benchmark, and the page does not give enough context to treat 30% as a general accounting result. Still, the product mechanics are worth studying.

Basis treats accounting as a collection of workflows with different context and complexity. A supervising agent routes work to specialized sub-agents. The routing decision considers the task, complexity, latency needs, and input type. In the example, the system can use one model for quick clarification and another for a more complex process such as month-end close.

The important bit is the boundary between “the model answered” and “the workflow moved.”

Three things worth copying

1. Route by the job, not by model fashion

If every task goes to the same model, you are making a hidden assumption: that every task has the same tolerance for speed, depth, context, and cost.

Basis makes that assumption explicit. A short clarification does not need the same path as a multi-step reconciliation. A weird transaction pattern does not have the same shape as a routine journal entry.

For a founder, the first useful artifact is not a multi-agent diagram. It is a task map:

• Which jobs are routine enough for a fast path?
• Which jobs need more context or reasoning?
• Which jobs need a human before the system acts?
• Which jobs should the product refuse?

If the answers are the same for every job, routing may be premature. If they are materially different, routing can be a product decision rather than architecture theatre.

2. Make review part of the output

The Basis story says an accountant sees the proposed entry alongside the supporting data, the mapping logic, assumptions, and confidence. That is not merely an explanation layer added for marketing. It is how the buyer decides whether to approve the work.

This matters in any workflow where the agent is not the final authority. A reviewer needs to know what the system used, what it inferred, and where the uncertain edge is. Otherwise “human in the loop” means a person rereads everything from scratch.

The product question is therefore not “Can the agent explain itself?” It is “Can the reviewer make a faster, better decision from the evidence the product exposes?”

That is a much higher bar.

3. Benchmark the work you actually sell

OpenAI's story says Basis runs detailed benchmarks on real accounting workflows and evaluates more than accuracy, including the clarity of the reasoning and explanations. It also describes model migrations as the stack changes.

Again, the page's benchmark claims are company-reported. The useful pattern is the loop: real workflow, known failure, targeted evaluation, model or harness change, regression check.

If your company sells invoice reconciliation, a generic reasoning leaderboard is not your product benchmark. If you sell legal review, a pretty demo is not your evidence. The fixture needs to look like the job and the reviewer needs to agree on what “done” means.

What I would not copy

I would not copy Basis's model roster. It is a moving implementation detail and the public case study is not a neutral comparison of providers.

I would not copy the 30% claim into a pitch deck as if it were a benchmark. The source does not establish the baseline, customer sample, counterfactual, or how much implementation support was involved.

And I would not add sub-agents before the workflow needs different paths. Orchestration can add latency, cost, state, and new failure modes. The architecture should earn its place by making a real review or completion decision better.

The founder conclusion

Copy the operating contract, not the stack.

Start with a small set of real jobs. Route only when their constraints differ. Expose the evidence a reviewer needs. Keep a regression fixture for every painful failure. Attribute customer claims precisely, then test your own workflow before making a broader promise.

That is the part of the Basis story that survives a model release.