AI Agents & Automation

Two very different products are sold under the same words right now, often at a similar price. The first answers questions from your website and then shows a contact form. The second checks real availability, quotes from real pricing rules, and creates the booking. The gap between them is architecture, not prompt wording.

I build both, and I will tell you which one you need. For a lot of businesses the honest answer is the cheaper one.

What this actually is

At minimum, retrieval augmented generation: your services, prices, service area, exclusions and guarantees indexed and searchable, with the model constrained to answer only from those documents and instructed to defer rather than guess. For a business that quotes real numbers, that constraint is not an upgrade, it is the bar. A system that invents a price creates a customer who believes they were quoted it.

Beyond that, tools the agent is permitted to call: check availability, calculate a quote, create a booking, look up a customer. The Model Context Protocol gives one consistent interface between the model and your systems rather than bespoke glue for every integration. Each tool carries its own permissions, because reading availability is safe and taking payment is not.

Anything with a correct answer is calculated in code, not generated. Pricing from square footage, age and distance. Whether you serve a postcode. Those are lookups, and the model reports the result rather than improvising it.

What you get

How it works

Start with retrieval only. Launch the grounded assistant and let it run for a month against real visitors. The transcripts tell you exactly which tools are worth building, which saves considerable money compared with speculating up front. Almost nobody guesses the right qualifying questions before seeing real conversations.

Then add tools, in order of value. Usually availability first, then quoting, then booking. Each one is scoped, permissioned and tested on its own.

Then the workflow. Orchestration in n8n is unglamorous and it is where reliability problems actually live, so it gets proper attention rather than being an afterthought.

Build time is typically four to eight weeks for the full booking version. The modelling is rarely the slow part: documenting your pricing rules and integrating with your existing scheduler is where the time goes.

What it costs to run, not just to build

Build cost gets quoted. Running cost frequently does not, and it decides whether this is sustainable for you.

There are three ongoing components. Model usage is charged per token, so cost scales with how many conversations you have and how verbose the agent is. Hosting for the agent service is modest but real. Maintenance is the one people forget: when you change a price, add a service, or your scheduler updates its API, someone has to update the agent.

Content drift is the most common way these systems fail. An agent that was accurate at launch is quietly wrong six months later because nobody reviewed it. I budget a quarterly review into any build: read a sample of transcripts, check the answers against current reality, fix what has moved. An agent nobody audits becomes a liability slowly and invisibly, which is the worst way for a customer-facing system to fail.

Plan for one round of changes after the first month too. Almost nobody gets the qualifying questions right before seeing real conversations, because visitors ask things you never anticipated.

When you do not need this

I would rather say this early than take the work. Skip the booking agent if your jobs cannot be quoted without seeing them, if you get under roughly thirty enquiries a month, if your scheduling involves crew skill matching and drive time, or if your prices are not documented anywhere yet. An agent cannot apply rules that do not exist.

The strongest honest case for a booking agent is coverage of the hours you do not work. Look at when your enquiries actually arrive. For most home services a real share land in the evening and at weekends, and those people contact the next company on the list. The agent does not need to beat you. It needs to beat your voicemail.

Common questions

What if it tells a customer something wrong?

The right thing to worry about. Constrain it to retrieved content, calculate anything with a correct answer in code, require confirmation before any action, and log everything so you can audit it. The risk does not reach zero, which is exactly why pricing and availability must never be improvised.

Does this replace my scheduling software?

No. It writes into it. Your scheduler stays the source of truth and the agent becomes another way to create a booking in it, alongside the phone and your form.

Will it slow my site down?

It will if you let it. Deferred loading, restriction to relevant pages, and measuring before and after keeps it manageable. I measure rather than assume, and I have removed chat widgets that cost more in abandoned page loads than they produced in leads.

If you are being quoted for an AI chatbot, ask what happens at the moment a visitor says yes. If the answer is a contact form, you are buying the cheaper product at the more expensive price. Send me the quote and I will tell you which version you actually need.