Not every step needs AI: the case for functional decomposition

A useful AI prototype can start with a conversation: give the model some tools, describe the job and see whether it can work through a real example. That is a useful way to discover what is possible. Turning it into an everyday business capability means looking more closely at the work inside the loop.

Which steps follow a defined rule? Which need an interpretation of incomplete or ambiguous information? Where does an action require authority the system does not have? Answering those questions is functional decomposition: breaking a process into parts and choosing how each part should work.

Two kinds of steps

Consider receivables follow-up. Pulling overdue invoices, calculating their ageing brackets and applying an agreed escalation schedule follow explicit rules. Recording a promise and scheduling a check can also be ordinary software operations. There is little value in asking a language model to work out the same rules on every pass.

Reading a customer’s reply is different. Does the message contain a promise to pay, a dispute or a request for more information? What does it mean alongside the account history? Preparing a suitable response also requires attention to context and tone. These are useful places for AI judgement, within the business’s policies.

The model is called where judgement adds value, not on every step of every cycle.

What the chat loop actually costs

Putting every step through a model adds work: context has to be supplied, a response generated and that response checked. It also gives the model decisions that may already have a precise answer. When an invoice’s due date and the escalation rule are known, a calculation is a better fit than a fresh interpretation.

Separating the steps makes their behaviour easier to inspect. We can test the calculation, exercise the account permissions and check duplicate handling independently of the model’s interpretation. At the judgement point, we can evaluate the model against representative replies and see where it needs better context or a clearer policy.

Ordinary code still has infrastructure, maintenance and testing costs. The aim is to keep model use proportional to the decision it helps make, while giving each part of the process a defined responsibility.

How to do the split

Work through real cases with the people who understand the job. For each step, describe the input, the rule or judgement involved, the permitted action and the evidence that the step has completed.

Defined rule: code

Look up the record, calculate the balance, apply the schedule or record the result. Make the rules explicit and test them.

Context and judgement: AI

Interpret a reply, bring context together or prepare the next action. Give the model a focused question, relevant information and defined authority.

Policy gap: person

When the rules do not cover the case, route it to the responsible person. Record the decision so it can improve the policy used in future cases.

The system enforces the permissions around every action. A model’s confidence does not extend its authority. An explicit approval requirement still applies, even when the model can interpret the situation.

Improve the process you already have

A working prototype gives you something valuable to examine. Trace what it does across real cases. Move the steps governed by stable rules into testable code. Keep the model where interpretation adds value, and make the handoff for exceptions clear.

Then connect the result back to the decision. A reminder sent, a promise recorded and a payment confirmed are different states. The next judgement should use what actually happened. Recorded exceptions help refine the policies, with changes reviewed and tested before they shape future actions.

That gives the business a process it can understand, measure and improve, with AI doing a specific, useful job inside it.