Automation & AI agents

Which parts of a business process should use AI, and which code?

The short answer

Use a model for steps that read messy input, draft something, or classify something genuinely fuzzy. Use code for anything that must give the same answer every time — arithmetic, money, compliance, routing rules. Often two steps in a process should involve a model, and the rest should be code.

Updated September 26, 2026

Write the process out first

Break the process into discrete steps before deciding where a model goes. POD Engine is fourteen workflows across nine stages, not one long prompt with tools attached, and that decomposition is what makes it possible to say which single stage a person owns.

The test for each step

Would it worry you if this step gave a different answer tomorrow on the same input? If yes, it is code. If no — summarising an email, drafting a reply, sorting enquiries — a model can do it.

Put the guard rails in code

On our own Growth Engine, outbound email has a regulator attached, so compliance is code rather than a paragraph in a prompt: a contact address must be published on the prospect's own site, with the source URL kept as evidence, and guessed or suppressed addresses fail closed.

Money never touches a model

In Contractor OS, every financial calculation happens in integer cents and every document posts a balanced journal entry. A model can explain a figure afterwards; it should never produce one.

Asked next

Can an AI model reliably check its own output?

Not reliably. A check that runs after the model, in code, catches what the model missed. On our own Growth Engine, the compliance checks run after the model has written, not as instructions inside the prompt.

What about steps that need taste or legal judgement?

Keep a person there, at one gate placed at the last reversible moment. POD Engine keeps exactly one human approval gate, because taste and legal exposure are the two decisions that should not be automated.