A same-model decider above an agent's writer: one task, two configurations
An AI agent can be built so that every step takes two model calls. The writer is the model that does the work: it proposes the next action and writes the document. The decider is a second model call that looks at the writer's proposals and picks which one to carry out. The hope is that the decider catches the writer's mistakes.
To test that, we ran one research task twice, once with a decider and once without. Both used the same model for every role, because that was our default setting.
The run with a decider took 6.3× as long, made 3.1× the model calls and sent the model 10.7× as much text. It produced exactly the same document, with the same mistakes in it.
What a research run is
hedwigai makes workbooks: documents such as reports, trackers and lists that AI research runs write and keep current.
A research run is an AI agent given one piece of work, here “find more people to write to”. It works in steps. Each step is a tool call: an action such as running a web search, opening a page or editing the document. This post is about who chooses each tool call: the writer alone, or a decider above it.
In short
- Question
- Does a decider that picks each tool call, from options another model proposes, change what an agent run produces?
- Setup
- One document, one four-word instruction, two runs that differ only in the decider. The same model filled both roles, because that was our default.
- Result
- The same document, including the same three email addresses that do not accept mail. It took 6.3× the time, 3.1× the model calls and 10.7× the prompt tokens.
- Limits
- One task and one run each way. It says nothing about a decider that is a different model from the writer.
- What changed
- The default is now one model. A decider is used only when a second, different model is chosen for it.
How the test was set up
Our agent runs can be set up two ways. With one system, one model writes the document and makes the tool calls itself. With two systems, a decider sits above it. On every step, the writer proposes some tool calls, and the decider chooses which one to make and with what details. That costs an extra model call for every decision. We expected it to pay for itself by catching bad tool calls.
Both runs started from the same document, restored to the same version: a contact list that already held six people. The instruction was the same four words, deliberately open ended: find four more people to write to at companies in one trade. Everything else was the same too: the code that runs the agent, its tools, its time limit and the writing model. The only difference was the decider.
What happened
Time and cost
Time is wall clock: how long the run took from start to finish. Model calls count each time a model was asked for a response. Prompt tokens measure the text sent to the model across all those calls. A token is a small piece of text, and it is what model use is billed by.
| Setup | Time | Model calls | Prompt tokens |
|---|---|---|---|
| Two systemsa decider above the writer | 23m 36s | 104 | 6,623,438 |
| One systemthe writer, addressed directly | 3m 46s | 34 | 619,648 |
The documents
The two documents were identical: the same four contacts, in the same order, at the same four companies, with the same addresses. A line-by-line comparison of the two found no difference.
They were also wrong in the same way. Afterwards, a tool that checks whether an email address accepts mail found one of the four new addresses good and three not. One of the three had been removed from this same document two versions earlier, because it did not accept mail. Both runs added it back, even though the earlier versions were there for either run to read. The decider did not catch any mistake the writer made.
Why the decider added nothing
Both roles were filled by the same model. The decider was choosing among options proposed by another copy of itself. The arrangement added a second bill, but no second opinion.
That was the default for every new workbook. The code that sets up a run says, in a comment, that one model deciding over itself is not worth paying for. Four lines above that comment, the default put the same model in both roles anyway.
Our run records could not tell the two setups apart either. Both recorded the decider's model as the model they ran, because that field is always filled with it. We had to fix the records before this comparison could be read from them.
What this does not show
- One task, one run each way. Runs on this same document have used between 22 and 104 model calls, depending only on how specifically the instruction was worded, so a smaller gap would be noise. The 10.7× token figure is well outside that range, and identical output is not a matter of degree. Still, the exact multiple should not be relied on.
- Part of the time gap is probably a head start. The one-system run went second, in a session where the first run had already loaded files it could reuse (a cache).
- It is about a same-model decider only. That is what our default did. Whether a different, cheaper decider pays for itself is a separate question this test does not answer.
What we changed
One system is now the default: the writer makes its own tool calls, with no decider above it. A decider is used only when someone picks a second, different model for it. That is the one setup in which it has a second opinion to offer, and it no longer has a default.
Runs now record the setup they actually ran under, so the next comparison can be read back from the records.
Measured on one workbook, 23m 36s and 3m 46s of wall clock, September 2026. The task was contact research; contact details are withheld.