Advisor Consult

also known as Advisor Strategy, Advisor Tool, Executor-Advisor Split, Strong-Model Consult

Let a lower-cost executor model run the whole task and, at decision points it chooses, consult a stronger advisor model that reads the full transcript and returns guidance only, never actions.

This pattern helps complete certain larger patterns —

specialisesAdaptive Compute Allocation★— Allocate inference-time compute (thinking tokens, samples, depth, model size) per query based on input difficulty, rather than using a fixed budget across all queries.

Context

A long agentic task such as a refactor, a browsing session or a multi-step research run consists mostly of mechanical turns: read a file, call a tool, apply an edit. A few turns decide the outcome, for example choosing an approach, diagnosing an error that keeps coming back, or judging whether the work is actually finished. A smaller model handles the mechanical turns well and cheaply, while a frontier model handles the decisive turns better but costs several times more per token.

Problem

Running the strongest model on every turn pays frontier prices for work that a smaller model does just as well. Routing each request to a model tier up front does not help, because the hard moments appear in the middle of a run and cannot be predicted from the request. Delegating a hard sub-task to a stronger sub-agent hands over control and forces the parent to summarise its context into a task string, losing the tool results and failed attempts that make the decision hard. Planning once with a strong model and executing with a weak one fixes the plan before the executor has met the problems the plan did not foresee.

Forces

Most turns in a long run are routine, so token spend is dominated by turns that do not need the strongest model.
The turns that decide the outcome cannot be identified before the run starts; they surface as the executor meets the task.
A useful second opinion needs the evidence the executor has gathered, including failed attempts, not a summary the executor chose to write.
The party that knows when it is stuck is the executor, yet a weaker model is also the one least able to recognise its own blind spots.
Advice that the executor must obey can be wrong about local facts it never observed, while advice it may ignore is only as useful as the executor's willingness to act on it.

When to use

Long agentic runs where most turns are mechanical but a few decisions determine the outcome.
A cheaper model handles the routine turns well, and a clearly stronger model is available for the same provider or harness.
The hard moments cannot be predicted from the request, so up-front routing would either overpay or underperform.
The second opinion needs the gathered evidence, including failed attempts, not a summary.

When not to use

Tasks are short, so there is little to plan and the consult overhead outweighs its benefit.
Every turn needs the strongest model, in which case switching the main model is simpler.
The executor is already close to the advisor in capability, so consults add cost with little gain.
The transcript cannot be shared with a second model for data-handling reasons.
The hard part is a well-bounded sub-task that should run in its own loop with its own tools, which is agent-as-tool embedding.

Example

A coding agent running on a mid-size model is fixing a flaky test in a large repository. Most of its work is reading files and running the test suite. After the same timeout error appears three times, it asks the advisor, which reads everything the agent has tried and points out that the test depends on a shared fixture the agent never looked at. The agent opens the fixture, fixes it, and finishes without the stronger model ever touching a file.

Diagram

sequenceDiagram participant App as Application participant E as Executor (cheaper model) participant H as Harness participant A as Advisor (stronger model) App->>E: Task with tools + advisor tool loop Routine turns E->>E: Tool calls and edits end E->>H: advisor() at a decision point H->>A: Full transcript, read-only Note over A: No tools, no user output A-->>H: Plan, correction, or stop H-->>E: Advice as tool result E->>E: Check advice against evidence, continue E-->>App: Final answer

Solution

Therefore:

Expose the advisor to the executor as one tool with no meaningful arguments. When the executor calls it, the harness, not the executor, assembles the advisor's input from the full transcript: the system prompt, tool definitions, prior tool calls and their results. The advisor runs as a separate inference pass under its own instructions, with no tools of its own, and returns guidance text such as a plan, a course correction or a recommendation to stop. That text is inserted as the tool result and the executor continues in the same request. The executor decides when to consult; typical moments are before committing to an approach, when an error recurs, and before declaring the task done. Because the advice is guidance rather than a command, the executor still checks it against what it has observed and surfaces a conflict when a recommended step fails or contradicts the files. A per-request cap on consultations bounds cost, and advisor tokens are metered separately from executor tokens so the trade-off stays visible. Where the executor under-consults, a single nudge early in the run, or a forced call at a known decision point, restores the call rate.

What it gives you

Quality on hard tasks rises toward that of the stronger model while most tokens are billed at the executor's rate.
The advisor judges from the actual evidence, including failed attempts, because it reads the transcript rather than a hand-written brief.
Control never leaves the executor, so there is no handoff to coordinate, no second agent loop to debug and no merge of two conversations.
Adding or removing the advisor is a one-line change to the tool list, which makes it cheap to run the same workload with and without it.

What it costs you

Each consult re-reads the whole transcript at the advisor's input price, so late consults on a long run are the most expensive ones.
The weaker model decides when to ask, and it is the model least able to notice what it does not know, so under-consulting is the typical failure.
The executor's stream pauses while the advisor runs, adding latency at exactly the moments the run was already slow.
The gain shrinks as the executor's own capability approaches the advisor's, so the pairing must be re-measured on every model upgrade.

What this pattern forbids. The advisor must not call tools, write to the user or take over the run: it only reads the executor's transcript and returns guidance text, and control returns to the executor after every consult, at most a capped number of times per request.

And the patterns that stand alongside it, or against it —

alternative-toAgent-as-Tool Embedding★— Wrap a sub-agent (with its own loop, prompt, and tool palette) behind a single function-shaped tool signature, so the parent agent calls it like any other tool and never sees the sub-agent's internal turns.
alternative-toPlan-and-Execute★★— Plan all the steps once with a strong model, then execute each step with a cheaper model under the plan.
complementsMulti-Model Routing★★— Send each request to the cheapest model that can handle it well.
alternative-toComplexity-Based Routing★— Estimate a request's difficulty up front and bind it to the cheapest model tier that can answer well, using an explicit complexity classifier as the routing key.
complementsTop-Tier Model For Everything (Cost)✕— Anti-pattern: route every request through the highest-tier model regardless of difficulty, treating cost as a model-choice problem instead of a routing one.
complementsEvaluator-Optimizer★★— One LLM generates; another evaluates and feeds back; loop until criteria are met.
complementsDegenerate-Output Detection★— Detect when the agent is about to emit a near-duplicate of its own recent output and either drop, replace, or escalate to a stronger model rather than ship the loop.
complementsStep Budget★★— Cap the number of tool calls or loop iterations the agent is allowed within a single request.
complementsReflexive Metacognitive Agent·— Agent maintains an explicit self-model of its own capabilities, confidence and limitations, and reasons over that model when accepting / refusing / handing off tasks.