Loading lesson…
AI Workflows & Automation / Workflow Patterns
Knowing which steps should not be a model call.
Reviewed by Yuvaraj
Every AI automation is a pipeline of steps, and the single most consequential design decision you make is which of those steps run as plain code and which run as model calls. It is tempting to reach for a model everywhere because it feels flexible, but a model call is the most expensive, slowest, and least predictable tool in your toolbox. The craft of building reliable automation is knowing where genuine ambiguity lives, spending model calls only there, and surrounding each one with deterministic code that catches its failures.
A deterministic step is ordinary software. Given the same input it produces the same output, every time. Parsing a date, validating a JSON shape, summing a column, matching a known status code, calling a REST endpoint, or branching on an explicit rule are all deterministic. These steps are cheap (fractions of a cent), fast (microseconds to milliseconds), and, crucially, testable: you can write a unit test that pins the behavior forever.
An AI step is a call to a model that maps fuzzy input to a plausible output. Its strength is handling things you cannot enumerate in advance: free-form language, messy layouts, intent, tone, classification with no clean rule. Its costs are real. Each call has latency and a dollar price, and the output is non-deterministic, the same prompt can return different text across runs, model versions, or temperatures. You cannot unit-test an exact string; you can only test the shape and constraints of what comes back.
The heuristic follows directly: if the rule is already known, write the rule. Use a model only where the rule cannot be written down.
Consider a pipeline that ingests supplier invoices as PDFs and posts them to a ledger. Notice that only one step genuinely needs judgment.
Ask about this lesson, or about anything in AI. Answers cite the lessons they draw on.
Finished this lesson?
Mark it complete to earn XP, keep your streak, and schedule a review.
Five of the seven steps are deterministic. The model does exactly one job, turning unpredictable text into structured fields, and its output immediately flows into deterministic checks that verify the numbers add up and the vendor exists. The model is never trusted; it is bounded.
Because a model can return anything, an AI step is only production-ready once deterministic code stands on both sides of it. On the way in, constrain the request (a tight prompt, a required output schema, examples). On the way out, validate before you trust: parse the response against a schema, reject malformed output, retry with backoff on transient failures, and run domain checks such as the total reconciliation above. If validation fails after a bounded number of retries, fall back to a human or a safe default rather than passing garbage downstream.
A useful reframing
Treat every model call as an unreliable remote service that occasionally lies. You would never post its raw output straight to a ledger, so wrap it exactly as you would wrap any untrusted API: validate, retry, and have a fallback.
Common mistakes
regex or an if would do. Classifying a status that has five known values, or extracting a date in a fixed format, is deterministic work. A model here just adds cost, latency, and a new failure mode.