Workflow or Agent? Deciding for an Expense-Report Reviewer
Your company wants an LLM-powered system that reviews submitted expense reports. Two versions are on the table:
Version A: "Read the report, check it against the three standard policy rules (receipt attached, amount under $500, category is one of five allowed categories), and output approve / flag / reject with a reason."
Version B: "Read the report, investigate anything that looks off — cross-reference against the employee's travel calendar, check for duplicate submissions against the last 90 days of reports, look up whether the vendor is a known contractor the company already pays through payroll — and produce a recommendation with full justification."
- For each version, decide: fixed workflow or agent? Justify each decision using the criteria for "when not to build an agent."
- For whichever version you decided is an agent, specify concrete step/tool-call budgets and what should happen when the budget is hit.
- A colleague argues Version A should "also be an agent, just in case we add more rules later." Explain why that reasoning is backwards.
1. Workflow or agent, for each version
Version A is a fixed workflow. The rules are fully enumerable in advance — three checks, five allowed categories, one of three fixed outputs. Nothing about the task requires the model to decide what to check next; it always checks the same three things in the same order. This is exactly the "steps are enumerable" case: implement it as a short pipeline (extract fields → check receipt → check amount → check category → emit verdict), with an LLM call only where language understanding is genuinely needed (reading the receipt/description), not for the control flow. It is deterministic, unit-testable per check, and cheaper than a loop that re-decides "what should I check next" every time when the answer never varies.
Version B is a genuinely agent-shaped task. Which checks are worth running, and in what order, depends on what's found along the way — a report that looks clean after the calendar cross-reference doesn't need the duplicate-submission check to be exhaustive; one that looks suspicious after the vendor lookup might warrant deeper investigation the fixed three-rule version never anticipated. The branching isn't a small fixed set of known paths, and the "investigate anything that looks off" framing is explicitly open-ended. This is a case where the steps cannot be fully enumerated up front, which is the condition under which an agent earns its keep.
2. Budgets for Version B
Cap at roughly 4–6 tool calls per report: one calendar lookup, one duplicate-submission search, one vendor/payroll lookup, and at most one or two follow-up calls if the first pass surfaces something specific to dig into. A trajectory needing far more than that on a single expense report is itself a signal something is wrong (a confused loop, a tool returning unhelpful results) rather than a sign the report is unusually complex. On budget exhaustion: stop, summarize what was checked and what was found so far, and route to a human reviewer labeled "investigation incomplete — stopped at tool budget" rather than emitting a final approve/reject verdict the trajectory didn't actually earn. Any reject/flag with financial consequence should also require the underlying evidence to be shown, not just an LLM's summary of it.
3. Why "make A an agent just in case" is backwards
Autonomy is a cost paid for flexibility, and the argument for paying it should be "we have concrete evidence the fixed steps are insufficient," not "we might need it later." Making Version A a loop today buys nothing — it still checks the same three things, just more expensively (a full LLM decision cycle per step instead of a cheap deterministic check) and less testably (an agent trajectory is harder to pin down for a regression test than a three-stage pipeline). If a fourth rule is added later, add a fourth stage to the workflow — that is a one-line change, not a reason to have paid loop overhead the whole time it wasn't needed. The right sequencing is the one this subject argues for throughout: ship the workflow, measure where it actually falls short, and add autonomy only in the specific place the measured gap justifies it — never preemptively.
Share this question