AI doesn't run your business. The plumbing does.

You watch a demo. Someone types a question, a chatbot types back a clean paragraph, and the room agrees the machine runs the work now.

It does not. The thing that moved the order, updated the records, and sent the confirmation was plumbing. A webhook fired. A payload got checked. A job went on a queue. A failed step retried. Every action wrote a line to a log. The large language model (LLM) touched one step out of nine. The other eight would run without it.

We build automation for small businesses. Most weeks, the hardest part of a build has nothing to do with the model. It is the pipes. And the reason to care is money. When you buy a system sold as artificial intelligence, you watch the model and ignore the pipes. Then the model returns a wrong answer one night, and you learn the pipes were never laid.

Below: what a single automated enquiry does step by step, the four pieces of plumbing that carry the load, the one place the model earns its seat, and the questions to ask a vendor before you sign.

What the demo hides.

A demo shows you the one second the model speaks. It hides the parts around it, because those parts are boring to watch.

The boring parts are the system. A reply on a screen is not a booking, an invoice, or a dispatched order. Something has to take the model’s output, check it, act on it, and record what happened. None of that is the model. All of it is the difference between a toy and a tool.

Follow one enquiry.

Trace a single message from a customer through a working setup.

1. The message arrives. A webhook fires the moment it lands, so nothing waits for a person to refresh an inbox.
2. The payload gets validated. Name, contact, and request go into fixed fields. Malformed input gets rejected here, not three steps later.
3. A record is created. The enquiry becomes a row with a stable identifier, not a screenshot in a chat thread.
4. A rule routes it. Sales goes one way, support another, a known customer a third. The rule is explicit and the same every time.
5. The model reads the messy part. It classifies intent or drafts a first reply from the free text a human wrote.
6. The draft gets checked. A confidence threshold or a human tier decides whether the reply sends or waits.
7. The action runs. A reminder schedules. A quote generates. A task assigns.
8. A failure retries. If the courier service is down, the job waits and runs again instead of vanishing.
9. Everything writes to a log. Who, what, when, and the result.

The model owns steps five and six. Steps one through four and seven through nine are plumbing. Pull the model out and replace it with a fixed rule, and the pipeline still runs, a little dumber. Pull the plumbing out and keep the model, and you have a chatbot that forgets everything the moment the tab closes.

The four pieces that carry the load.

Webhooks and triggers start the work without a human. An event happens, a message arrives, a payment clears, and the system reacts in the same second. No polling, no refresh, no someone-noticed delay. This is the difference between a five-minute reply and a five-hour one. We wrote about that gap in the five-minute window.

Structured data is the shared language. The model speaks fuzzy text. Your courier, your billing, and your calendar speak fixed fields. Plumbing turns one into the other and back. A name is a name, a phone number passes a format check, an order holds a status from a known set. Without it, every handoff is a guess.

Queues and retries are the part that survives a bad day. Real systems fail. A service times out. A third party returns an error. A queue holds the work and tries again instead of losing it. Most of what separates a weekend hack from a system you trust lives here, and none of it is the model.

The audit trail is the record. Every message, every decision, every action, logged and reversible. When a customer disputes what happened, you read the trail. When you want to know why the system did something, you read the trail. It is the least glamorous line item and the one you miss most when it is absent. The trail matters enough to get its own post later in this series.

Where the model earns its seat.

This does not argue the model is useless. It argues the opposite at one job: reading the messy thing a human wrote and turning it into something the plumbing acts on.

Classifying an enquiry. Drafting a reply that sounds human. Pulling three fields out of a paragraph nobody formatted. Summarising a long thread. The model is good at the fuzzy edge where rules break down.

What the model does not do: remember anything after the reply, route work to the right place, retry a failed step, or keep a record. Ask it to, and you are handing one tool four jobs it was never built for. Those are different jobs. One model, one node, one step in a graph that mostly runs on rules and pipes.

What to ask before you sign.

When a vendor sells you “AI”, the model is the part they demo. The plumbing is the part you are paying for. So ask about the plumbing.

What happens when the model is wrong? What happens when it is down? Where is the work logged, and who reads the log? How does a failed step recover? Who reviews the answers the model is unsure about?

A team that built the pipes answers in specifics. A team that wrapped a model in a nice screen changes the subject back to the model. The answers tell you which one you are talking to.

The boring parts first.

We build the plumbing before the model, on every job, including our own. The back office that runs LeadHunt is webhooks, queues, structured records, and logs, with a model sitting in the few spots where messy text needs reading. We wrote about running it on ourselves in what we run before we sell it.

The model gets the attention. The plumbing gets the work done. Buy the plumbing. The model is a node you swap when a better one ships, and a better one always ships.