Use ordinary rules for steps with clear conditions and known answers. Consider AI for a specific part that needs interpretation, then check its result before it drives another action.
You don't need to choose between an entirely rules-based workflow and an AI agent that runs everything. Many useful integrations combine a small AI step with predictable routing and validation.
Split the task into different kinds of work
Take a fictional facilities business receiving maintenance requests by email. A request needs to become a job record, but the steps are not all the same:
- Receive the message and keep its reference.
- Identify the property and contact.
- Interpret a free-text description of the fault.
- Check whether required information is missing.
- Send the request to the appropriate review queue.
The third step might benefit from AI. Receiving the message, checking a property reference and recording the result normally need dependable connections and explicit rules.
If the form already asks customers to choose the service and property, interpretation may not be needed at all. Fixing the input can be simpler than adding a model later.
Write the rule you wish existed
Try to explain the decision without naming a tool. “If the customer selected plumbing, assign the request to the plumbing queue” is a rule. “Read whatever they wrote and work out what they probably need” involves interpretation.
Some apparently intelligent tasks are just lookups. Finding the account manager from a customer reference should use the approved record rather than asking a model to guess from a company name.
Other tasks mix both. A model can propose that “the heating stopped overnight” belongs to a heating category. A separate rule can require a known property, an allowed category and a review owner before creating a draft job.
Microsoft's AI Builder overview lists interpretation capabilities including text classification and document extraction within workflows. Choose a capability for the step you actually need, rather than treating an available AI action as a reason to redesign the whole process.
Give the AI a bounded output
For the fictional business, useful output might be one proposed category, a short fault summary and a flag saying that more information is needed.
Use a fixed list of allowed categories and an explicit uncertain route. Keep the original description alongside the proposal. A category is a suggestion about the text, not confirmation that a qualified person has diagnosed the problem.
Don't let that interpretation silently authorise call-out charges, choose a safety response or promise an appointment. Those decisions need their own agreed rules and appropriate expertise.
Compare with the simpler version
Before integrating a model, run the same approved test examples through the ordinary process. Could a better form, a short lookup list or an existing software feature handle most of them?
Then compare both approaches on the whole task:
- useful outcomes completed correctly.
- mistakes that create extra work or delay.
- requests needing a person.
- staff time spent checking and correcting.
- cost and time needed to keep the workflow running.
Include difficult wording and missing information. A model that appears helpful on five neatly written examples may struggle with the messages staff actually receive.
Keep fallback behaviour ordinary
Decide what happens if the AI service times out or returns an unusable result. The original request should remain visible and reach a person, not disappear because a classification field is empty.
Make the uncertainty route part of normal operations. If staff spend every morning rescuing stuck requests, the model hasn't removed the work. It has moved the work into a less convenient place.
Know when AI belongs in the process
AI is worth considering when interpretation materially improves a task you can define, test and recover. It is less useful when the business rules are unsettled or the required fact already exists in a trusted system.
The guide to choosing a first automation helps identify a manageable starting point. Once the process is clear, your builder can explain exactly which step needs a model and how the surrounding workflow keeps its result useful.