Automations inside your software: where AI fits
Most automation inside an application is rules and events. Where a model adds value, where it does not, and how to place it.
The short answer
Most automation inside a business application is not AI and should not be. It is events and rules: when an order is placed, reserve stock and send a confirmation; when an invoice is thirty days overdue, send a reminder and flag the account. Deterministic, cheap, explainable, testable. AI fits in the steps that rules cannot handle because the input is unstructured: reading an incoming message and deciding what it is about, extracting fields from a scanned document, summarising a case history, drafting a reply. Place those steps inside the same event and job infrastructure as everything else, fenced with validation, a confidence signal and a person at the gate where stakes require, and keep them replaceable.
Rules or model, per step
| Step | Rules or model | Why |
|---|---|---|
| Send a confirmation when an order is placed | Rules | Deterministic event |
| Calculate a discount, a tax, a due date | Rules | Arithmetic must be exact |
| Route a ticket by product line from a dropdown | Rules | Structured input |
| Route a ticket by reading its free-text description | Model | Unstructured input; intent |
| Extract invoice number, date and total from a PDF | Model, validated against rules | Unstructured input; output checked |
| Summarise a long case history for a handover | Model | Reading and writing |
| Draft a reply using the customer’s history | Model, person sends | Writing with context; judgement stays human |
| Approve a refund | Rules for eligibility; person for the decision | Money and commitments |
Placing an AI step
- Identify the unstructured step in an existing workflow: reading, writing, classifying, extracting.
- Define the output shape precisely: which fields, which allowed values, what confidence means.
- Trigger it from the same event system, run it as a background job with retries and timeouts.
- Validate the output against the shape and the business rules; reject and route what fails.
- Route by confidence and stakes: straight through for routine, to a person for the rest, all logged.
- Wrap the model call in a function with an adapter, so the model can change without touching the workflow.
- Test it with an evaluation set from real cases, and monitor it in production like any other job.
Keeping it replaceable
The workflow calls “classify this message”; today that function sends the text to a model with a prompt and validates the answer. Next year it may use a cheaper model, a fine-tuned one, or a rule that turned out to be good enough. Because the workflow never knew which, the change is inside one function with an evaluation set to prove it. That separation is what stops an application from being rebuilt every time the model market moves.
What this means for you
Keep rules and events as the default automation inside your software. Add a model only where a step reads, writes, classifies or extracts from unstructured content, and add it as a fenced background job with validated output, a confidence gate and a replaceable implementation. The application stays predictable, the AI step stays contained, and the model can be swapped when a better one arrives.
Frequently asked questions
Where in our application would AI actually help?
Look for the steps a person does by reading or writing: triaging an incoming message, summarising a case, extracting fields from a document, drafting a reply, tagging an item. Those are the steps rules cannot do and models do well. Steps that are already rules, calculations or lookups do not need a model and are worse with one.
How do we add AI without making the software unpredictable?
Treat the model as one step in a normal workflow: triggered by an event, run as a background job, its output validated against a schema and rules, with a confidence signal, logged, and routed to a person when uncertain or when the stakes require. The workflow stays deterministic; only one step inside it is probabilistic, and it is fenced.
Will the AI step be expensive to run?
Rarely, if placed well: it runs only when triggered, on the relevant text, with a model sized for the task. The cost is per event, visible in the logs, and cappable. The expensive pattern is calling a model on every page view or on whole documents when a few fields would do.