Hybrid Multi-Agent Systems, Design Principles and Applications
Placing an LLM-based agent uniformly at every stage of a pipeline creates two problems at once. Even repetitive, deterministic work that needs no judgment gets routed through reasoning every time, driving up token cost and latency unnecessarily, and because the same input can take a different reasoning path on each run, reproducibility suffers. Go the other way, though, and build the entire pipeline out of deterministic rules and learned functions alone, and you lose the ability to handle exceptions that can't be enumerated in advance or stretches of work that genuinely call for open-ended judgment.
A Hybrid Multi-Agent System solves both problems at once by matching each stage of a pipeline to the agent class that stage actually calls for. Reasoning-based agents go where judgment and re-observation are needed; deterministic functions go where input maps predictably to output — securing autonomy exactly where autonomy is needed, and resource efficiency exactly where efficiency is needed.
This post pulls together academic and industry discussion to pin down a clear definition of the Hybrid Multi-Agent System, then looks at the agent classes that make it up and the criteria for placing them. From there, it walks through a standard web application pipeline that takes a formalized technical spec as input as a representative use case.
Defining the Hybrid Multi-Agent System
A Multi-Agent System (MAS) is a long-established term in distributed AI for a computational system in which multiple autonomous agents interact to solve a single problem. Each agent holds partial autonomy and operates from a local vantage point without complete information about the system as a whole, and no single agent controls the overall behavior — a decentralized structure by design.
One term worth clearing up first, since it's easy to confuse: "Hybrid Agent (Architecture)" is a separate, much older concept describing an architecture inside a single agent that combines a reactive layer, handling immediate responses, with a deliberative layer that does the planning. It's worth noting that this is a discussion about the internal structure of one agent, not about a team made up of several agents. The Hybrid Multi-Agent System this post covers is different — it means the agents making up the team are themselves a mix of different classes. The two terms sit at different levels entirely and shouldn't be used interchangeably.
The underlying idea of mixing reasoning-based agents with deterministic functions inside one system connects to the Compound AI System concept that Berkeley AI researchers put forward in 2024 — systems that tackle an AI task by combining multiple interacting components: model calls, retrievers, external tools, and the like. There's practical precedent for this, too: recent research on LLM-based multi-agent systems has reported replacing generative agents with rule-based ones specifically to improve efficiency. That said, no standard taxonomy has yet organized this kind of combination under a single name like "Hybrid Multi-Agent System." The most accurate way to read the term as used in this post is as a practitioner's label for the design pattern of explicitly sorting each agent into the class its role calls for and placing it accordingly.
Agent Classes: ReAct Agent and Functional Agent
The agents that make up a Hybrid Multi-Agent System fall into two broad classes.
| Class | Definition | Execution |
|---|---|---|
| ReAct Agent | A process whose next action changes every time based on the observation history. Not a fixed function — the only class that can genuinely be called an "AI agent" | Observation → Hypothesis → Action → re-Observation, repeated |
| Functional Agent — Rule-based | A deterministic function a person writes explicitly. Same input, same output, always | Validates input/output and returns immediately; changes are managed through code review |
| Functional Agent — Learned | A fixed function derived statistically from data (classical ML). Doesn't depend on internal state or execution history | Validates input/output and returns immediately; needs data-drift detection, retraining, and version management |
The agent classes that make up a Hybrid Multi-Agent System
All three classes look similar at the execution level — none of them needs to hold session state, and a simple retry is enough when something fails — but they're fundamentally different underneath. A ReAct Agent takes a different path on every call depending on its observation history, while both Functional Agent variants reproduce the exact same path for the exact same input every time. Functional Agents typically handle four representative roles: mapping schema input onto a fixed template output (Rule-based), compressing a large volume of items by similarity to narrow down what needs further processing (Learned), scoring risk from learned patterns to set processing priority (Learned), and settling a pass/fail outcome through a boolean check against predefined conditions (Rule-based).
Where to Place a ReAct Agent
A ReAct Agent carries real cost and latency and comparatively lower reproducibility, so there's no reason to place one at every stage of a pipeline. It belongs only at points where all three of the following conditions hold; if even one doesn't, the first move should be to consider replacing it with a Functional Agent or some combination of deterministic and learned functions.
The first is a finite candidate space. The candidate causes or choices have to be enumerable. The code paths that could be behind a compile error are a good example of something you can statically enumerate as a finite set.
The second is differential informativeness of actions. An action has to generate information that wasn't there before it ran. A procedure that just re-checks the same data doesn't qualify as an action.
The third is a falsifiable judgment criterion. There has to be a clear standard for determining whether a hypothesis is true or false. Without one, an agent risks falling into confirmation bias — building a plausible-sounding story after the fact rather than actually testing anything.
A Representative Case: A Spec-Driven Pipeline for Automated Web Application Development
How a Hybrid Multi-Agent System actually behaves in practice shows up clearly in a pipeline that takes a formalized technical spec as input and automates a standard-stack web application — say, a typical app built from a frontend, backend, and database — all the way from implementation through testing and verification. The input is a spec document that structures entities, API contracts, and screen composition, and, assuming that spec is written well enough, the pipeline below is how the flow comes together.
How agent classes get placed across a spec-driven web application pipeline — the dashed box is the loop that repeats until it's cleared. Regression impact analysis (Learned), which runs continuously on every code or diff change and narrows how much of that loop needs to re-run, works alongside the flow at all times, outside the diagram itself.
The Full Test Run stage is deterministic, just like Scaffolding and the Final Gate, but it isn't classified as an agent. It performs no transformation whose output varies with input — it's infrastructure that always runs the exact same procedure regardless of what the code or tests actually contain. Failure Triage and the Debugging Loop form a cycle: when Full Test Run turns up failures, a Learned Functional Agent groups them to compress the set, a ReAct Agent takes each group's representative failure, traces it back to the root cause, fixes it, and Full Test Run runs again. That cycle keeps going until every group has been cleared.
Design Principles That Keep the Class Boundary Intact
For this pipeline to actually run both autonomously and resource-efficiently, it needs a handful of principles that explicitly enforce the boundary between agent classes.
First, a single source of truth for the spec. Scaffolding and standard test generation must share the exact same spec parser. Generate them through two separate LLM calls instead, and both outputs end up carrying the same misreading — meaning neither can catch the other's mistake.
Second, restricting ReAct's scope. Custom logic implementation, edge-case testing, and the debugging loop all need their scope explicitly narrowed to "whatever standard scaffolding can't resolve." Let that boundary blur, and the same risks resurface: lower reproducibility, higher cost, and security vulnerabilities spreading further than they should.
Third, ML performs grouping and prioritization, never the final verdict. What Failure Triage and Regression Impact Analysis produce is priority information — "look at this first" — not "this is the answer." Determining the actual root cause and deciding whether to fix it stays with the ReAct Agent's debugging loop, which has a falsifiable standard to work against.
Fourth, the Final Gate always stays Rule-based. Let an LLM's subjective judgment into the pipeline's last pass/fail call, and the reliability of the verification itself is at stake. The final verdict has to be mechanically reproducible, every time.
Fifth, the interfaces between agent classes are defined with strongly typed schemas. The boundary between a ReAct Agent and a Functional Agent is connected through a structured task schema, not free text, with a parameter-validation gate in front of every execution. That's specifically there to keep an LLM's hallucination from propagating straight through into the deterministic pipeline unchecked.
With all five principles working together, the pipeline secures two things at once. Where judgment and re-observation are genuinely needed — custom logic implementation, edge-case interpretation, debugging — a ReAct Agent handles the problem autonomously, with no human in the loop. Everywhere else, where input maps predictably to output — scaffolding, standard test generation, grouping, prioritization, the final verdict — a deterministic function or a lightweight ML model does the work at no token cost. Compared to building the whole pipeline out of ReAct Agents alone, this cuts LLM calls and token cost substantially, and because the deterministic stages always produce the same output for the same input, reproducibility comes along with it.
In Summary
A Hybrid Multi-Agent System is a design approach that deliberately mixes agents of different classes within a single team. What separates a ReAct Agent — which judges its way down a different path every time based on its observation history — from a Functional Agent — which always produces the same output for the same input — comes down to three things: whether the candidate space is finite, whether the action generates new information, and whether there's a clear standard for falsifying the hypothesis. Placing a ReAct Agent only where all three hold, and handling everything else with a deterministic or learned function, is the core placement rule behind this design.
The spec-driven pipeline for automated web application development is a representative use case where this placement rule plays out directly. A ReAct Agent handles the stretches that genuinely need judgment and re-observation — custom logic implementation, edge-case interpretation, debugging — while a Functional Agent takes the stretches where input maps predictably to output: scaffolding, standard test generation, grouping, the final verdict. The result is a pipeline that solves problems autonomously, with no human intervention, wherever judgment is required, and skips the LLM call entirely wherever it isn't — cutting token cost and latency together. The deterministic stages, for their part, reproduce the same path every time, which lifts the reliability of the pipeline as a whole. Securing autonomy, resource efficiency, and reproducibility all at once — that combination is the real payoff of applying a Hybrid Multi-Agent System to a case like this.