This is Part 3 of a four-part series on building AI agents for a small business. Part 1 covered the full 700-hour journey. Part 2 was an honest inventory of the mistakes. This piece is the prescriptive companion: what I would tell a peer starting fresh today.
If I could reset the clock to December 2025 with what I know now, the path would look almost nothing like the one I actually took. I do not regret the route I traveled — the failures taught me things I could not have learned any other way. But the time cost was higher than it needed to be, and the operator reading this should not have to absorb the same cost to reach the same destination.
What follows is the playbook I would actually use. It is not theoretical. It is the distillation of four months, three framework deployments, and close to a billion tokens of hard-earned context.
Rule 1: Start With One Problem Worth Solving
The most common mistake I see operators making right now is building an AI platform before they have an AI project. They set up a stack, wire up integrations, and spend weeks on infrastructure before a single business outcome has been improved by a single line of AI-produced work. The setup becomes the goal, and the goal recedes.
The correction is straightforward. Before you write a prompt, pay for a subscription, or evaluate a framework, identify one problem in your business that meets three criteria: it is repetitive, it is costing you or your team real hours every week, and the output is something you can verify. Customer inquiry triage. Weekly reporting. Catalog cleanup. Content formatting. Release setup. Any one of these is a better starting point than a grand architecture.
Solve that one problem with the simplest AI tool that works. Live with it for two weeks. Measure whether the time savings are real or whether you just moved the work around. Only then look at the next problem.
The business owners who have succeeded with AI in my orbit share a common pattern. They did not build a fleet first. They built one thing that worked, and the fleet came later because the results justified it.
Rule 2: Follow the Tool Progression in Order
There is a natural progression of AI tools that matches a natural progression of sophistication. Skipping stages usually wastes money. In my experience, the right order looks like this:
Stage one: a capable chat model. ChatGPT, Claude, Gemini — pick one. Use it daily for two to four weeks for real work, not demos. Learn its strengths, its failure modes, and the prompt patterns that produce reliable outputs. This is not a throwaway stage. Most of the leverage you will eventually extract from agents starts with habits formed here.
Stage two: a code-capable AI environment. This is where Claude Code changed everything for me. When you move from chat to an environment where the AI can read and write files in a real project, the character of the work changes. You stop generating snippets and start shipping systems. Even if you are not a professional engineer — I am not — this stage is where AI begins to produce durable artifacts instead of temporary outputs.
Stage three: one agent doing one job autonomously. Pick a recurring task in your business and give a single agent responsibility for it. Let it run. Observe the failure modes. Fix the failure modes. This stage teaches you what autonomy actually requires: clear instructions, bounded scope, reliable inputs, and clear escalation paths when something breaks.
Stage four: a small team of coordinated agents. Only after stage three works should you build agents that hand work to each other. And when you do, resist the urge to build ten at once. Three focused agents that coordinate well will outperform twenty agents that step on each other every time.
Most operators I see failing with AI jumped from stage one to stage four. They read about multi-agent systems on Twitter and assumed they needed one. They did not. They needed a working stage three.
Rule 3: Budget Time Like a Project, Not a Hobby
I spent 700 hours on AI in four months because I could, and because curiosity kept the hours from feeling like work. An operator without my particular obsession with building will not have that tolerance, and should not need it.
A reasonable time budget for a first-time implementation looks something like this. Forty hours for stage one (capable chat model, real work). Forty to sixty hours for stage two (code-capable environment, first small project). Forty to eighty hours for stage three (one autonomous agent). That is roughly a hundred and twenty to a hundred and eighty hours of focused work spread across two to four months, depending on how aggressive you are. It will not be glamorous. It is, however, sufficient to build a real operational advantage.
If you are tempted to budget less time, you will produce demos instead of durable systems. If you are tempted to budget more, you are probably about to repeat my mistakes. Set the budget, track the hours, and stop when the budget is spent — then evaluate before committing more.
Rule 4: Build What Is Core. Buy What Is Common.
The build-versus-buy decision in AI has been confused by the fact that you can now build almost anything quickly. Quickness is not the same as wisdom.
The test I use is this. If the capability I am considering is a differentiator — something specific to my business, my customers, my data, my institutional knowledge — I build it. A custom knowledge base for my community at House of Carts. A budgeting and inventory tool that actually fits how small operators think. An internal agent that understands our specific processes. These are built, because no vendor will ever capture the specificity that makes them useful.
If the capability is a commodity — transcription, generic writing, boilerplate reporting, standard integrations — I buy it. The market has good tools for these categories, they are cheap, and building them yourself extracts no strategic advantage. Every hour spent rebuilding a commodity is an hour not spent building what is proprietary.
The mistake in the other direction is just as common. Operators buy bespoke workflow products when their workflow is too specific to fit the product. They end up configuring around the vendor's assumptions forever. If the product requires you to change how you operate to fit it, you are probably paying a subscription to adopt someone else's worse system.
Rule 5: Keep Your Memory and Data Portable
This is the single most important rule, and it has its own article at the end of this series. But it deserves mention here too, because it is the decision that most determines how much of your investment survives when your tools change.
Every AI tool you use today will be replaced, pivoted, acquired, or repriced. I say this as someone who has migrated between platforms repeatedly. The operators who lose their work when those transitions happen are the ones whose agent memory, institutional knowledge, and accumulated context lived inside a proprietary system they do not control. The operators who keep moving forward are the ones whose context lives in files and formats they own.
If you take one action from this post, make it this: whatever AI system you choose, confirm before you commit that you can export your data and your agent’s knowledge in a format you could read in a plain text editor. If the answer is anything other than yes, find another tool.
Part 4 of this series covers this in detail.
The Minimum Viable AI Setup for a Small Business
If you asked me what the smallest reasonable AI stack looks like for a small business owner in 2026, I would describe something close to this.
A single capable subscription-grade model — Claude or ChatGPT at the mid-tier — used daily for real operational work, not novelty. A code-capable environment like Claude Code for any task that benefits from reading and writing files. One well-scoped agent handling one recurring task autonomously, with outputs you can verify. A memory system in plain text or markdown files stored on infrastructure you control, version-tracked if you can manage it. A clear budget both for tokens and for your own hours.
That setup will not make headlines. It will, however, compound quietly over twelve months into something most of your competitors do not have: a system that actually works, that you understand, that you own, and that gets better the longer you use it.
Everything else — the multi-agent swarms, the custom orchestration layers, the exotic integrations — is optional. The minimum viable setup is what generates returns. The more ambitious versions are what you graduate into when the foundation has proven itself.
A Final Note on Ambition
None of the above is an argument against ambition. It is an argument for sequenced ambition.
Build the thing that saves you six hours a week before you build the thing that might run your business autonomously. Ship one production system before you design a fleet. Let the results earn the next investment. This is not a conservative playbook. It is the one that actually reaches the finish line.
Coming Up
The final article in this series is the one that matters most for anything you build with AI long-term. It is about memory — specifically, where your agent’s memory lives, who owns it, and why that single decision will determine whether your investment survives the next tool migration. That is Part 4: Your AI’s Memory Will Outlive Your Tools.
Series navigation:
- Part 1: What 700 Hours of Building AI Agents Taught Me About Small Business
- Part 2: Things I Did Wrong Building AI Agents (So You Don’t Have To)
- Part 3: A Smarter Path — What I’d Do Differently Starting AI from Scratch (this piece)
- Part 4: Your AI’s Memory Will Outlive Your Tools
Christopher George is the founder of Marching Dogs and House of Carts. He runs a fleet of AI agents across seven machines for his businesses and has spent more than 700 hours building, breaking, and rebuilding AI systems without a computer science degree.