AI & automation
What AI integration actually involves
Most of what’s written about AI is either selling you something or warning you off it. I’ve built four systems that use it, including one that ran on an earlier version of this site, and one that deliberately doesn’t use it at all. Here’s what I’d want to know before paying for any of it.
Four questions
The short version
Four questions decide whether AI belongs in the job at all.
-
Is being roughly right most of the time useful?
If it has to be right every time, you want code, not a model.
-
Does the answer depend on your data or on general knowledge?
If it's your data, most of the work is getting that data to the model reliably. Very little of it is the model itself.
-
Can someone check it before it reaches anyone?
If a person signs off each answer, the model's allowed to be wrong now and then. If it goes straight to a customer or into your accounts, pick a job where being wrong costs nothing: a suggestion someone can ignore, not an invoice.
-
Would a set of rules do it?
If the rules are stable and you can write them down, write them down.
If three or four of those point away from AI, ordinary software will be cheaper, faster and more predictable, and I say that having built plenty of both.
In practice
Where it earns its place
Three jobs, from systems that actually shipped.
-
Answering questions about one business
The previous version of this site ran a chatbot on GPT-4, grounded in a file describing Method7: what I do, roughly what things cost, the portfolio, how to get in touch. Visitors asked in their own words and got answers about my business, not the internet's general opinion of web development. The model supplied the language. The file supplied the facts.
-
Finding structure in more data than anyone will read
M7SEO, my own search platform, runs two agents. One reads a site's search queries and groups them into themes, classifying the intent behind each. The other turns those themes into ranked opportunities. That's classification and judgement across thousands of rows. You could do twenty by hand. You're not doing two thousand.
M7SEO → -
Acting inside a narrow surface
Curator, a Web3 platform I led the engineering on, has an autonomous publishing agent. It owns a smart-account and publishes curated records on-chain to a decentralised knowledge graph as a space editor. It does one thing, under its own identity, and everything it does lands on a ledger it can't quietly rewrite.
Curator →
Answering, classifying, acting. Each one is harder to build than the last, and each one costs more when it goes wrong.
The counter-example
Where it doesn’t
I built a digital HACCP system for an artisan smokehouse. It records times, temperatures, batches and checks as the food is made, and it tells the producer what’s due next. The smokehouse is Method7’s own venture, so there was no client to hide behind.
There’s no AI in it, and there shouldn’t be. Food safety is a set of rules, written down in law and in the producer’s own plan. A rule engine applies them identically every time and can be audited line by line. A model would apply them almost identically every time, and nobody should want almost when the question is whether a batch is safe to sell.
That’s the test, really. Where the rules are stable and you can write them down, write them down. AI earns its place when the input is messy, the rules are genuinely fuzzy, or there’s more of it than a person can get through.
Patterns
Three shapes an integration takes
Call a provider from your own backend
The common case. Your server holds the credentials and talks to the provider, and your application talks to your server. Never straight from the browser: whatever your front-end holds, every visitor holds as well. A key sitting in a published bundle isn’t a secret.
Ground it in your data
A model’s general knowledge isn’t your business. Grounding means gathering the facts that matter and handing them over with the question, so the answer comes from your material. The chatbot above did it with one structured file. Bigger jobs need retrieval, which is more machinery doing the same thing.
Let it act
Give it a tool, a permission, an account. This is where things go wrong fastest, so keep the surface as narrow as the job allows and make sure everything it does leaves a trail.
Engineering
What makes it reliable
People spend a long time choosing a model. Hardly any of this is about that. Swap the model out and every problem below is still sitting there.
-
Validate before you store
M7SEO describes each agent's output as a schema, and anything that doesn't match gets rejected instead of saved. Nothing unvalidated reaches the database. A model returning something odd now and then is normal. A database full of odd records is a mess you live with.
-
Don't make the model carry identifiers
M7SEO's agents return names, and the code looks those names up. Asking a model to repeat a UUID correctly is a tax you pay for nothing. Get a name wrong and the code catches it. Get an id slightly wrong and it's stored, and believed.
-
Make it propose, not decide
Where M7SEO estimates how commercially valuable a theme is, that number is explicitly a proposal for someone to confirm, not a decision. It acts on its best guess and I can overrule it. Build that in from the start, because it's much harder to add later once something downstream is relying on the number.
-
Make it say when it doesn't know
The chatbot's best feature wasn't an answer. When it couldn't answer from what it had, it emailed me the question. I found out what people were asking that I'd never written down anywhere, and nobody got a confident invention instead. Anything that takes questions needs somewhere for its failures to go.
-
Separate the failures worth retrying from the ones that aren't
A timeout is worth retrying. A malformed response isn't, not forever. M7SEO sorts its errors into those two buckets. Without that you either give up on a blip, or keep hammering the provider with something that's never going to work.
Cost
What it costs, and what actually drives it
Model usage is usually the smaller number. Two things drive the real cost.
Repeat work. If the system chews through the same content on every run, you pay on every run. M7SEO hashes page content and skips whatever hasn’t changed, and that’s the single biggest lever on what it costs to run. Most systems have an equivalent, and finding yours early is worth more than shopping around for a cheaper model.
The engineering around the model. Validation, grounding, retries, logging, somewhere for a person to check the output. That’s where the time goes, and it’s what you’re really paying for. Budget for it. Skip it and you get something that demos beautifully and nobody trusts after the first wrong answer.
Getting started
A sensible first step
Pick one narrow job. Something that happens often enough to matter, where you can tell whether the output is any good, and where somebody sees the result before a customer does. Measure it against how you do it today, and keep a way to switch it off.
If it works you’ll know something real about how your own process runs, which is worth having either way. If it doesn’t, you found out cheaply.
Two things I’d avoid. Buying a platform before you’ve got a problem to point it at. And bolting AI onto something that already works, because it feels overdue. I see both a lot. Usually somebody has decided to use AI and is now looking for a reason.
If you’re weighing this up for a system you already run, bespoke software development is the wider picture. It’s usually worth a conversation before anything gets built.
Bespoke software
Got something that needs building properly?
If you are weighing up where AI fits in a system you already run, or whether ordinary software would serve you better, tell me what the work looks like today and I will give you a straight read on it.