The decision rule
Fixed steps need automation. Variable decisions need an AI agent. Visibility, control and business-specific workflows need custom software. A serious department-level system will often combine all three, with a human supervising the areas where the risk justifies it.
Business owners call almost everything an AI agent now. A form creates a Google Drive folder and suddenly somebody says they have an autonomous workforce.
They do not. They have a useful automation, and there is nothing wrong with that. The problem starts when the label becomes more impressive than the system.
I have also seen the opposite. A founder launches an open-ended agent, has to keep telling it what to do, and watches a poorly configured setup burn through hundreds of dollars a day in cloud and API costs. That is more intelligent than a Zapier workflow, but it is still not a complete operating system.
The right question is not, “How much AI can we put in this?” It is, “What is the simplest architecture that can reliably remove the constraint?”
01 · Get the language straight
The four architecture levels founders keep mixing together
These categories overlap, but they are not interchangeable. Each gives you a different level of flexibility, control and complexity.
| Architecture | What it does | Best used when | Main limitation |
|---|---|---|---|
| Basic automation | Runs fixed triggers and actions | The same steps happen every time | Limited by the platform and its integrations |
| AI agent | Interprets information and chooses an action | The work contains judgement or variation | Can lack visibility, controls and a usable interface |
| Custom software | Creates a controlled product around your process | The workflow is specific to your business | Without AI, decisions still follow fixed logic |
| Combined system | Uses automation, AI and software as one operation | You are changing a department or major constraint | Requires real engineering, QA and maintenance |
Basic automation
A basic automation is a trigger followed by a set of actions. Somebody fills out a form, Zapier, Make or n8n receives it, then the platform creates records, moves data or sends messages.
It is easy to implement, easy to understand and normally easy to maintain. It is also capped by what the platform allows. You are working with its apps, triggers and actions. If the workflow needs something outside those rails, you start fighting the tool.
AI agent
An AI agent is a computer with a brain. Instead of following the exact same path every time, it can read context, make a bounded decision and take an action. That agent might live inside n8n, or it might run through an agent framework such as Hermes Agent or OpenClaw.
The important part is not the label. It is what the agent can understand, which tools it can use, how much freedom it has and what happens when it is uncertain.
Custom software
Custom software gives the business its own interface, data, permissions, reporting and workflows. It looks and behaves the way the operation needs because it is not trying to support thousands of unrelated companies.
That control is the reason I see it as the gold standard when the problem is important enough. But custom software without an AI layer still follows deterministic logic. It can be a beautiful, powerful automation without being able to think.
The combined system
The highest standard for a serious operational system combines all three. Basic automations handle predictable triggers. AI agents interpret the grey areas. Custom software gives the team visibility, controls, data and a front end built around the business.
That does not mean every workflow deserves all three. It means the architecture should expand only as far as the business problem requires.
02 · Simple is sometimes exactly right
When a basic automation is the best answer
In one of my previous agency roles, our client onboarding flow started when somebody submitted a Typeform. The automation created their Slack channels, built a Google Drive folder, added the relevant Google Doc templates and sent their PandaDoc contract.
The steps were known. They happened in the same order. There was no judgement call for an AI model to make.
Building custom software for that workflow would have been a waste of time and money. It was not the constraint in the business, it was not a major cost, and a non-technical team member could adjust the workflow without waiting for a developer.
Use basic automation when
- The trigger is clear.
- The actions happen in a fixed order.
- There are very few grey areas.
- A failed step is easy to identify and replay.
- The workflow is useful but not a strategic differentiator.
Good architecture is not about building the most sophisticated thing. It is about refusing to over-engineer the simple thing.
03 · Give the system a brain when it needs one
When an AI agent earns its place
AI becomes useful when the same thing does not happen every time. The system has to read information, understand what matters, adapt to context and decide what to do next.
Client-facing work, research, content decisions, campaign optimisation and department-level operations all contain grey areas. A fixed flow can route the work, but it cannot handle every variation without becoming an unmaintainable mess of branches.
“If something has to think and make decisions without you prompting it, that is where AI comes into play.”Harry Meighan
A useful agent that did not need custom software
At my previous agency, we ran a scheduled research agent every week. It collected public conversations and search results from places such as Reddit, Quora and Google across Google Ads, Meta Ads, SEO and AI web design.
It looked for the posts and articles where people were discussing new ideas, ranked what appeared useful, drafted a short research document and sent the relevant findings to each department.
That agent was valuable because it helped the team find innovation near the start of a trend instead of after it had become saturated. It ran in the background on a schedule. We did not need to build a full interface around it because the output was simple and the risk was low.
This is an important distinction. An agent does not automatically need a custom product. If the task is bounded, the output is easy to inspect and nobody needs a dashboard, the agent can stand alone.
04 · Control changes the architecture
Why an agent sometimes needs custom software around it
A backend agent can do impressive work, but the team may have no useful way to see what it is doing. There is no clear dashboard, approval queue, permissions model, audit trail or reporting layer. It just operates.
That can be acceptable for low-risk research. It is not acceptable when the system affects client delivery across dozens or hundreds of accounts.
Custom software becomes necessary when you need:
- Visibility into every job and decision.
- Controls for pausing, approving or rerunning work.
- Different permissions for operators, managers and clients.
- A shared source of truth instead of scattered tool history.
- Reporting tied to the operation rather than a single app.
- A product that reflects your process and brand.
The software is not there to make the agent look nicer. It turns intelligence in the backend into an operation that people can trust, supervise and improve.
05 · What the combined system looks like
Inside the AI-driven SEO platform we built
The clearest example from my previous Head of AI role was an SEO operation serving an automotive marketing agency. The department had seven people, cost about $20,000 a month in payroll and had become the constraint because performance and delivery quality were contributing to churn.
We did not solve that with a single agent or a long n8n flow. We built a complete AI-driven software platform.
The front end gave the operator a dashboard, reporting and a Kanban board showing the tasks the AI was working on. The backend included the content engine, research workflows, Google Business Profile tasks, analysis using Screaming Frog data and agents for the work that required interpretation.
Basic automations handled predictable events. For example, when a new review arrived, the system could notify the app and prepare the correct response workflow. The AI layer handled decisions and content. The custom software gave one human operator visibility and control across more than 100 client accounts.
Removing the seven-person payroll saved about $20,000 a month at the team level. The completed operation cost roughly $5,000 a month to run, including the remaining operator and system costs, so the net monthly reduction was around $15,000.
Experience note: this platform was built during Harry’s previous in-house role as Head of AI, before Build, Ship & Scale. The figures are presented to explain the architecture and operating logic behind the current team’s work.
06 · Buy the narrow tool, build the operation
When SaaS is enough and when custom becomes worth it
Most SaaS products solve one common problem for a large number of businesses. That is exactly why they can be launched quickly and sold for a relatively low monthly fee.
If you need one reporting feature, one rank tracker or one research tool, buying software is normally sensible. You get value quickly without paying to recreate a solved problem.
Custom becomes worth considering when the business needs one end-to-end system across the department, or when its process is too specific to fit the average customer a SaaS company has designed for.
If you are comparing implementation routes, read our full build vs buy vs hire guide for AI systems.
| Buy existing software | Build a custom system |
|---|---|
| You need one common capability. | You need an end-to-end department workflow. |
| The process is not a competitive advantage. | The process directly affects capacity or retention. |
| The standard workflow fits the team. | The operation needs its own logic and controls. |
| Speed matters more than ownership. | Data, ownership and long-term control matter. |
Owning the system can also reduce dependency on a collection of subscriptions and make the operation more defensible. That can strengthen the business, but only when the system solves something valuable enough to justify building and maintaining it.
07 · The expensive mistakes
Where these projects actually go wrong
Building the wrong system
The biggest mistake is architectural only in the broadest sense. A perfectly engineered product is still a bad investment if it does not remove the constraint or reduce a major cost.
If you have not chosen the problem yet, start with our guide to finding the first AI system worth building.
Trying to vibe-code production software alone
AI coding tools are useful, but they do not replace software engineering judgement. Without somebody who understands the architecture, security, data model and failure modes, the code can go in the wrong direction very quickly.
The danger is not that a prototype fails to appear. It is that the prototype looks convincing enough to put in front of clients before anybody knows what is underneath it.
Expecting one hire to be an entire product team
Hiring a strong AI engineer into a smaller business is difficult. Even after finding one, a production system still needs product thinking, software engineering, infrastructure, security, testing and ongoing maintenance.
One expensive hire can still leave the founder managing a development function they never wanted to build.
Treating testing as the final checkbox
There are always bugs. A system that has not been tested is not almost ready. It is simply not ready.
08 · Intelligence still needs engineering
What production-ready actually means
At Build, Ship & Scale, our QA team is the same size as our development team. Developers build. Testers actively try to find where the product breaks. Developers fix what they find, then the cycle continues.
The test process includes:
- Unit tests for individual pieces of logic.
- Integration tests for connected services and data.
- End-to-end tests across complete user workflows.
- Regression tests so new work does not break old behaviour.
- Common client and operator flows tested in a UAT environment.
Human oversight is also an architecture decision, not an admission that the AI failed. The SEO platform had one person overseeing more than 100 active clients because there were many moving parts, exceptions to review and improvements to make.
How much oversight a system needs depends on the risk tolerance of the business and the cost of a wrong decision. A research summary and a client-facing fulfilment action should not have the same approval rules.
After launch, maintenance matters for the same reason. Operators need somewhere to raise bugs and request features. The system should improve as the business changes instead of becoming a frozen product nobody wants to touch.
09 · Count the real cost
The cheapest-looking route is rarely the cheapest
You can try to build the system yourself. You can hire one person and hope they cover every discipline. You can connect more subscriptions until the workflow mostly holds together.
When you compare those choices, include the founder’s time, the cost of a wrong hire, the months lost, the security and reliability risk, client complaints, fulfilment mistakes and the churn a bad system can create.
Then compare that total with using a team that already has developers, QA testers and experience building systems across agencies and info businesses.
The goal is not to buy more AI. It is to build the simplest reliable system that removes the constraint and gives the business control over what happens next.
Our AI system ROI framework shows how to compare that complete cost with the capacity, savings and retained profit the system could unlock.