AI Automation Examples: Six Patterns We Actually Build
Six AI automation patterns broken down by input, decision, action, approval gate, system of record, recovery path, and the measure that proves it worked.
By Sarthak Arora
Everything on this page is a pattern we design and build. None of it is a case study.
That distinction matters enough to state before you read a word of it. These are the shapes we reach for when a client describes a workflow, written out at the level of detail we would use in a design session. They are not reports of completed engagements, they carry no client names, and they carry no numbers, because a number without a named source, a period, and a measurement method is decoration rather than proof.
If you are looking for vendor bullets that say "automate your invoices with AI," this is not that. What follows is the mechanism.
The frame every pattern has to survive
Most published use case lists are one sentence long each, which is exactly long enough to sound good and too short to be checkable. We describe a pattern in seven parts, and a pattern that cannot fill all seven is not ready to build.
- Business input. What arrives, in what form, from whom.
- Decision. The bounded judgment call the system makes.
- Action. What actually changes in a real system.
- Human approval or escalation point. Where a person has to say yes, or where the system hands the case over.
- System of record updated. The place your business treats as the truth.
- Error and recovery path. What happens when a step fails or the input is unusable.
- Measure of useful change. The thing you agree to measure before the build starts, so the argument about value happens up front rather than at the end.
Use the frame on your own candidate workflow as you read. The gaps you cannot fill are the real project.
Pattern one, inbound document intake
Business input. Documents arriving by email, portal upload, or shared drive: supplier invoices, purchase orders, claim forms, signed agreements, statements. Layouts differ by sender and change without notice.
Decision. Classify the document type, extract the defined fields, and judge confidence per field. Then decide whether the extraction is clean, mismatched against the reference record, or unusable.
Action. Post clean documents into the finance or operations system with the extracted values attached. Queue mismatches with the specific conflicting fields highlighted. Attach the source file to the record every time.
Human approval or escalation point. Anything outside tolerance goes to a named reviewer. Tolerance is defined per field, not globally, because a wrong supplier name and a wrong total are not the same risk.
System of record updated. The accounting or ERP record, plus the document store, with a link between them.
Error and recovery path. Unreadable or partial documents are quarantined with the reason, never silently dropped. A failed system write retries, then raises an alert naming the document and the failure. Nothing is marked processed until the write is confirmed.
Measure of useful change. Cycle time from arrival to posted record, share of documents needing manual touch, and rework caused by wrong data downstream. Baseline first, then compare.
Evidence status. Proposed pattern from the AIkrates delivery model. Not a client result.
Why AI and not rules. A rule set can read one template. It cannot read four hundred, and every new supplier is a new template.
Pattern two, support conversation triage
Business input. Inbound customer messages across email, web form, and chat. Free text, mixed languages of urgency, frequently containing two problems in one message.
Decision. Identify intent, urgency, and the account involved. Decide whether an answer exists in your own documentation, whether the case needs a specialist, and whether anything in the message is a churn or complaint signal.
Action. Draft a grounded reply using your documentation and the account history, tag the conversation, and set priority. Send directly only for the intent categories explicitly approved for direct send.
Human approval or escalation point. Everything else is held as a draft for an agent, with the reasoning and the sources shown. Billing disputes, cancellations, legal language, and anything the model flagged as low confidence never send automatically.
System of record updated. The ticketing system: conversation, tags, priority, assignment, and the draft or sent reply.
Error and recovery path. If no grounded answer exists, the system says so and routes to a human rather than generating one. If the account cannot be identified, the message is assigned to the general queue with that reason attached. Retrieval failures escalate instead of falling back to guesswork.
Measure of useful change. First response time, share of conversations resolved without a second human touch, reopen rate, and agent edit distance on drafts. Edit distance is the honest one, because it tells you whether the draft was genuinely useful.
Evidence status. Proposed pattern from the AIkrates delivery model. Not a client result.
Why AI and not rules. Keyword routing fails the moment a customer describes a symptom instead of a category, which is most of the time.
Pattern three, operational exception handling
Business input. Records that do not agree. An order that does not match inventory, a delivery that does not match the order, a payment that does not match an invoice, two systems that disagree about the same account.
Decision. Determine the exception type, gather the evidence from both sides, and propose a resolution with the reasoning written out. Decide whether the exception falls into a category already approved for automatic closure.
Action. Close the approved categories automatically with a full audit trail. For everything else, create a resolution task pre populated with the evidence and the proposal, so the human decides rather than investigates.
Human approval or escalation point. Every category starts as human approved. A category is promoted to automatic closure only after it has run long enough for the owner to trust it, and promotion happens one category at a time.
System of record updated. The operational system holding the disputed record, plus an exception log that records what was decided, by whom or by what, and on what evidence.
Error and recovery path. If the two sources cannot be reconciled, the case is escalated with both versions preserved. No partial writes: either the resolution completes and is logged, or it is rolled back and flagged.
Measure of useful change. Exception backlog age, share of exceptions closed without human investigation, and the override rate on automatic closures. A rising override rate is the signal to demote a category.
Evidence status. Proposed pattern from the AIkrates delivery model. Not a client result.
Why AI and not rules. The clean path is rules and should stay rules. Exceptions are exceptions precisely because they did not fit the rules.
Pattern four, inbound lead qualification
Business input. Form submissions, replies, and demo requests, plus whatever public information exists about the company behind them.
Decision. Read the message and the available context, then score against your real criteria rather than a generic template. Decide the segment, the likely use case, and whether this is a fit, a partial fit, or a decline.
Action. Write the score and the reasoning into the CRM, assign to the right owner by segment, and create the follow up task with a drafted opening that references what the lead actually said.
Human approval or escalation point. The pursuit decision stays human. The system never sends the first outbound message on a scored lead without the owner reviewing it, and declines are reviewed in batch rather than deleted.
System of record updated. The CRM: lead record, score, reasoning, segment, owner, and task.
Error and recovery path. Missing context produces a lower confidence score and a note saying what was missing, never an invented company profile. If enrichment fails, the lead is still routed, because a slow human read is better than a lost lead.
Measure of useful change. Time from submission to first human contact, agreement between the score and what the owner concluded after the call, and the share of scored declines that a human overturns.
Evidence status. Proposed pattern from the AIkrates delivery model. Not a client result.
Why AI and not rules. Qualification is reading comprehension. Field matching tells you the company size and nothing about whether they have your problem.
Pattern five, recurring reporting and reconciliation
Business input. A schedule, plus data pulled from the systems that hold the numbers.
Decision. Detect what changed against the prior period, decide which movements are material enough to explain, and identify the likely driver from the underlying records. Decide whether any figure looks wrong enough to withhold.
Action. Assemble the report, write the commentary on material movements with the supporting figures cited, and distribute it to the named recipients.
Human approval or escalation point. The owner reviews before external or board distribution. Internal operational reports can send automatically once the source checks pass, because the cost of a wrong internal chart is a correction rather than a credibility problem.
System of record updated. The reporting store and the distribution log, so you can always answer which version of the numbers went out and when.
Error and recovery path. If a source is unavailable or fails a completeness check, the report does not go out with a hole in it. It holds, and the owner is told which source failed. A partial report that looks complete is worse than a late one.
Measure of useful change. Preparation hours, distribution punctuality, and the number of corrections issued after distribution.
Evidence status. Proposed pattern from the AIkrates delivery model. Not a client result.
Why AI and not rules. The pull and the layout are rules. Writing the explanation of why a number moved is the part that needed a person.
Pattern six, renewal and account risk review
Business input. Usage data, support history, invoice and payment history, and the conversation record for accounts approaching a decision point.
Decision. Assess risk for each account, name the specific evidence behind the assessment, and decide whether the account needs an intervention, a routine renewal motion, or nothing at all.
Action. Write the assessment and its evidence to the account record, create the intervention task for at risk accounts with a suggested approach, and brief the owner ahead of the conversation.
Human approval or escalation point. Everything customer facing is human. The system prepares and proposes, it does not contact the customer. High value accounts are reviewed by a named person regardless of the assessment.
System of record updated. The CRM account record, with the assessment, the evidence, and the task.
Error and recovery path. Accounts with insufficient data are marked as unassessed rather than scored as healthy. Silence is not a positive signal, and treating it as one is how renewals get lost.
Measure of useful change. Share of at risk accounts identified before the customer raised the issue, and how far in advance. Renewal outcomes are tracked but never claimed as caused by the system without a controlled comparison.
Evidence status. Proposed pattern from the AIkrates delivery model. Not a client result.
Why AI and not rules. A usage threshold tells you an account went quiet. It does not tell you why, and the why is the entire intervention.
What the six have in common
Read them together and the pattern behind the patterns shows up.
- The model always makes a bounded decision with a known set of allowed outcomes. It never has open ended authority.
- Deterministic code does the fetching, the enforcing, the writing, and the alerting. The model reads and judges.
- Every irreversible or customer facing action passes a human gate, and the gate is narrower at launch than it will be later.
- Every run ends in a system of record, not in a log or a chat thread.
- Every pattern has a defined behaviour for failure, and that behaviour is to stop and tell someone rather than to guess.
- Every pattern has an agreed measure before the build, and a baseline to compare it against.
What we decline to build
Judgment is visible in refusals more than in menus.
We do not build automations that take irreversible financial or legal actions without a human gate. We do not build on data that two systems disagree about until the disagreement is resolved, because the automation will simply distribute the error faster. We do not build workflows with no named owner after launch, because unowned automations are switched off within a quarter. And we do not build a model into a workflow that a rule would have handled, since a rule is cheaper to run, easier to test, and it does not drift.
Where to take this
Take the seven part frame to your own shortlist and try to fill it in for each candidate. The workflow where you can complete all seven without guessing is very likely your first build.
If you want to see how these patterns get delivered as a maintained system rather than a pilot, read how we approach AI automation. If your shortlist has five candidates and no ranking, the workflow selection guide covers the ten factors we score before recommending anything at all.
Subscribe to the notebook.
New notes when they ship. Roughly once a week.