Production agents burn latency and reliability re-solving the same routine on every request, regenerating query code for steps that never change. This system compiles each repeated step into a validated, versioned tool the agent calls directly — falling back to writing code only for genuinely new steps. In a live fulfilment-centre alarm-triage system that cut median latency 42% and end-to-end errors up to 53%, and a simpler direct-call design cut latency a further 62%.
A production triage agent follows a fixed standard-operating-procedure: a decision tree of 44 decision nodes and 19 action nodes. Decision nodes come in three kinds — observations (test a metric against a threshold), root causes (name the failure), and constraints (gate an expensive action, e.g. “is the collector belt empty enough to justify a staffing change?”). Most of these steps are identical from one alarm to the next.
The common pattern still handles them with a code-writing sub-agent: for every alarm it generates fresh query code, executes it against the tool/data environment, reads the result, and reasons to a verdict — again for the next alarm, and the next. That costs latency, and because the code is regenerated each time it also varies run-to-run: a datatype it silently coerces today it might mishandle tomorrow. The waste shows up plainly in the token bill.
The fix moves the coding loop out of the request path and into a build step. Before deployment, a three-stage tool-maker turns each SOP node into a single tool with a fixed signature — (warehouse, timestamp, context) in, a structured verdict out: (verdict, observed value, threshold, explanation). Step through it on one node — the belt-empty constraint that gates a costly staffing change.
At runtime the production agent simply calls the deployed tool. If a tool is missing or throws, it falls back to the original code-writing sub-agent — the same one used to collect data in stage 1 — so nothing is ever worse than the baseline.
Slotting the tools into the existing sub-agent already cuts latency. But because a tool returns a compact structured verdict instead of a wall of code and raw data, the sub-agent layer stops earning its keep — the main agent can call tools directly. Each step down simplifies the architecture. Pick an architecture and watch p50/p99 latency and the error rate move together.
Latency indices are model-agnostic (baseline = 100). Error rates are end-to-end on 1,500 historical alarms with GLM-4.5-Air; Qwen3 32B shows the same direction (2.8% → 1.8% for the first two arms).
A tool is only worth calling if it is correct. Two stages carry that: giving the tool-maker the data-collector’s execution trace, and running the test-repair loop. Ablate each and watch per-node Pass@1 (best model, GLM-4.7). Neither alone reaches the deployed number.
With trace + repair, most residual failures traced to just 4 of the 44 nodes — where the human-written SOP text was ambiguous (unclear averaging windows, unstated edge cases). The tool-maker cannot invent the author’s intent, but it localised the ambiguity. Clarifying only those four nodes’ wording closed almost all the gap.
Regenerated code silently adapts to whatever it sees — which means real environment changes disappear into run-to-run variance. A tool has stable, reproducible inputs and outputs, so the same drift becomes a visible, pinpointed signal. Three real production issues surfaced this way:
If your agent re-runs the same procedural step across requests — “check inventory before confirming an order”, “look up the account tier”, “validate the shipping address” — you are paying to re-solve it every time, and inheriting whatever the model improvises that run. Flip the same step between regenerating code and calling a compiled tool. Illustrative walkthrough — the code is simulated; the paper’s measured effects are the direction, not these exact numbers.
This is validated on one application (outbound-dock alarm triage); generalisation to free-form runbooks or other domains isn’t established. The loop still retains human oversight — it doesn’t yet guarantee every failure is caught without review of newly generated or repaired tools, and clarifying an underspecified SOP is inherently a human task, since the spec encodes the author’s intent. Tool creation still benefits from labelled cases: a label-free variant trails the labelled ceiling by ~3 points (91.6% vs 94.5%). What is real: the tools have run across 5,000+ production alarms since deployment.
When you catch the agent re-deriving the same multi-step routine on every request, compile that routine into a validated, versioned tool it calls directly — and fall back to generating code only for genuinely new steps. In the paper's alarm-triage system that cut p50 latency 42% and errors up to 53%.