What it actually takes for a business to use AI agents

The problem. An AI agent is only as good as the information you give it, and most businesses keep what matters scattered across inboxes, spreadsheets, and people's heads. Hand an agent that mess and you'll quickly find yourself with the worst case of buyer's remorse.

The goal. What would it take for a small business, two to forty people, to actually put AI agents to work?

The approach. Get everything into one trustworthy place, set the rules the agent must follow, then turn it on. Build it so a person can always check its work.

The takeaway. The AI turned out to be the easy part. Capturing how the business actually runs was the hard part, but the bigger one is the handoff: agents change how work moves between people and software, and the larger the team, the more they reshape how people work. For many, that means real re-skilling.

1. A complete operating model. Minimum viable spine (data model) of fifteen connected databases across four tiers, seeded with real data rather than samples.
2. A governance layer. Five plain-English harness files that define how an agent must behave: the conventions it operates under, the vocabulary it uses, the voice it writes in, and the rules determining exactly when a human is brought in.
3. A proven loop. A live inbound enquiry taken from trigger to approval to record update. The agent read, drafted, and waited. Approval took under thirty seconds. Nothing reached the record without a decision.
4. An operator dashboard. A working interface demonstrating the day-to-day experience: what needs a decision, what was handled automatically, the record itself, and the rulebook governing it.

Alongside the build, I worked through what it would take to deliver this repeatedly rather than once.

5. A discovery method (v1). A structured conversation for extracting how a business actually runs, organized around four layers: alignment, relationships, delivery, and operations. This is the front end of every engagement and the part that determines whether everything downstream is correct.
6. A management system (v1). The back office for running these builds: version control on the governance files, client-specific documentation, workflow libraries, and a decisions log. Built in the same architecture as the product, which means the delivery method is itself run on the system it delivers.

1. Operating system design. Designing and delivering the operating system a business actually runs on: the operational workflows, the databases structured to a real standard, and the software chosen to support the internal team rather than fight it. This is closer to organizational design than to software, and it is the foundation everything else sits on. I developed a rev model that could yield a entrepreneur $1M-2M annually.
2. Enterprise context architecture. Getting a business's data into a shape an agent can actually use. Super unsexy but this gap is a gold mine for the independent developer, operator, or freelancer willing to do the unglamorous work. Same rev opportunity depending on your bandwidth.
3. Agentic system development. What I did in this build, but model first and at small-business scale: the governance layer, the escalation rules, and the review console, delivered for a single team rather than an enterprise. The same discipline, a smaller version of it.

On price, the model takes two shapes. Delivered solo, one operator running a handful of engagements a year, it is a $1M to $2M practice. With a small senior team of four to six running the same method at more throughput, it reaches up to $5M. The ceiling in both is how many engagements can run without diluting the discovery work, which is the part that does not delegate easily.

• The record is the real constraint. In most businesses the operating record is scattered across inboxes, spreadsheets, and people's heads, with no single source of truth. An agent dropped into that does not resolve the disorder, it propagates it at speed. Getting how a business runs down as structure is what decides whether automation is viable at all.
• General tools don't enforce integrity. Partway through I deliberately broke the model: deleted a company that still had contacts attached, created two identical records, orphaned a project from its parents. All three succeeded silently. That is fine while a human does the writing, because humans notice. It stops being fine the moment software does, because software does not.
• Reviewable beats trustworthy. The console shows what the agent read, what it proposes, and the rule that made it stop for a human, and every automatic action can be opened afterwards and traced to the sentence that permitted it, in plain English and editable without a developer. Asking someone to trust an autonomous system is a big ask. Giving them the means to inspect it is a small one, and far easier to build.

• Order first, agent last. The record comes first, the governance layer second, the agent last. Every serious attempt I have looked at arrives at that sequence eventually, and it is cheaper to start there.
• The handoff is the real work. Agents change how work moves between people and software, and the larger the team, the more they reshape how people work day to day. For many that means real re-skilling, which turns out to be harder than the technology.
• This is still early. Five days and one worked example. The model has not run in production, the loop was executed by hand rather than by software, and the escalation thresholds are placeholders that only real use will calibrate. What I am confident about is the ordering.