A compiler for workflows written in plain English
Researchers at Purdue built Artic, a compiler that transforms a plain-English procedure into a structured workflow. Each step declares the data it reads and writes, and a deterministic script routes execution. On 488 tasks from 11 real-world domains, the compiled workflows resolve 28 percentage points more tasks than the original text, and they behave far more consistently across models and repeated runs.
The problem
Teams increasingly write procedures for agents in natural language: skill files, standard operating procedures, workflow prompts. The promise is that a domain expert can write the procedure once, and any agent can execute it. The paper argues this promise fails for two reasons.
First, a text workflow leaves data dependencies implicit. Every intermediate result stays in the agent's context, and any later step may read any of them. The authors compare this to a program in which all intermediate results are global variables. At each step, the agent must select the relevant results from a noisy context, and it sometimes selects the wrong ones. In their example from a healthcare benchmark, an agent must approve complex care because of a recent heart-failure event, but it instead follows the referring doctor's request for chronic care, because nothing marks which input the decision must use.
Second, the effort of following instructions grows with control-flow complexity and context load. A workflow that says "high risk or recent acute utilization" gets misread as and. Long workflows lose steps when the context gets compacted. The agent is an unreliable interpreter, and the text gives it too many ways to fail.
The idea: declare the data flow, then compile for it
The authors define an artifact-driven workflow. An artifact is a named intermediate result, such as a risk score or a utilization summary. Each step declares which artifacts it reads and which it writes. Constraints gate each produced artifact before execution continues. Explicit conditions route control between steps. Inside a step, the instruction can still be natural language, executed by a subagent — the structure constrains the data flow and the routing, not the local reasoning.
The key benefit is that this representation makes execution difficulty measurable. The compiler, named Artic, computes four signals with standard program analysis: how many branches a step contains (cyclomatic complexity), how much context one subagent must carry, how many artifacts must stay available across a point where the context gets compacted, and how much extra length the written-out artifacts add. When a step scores high, the compiler decomposes it into smaller steps with narrower inputs. An LLM proposes the workflow; the program analysis critiques it; the loop repeats. The authors call this constrained optimization: the analysis sets the limits, and the LLM searches inside them.
The compiled result is ordinary software: a deterministic Python orchestrator invokes one step module at a time, checks the produced artifacts against schema and quality gates, and follows the declared route. Artifacts are versioned, and failed attempts are never committed. Subagents only run inside steps.
Checking the compiler's work
The compiler itself uses an LLM, so it can mistranslate the source procedure. Artic validates each candidate in three passes. Static checks confirm that every artifact a step reads is produced on every path that reaches it — this catches procedures that create data inside one branch and silently assume it later. Inductive validation splits the large claim "the compiled workflow matches the source" into many small claims, one for each part of the workflow. An LLM checks each small claim, and the small checks are more reliable than one check of the whole. Dry-run simulation then extracts the decision predicates, generates concrete test scenarios that flip each predicate, and simulates the source text and the compiled workflow on each scenario independently. When the two traces disagree, the disagreement localizes the error.
Results
The evaluation covers 488 instances from 11 domains (customer service, order fulfillment, patient intake, and others) drawn from two benchmarks in which a program checks each result automatically. Across three executor models, the compiled workflows average 82–85% task resolve rate, against 46–62% for the raw text — the claimed 28-point gain. Two baselines matter. Rewriting the workflow as a clearer skill document helps inconsistently: it lifts one executor model by 16 points and does nothing for another. Asking a coding agent to implement the workflow as Python reaches 72–73% on average; it scores best on a few simple domains, but the authors report those scores come from brittle shortcuts such as keyword matching.
The consistency numbers are the stronger result. On the healthcare domain, the text workflow's resolve rate spreads from 28% to 60% across six executor models; the compiled workflow spreads from 72% to 88%.
On per-instance agreement — all six models pass or all fail the same instance — the compiled workflow reaches 80% against 48% for text. Under ten repeated runs, about 72% of instances pass every run, against 16% for text. Per-subagent input tokens drop 63%. Compilation is a one-time cost: under 5 minutes and under $3 per workflow with one compiler model.
Caveats the paper states: two domains stay weak for every representation, because the tasks need model judgment (is this mismatch a typo or fraud?) that no workflow structure can supply. All executions use one agent harness. The consistency and robustness deep-dives cover one domain. These are the authors' own benchmarks and measurements.
What you can do with it
The prototype is not yet released, but the design transfers directly. If you maintain agent skills or workflow prompts, the paper's four difficulty signals work as a lint check today: count the branches in each step, count the inputs each step actually needs, and split any step that scores high — give the split step only its declared inputs, not the whole conversation. The static join check is a useful review question for any procedure: does every path that reaches this step produce the data this step assumes? And the dry-run pattern — generate scenarios that flip each decision predicate, then simulate the old and new versions independently and compare traces — is a cheap validation recipe for any LLM-assisted rewrite of instructions, not only workflows. The larger claim is simple: a natural-language procedure becomes reliable software only when its data flow and its routing are explicit.