How Fusion allocates intelligence
Fusion is FUMO Lab's compound intelligence system. It selects model capabilities according to what the task needs at each step.
A bounded request may need one capable model. An agentic workflow can move from exploration to implementation, from a failed action to diagnosis, and from a candidate result to verification. The useful capability changes as the task state changes.
This page summarizes the architecture and research direction in the Fusion whitepaper, Revision 0.1↗. The API references define the currently exposed client contract.
From routing to allocation
Routing is useful when a request's requirements are visible at the outset. Fusion treats routing as one possible action inside a broader allocation process.
An allocation can choose a model, a role, a bounded view of the task, a compute budget, or no further call. The choice depends on the open question: it may call for another solver, a specialist, an independent critic, or a deterministic check.
The goal is to acquire evidence that could change the next decision.
One task state, many perspectives
Fusion uses a normalized view of the supplied work: user intent, constraints, earlier decisions, tool observations, failures, and acceptance conditions.
Different computations can receive different views of that state. An explorer may need the open question; a critic may need a candidate and its constraints; the final synthesis path must retain the conversation and action contract. These views give contributors a defined purpose without granting them independent control of the workflow.
The public API is stateless. Clients send the complete conversation and tool history on each request. Fusion does not store Responses objects for continuation via previous_response_id.
Models as sources of evidence
A model's value as a contributor depends on its role, the available context, evidence already gathered, reliability, latency, and cost.
Fusion can use complementary capabilities asymmetrically: a specialist for a narrow question, an efficient model for a bounded check, or frontier capability for a decision that requires stronger judgment. Each contribution still needs to be evaluated: misleading or redundant evidence can make the result worse.
Each role defines the evidence being sought. The roles and internal model pool can evolve as the system develops.
A closed loop around the next decision
The whitepaper describes allocation as a repeating process:
- Understand the state — identify what changed and which uncertainty could affect the next answer or action.
- Choose the next computation — select a source, role, context view, and budget, or decide that no additional call is warranted.
- Evaluate the evidence — preserve where a contribution came from, compare claims, and resolve or reject conflicting material.
- Commit one result — return an authoritative answer or tool call under the original contract.
- Update from the observation — when the client returns a tool result or the user adds information, use the updated history for the next step.
The diagram shows one example of the collaboration process. The path can change with the task state, including steps where a single model is sufficient.
One authoritative answer or action
Candidate answers, criticisms, test results, and suggested tool calls are evaluated according to their relevance and reliability.
Only the authoritative response path can emit a client-visible tool call. Intermediate contributors cannot independently execute a client tool or make conflicting changes to the outside world.
The client executes supported function or custom/freeform tool calls and sends back their results. The public endpoint supports client-executed tools; hosted web search and computer use are unavailable. See the Chat Completions and Responses references for supported features.
Compute follows the value of evidence
Another independent approach can be valuable early in a task. Once an implementation exists, verification may be more useful than another candidate. When the evidence is sufficient for the next decision, extra inference may add cost and latency without improving the result.
Fusion therefore treats admission, collaboration, escalation, and stopping as related allocation choices. These choices balance the expected value of further work against its cost and latency.
Two sources of progress
The whitepaper distinguishes model progress, which expands available capability, from allocation progress, which improves how that capability is used.
Revision 0.1 describes structured task perception with explicit policy boundaries. Learned allocation is a research direction, with versioned evaluation and reversible policy changes proposed as safeguards.
The research goal is to grow system capability while limiting the growth in frontier-compute consumption. Establishing that relationship will require further evaluation.
Read the benchmark results and evaluation conditions · Send your first request