The agent was reasoning about a supply chain it couldn't touch
Amazing Digital Dentures pitched a compelling story: take the chaos of dental appliance logistics—impressions, fabrication, try-ins, remakes—and hand it to an AI agent that reasons through multi-party workflows in real time. The model was GPT-4o. The demo was fluid. The startup raised money.
The failure wasn't the model. It was that the LLM had no hands.
The agent could talk about dental logistics, could describe what it should do next, but it couldn't actually touch the systems that mattered: the lab management software where appliances live, the courier APIs that move them, the dental practice management systems (Dentrix, Open Dental) where prescriptions originate. It called them as functions, sure—but those functions hit dead ends, returned nulls, and the agent had no way to know which were real constraints and which were hallucinations.
The uncomfortable rule: if you don't own or deeply integrate with the system of record, your agent is a chatbot with extra steps. It can reason beautifully about abstractions. It cannot command the actual operations that matter.
Unglamorous constraints the demo never showed
Dental appliance logistics isn't a reasoning problem dressed up as one. It's a domain where tiny failures compound into waste, and where the business already knows exactly what goes wrong and how often.
Impression-to-fit tolerances are measured in 0.1mm increments—not tokens, not semantic understanding. A denture mold that's off by half a millimeter is a remake, a two-week delay, a patient in pain, and a cost the lab absorbs at 15–25% remake rates across a typical month. An agent can't reason its way around dimensional reality. Neither can an LLM. Nor should it have to.
Then there's the multi-party handoff: dentist submits impression and prescription; lab receives and scans the mold; technician fabricates; courier picks up and ships; dentist tries it in; if it doesn't fit, the lab remakes it and the cycle repeats. Every handoff is a state transition. Every transition has a window (the dentist has a 7-day window to try-in or the whole case risks insurance pre-auth expiration). Insurance coding—D5110 for the denture, D5120 for remake—has pre-authorization windows. The impression itself is a Class II FDA device requiring lot tracking and traceability. None of this is in the model's pretraining. All of it is non-negotiable.
A generalist agent reasoning loop cannot absorb these constraints because it has no enforcer. It can output "remix the case" but can't guarantee the 0.1mm tolerance. It can suggest a courier but can't prove the shipment meets lot-tracking reqs. It hallucinates. The business fails silently until a patient complains.
This is what the hidden cost of manual ops feels like in motion: someone manually checking the agent's output because the agent can't be trusted with the details.
Reasoning loops vs. purpose-built workflows: when each wins
We've shipped both. Here's the decision framework we now use internally.
If your problem has a bounded state space and hard constraints—impression received, scanned, fabricated, shipped, tried-in, remake or closed—and if the transitions are deterministic, you want a workflow. Workflows are dumb, fast, and predictable. A six-step deterministic workflow (receive → scan → fabricate → ship → try-in → decide) costs about $0.002 per run, runs at p95 latency under 2 seconds, and fails loudly when something breaks. You know exactly where it broke and why.
Agents live in open-ended planning: "given this incomplete information and these 47 tools, figure out what to do." They're beautiful when you genuinely don't know the path ahead. They're expensive and slow when the path is well-worn. An agent loop averaging 14 tool calls costs $0.30 per run, p95 latency runs 20–60 seconds with retries, and when it fails, it fails silently in the middle of reasoning. You find out when a patient hasn't heard from the lab in three weeks.
Amazing Digital Dentures should have landed on a workflow with a narrow LLM call for triage—"given this impression and this patient history, is this a routine case or does it need escalation?"—not a planner pretending to orchestrate a supply chain it couldn't touch. When to build an agent vs. a workflow outlines the tradeoffs in more detail, but the lesson here is simpler: if you can describe the work as a flowchart, start with a workflow.
What 'deep integration' actually looks like in code
The gap between a demo agent and a production one is integration depth. Most teams miss this entirely.
Real integration means owning (or wrapping) the system of record. For dental logistics, that's the lab management software, the courier APIs, the PMS integrations. It means typed tool schemas with idempotency keys—not "call the lab API", but "call create_job with impression_id, dentist_id, material_spec, idempotency_key, and expect status 201 or 409 if the job already exists." It means webhook-driven state machines so the agent reacts to physical events: "package scanned at origin", "package in transit", "try-in completed"—not polling or waiting for the agent to remember to ask.
It means idempotent retries on 409, 429, 503 with dead-letter queues for cases the system can't auto-recover. It means eval harnesses tied to operational KPIs—remake rate, turnaround time, insurance pre-auth expiration rate—not BLEU scores. The "agent" itself is often 200 lines of LLM glue around 2,000 lines of integration plumbing. The 2,000 lines is what separates a product from a press release.
We've seen what agentic workflow engineering actually required under the hood—teams cut requirements analysis time, but only because they built the integration skeleton first, instrumented it, and then added the reasoning layer. The teams that bolted reasoning on top of unintegrated systems? They're still debugging.
The pattern we now use before writing a single prompt
Before you open a text editor to spec an agent, run this checklist with your ops team and your engineers in the same room.
Map every external system. Lab management software: API, scrape, or nothing? Courier: API or nothing? PMS: API, webhook, or nothing? Mark which you control and which are someone else's black box. If more than half are black boxes, stop here.
Enumerate the failure modes the business already tolerates. Remake rate? Try-in delays? Insurance pre-auth expirations? If it happens 3% of the time today, an agent that hallucinates 5% of the time is a net loss.
Identify the 3–5 decisions that actually need reasoning. Routing a complex case to a specialist? Maybe. Deciding impression quality is acceptable? Probably not—that's a deterministic check. Scanning for dimensional conformance? Definitely not. Most operational workflows have maybe two or three decisions that are genuinely open-ended. Everything else is plumbing.
Build the workflow skeleton first. Wire the systems, test the integrations, instrument for operational KPIs. Add LLM nodes only where deterministic logic loses and the upside is clear. Right-size your agent's reasoning model with a cost audit: does the marginal value of better reasoning justify the latency and token cost?
Kill the agent if it doesn't win on the first 100 cases. If a rules engine gets the decision right 94% of the time and your agent gets it right 93%, you've added cost and latency for nothing. Ship the rules engine. Add the agent later if the domain shifts.
Before you spec another agent, list every system it needs to touch and mark which ones you actually control. If more than half are someone else's black box, you're building a press release, not a product. If you want a second set of eyes on that map, contact us.