94% in the demo, 11% in production: the agent gap is architectural

A logistics company in Dubai ran an "autonomous customer operations" pilot that resolved 94% of test cases without a human in the controlled demo, then resolved 11% of cases on live traffic of roughly 4,000 tickets a day ^[1][2][3]. According to the consultant who wrote up the visit on dev.to, the demo was not faked and the model was fine; what was missing was any design of the system's architecture ^[5]. The arithmetic matters more than the percentages. Eleven percent of about 4,000 tickets is roughly 440 closed a day, leaving about 3,560 to land on humans ^[2]. At the demo rate the same queue would have closed about 3,760, so the distance between the slide and the staffing plan is on the order of 3,300 tickets a day ^[3]. The residue was not inert either: the agent hallucinated a delivery promise onto at least a dozen of the cases it did not resolve, and some of those promises turned into refunds and re-shipping ^[6][7]. That is the shape of the risk. An agent that declines to act is a throughput problem. An agent that invents a commitment on the company's behalf is a liability, and real traffic (messy addresses, late tracking feeds, angry customers) is exactly what produces those cases ^[4]. The stated diagnosis is blunt: someone pointed a capable model at a prompt, wrapped it in a loop, and called it an agent ^[8]. The author's framing is that "agent" is a marketing word while "topology" is the engineering one, meaning how many reasoning loops exist, how they talk to each other, who owns the state, and who decides what happens next, and that when a production agent collapses it is almost never the model's fault but a topology that did not fit the task ^[9][10]. The guide sorts every architecture into six of those topologies, each with its own cost profile, failure mode, and narrow band of tasks it is actually good at ^[11]. The single loop, one model and one context window with tools and a budget counter, is cheapest and fastest and suits narrow work such as balance lookups and form extraction ^[12]. The router puts a small fast classifier in front of specialised handlers, adding one cheap call ^[13]. Orchestrator plus workers, which is what most people mean by "multi-agent," fits report generation, research, and code review at medium cost ^[15]. Hierarchical orchestration is high cost and high latency, justified for enterprise pipelines over thousands of documents and usually a mistake elsewhere ^[16]. Peer collaboration, the CrewAI and AutoGen picture of researcher, writer, and critic, bills a full model call per turn and is unsuited to anything with a deadline and a fixed budget ^[17]. The sixth has no loop at all: a directed graph of steps, each deterministic or model-assisted, with the lowest per-step cost and predictable latency, which is what LangGraph's graph model and n8n's nodes already are ^[18]. Two of the author's own preferences are the useful part. The router is called the most underrated pattern in production and the first one he reaches for, and the worked example is a ticket triager that sends payment disputes to a refund workflow and delivery questions to a tracking tool ^[13][14]. The graph is called the most honest pattern in the list, on the grounds that most "agent" use cases are secretly a known process with a few fuzzy decision points ^[19]. The Dubai pilot was ticket triage with a delivery-tracking tool. It was built as a single loop. What to watch, on your own pilots: the demo pass rate is not a forecast, so measure resolution rate against live volume, and count the unresolved cases in which the system still made a promise to a customer.