LLM-Powered Automations

Picture two machines behind the counter of your business. One is a vending machine: press B4, get a specific snack, every time, no exceptions. The other is a capable assistant who can read a messy handwritten note, work out what the customer actually wants, and handle it. Traditional automation is the vending machine. LLM-powered automation is closer to the assistant.

An LLM-powered automation is a workflow that uses a large language model (the technology behind tools like ChatGPT and Claude) to do work that involves reading, writing, and judgement: drafting a reply, summarising a document, pulling figures out of an invoice, sorting an enquiry into the right bucket. Ordinary automation follows fixed rules you write in advance. This kind reads unstructured language and works out what to do with it.

In our work building automations for small businesses, the wins and the failures both trace back to one question: did the task suit a rule, or suit a model? This explainer draws that line, walks through the anatomy of one working automation end to end, and is precise about the decisions a model should never make alone.

A rule follows, a model reads

Traditional automation runs on if-this-then-that logic. If a form is submitted, then add the row to a spreadsheet. If an order ships, then send the tracking email. The rules are explicit and the inputs are tidy, so the behaviour is identical every time. For structured, predictable work this is excellent: fast, cheap, and you can predict exactly what it will do.

It falls down the moment the input stops being tidy. A rule cannot read three differently worded emails and see that all three are asking for a refund, find the total on an invoice in an unfamiliar layout, or decide whether an enquiry is a hot lead or a job application. That work needs to interpret language and exercise something close to judgement, which is what a language model adds.

You do not replace one with the other. The strongest systems use both: rules move the data and trigger the steps, and the model handles the part in the middle that needs reading and interpretation.

The anatomy of one automation, from trigger to action

The fastest way to understand these systems is to walk through one. Here is the shape of an email-triage automation of the kind we build, and the same four stages sit behind invoice extraction, lead routing, and most of the rest. Only one of the four involves the model.

Stage 1: a webhook announces the event. A customer emails your business. A webhook lets one tool push data to another the instant something happens, rather than the automation asking "anything new yet?" on a timer. GitHub's documentation describes webhooks as a way to "subscribe to events happening in a software system and automatically receive a delivery of data to your server whenever those events occur" (GitHub). The email lands, the webhook fires, and the automation wakes with the message in hand.

Stage 2: APIs retrieve the context. Before the model reads anything, plain rules gather what it will need. The automation calls your CRM's API to fetch the sender's record, past orders, and any open issues. An API is how one piece of software talks to another; as Mozilla's MDN Web Docs puts it, the web's underlying protocol is "the foundation of any data exchange on the Web," where "clients and servers communicate by exchanging individual messages."

Stage 3: the model reads and structures. Now the language model does the one thing rules cannot. It reads the messy email alongside the retrieved context and returns a structured judgement, something like this:

{
  "category": "refund_request",
  "order_ref": "INV-1042",
  "sentiment": "frustrated, second follow-up",
  "summary": "Item arrived damaged, wants refund not replacement",
  "draft_reply": "Hi Sam, sorry the stand arrived damaged...",
  "route_to": "owner_approval"
}

Look closely at what the model produced: a classification, an extraction, a summary, and a draft. Not one action.

Stage 4: rules act on the result. Fixed logic takes over again. It files the email under the right customer, updates the CRM over the API, and queues the draft reply for a person to approve. Nothing has been sent, changed, or spent by the model itself.

That division of labour is the design rule worth memorising. Webhooks and APIs move the data, the model interprets it, and rules carry the result. The model sits in the middle of the pipeline, not at the controls.

What the model part does well

The reliable uses cluster around four verbs: drafting, classifying, extracting, and summarising. Anthropic describes the same territory for its own model, noting that Claude helps with "summarization, search, creative and collaborative writing, Q&A, coding, and more," with customers citing "drafting, summarising, translations, and explaining complex concepts in simple terms" (Anthropic). Inside a small business, that looks like five jobs.

• Email triage and first-draft replies. The repetitive bulk of the inbox handled in seconds, with the owner approving anything that goes out.
• Document summaries. A long contract, a dense report, or a forty-message thread reduced to its substance. Useful for the first pass, never the final word on anything legal or financial.
• Invoice data extraction. Supplier invoices arrive in dozens of layouts; the model pulls supplier, date, total, and line items into a format your accounting tool can take. This is the slow, error-prone data entry that quietly eats hours every week.
• Lead categorising and routing. Sales, support, partnership, or spam, enriched with available data and sent to the right person. Nothing sits unread.
• First-draft content. Product descriptions, social posts, a draft proposal. The model removes the blank page; a person edits, fact-checks, and approves.

In each case the model does the heavy lifting on language, and a person owns the decision that carries weight. That is not a limitation to apologise for. It is the design.

What the model should never decide alone

The common wrong belief about these systems runs like this: the pipeline is automated, so the model must be making the decisions, and its output reads confidently, so it must be right. Both halves are wrong. A language model produces fluent, plausible text whether or not that text is true. Anthropic is direct about this in its developer guidance, warning that even advanced models "can sometimes generate text that is factually incorrect or inconsistent with the given context," a phenomenon known as hallucination, and that techniques to reduce it "don't eliminate them entirely. Always validate critical information, especially for high-stakes decisions" (Anthropic).

Wrong output reads exactly as confident as right output, so confidence tells you nothing, and the checkpoint has to be built into the pipeline. This is why keeping a human in the loop is not a nicety. The rule we apply: the more a mistake costs, the closer the human sits to the decision. In any automation we build, the model never decides alone on three things.

• Anything customer-facing. A person reviews every outbound message before it sends. One hallucinated refund policy or invented delivery date can cost a relationship.
• Anything that moves money or changes a record. Payments, deletions, contract terms: the model drafts, a person clicks.
• Any figure that feeds a real decision. Extracted totals and summarised numbers get checked before they steer spending or reporting.

Low-stakes, easily reversed work (filing an email, drafting an internal note) can run with lighter oversight. The automation prepares the work; a person approves the part that matters. An unattended automation does not make a mistake once. It repeats it at machine speed until someone notices.

The Enki approach

We build these as Custom Automations: workflows shaped around how your business actually runs, not a generic template you bend yourself to fit. We map the real process, separate the parts that suit a fixed rule from the parts that need a model, and put a human checkpoint wherever a mistake would cost you. Our Lead Management System build is the worked example. Leads were handled by hand across disconnected tools, with reporting assembled manually. The system that replaced that work reads, classifies, and routes enquiries, generates the reports automatically, and saved the client more than 1,500 hours a month. The work was rule-bound in some places and judgement-heavy in others, and the build matched the right tool to each part.

The next step up, where the automation plans and takes multi-step actions on its own, is agentic AI, and the same discipline applies. Begin with one repetitive, high-volume task where a mistake is cheap. Get it reliable. Then widen the circle.