Should You Hire an AI Automation Agency or Build It In-House?
- Who owns the thing once it is live?
- How do you know it is right?
- What happens to the inference bill at volume?
- Does it belong inside the product?
- Will it survive your data protection review?
The pitch sounds reasonable: a chain of steps, an LLM in the middle, a monthly fee to keep it alive. It runs fine in the meeting. The trouble starts when nobody is watching, a step fails silently, and you hear about it from a customer rather than a dashboard. Before you sign anything, these are the questions that separate a system from a rented workflow.
Who owns the thing once it is live?
This matters more than the price. If the automation lives in someone else’s account, on a platform you cannot read, you have bought a dependency rather than an asset. Ask what happens on the day you part ways: can you read the code, run it, change it? A good answer describes something deployed in your infrastructure, with your database and your APIs, and no migration needed to get there. A weak answer talks about their portal and their support hours. Ownership is also a debugging question. When a step fails at an odd hour, someone on your side needs to be able to look at the queue and understand it.
How do you know it is right?
An automation that is correct most of the time is often worse than none, because a person still has to check every output. The useful question is not whether it works but how often, on what data, and what it costs per run. A serious agency will have measured accuracy on your real examples before go-live, not on a tidy sample. They will also have a view on the hard cases: where confidence drops, does the system guess, or does it hand the item to a person? You should be the one deciding where that line sits, because it is a business judgement, not a technical one.
What happens to the inference bill at volume?
Cost behaviour is where cheerful pilots quietly die. Ask what the automation does when traffic triples, and whether the answer involves caching, routing between models, or usage limits. Anyone who shrugs at this question has not run a pipeline past its first month. You do not need a precise figure, but you do need to hear that the cost curve is something they think about deliberately rather than discover later.
Does it belong inside the product?
Most automation shuffles data between SaaS tools. The compounding value sits elsewhere: the onboarding flow, the matching logic, the review queue. That is where unit economics change, and it is exactly where a plugin cannot reach. If your process is a spreadsheet someone repeats a hundred times a week, an external workflow may be fine. If it is core to how the product works, it should be built in. Knowing which case you are in is half the decision, and an honest agency will tell you when the simpler answer is the right one.
Will it survive your data protection review?
UK teams increasingly find out late that an automation touches personal data in ways nobody mapped. This is not a reason to avoid the work, but it is a reason to ask early how data flows, where it is stored, and what the retention story is. Vague reassurance is a warning sign. So is an agency that agrees everything can be automated; the useful ones push back on steps that should stay human, and say so on the first call.
The full guide sets out the specific package a build should ship with, the questions that expose a rented workflow, and how the AI automation agency London approach differs when the automation lives inside your product rather than beside it.
Write a comment