Why a Stronger LLM Isn't Enough to Orchestrate a Reliable Conversational Agent
Published on September 10, 2026
The gist
On well-defined procedural tasks, a model given the whole procedure in its prompt outperforms a LangGraph orchestration. A study published in April 2026 measures it [1].
That gain is about average quality. It does not promise that an anomaly you have already spotted will never come back.
At Gamaro, a code harness surrounds the model. Inside it, an orchestrator drives the qualification forward. The guards that matter most (no repeated questions, free-text refusals, consistent business rules, the consent request) come from an empirical method: anomalies spotted while building the product became constraints in code.
So the edge does not come from the model, which anyone can call. It comes from that harness and the guards accumulated inside it, each born from a specific case, and impossible to rebuild in one go.
For a lead qualification agent, an uncovered edge case can cost a qualified prospect or create GDPR exposure.
The bet on a stronger model
Maintaining an orchestrator and hundreds of lines of guardrails gets expensive every time the product changes. Hence a reasonable temptation: put the whole procedure in the system prompt, plug in a few MCP servers for data access, and let the model run the conversation on its own.
That bet now has measured support. Dennis, Diamond, Patil, Shabahang and Guo ran the same model in two setups [1]. In one, it gets the full procedure in context. In the other, a LangGraph orchestrator routes the conversation from node to node. Across three procedural tasks, with 200 conversations per condition scored by an LLM judge, in-context steering scores 4.53 to 5.00 out of 5. The orchestrator scores 4.17 to 4.84.
Outright failures drop as well, in all three domains tested [1]:
Show the data
| Domain and architecture | Failure rate (%) |
|---|---|
| Travel (LangGraph) | 24 |
| Travel (in context) | 11.5 |
| Zoom support (LangGraph) | 9 |
| Zoom support (in context) | 0.5 |
| Claims (LangGraph) | 17 |
| Claims (in context) | 5 |
The authors themselves limit their conclusion to well-defined procedural tasks. On that ground, the result is serious. It measures rates across many conversations. It says nothing about the question a business agent has to settle: can a specific anomaly, already spotted and ruled out, come back?
What an average doesn't guarantee
A prospect repeats their question in an unexpected way. Two business rules contradict each other depending on the target city. A visitor refuses to leave their contact details, in their own words. An average score of 4.8 out of 5 says nothing about those conversations. At Gamaro, each of them was first an anomaly spotted while building the product, then a dedicated constraint.
Anthropic distinguishes two architectures [2]. A workflow routes tasks through predefined code paths. An agent lets the model direct its own process. An agent improves when the model improves. A workflow encodes a specific constraint, which no average score replaces.
Dennis et al. compare two extremes: the whole procedure handed to the model, or the whole conversation routed node by node through LangGraph. Gamaro sits between the two. An orchestrator written in code drives the qualification forward: which field to ask next, when the objective is met, when to move on to contact details and then consent. The model phrases the questions, interprets most free-text answers, and answers the visitor's digressions when the code lets it serve them.
Definition
The harness is the code that surrounds the model: choosing the next step, guards, tools offered or withdrawn, deterministic answers. The model does the phrasing; the harness decides the step and what the model is allowed to do.
On progression, then, Gamaro does what the study calls into question: an external orchestrator picks the next step. We keep it for a reason the study does not measure. "Objective met" is not just a moment in the conversation. It is a fact other components read: funnel tracking, the call to action, the consent request. It has to be computed by code, not estimated by the model.
A code constraint holds where an instruction gives way
The examples below come from our engineering history and internal test sets, not from measurements on real traffic: the product is still being built.
A model can follow a prompt instruction the vast majority of the time and still bypass it. We measured this with a dedicated metric, crush_rate: how often the orchestrator overrides a visitor's off-topic question to ask its own. Lifting the requirement to call the orchestration tool (forceToolUse: false) was not enough: the model called it anyway. The fix that held removes the tool from the catalog offered to the model for that turn. What no longer exists among its options cannot be chosen.
A few weeks later, evaluating a candidate model during a provider switch brought the problem back. Under that model, crush_rate stayed stuck at 1.00, across several runs and several temperatures. The hard lever already existed. The classifier meant to trigger it was missing cases: it caught 5 out of 8 on the diagnostic set. With richer labels, it catches 8 out of 8, and the metric went back to its expected level.
Both episodes teach the same lesson. A decision left to the model's judgment alone depends on the model. It can stop holding when you change LLMs, without a single line of code changing.
One guard per anomaly, rarely anticipated
The three guards below were not worked out in advance. Each came from a specific anomaly, spotted while testing the product.
A test session showed an agent asking the exact same question two turns in a row, even though the user had given two different answers. The repetition was bounded, but real. Fixing it took a redesign of the orchestrator, not a local patch.
On the real estate demo app, another anomaly blocked a multi-city search: zero results displayed despite 28 calls to the orchestrator. Two tool activation conditions ruled each other out in one specific configuration. The location data model had to be reworked.
A third case came from prompt labels that no longer matched the values a tool accepted. The prompt was fixed, and a lint rule, backed by tests, now catches that kind of drift.
None of these fixes followed from a general spec for a "good conversational agent". A competitor starting today with the best model and off-the-shelf MCP servers inherits none of them. We spotted them while building the product. They will most likely discover them in production, with their own users as detectors.
Refusals in free text
A visitor who refused in plain words to leave their contact details, instead of clicking the button provided, was not always heard. Exact-match detection missed the refusal as soon as it was phrased differently. For a lead qualification agent, that is a compliance problem as much as a conversational one.
The fix is a dedicated classifier, called as a fallback when deterministic parsing of the answer fails while contact details are expected. Its confidence threshold is deliberately high: 0.85, against 0.70 for a neighboring, less critical classifier. A refusal leads to a terminal state, so a false positive would silently lose a valid prospect.
Method
Internal evaluation set of 12 cases, including 5 refusals: precision 1.00, recall 0.60, no false positive. A sample this size is indicative, not a production measurement.
On this set, two refusals out of five still slip past the classifier. The threshold remains something to watch, not proof that the whole setup is compliant.
Consent as a state, not a judgment call
In production, a prospect converted without the agent ever offering them a confirmation email for their request. Sending that email requires the visitor's explicit agreement, and asking for it was left entirely to a prompt instruction. The model never asked, even though the matching tool was available on every turn.
The fix was not to word the instruction more firmly. When the option is enabled, the orchestrator turns the end of the conversation into a dedicated step: email collected, objective met, agreement not yet requested. Two fixed quick replies (accept, decline) then appear, and a deterministic follow-up takes over if the model leaves its turn empty.
The model still phrases the question, and recording the answer goes through a tool call it triggers on the next turn. But that turn no longer rests on free interpretation: the click can only take two values, and agreement is never inferred from a sentence. This does not prove end-to-end regulatory compliance. It removes a step where the model's judgment had already failed.
What a competitor can't copy by switching models
None of this refutes Dennis et al. On known, bounded procedures, a capable model steered directly can beat a poorly designed orchestration. But a lead qualification agent is not judged on its average quality. It is judged on the worst case a real visitor will eventually trigger, in a way nobody anticipated. On that axis, a harness that accumulates deterministic guards, anomaly after anomaly, builds a lead that a model switch does not close in one go.
The model is not the moat: anyone can call the same API tomorrow. The moat is the harness: the orchestrator that drives qualification, enriched by every anomaly already spotted and fixed. Each guard is written in code, so it can be read and tested. Sovereignty and Local Models makes the same case on the infrastructure and inference cost side [3]. This article is its counterpart on the orchestration side.
[1] Dennis, S., Diamond, M., Patil, R., Shabahang, K., Guo, H. (2026). In-Context Prompting Obsoletes Agent Orchestration for Procedural Tasks. arXiv:2604.27891.
[2] Anthropic (December 2024). Building Effective Agents.
[3] Gamaro (August 2026). Sovereignty and Local Models: The Hidden Cost of Inference at Leboncoin's Scale.