Additional intelligence has to be captured
Another source may expand available capability, but only if its marginal information can be exposed, evaluated, and preserved.
Fusion explores how different forms of intelligence — models, tools, research, and people — can be selected, given the right context, and combined for problems where additional reasoning effort is worth its cost.
Mixture-of-Agents reports 65.1 vs 57.5 LC win rate on AlpacaEval 2.0 (as reported, 2024).
OpenRouter ships Fusion as a documented production feature, not a research demo.
IQ256 runs Fusion internally in selected analysis and decision-support workflows.
External results are cited as evidence that the field is real. They do not describe IQ256's architecture, which is not shared with any of them.
IQ256.ai is a founder-led research and engineering effort. Fusion is used internally in selected analysis and decision-support workflows. Public API access is not available. Feedback and investment conversations are welcome.
Multi-model and multi-agent systems have demonstrated useful results in research and in production: cross-checking, debate, decomposition, tool use, and verification stages that catch what a single pass does not.
Those results validate the field, not one universal recipe. The open engineering problem is how to allocate intelligence under cost, latency, reliability, context, and objective constraints — and when to stop.
Historical published benchmark, not an IQ256 result; shown as evidence that selected multi-model architectures can outperform strong Solo AI in specific evaluations.
“use it when the cost of being wrong outweighs the cost of a few extra completions.”
Fusion is a documented production feature elsewhere in the industry. IQ256 does not imply a shared architecture.
| Area | Status | What is still unclear |
|---|---|---|
| Cross-model verification | Established in practice | Which claims are worth the verification budget. |
| Decomposition into sub-problems | Established in practice | How decomposition interacts with synthesis quality. |
| Debate and structured critique | Demonstrated in research | When critique adds signal rather than confident noise. |
| Inference-time compute allocation | Actively researched | How to predict, ahead of time, where compute pays. |
| General rules for combining intelligence | Open | No general theory; results remain setting-specific. |
A cheaper model, a tool, an external expert, or an employee of the customer may be globally weaker or much narrower than a frontier model, and still hold the information a specific subproblem depends on.
So the question is not “which source scores highest on average?” but “what information does this source contribute that is not already available, and what does it cost to obtain it?”
Fusion is not about averaging intelligence. It is about capturing complementary capability.
More intelligence may be available. Capturing it is the hard part.
noteThe implication is architectural: additional reasoning sources are useful when the system can preserve their independent signal and capture the information they add.
A simple Fusion implementation may look like this: run several models, aggregate their outputs, return an answer. That is a valid implementation, and for some problems the simplest useful configuration is a single model.
Both are points in a much larger design space. The decisions that matter — which source, for which subproblem, with which context, in which sequence, and when to stop — are made before and around any aggregation step.
Objective, budget, latency, risk, and what evidence is available.
The problem is split into subproblems with different requirements.
Models, tools, research, or humans — chosen per subproblem.
Each source receives only the context that changes its answer.
Planned branches may be dropped; findings can open or close others.
Claims that matter are contested before they are accepted.
Partial results become one coherent position.
Form is designed for the decision, not merely formatted.
What happened afterwards informs later orchestration research.
Model A + Model B + Model C → aggregate → answer. Easy to describe, easy to operate, and bounded in what it can improve.
lab noteAggregation assumes the useful information is already present in the outputs. Much of the interesting design work happens before aggregation, not at it.
Budget, latency, risk tolerance, and what the answer is for.
What is already known, and what must be obtained first.
How a problem is split before intelligence is applied.
Which model, tool, research path, or person for which subproblem.
Under which conditions a given source has been useful before.
How genuinely different the participants are, not how many there are.
What each source is given, compressed, or deliberately not given.
What is carried across steps, and what is allowed to decay.
Who sees what, when, and whether independence is preserved.
Sequential, parallel, adversarial, hierarchical — or mixed.
Whether reasoning develops simultaneously or builds in stages.
When to look outward instead of reasoning further inward.
How claims are challenged before they are accepted.
How much effort a given subproblem actually deserves.
How partial results become one coherent position.
The form an answer takes so it can actually be used.
When further reasoning stops being worth its cost.
What happened afterwards, and what it implies for orchestration.
Where a person holds information the machines do not.
These are dimensions of the general design space. They do not describe IQ256's implementation, which remains proprietary.
The important problem is not how many models to run. It is which intelligence to invoke, for which subproblem, with which context, in which sequence — and when to stop.
“how to harness the collective expertise of multiple LLMs is an exciting open direction.”
Reasoning sources overlap substantially. The engineering question is how to reach the parts that do not overlap, test them, and fold them into one answer — not how to collect more votes.
# conceptual only — not production logic
state = frame(problem, constraints)
while expected_value(next_action(state)) > cost(next_action):
subproblem = select_uncertainty(state)
source = select_intelligence(subproblem, state)
evidence = invoke(source, context_for(source, state))
state = update(state, evidence)
return design_outputs(synthesize(state))“the effectiveness of different approaches to scaling test-time compute critically varies depending on the difficulty of the prompt.”
Independent passes, combined once.
Claims are contested before acceptance.
Each stage rewrites the prior state.
The same sources, given different context and a different sequence, can produce materially different results. Composition is a design decision, not a formatting one.
The positions below shape how we allocate effort. They are stated as working positions, not settled results.
Another source may expand available capability, but only if its marginal information can be exposed, evaluated, and preserved.
Capability, cost, latency, availability, correlation, and context needs differ. Those differences are the design material.
A single leaderboard score does not say when a source is useful. Usefulness is conditional on problem, context, and task.
Bringing a source up to speed consumes budget, attention, and time — and can degrade as much as it adds.
The same sources in a different order, topology, or context can produce materially different results.
Not invoking an unnecessary model, tool, search, or person is a successful outcome, not a missed opportunity.
The same reasoning, shaped differently, can be decisive or unusable for the person receiving it.
A good result shows the configuration was sufficient. It does not show that a cheaper or better one did not exist.
We are confident because we hold a strong thesis, not because we consider these questions closed.
“multiple language model instances propose and debate their individual responses and reasoning processes over multiple rounds”
Debate is one interaction topology among many. It is evidence that structure between reasoning sources matters — not a description of IQ256's architecture.
This is a practical engineering position, not philanthropy and not an argument against automation. Human + AI is not universally superior; it is one configuration among several.
A person is the right source when relevant experience, tacit knowledge, organizational context, an unusual perspective, or accountability contributes information that is unavailable elsewhere. Human attention is scarce, so it should be selected for marginal value — not for panel size.
| Configuration | Adds | Cost to consider |
|---|---|---|
| Solo AI | Speed and simplicity; often sufficient. | Single perspective, single failure mode. |
| AI + tools | Facts and computation the model does not hold. | Latency, tool reliability, and context handling. |
| AI + external human | Domain experience and accountability from outside. | Scheduling, briefing, rates, and conflicts. |
| AI + internal context | Organizational facts that were never written down. | Employee attention, and the cost of transferring context. |
This describes the broader Fusion research space. It does not describe an IQ256.ai product that orchestrates customer employees.
The question is not “human or AI?” It is which intelligence source has the most relevant information for this subproblem.
Facts about the situation that were never written down.
Judgement built from outcomes, not from text.
Framings a model is statistically unlikely to produce.
A decision owner, which no model can be.
IQ256 is a founder-led research and engineering effort focused on practical AI Fusion. We build this because we use it. Internal results have been encouraging, and selected internal Fusion configurations have produced stronger results than frontier Solo AI in specific use cases.
We deliberately do not generalise from that. The broader objective is learning when to invoke which intelligence, and how to compose it — including when the right answer is to invoke less.
| Category | Position | Basis |
|---|---|---|
| Demonstrated externally | Selected multi-model and multi-agent architectures can outperform strong individual models in particular settings. | Published research and production systems. |
| Observed internally | Selected internal Fusion configurations have produced stronger results than frontier Solo AI in specific use cases. | Our own internal evaluations. No published figures. |
| Our thesis | The engineering problem is allocating and composing intelligence — which source, which subproblem, which context, which sequence, when to stop — not running more models. | Working conviction, actively tested. |
| What we do not claim | Not universally better. Not hallucination-free. Not an optimal or finished architecture. | Deliberate limit on our claims. |
lab noteWe add intelligence where an error is more expensive than the extra effort — and we treat intelligence avoided as a result, not a shortfall.
Fusion is currently used internally across selected analysis and decision-support workflows. IQ256 is continuing to test the technology internally before considering broader API access.
When we open access, it will be because the architecture behaves predictably enough to be relied on by someone other than us.
We welcome technical feedback, collaboration conversations, and questions from researchers and builders. For commercial and investment conversations, please use the IQ256.com contact page.