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 decides what to do with it.
That difference is the whole story, and worth getting right before you buy anything. 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?
Rule-based automation versus LLM-powered automation
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.
| | Rule-based automation | LLM-powered automation | |---|---|---| | Input it handles | Structured, predictable data | Messy, unstructured language | | How it decides | Fixed rules you write | Interprets meaning, infers intent | | Output | Identical every time | Varies with the input; needs review | | Best for | Moving data, triggering steps | Drafting, classifying, extracting, summarising | | Fails when | The input is ambiguous | The task needs guaranteed, exact correctness |
You do not replace one with the other. The strongest systems use both: a rule moves the data and triggers the steps, and the model handles the part in the middle that needs reading and judgement.
What LLM-powered automations actually do 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," and customers cite "drafting, summarising, translations, and explaining complex concepts in simple terms" (Anthropic). Inside a small business that looks like this.
Triage and draft email replies. An automation reads each incoming email, works out what it is about, and either files it or writes a first-draft reply for a person to check and send. The repetitive bulk of your inbox gets handled in seconds. The owner still approves anything that goes out.
Summarise documents. A long contract, a dense report, a forty-message thread: the model produces a short summary so a person grasps the substance without reading every line. Useful for the first pass, never the final word on anything legal or financial.
Pull data out of invoices. Supplier invoices arrive in dozens of layouts. A model reads each one and extracts the fields you care about (supplier, date, total, line items) into a format your accounting tool can take. This is the slow, error-prone data entry that quietly eats hours every week.
Categorise and route leads. A new enquiry comes in. The automation classifies it (sales, support, partnership, spam), adds whatever data is available, and routes it to the right person or queue. Nothing sits unread, and the right human sees it first.
Generate first-draft content. Product descriptions, social posts, a draft proposal, an FAQ answer. 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 any weight. That is not a limitation to apologise for. It is the design.
Where a human has to stay in the loop
LLM-powered automation has one failure mode you must design around: the model can be confidently wrong. It 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).
This is why keeping a human in the loop is not a nicety. The output reads exactly as confident when it is wrong as when it is right, so confidence tells you nothing. The rule we apply: the more a mistake costs, the closer the human sits to the decision.
In practice a person reviews anything customer-facing before it sends, signs off on anything that moves money or changes a record, and checks any figure that feeds a real decision. 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.
How these automations connect to your existing tools
An LLM-powered automation is only useful if it can reach the rest of your business: your inbox, your CRM, your accounting tool, your website. It does that through two pieces of plumbing worth understanding in plain terms.
The first is the API (application programming interface), which is how one piece of software talks to another. The web runs on this: as Mozilla's MDN Web Docs puts it, the underlying protocol is "the foundation of any data exchange on the Web," where "clients and servers communicate by exchanging individual messages," requests and responses. When your automation needs to read a customer record or post a draft reply, it calls that tool's API. The API is how it acts on your systems rather than just talking about them.
The second is the webhook, which gets the automation started at the right moment. A webhook lets one tool push data to another the instant something happens, instead of repeatedly asking "anything new yet?" GitHub's documentation describes them 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," used "to receive data as it happens, as opposed to polling an API" (GitHub). A new email arrives, an invoice lands, a lead fills in a form: the webhook fires and the automation wakes up.
Put the two together and the shape is clear. A webhook triggers the automation, the model does the reading or writing, and APIs move the result into the tools you already use. No copy-pasting between tabs, no data sitting in one system waiting to be retyped into another.
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. The aim is hours returned and errors removed, with you still in control of the decisions that matter.
Our Lead Management System build is the worked example. Leads were handled by hand across disconnected tools, with reporting assembled manually. The system we built reads, classifies, and routes enquiries and generates the reports automatically, and it saved the client more than 1,500 hours a month. The headline number is not the point. The point is that the work was rule-bound in some places and judgement-heavy in others, and the system 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.