The Forward Deployed Audit: Deciding Which Workflows Actually Need AI

Forward deployed engineering is usually pitched as installation work: an engineer shows up, wires a model into your systems, and leaves you "AI-powered." That pitch has the job backwards. The real deliverable is a classification. You walk the business's actual workflows step by step, and for each step you answer one question: does this need judgment, or does it need a script? Most steps need the script.

I run software this way for a living - for a paying client, and for my own operation, a portfolio of production apps maintained largely by autonomous agents. Both were audited with the same method, and both landed on the same shape: deterministic software does the bulk of the work, agents are reserved for the narrow set of steps that need a reader, and a human holds the irreversible ones. Every number below is measured from systems I operate.

Deployment is an audit, not an installation

A forward deployed engineer embeds with a business in a way a normal vendor never does: you sit inside the workflows, run them end to end with the people who own them, and then own what gets built. The tempting move - and the sales pitch of the moment - is to route everything through a model, because a model can plausibly do anything. Plausibly is the problem.

Non-determinism has a price list. Tokens cost money on every run. Latency is variable. The same input can produce different outputs, so every output needs review, because it can be differently wrong each time. Paying those prices for work a script could do identically forever is the defining mistake of enterprise AI adoption right now. The inverse mistake is quieter but just as expensive: scripting a step that needed a reader, and silently mishandling every case the rules never anticipated. The audit exists to keep you from making either one.

One question per step

The method is unglamorous. Take one workflow at a time and name its output first - a workflow whose output nobody can name is a wish, not a workflow, and no automation of any kind will fix that. Then decompose it into steps and split each step's deterministic half from its judgment half.

The operating rule I hold my own automation to is written into my organization's manual: "Deterministic scripts gather; agents spend tokens only on judgment over script output." The classification rule follows from it: if it acts with judgment on a trigger, it is agent work; if a re-run must produce the identical result, it is a tool. A tool that makes judgment calls cannot be trusted to re-run. An agent that re-derives arithmetic burns money doing it.

A worked example from my own systems: triaging user feedback. Mapping a submission tagged bug to a high-priority work item is a rule - it must not drift between runs, so it is a script. Deciding that "the pricing page confused me," typed into a plain feedback box, is actually a real work item worth scheduling - that needs a reader. The script files the obvious cases and holds the ambiguous ones; the agent reads only what was held, and must state a reason for every promotion. Same workflow, two halves, priced separately.

Scripts, agents, humans

Classifying a step takes three questions, asked in order. Irreversibility is checked first, because it overrides everything else.

Inside my own systems, the deterministic column is deliberately large. These stay scripts by design, even though an agent could do them:

• Gathering. Surveys of project state, exports, and syncs run as scripts that print structured output. The standing instruction is literal: run the script, do not reason.
• Verification. Tests, linters, type checks, and security scans decide pass or fail with no model in the loop. A model reviewing its own work is not verification.
• Routing. Which class of model handles a task is a keyword match on the task's text, not a model call - the same cheap determinism, pointed at cost and scheduling.
• Deduplication. Re-runs are made safe by idempotency keys, not by a model comparing items and guessing what it has seen before.
• Status. Verdicts like failing, stale, or never-run come from hard thresholds, so they are identical every run - and a dead data source degrades to unknown, never to ok.

The judgment column is short, and every entry on it involves reading: reading a customer's free-text feedback, writing the specification for a change (with acceptance criteria a machine can check afterward), verifying that a task's premise is still true before building it, and naming a failure mode nobody has seen before. That is what the tokens are for.

Then there is the third column. Some steps are neither script work nor agent work at any level of maturity:

And a set of hard carve-outs overrides everything above: any change touching authentication, payments, a schema migration, secrets, or deletion of user data routes to a human first - always, no matter how mature the automation around it has become. Blast radius has no stage.

A shop with thirteen seasonal staff

The client is a seasonal deer processing and taxidermy operation in rural Indiana: a purpose-built facility, about thirteen seasonal staff, and a few frantic months a year when hunters line up at the counter. The engagement was to take check-in digital - the intake forms for processing and taxidermy orders, and everything the shop does with them afterward.

This is exactly the kind of business the current wave wants to sell a chatbot to. The audit said otherwise. Walking the workflow with the owners produced a system with no model in it at all:

The interesting decisions are the negative ones, and each came from listening rather than from a feature list. An online submission is not an order - it becomes official only when staff check it in at the counter with the animal physically present, because possession is the shop's real source of truth. The owners get no notification email per submission, because during the season that would be a hundred emails a day nobody reads; the pending queue is the inbox, worked at the counter. Customer order details are deliberately not editable in place: small changes go on butcher notes, big changes go through a fresh check-in cross-referenced to the old one, and the money fields staff actually need to adjust are the only fields staff can adjust - with the audit trail recording who touched what. Exports are CSV because the back office runs on Excel, not on dashboards.

Even the client communication followed the audit's logic. Questions went out in written batches - seven rounds so far - published as web pages first, because a page can be translated by any phone in one tap, with a PDF fallback that has ruled answer lines, because shops print things and write on them. Structured-enough answers, zero new software for the client to learn.

Here is the punchline. The AI content of the delivered product is nothing: no model in the customer-facing request path, no chatbot, no "AI-powered" anything. Every flow the audit surfaced needed deterministic software that behaves identically on the ten-thousandth deer as on the first. The AI leverage in this engagement was in the delivery - agent-driven builds working from written specifications, behind the same review gates described above. The client bought outcomes, and the audit is what kept them from buying tokens instead.

The ratio holds at fleet scale

One client engagement is an anecdote. So I ran the same audit on my own operation - a portfolio of 69 active repositories maintained by one human plus autonomous agents. Over a 41-day window the system ran 103 unattended passes, produced 1,001 work-item rows across 75 projects, and verifiably shipped 342 of them (a floor - the real number is higher, but I only count what leaves a trace). July alone saw 2,089 commits against a pre-automation baseline of roughly 40 a month. This is not a demo; it is the most agent-saturated environment I can measure. And even here, the automation surface is mostly scripts:

The clearest artifact of the audit is the scheduling manifest, where every recurring job carries a machine-readable answer to the question "does this need a model?" Half do not, and that answer has an infrastructure consequence: the deterministic jobs can migrate to any commodity Linux host, while the agentic ones are pinned to a machine with model access.

Even where the agents do run, the spend shape is engineered like infrastructure rather than magic: of 11.82 billion tokens metered over 29 active days, about 96% were cache reads - repeated context served from cache at a fraction of the cost - with only 27.9 million tokens of actual model output. The same platform also ships models where they earn their place: consumer products of mine like Lost Pet Radar and WriteMyCard AI put image moderation and LLM drafting in front of paying users, behind the same deterministic billing, auth, and deploy rails. The audit is not anti-AI. It is anti-waste.

What to buy, what to build

If you are a business considering AI, the audit reframes the purchase:

• Buy judgment only where a step needs a reader. Free-text, ambiguity, novelty, and specification are agent work. Everything with a nameable, repeatable output is a script wearing an AI costume.
• Prefer deterministic software for the bulk. It is cheaper per run by orders of magnitude, it is testable, it is auditable, and it does not degrade or drift while you sleep.
• Keep the irreversible steps human. Auth, money, schemas, secrets, and deletion do not get automated judgment at any maturity level - the cost of being wrong once exceeds the cost of every approval you will ever click.