Use Agents to Discover the Workflow, Then Compile It to Code

An autonomous multi-turn agent loop is an expensive way to run a for loop you have not written yet. Teams preparing for Q4 budget renewals are discovering an uncomfortable pattern in their production traces: after the first month of operating an internal or customer-facing agent, the bulk of invocations in a mature workflow follow the exact same four-step tool sequence. Yet on every single run, the system still pays frontier reasoning token rates and ten-to-twenty seconds of serial model latency to re-decide that sequence from scratch. Token price cuts do not rescue a bill when your architecture uses a general-purpose planner to execute a settled state machine thousands of times a day.

In September 2026, Will Larson named the operating model that fixes this the “Software Factory” pattern: use agents and frontier models to explore messy, under-specified workflows until the shape of the work is clear, then refactor the recurring path into deterministic code. The mistake most engineering organizations make is treating “agentic” and “deterministic” as permanent properties of a product feature rather than stages in a workflow’s lifecycle. Autonomy is discovery scaffolding. Once the scaffolding has mapped the terrain, you should pour concrete over the highway and save the scaffolding for the unpaved edges.

To run that lifecycle as an engineering discipline rather than an occasional rewrite, wire a three-stage compilation contract into your agent platform. Stage one is discovery telemetry. When a new workflow launches, say triaging vendor onboarding packets or reconciling logistics exceptions, let a multi-turn agent handle the messy inputs under strict tool guardrails. On every completed trace, record a normalized trajectory signature: the input classification, the ordered graph of tool names and argument schemas invoked, the number of retry turns, and the final verification status. Within weeks, your trace store will show whether the workflow has a dominant mode: a small number of trajectory signatures accounting for the majority of production volume, and a tail of genuine edge cases.

Stage two is the compilation gate, and it requires three criteria to pass together before a trajectory cluster graduates into a deterministic Go service . First, sequence invariance: the candidate cluster must execute the same ordered tool graph across a defined share of traffic (for example, at least 75% of runs in that intake class over thirty days). Second, shadow-replay outcome equivalence: identical tool order does not prove that a deterministic workflow produces the same business result, because the agent may have been quietly normalizing messy intermediate payloads between calls. Run the compiled code path in shadow mode against held-out production traces and require outcome equivalence on the final state assertions before cutting traffic over. Third, economic return above the maintenance floor: every piece of software you own carries an operating cost , so only compile a path when unit_cost_savings × monthly_volume (or the latency SLA gain) pays for ongoing engineering ownership. In the compiled workflow, Go code owns the control flow, retries, and API orchestration, calling a narrow, single-turn model endpoint only at the specific step that requires unstructured extraction or classification.

Stage three is the de-compilation trigger, which is the piece most hand-rolled rewrites forget. Deterministic code is fast and cheap precisely because it assumes upstream APIs, document templates, and business rules stay inside a known schema. In production, a partner changes an invoice layout or a third-party API adds a status enum on a Tuesday afternoon. If your compiled path fails with a blind 500 error or restarts the whole workflow from step one after earlier steps have already mutated external state, engineers will route all traffic back to the slow agent loop permanently out of self-defense. Instead, persist a step-level execution checkpoint before each external call and wrap every step of the compiled service in strict input-schema and output-invariant sensors. When step m trips a schema or invariant check, the service does not crash or re-run steps 1 through m-1; it hands the trace, the committed step receipts from steps 1..m-1, and the active step-scoped idempotency keys to the guarded agent discovery lane so the agent resumes from the failing boundary, and pages the workflow owner with the schema diff once the fallback rate crosses a threshold, say 5% of hourly volume.

Track one ratio on your platform review dashboard this quarter: the share of completed production workflows executed by compiled code versus multi-turn agent loops, segmented by workflow age and compilation-gate eligibility. A newly launched workflow, or a low-volume workflow that has not cleared the three-part gate, belongs in the agent lane; a high-volume workflow that has been in production for ninety days, whose top trajectory clusters cleared the compilation gate a month ago, and that still runs ninety-five percent of its traffic through an open-ended planner is leaking margin and latency by choice. Ask the owner of your highest-volume agent a single question: which three tool sequences account for the bulk of last month’s traces, and why is a model still deciding that control flow on every request?