MAUL — Multi-Agentic Unified LLM

2026 · UnikAI Lab

We present MAUL, a modular multi-agent routing framework built on a single hypothesis: that a system of specialised agents, each operating in its domain of highest competence and coordinated by an intelligent dispatcher, will outperform a single generalist model on every task it covers. Across two generations, MAUL demonstrates this on grade-school mathematics, code generation, and conversational reasoning — routing inputs through deterministic computation, live information retrieval, and domain-tuned language agents rather than asking one model to do all three from frozen weights alone. With Hydrogen-2 as the backend, MAUL-2 achieves 95.90% on GSM8K and 97.56% on HumanEval.

Keywords: multi-agent systems, semantic routing, tool use, specialisation, language model orchestration, deterministic computation, retrieval-augmented generation.

1. Introduction

Large language models are trained to do everything. They answer math questions, write code, retrieve facts, hold conversations, and generate creative prose — all from the same frozen weight matrix. This generality is their stated strength. It is also a fundamental structural constraint.

A single model cannot be simultaneously optimal at arithmetic and open-ended reasoning. Arithmetic requires determinism: there is one correct answer to 847 × 63, and a probabilistic model that pattern-matches toward that answer from training distribution will sometimes be wrong. Factual retrieval requires currency: a model trained on a corpus with a knowledge cutoff cannot know what happened last week. Creative reasoning requires breadth: a model tuned to be precise about code will make a worse creative writer.

The question MAUL asks is not “how do we make one model better at all of these?” It asks: “what if we stopped trying?”

2. The Hypothesis

Specialisation beats generalisation. Not as an absolute claim about language model capability, but as a structural claim about system design. A system that correctly identifies which tool is best suited to a given input, and routes to that tool without friction, will outperform a single agent attempting the same inputs across domains.

This is not a new idea in engineering. It is the reason databases exist separately from application logic, the reason compilers are not runtime interpreters, the reason calculators were built before language models. What MAUL adds is the coordination layer: a semantic understanding pass that determines what the user actually needs before routing, and a synthesis pass that assembles the specialist outputs into one coherent reply.

The hypothesis has a falsifiable implication: if MAUL does not outperform the generalist model it routes through on the domains it covers, the routing is either wrong or the specialists are not better than the generalist at their speciality. Both are testable. We report results on GSM8K and HumanEval below.

3. Architecture

3.1 Semantic Understanding Phase

Before any routing decision, MAUL runs a semantic interpretation pass over the input. This phase operates on intent, not surface form. The goal is to answer three questions:

• What type of task is this?
• What external resources, if any, are required to answer it?
• What specialist is best equipped to produce the response?

Surface-form routing — keyword matching, regex, classifier heads — fails on paraphrase. “What is the square root of 144” and “144 under the radical sign” should route to the same calculator path. They do in MAUL because routing is downstream of semantic understanding, not upstream of it. The understanding phase uses the backbone language model to produce a structured task representation before any routing logic fires.

3.2 Routing Engine

The routing engine receives the structured task representation and selects one of three primary paths. The selection is deterministic given the task type — there is no sampling, no probability distribution over paths. The system either routes to the calculator, to search, or to a direct specialist. Ambiguous cases default to the direct path with the most general specialist.

Calculator path. All arithmetic, algebra, and mathematical computation routes here. The backbone model is used only to extract the symbolic expression from natural language. The expression is passed to SymPy, a deterministic computer algebra system, for evaluation. The model never computes — it reads and transcribes. This eliminates the class of errors where a language model approximates a numerical result from training-distribution frequency rather than computing it.

Search path. Queries requiring external, current, or highly specific factual information route here. The query is issued to DuckDuckGo and, where appropriate, Wikipedia. Retrieved content is passed to the synthesiser rather than the backbone model directly, preventing the model from ignoring retrieved evidence in favour of prior weights.

Direct path. Reasoning, creative, conversational, and code tasks route here, branching further to the appropriate domain specialist. The backbone model is invoked with a specialist-tuned prompt rather than a generic system prompt. The five specialists are: Coder, Logic, Creative, Researcher, and Chat. Each carries a prompt that tunes tone, reasoning style, and output format to its domain.

3.3 Specialist Agents

Specialist agents are not separate models. They are the same backbone language model invoked with different system prompts, different output constraints, and different expectations about what constitutes a correct response. The prompts are domain-specific in a way that general instruction-following prompts are not.

• Coder. Produces syntactically valid, runnable code. Output is constrained to code blocks with language annotations. Reasoning is expected to be explicit and sequential.
• Logic. Handles deductive and inductive reasoning, structured argument, and formal problem decomposition. Responds in steps with intermediate conclusions made explicit.
• Creative. Handles generation tasks where correctness is not a binary property. Tuned for fluency and originality over precision.
• Researcher. Handles synthesis of retrieved content. Tuned to produce responses grounded in the retrieved material rather than prior weights.
• Chat. Handles conversational and open-ended interaction. General-purpose with minimal constraints.

3.4 Synthesis and Quality Audit

All paths return a raw specialist output to the synthesis layer. The synthesiser assembles this into a final response with consistent tone, removes artefacts from the specialist prompt format, and ensures the response addresses what the user actually asked rather than what the specialist was tuned to answer.

A lightweight quality audit runs after synthesis. It checks that the response is not empty, does not contradict the retrieved evidence (on search-path responses), and does not produce an obviously malformed output. Failures trigger a single retry with an adjusted specialist prompt before delivery.

4. Results

All results reported for MAUL-2 paired with Hydrogen-2 as the backbone. Evaluation follows standard protocols for each benchmark.

• GSM8K — 95.90%. Grade-school mathematics. The calculator path handles all arithmetic evaluation; the backbone model handles expression extraction and word-problem parsing only.
• HumanEval — 97.56%. Python function generation from docstring. Coder specialist path. Output passed to a sandboxed executor for verification before scoring.

Both scores reflect the routing architecture. A generalist model invoked directly, without routing, scores lower on both because it attempts to compute and execute from internal weights rather than delegating to the appropriate tool.

5. Generational Evolution

MAUL-1 (2026). Foundation version. Established the routing pipeline: semantic understanding followed by path selection followed by specialist invocation. DuckDuckGo and Wikipedia tool integration. Gemini API backbone. Demonstrated the routing hypothesis at small scale across coding, logic, and conversational tasks.

MAUL-2 (2026). The semantic understanding phase was separated into its own structured pass, making the routing decision explicit and inspectable rather than implicit in the backbone model call. The deterministic calculator was added to the math path. Agent prompts were redesigned around observed failure modes from MAUL-1. Benchmark evaluation formalised across GSM8K and HumanEval.

6. Discussion

MAUL does not improve language models. It routes around their limitations. This distinction matters. Routing math through a deterministic calculator does not make the backbone model better at math — it removes the backbone model from the computation entirely. The improvement is architectural, not parametric.

This has an implication for how to think about the benchmark scores. 95.90% on GSM8K is not a claim about the language model's mathematical ability. It is a claim about what happens when you stop asking a probabilistic system to do deterministic work and give it to something deterministic instead.

The broader implication of the MAUL hypothesis — if it holds — is that the path to more capable AI systems is not exclusively through larger models trained on larger corpora. It is also through better system design: knowing what each component of a system is good at, and building the coordination layer that puts each component in its correct position.

7. Limitations

MAUL-2 has no persistent memory across sessions. Context from one conversation does not carry into the next. The routing decision is binary within each path — there is no partial routing or blended specialist response. The quality audit catches obvious failures but does not evaluate factual correctness on open-domain questions. Backbone model quality is a ceiling on the direct specialist paths.