An AI automation service builds workflows that connect your systems and put a model somewhere in the middle - and the part nobody discusses in the sales conversation is where those workflows run once the engagement ends.
This is a fast-growing category with a lot of agencies in it and a fairly uniform pitch: audit the process, identify the repetitive work, build the automation, report the hours saved. Some of that work is genuinely valuable. Evaluating it well requires knowing what the deliverable actually consists of.
Table of contents
- What these engagements actually consist of
- The questions to ask before signing
- Where automation genuinely pays, and where it does not
- What you own afterwards, and how to make sure of it
- Doing it yourself, briefly
- How this fits the rest of the stack
- FAQ
What these engagements actually consist of
Strip away the framing and almost every engagement in this category delivers some combination of four things.
- A process audit. Someone maps what your team does manually and identifies what repeats. This is often the most valuable part, and it is consulting rather than technology.
- Integration plumbing. Connecting the CRM to the spreadsheet to the inbox to the ticketing system. Mostly conventional integration work, with or without a model involved.
- Model-in-the-loop steps. Classification, extraction, summarisation, drafting. A model doing a discrete task inside a larger workflow, which is where the genuine leverage usually is.
- A dashboard or report. Visibility into what ran and what it saved.
Notice how much of that is ordinary systems integration. The model is frequently one node in a workflow of fifteen, and the value comes from the workflow existing at all rather than from the model being clever.
The questions to ask before signing
- Where does this run when you leave? On the agency’s account, on a hosted platform under your account, or on infrastructure you control? This determines whether you have bought an asset or a dependency, and it is the question most often left unasked.
- Who holds the credentials? Automations need API keys for every system they touch. Find out where those live and who can see them, and what happens to them at the end of the engagement.
- What happens when a step fails? Does someone get alerted, or does the workflow quietly stop and nobody notices for a fortnight? This distinguishes a system from a demo more reliably than anything else.
- Can your team modify it? If changing a field name requires the agency, the automation is a subscription rather than a deliverable.
- What is the ongoing cost? Per-task platform fees, model API usage, and hosting. The model bill in particular scales with volume and is easy to underestimate by an order of magnitude.
An agency that answers these clearly is worth working with. One that gets uncomfortable around questions two and four is selling a dependency, which may still be fine as long as you know that is what you are buying.
Where automation genuinely pays, and where it does not
The pattern is consistent across almost every engagement worth doing. Good candidates are high-frequency, low-judgement, and well-defined: moving data between systems, extracting fields from documents that arrive in a predictable format, routing enquiries by category, generating first drafts of routine correspondence, reconciling two lists nightly.
Poor candidates are the opposite: low frequency, high judgement, or ill-defined. Automating something that happens twice a month costs more to build and maintain than it saves, and it will break silently between uses. Automating a decision requiring real judgement produces confident wrong answers at scale, which is worse than the manual process it replaced.
The most reliable value in this category is not replacing a person. It is removing the copying and pasting between systems that a person currently does around the actual work - which is usually where the hours have been going all along.
What you own afterwards, and how to make sure of it
The difference between a good outcome and an expensive one is almost entirely about custody, and it is decided at the start rather than at the end.
Run it on your infrastructure. A self-hostable automation platform deployed under your account means the workflows, the execution history, and the credentials are yours. The agency builds in your environment and hands over access. If they leave, nothing stops.
Keep credentials in your own secret storage. Environment variables in your platform, rotated when the engagement ends, scoped to the minimum each workflow needs.
Insist on export. Workflow definitions in a file, in a repository, in version control. Even if the platform is the only thing that can execute them, having the definitions means you can rebuild rather than reverse-engineer.
Get the failure path documented. What alerts, to whom, and what the manual fallback is for each workflow. An automation nobody is watching is a liability wearing the costume of an asset.
Doing it yourself, briefly
For a lot of teams the honest answer is that the first few automations are within reach internally. Deploy a workflow tool, connect the two systems that annoy you most, and see what happens. The learning is fast and the exercise reveals which processes are actually well-defined enough to automate, which is the information the audit was going to sell you.
Bring in outside help for the genuinely complex ones, or when there are twenty processes and no time. Just make sure that help builds in your environment rather than theirs.
How this fits the rest of the stack
Whether you build the automations or buy them, they need somewhere of your own to run if they are going to be an asset rather than a subscription. The RunxBuild hosting calculator prices the tool, the database behind it, and the bandwidth so that decision has a number attached. RunxBuild runs n8n as a managed tool with its own plan, custom domains, environment variables, autoscaling, and logs, alongside managed Postgres and MySQL - so workflows and credentials stay in your account without you administering a server.
Useful related references:
- Zapier Alternatives: What Changes When Automation Runs on Your Own Infrastructure
- AI Blog Automation in WordPress: The Setup That Does Not Get You Penalised
- Railway n8n: What to Check Before You Self-Host Workflow Automation
- Services on RunxBuild
FAQ
What do AI automation services actually deliver?
Usually four things: a process audit identifying repetitive work, integration plumbing between your existing systems, model-in-the-loop steps for classification, extraction or drafting, and a dashboard. Much of it is conventional systems integration, with the model as one node in a larger workflow.
What should I ask an automation agency before signing?
Where the workflows run after the engagement ends, who holds the credentials, what happens when a step fails, whether your team can modify the workflows without them, and what the ongoing cost is across platform fees, model usage, and hosting.
Which processes are worth automating?
High-frequency, low-judgement, well-defined ones: moving data between systems, extracting fields from predictable documents, routing enquiries, drafting routine correspondence, nightly reconciliation. Anything infrequent or requiring real judgement costs more to maintain than it saves and fails quietly between uses.
How do I avoid becoming dependent on an automation agency?
Have them build on infrastructure under your account, keep credentials in your own secret storage scoped to each workflow, insist on exported workflow definitions in version control, and get the failure and alerting path documented for each automation.
Can we build automations ourselves instead?
The first few usually yes. Deploy a workflow tool, connect the two systems that annoy you most, and see what happens - the exercise reveals which processes are well-defined enough to automate, which is most of what an audit would tell you. Bring in help for genuinely complex work.