The Consultant Pattern: A Multi-Agent Design That Balances Model Capability and Cost

1. The Problem: Higher Capability Comes at a Higher Price

In LLM engineering practice, developers and enterprise users have long faced a sharp tension: the output quality of a high-performance model tends to scale with its usage cost. The more complex the task and the longer the reasoning chain, the more tokens a top-tier model consumes, and the higher the bill climbs. Going the other way—picking a lower-tier model purely to control cost—risks “crashing” at critical decision points, which leads to rework, hallucinations, or a directionally wrong result.

This is why the industry has started exploring a family of multi-agent collaboration patterns: combining models of different capability levels so that “the strong ones handle the hard problems while the weaker ones do the bulk of the work.” The Consultant Pattern is one of the most representative of these. Its goal can be stated in a single sentence: extract as much value as possible from a high-performance model’s capability ceiling while pushing overall cost as low as possible.

2. What the Consultant Pattern Is

The Consultant Pattern is a bottom-up, on-demand multi-agent collaboration model that separates two clearly defined roles in the task flow:

• Executor: runs on a lower-cost model. It owns the main task loop and handles the vast majority of routine computation and forward progress. It is the leading party in the flow.
• Consultant (advisor): runs on a high-performance model. It acts as an “external brain” that normally does not participate in execution and is only “woken up” at a small number of critical nodes.

Its most distinctive trait is that control stays with the executor. Unlike top-down patterns where the strongest model coordinates and the weaker ones do chores, here the executor judges for itself whether it needs help as it advances the task. When it reaches a node that calls for a judgment call, a course correction, or a directional decision, it issues a one-shot consultation to the consultant model through a tool call, absorbs the advice, and continues executing.

As a result, the high-performance model is invoked very rarely over the whole task—ideally, a single consultant call per task, used to correct the path or set the direction. The overwhelming majority of tokens are billed at the executor model’s low rate, so the cost structure is significantly optimized.

3. How It Works

The pattern can be abstracted as the following state machine:

1. Initialization: the executor receives the task description and performs decomposition and initial planning.
2. Loop execution: the executor advances step by step in the main loop, continuously producing intermediate state.
3. Trigger evaluation: after each stage, the executor assesses the current state—is there ambiguity, is it blocked, does it need higher-level directional calibration?
4. Optional consultation: if a critical node is hit and no consultation has happened yet, the executor calls the consultant model for evaluation, obtains a correction or direction recommendation, and merges it into subsequent context.
5. Output: once the task converges, the executor produces the final answer.

Illustrative implementation (model interfaces are omitted; the focus is the pattern itself):

class ConsultantPattern:
    def __init__(self, executor, consultant, max_consult=1):
        self.executor = executor        # low-cost executor model
        self.consultant = consultant    # high-performance consultant model
        self.max_consult = max_consult  # cap on consultations, usually 1
        self.consult_count = 0
    def is_critical_node(self, state):
        # Trigger only when a judgment, correction, or direction is needed
        return (state.is_ambiguous
                or state.is_blocked
                or state.needs_direction)
    def run(self, task):
        state = self.executor.init(task)
        while not state.done:
            if (self.is_critical_node(state)
                    and self.consult_count < self.max_consult):
                advice = self.consultant.evaluate(state)  # one tool call
                state = state.apply(advice)
                self.consult_count += 1
            else:
                state = self.executor.step(state)
        return state.result

The crux lies in the is_critical_node decision logic and the max_consult constraint. The former determines when to ask for help; the latter determines how many times at most. Together they form the tuning knob between cost and quality.

4. The Cost-Performance Tradeoff: Why This Pattern Pays Off

The value proposition of the Consultant Pattern becomes intuitive with a set of illustrative benchmark results. In an evaluation setting for coding tasks, the relative relationships typically look like this:

Approach	Relative accuracy	Relative cost
Low-cost model alone	Lower	Lowest
Low-cost model with consultant oversight	Close to the high-performance model	Medium
High-performance model alone	Highest	Highest

The pattern is clear: the combined approach reaches roughly 90% of the standalone high-performance model’s accuracy at about 60% of its cost. The reasoning is not complicated:

• Routine work is carried by the low-cost model, which accounts for the bulk of the computation.
• The high-performance model only “taps in” at critical nodes, so its strong judgment is placed precisely where it most affects success or failure.
• The overall outcome is therefore held up, while cost stays at the magnitude dominated by the low-cost model.

One caveat: the specific numbers vary with task type, model generation, and triggering strategy. The table above only illustrates the trend—concentrating expensive model calls on a few high-value nodes is the key lever for cost control.

5. Where It Fits

The Consultant Pattern is not a universal solution. It suits cases where an occasional high-level review is needed within a single task flow, typically including:

• Complex code generation: routine logic is written by the executor, while architecture decisions or tricky bug rulings go to the consultant.
• Proposal review: the executor produces multiple candidate versions, and the consultant gives trade-off recommendations at the key points of disagreement.
• Automation pipelines with dense decision nodes: operations remediation, risk-control judgments, and similar workflows where most steps can be automated, and expert-level review is introduced only at anomalies and high-risk nodes.

Conversely, if a task is demanding reasoning from start to finish—frontier mathematical proofs, complex system design—frequent consultations erode the cost advantage quickly. In such cases it is better to let a high-performance model lead throughout.

6. Comparison with Other Multi-Agent Patterns

The Consultant Pattern is easiest to understand within the broader spectrum of multi-agent collaboration:

• Executor-led (this pattern): the weaker model leads, the stronger model assists. The advantage is low cost; the risk is that the executor misjudges “this is not a critical node” and misses the window to ask for help.
• Strong-model orchestration: a high-performance model plans and schedules throughout, with lower-tier models handling subtasks. The quality ceiling is high, but so is the cost.
• Peer debate: multiple models challenge one another and converge by voting. Suited to scenarios that prioritize robustness but tolerate expensive runs.

The Consultant Pattern sits at the cost-sensitive end of this spectrum. By limiting consultation frequency, it buys a substantial cost advantage and represents a high-return engineering compromise.

7. Implementation and Best Practices

To put the Consultant Pattern into production, focus on the following:

1. Define “critical node” precisely. The trigger condition is make-or-break. Too loose and the consultant is called constantly, raising cost; too strict and correction windows are missed. Combining multiple signals—degree of ambiguity, blocked state, directional uncertainty—works well.
2. Cap the number of consultations. Set max_consult to 1–2 to avoid degenerating into high-frequency calls. The cap itself is a cost guardrail.
3. Ensure context is passed effectively. Consultant advice must be accurately understood and acted on by the executor. Keep the interface clear so that format or semantic drift does not cause advice to be silently ignored.
4. Observability and auditing. Log the trigger reason, latency, and cost of every consultation to make later tuning of the triggering strategy easier. General-purpose logging, monitoring, and alerting services can be used for collection and notification.
5. Keep a fallback path. When the consultant is unavailable or times out, the executor must be able to finish on its own so the main flow is not blocked by an external dependency.

8. Summary

The Consultant Pattern offers a pragmatic path: no need to run expensive models end to end in pursuit of peak quality, and no need to sacrifice quality at key decisions to save money. Through a clear separation of duties—low-cost models lead execution, high-performance models review on demand—it directs scarce high capability to the few nodes that matter most, achieving a solid balance between quality and cost.

For developers and enterprises building AI applications while constrained by inference costs, understanding and applying this kind of multi-agent collaboration pattern is an important lever for improving the system’s cost-effectiveness. The details that truly need polishing are the ones that decide success: when to ask, how many times to ask, and how to act on the advice.