Alibaba Cloud has removed "planning" from the AI agent that handles Elastic Compute Service (ECS) inquiries—at least for cases that recur repeatedly. "DualLane," presented at KDD 2026, routes known routine cases to pre-verified templates and reserves LLM-based solution construction only for unknown cases. The paper reports that after more than a year of production operation, it achieved 96.5% accuracy in offline evaluation, a median planning-and-execution time of 4.2 seconds online, and an agent-attributed error rate of 7.1%.
What this design targets is the assumption that making an agent smarter necessarily makes operations more stable. In responding to cloud incidents, if any single element breaks down—the tool chosen, the arguments passed, the execution order, or how results are interpreted—a plausible-sounding but wrong answer gets returned to the customer. Rather than putting the model's reasoning ability front and center, DualLane gains speed and accuracy by routing high-repetition domains back to deterministic processing.
Routine Cases to Templates, Unknown Cases to LLMs
Support inquiries don't arrive uniformly. Highly repetitive cases—can't connect, instance won't start, need to check a configuration value—arrive in large volumes, while cases involving multiple services or failures form a long, low-frequency tail. According to Alibaba Cloud's current documentation, the ticketing desk is included in all support plans from Basic to Enterprise. However, the deployment reported in the paper is within ECS production environments, and it's unclear from the public abstract which regions or plans DualLane actually serves.
According to The Register, DualLane runs a fast lane and a slow lane in parallel for each inquiry. When the fast lane determines that the case is a known, routine one, it selects the corresponding execution template and halts the slow lane that's still in progress. Because the system isn't structured to spend time on classification before invoking the LLM, even unknown cases enter planning without waiting for routing. For routine cases, the slow lane can be stopped before it reaches a maximum of 3,000 tokens.
The fast lane's templates aren't macros that simply paste in past response text. They are execution procedures with the necessary operational tools and dependencies pre-verified. Because the LLM doesn't reinvent tool configurations for each inquiry, the same processing can be applied to the same type of case. The fast lane is short not so much because it generates less text, but because it skips the planning search itself.
That said, since both lanes are launched simultaneously, the compute the slow lane consumes before the fast lane's determination completes doesn't disappear. The public abstract doesn't state what percentage of all inquiries the fast lane covers, or how many tokens are spent before cancellation. To measure the actual savings, one needs to look at the lane ratio in real traffic and the speculative-execution overhead, rather than the theoretical per-case ceiling.
Why Separate Planning from Argument Generation
In the explanation quoted from the paper by The Register, the Alibaba Cloud team divided the places where conventional agents make mistakes into four categories: failing to select the necessary tool; getting the tool name right but the arguments wrong—missing, mistyped, or wrong data type; failing to extract from an earlier execution result the value needed for the next step; and finally, misreading a tool's output or dropping key points from the answer. Even when the response reads smoothly as natural language, the correctness of this chain is not guaranteed.
The slow lane splits task decomposition and concrete argument generation into two stages. First it builds a dependency graph specifying "what to investigate, in what order," and then, at the point of calling each tool, it fills in the arguments using results accumulated so far. For example, when retrieving an instance's status and then checking network settings or monitoring information depending on that result, the identifiers or conditions needed for the later call aren't determined until the earlier step finishes. This localizes the handoff of values, rather than generating arguments for the entire workflow in one batch upfront.
ReAct, used as a comparison point, alternates between LLM reasoning and tool execution. While this allows flexible reaction to intermediate results, it tends to serialize processes that could otherwise run independently. LLMCompiler generates a task graph with dependencies and reduces this waiting time by parallelizing independent calls. DualLane also handles dependencies across multiple tools, but for high-frequency cases it skips even the step of generating a new graph. It doesn't replan known procedures—it only constructs procedures for the unknown ones.
Don't Read the Three Performance Numbers on the Same Scale
96.5%, 4.2 seconds, and 7.1% each measure DualLane's effect from a different angle. 96.5% is offline benchmark accuracy, 4.2 seconds is the median time from planning to execution in production, and 7.1% is the proportion of online errors attributable to the agent. Consequently, one cannot interpret the gap behind the 96.5% figure as a 3.5% production error rate, nor treat it as a contradiction with the 7.1% figure.
The "agent-attributed" qualifier also carries meaning. Cloud inquiries involve multiple causes beyond service-side failures and customer misconfiguration, including insufficient permissions and network issues. The 7.1% figure doesn't represent the overall unresolved-ticket rate—it refers specifically to errors attributed to the agent's planning, execution, or answer generation. The overall resolution rate and the rate of handoff to humans are not disclosed in the public abstract.
According to The Register, the internal cost of the maximum 3,000 tokens consumed by the slow lane is roughly $0.001, and Alibaba Cloud does not cite token cost as a primary motivation. Even when the dollar amount is small, plans involving tool calls increase both response time and the opportunity for errors. DualLane's economic value shows up not in the per-token price but in the time humans spend re-investigating misanswered tickets and the time customers spend waiting for recovery.
That said, the disclosed numbers alone don't let us isolate each lane's individual contribution. Without the fast lane's precision, the slow lane's standalone success rate, the rate of mistakenly classifying a case as routine, and the rate of handoff to humans, the 96.5% figure cannot simply be applied to other companies' support agents as-is. The results were obtained within Alibaba Cloud's own ECS environment, and all 11 authors are affiliated with the company.
What Learns Is the Operational Pathway, Not the Model
According to The Register, DualLane clusters the inquiries that keep remaining in the slow lane, and when similar cases recur, it flags them as candidates for promotion to the fast lane. Rather than automatically activating a template at that point, a human reviews the content before it's added. This lets a previously unknown problem turn into reusable operational knowledge, while avoiding the risk of locking in an incorrect LLM-generated plan as a standard procedure.
This cycle moves the agent closer to being operational software with verified procedures and exception handling, rather than a "model that reasons through everything each time." High-frequency processing runs as compiled pathways, while only the long tail is left to LLM interpretation. Successful procedures repeated in the field can be moved to the fast side without waiting for a model update.
The scope of applicability is clear. This approach works better in operations where similar inquiries cluster together, tool input/output specifications remain relatively stable, and correct procedures can be verified by humans. In investigative work with little repetition, or tasks where the objective itself shifts midway, the proportion that can be moved to templates drops. Furthermore, if ECS's APIs or diagnostic procedures change, previously verified templates must be updated as well.
The next benchmark for DualLane won't be flashy model performance, but rather the proportion the fast lane can safely cover. If the misclassification rate, the template revision interval, and resolution time including post-handoff-to-human time are disclosed, we'll be able to judge whether the two-lane design can be replicated beyond ECS. It's not the ability to use LLMs more, but the ability to decide where not to use them, that is starting to distinguish the maturity of production agents.