The real problem with AI rollout in SMBs and mid-market companies
Companies at the 50 to 500 person mark are in an awkward position with AI. The pressure to adopt is real. The expectation from leadership is real. But the internal capacity to do anything ambitious is not.
Most of these companies do not have a dedicated AI team, an internal machine learning function, or spare engineering bandwidth sitting around waiting to be pointed at agent projects. What they have is a small technical group, probably already stretched across the existing stack, being asked to somehow figure out AI on top of everything else.
That is the starting condition. And it shapes almost everything about how AI rollout goes wrong.
What leadership expects
A meaningful AI program running across the business within a reasonable timeframe.
What the team has to work with
A small technical group, existing delivery commitments, and no dedicated AI function.
What usually gets proposed
A top-down rollout where tech builds agents for each department, one at a time.
What usually happens
One or two pilots, then a long stall when the maintenance burden kicks in.
Why top-down rollout creates a bottleneck that never clears
The top-down model works like this: leadership decides to roll out AI agents. The brief lands with the tech team or a consultant. They start gathering requirements from each department, translating business problems into agent logic, building something, testing it, iterating. Then they move to the next department and do it all again.
The problem is not that this process is slow, though it is. The problem is that it asks a small technical layer to carry a kind of context that they cannot actually hold. To build a useful agent for a sales team, you need to understand how that team works day to day, what their tools look like, what slows them down, where the edge cases are. The same applies to finance, to support, to operations. That is not context you can gather in a requirements session. It lives in the people doing the work.
So the tech team builds something that is 70% right, the department uses it for a bit, requests come in to adjust it, and now whoever built it has to stay close to it indefinitely. Multiply that across four departments and the model has already broken down before it has even scaled.
| Stage | What breaks |
|---|---|
| Requirements gathering | Technical resources have to understand operating context they do not sit inside. |
| Build | Agents are built to spec rather than shaped by the people who know where the spec is wrong. |
| Handover | Departments use the agent but cannot change it without going back to the queue. |
| Maintenance | Tech ownership persists indefinitely. Every change request is a new dependency. |
| Scale | Adding departments multiplies the load without adding capacity to carry it. |
The scope versus adoption tradeoff
There is a version of AI rollout that most companies have not seriously considered because it sounds like it gives up too much. It trades scope for adoption. Instead of trying to build comprehensive, powerful agents that automate complex workflows end to end, it starts with governed, bounded agents that do smaller jobs, but that every person in the organisation can actually use and own.
Scope is what the agent can do. Adoption is how many people in the business are actually using AI day to day. The top-down model optimises for scope and gets almost no adoption. The bottom-up model optimises for adoption and earns broader scope over time.
This is not a consolation prize. It is a fundamentally different rollout theory. The bet is that 60 people each using a simple, governed agent produces more business value than one department using a sophisticated agent that three people in IT have to maintain.
| Approach | Optimises for | Risk |
|---|---|---|
| Top-down through tech | Scope and sophistication | Low adoption, high maintenance dependency, stalls at scale |
| Bottom-up with governed self-serve | Adoption and ownership | Scope starts narrow, expands as confidence and controls mature |
What bottom-up agent rollout actually looks like
Bottom-up does not mean uncontrolled. It means the locus of agent creation sits closer to the people who understand the work, rather than being centralised in a technical function that has to translate for everyone else.
In practice, it looks like this. Tech connects the tools and sets the approval model. Then people across the business, technical and non-technical, use a no-code builder to describe what they need in plain language. An agent is created, scoped to the specific job, and runs with defined approval rules, spend limits, and an audit trail. The person who built it owns it. They adjust it when their workflow changes. They do not file a ticket to do so.
A sales rep builds an agent that drafts outreach sequences from CRM data. A finance manager builds one that flags invoices approaching 30 days overdue. An operations lead builds one that compiles a weekly status summary from three different tools. Each agent has a small job. None of them require a developer to write or maintain them. All of them run inside a governance layer that the business controls.
- Anyone in the org can describe what they need in plain language and get a working agent.
- Tech sets the approval model once. Every agent operates within it.
- The person closest to the work owns the agent and adjusts it when things change.
- Scope expands over time as usage matures, not as a prerequisite to starting.
Why governance is what makes broad deployment safe
The legitimate concern with giving everyone in the business access to AI agents is that something goes wrong at scale. An agent writes to the wrong record. Costs run unchecked. Something happens that nobody can explain because there is no record of it.
This is a real concern and it is the right one to have. But it is a problem with ungoverned deployment, not with broad deployment. The two are not the same thing.
A governed no-code platform puts approval gates in front of every consequential action. Before an agent writes to a CRM record, sends a message, or creates a document, a human reviews and approves it. Spend caps mean an agent cannot run unchecked beyond a defined cost threshold. Audit logs give the business a complete record of what ran, what was approved, and by whom. Role-based permissions mean users can only deploy agents that access the tools and data they are supposed to have access to.
Broad deployment with governance is actually more visible than narrow deployment without it. When three people in tech are running agents on behalf of the business and something goes wrong, there is no formal record, no approval trail, and no clear owner. When sixty people are running governed agents, every action is logged, every approval is timestamped, and every agent has a named owner.
Approval gates
Write actions require human sign-off before they execute. Nothing consequential runs without review.
Spend caps
Hard limits per agent or per team. When the cap is hit, the agent pauses and notifies the owner.
Audit trail
Every action, decision, and approval is logged. The business has a full record without anyone maintaining it manually.
Role-based permissions
Users can only build and run agents within the scope of the tools and data they are permitted to access.
What this does to the culture inside the organisation
There is a dimension to this that does not show up in the technical argument but matters more than most leaders expect. When AI is introduced as something that tech does to the business, people notice. They do not always say it directly, but they wonder whether the agents being built on their behalf are there to help them or to replace them. That is a reasonable thing to wonder.
When the rollout model flips and people build and own their own agents, that feeling changes. They are not a subject of the rollout. They are a participant in it. They shape what their agent does. They approve or reject its actions. They adjust it when their workflow changes. AI becomes something they use, not something being done to them.
That distinction has practical consequences. Adoption that comes from people having genuine ownership of the tools tends to be durable. Adoption that is imposed from above tends to be surface-level and fragile. The culture of an organisation that has genuinely adopted AI looks different from one that has technically deployed it. The bottom-up model is the one that gets you to the former.
Frequently asked questions
Won't agents built by non-technical people be low quality or unsafe?
Not if the platform is designed for it. Governed no-code deployment means every agent runs inside approval rules, spend caps, and audit trails set by the business. The quality floor is set by the platform, not the builder. Non-technical users define what the agent does. The platform controls what it can actually touch.
What does trading scope for adoption mean in practice?
It means starting with narrower, more bounded agents instead of trying to automate complex end-to-end workflows on day one. A sales rep builds an agent that drafts follow-up emails. A finance manager builds one that flags overdue invoices. Each agent has a small job. Collectively, they add up to meaningful adoption across the org without a long technical build phase.
How do you stop agents from doing things they shouldn't?
Approval gates. Every write action, whether it is updating a CRM record, sending a message, or creating a document, can be set to require human sign-off before it executes. Spend caps stop runaway costs. Audit logs show exactly what ran and when. The governance layer is what makes broad deployment safe.
Does this replace the need for a technical team?
No. Tech still owns the platform, sets the approval model, connects integrations, and monitors usage. What changes is that they stop being the bottleneck for every new agent request. They set the guardrails. Everyone else operates within them.
What if we want more complex agents later?
You build on top of what you have. Scope expands as the team gets comfortable, as use cases mature, and as the business's appetite for broader agent access grows. Starting narrow does not lock you into narrow. It just means you are not betting the whole rollout on a complex deployment working perfectly on day one.