Executive Summary
Most writing about AI agents is speculative. It describes what agents will do, produced by people who have not run one in a business where the output matters.
We run several inside a working advisory firm — handling inbound calls, financial aggregation, bookkeeping and payroll, and marketing production. This is a practitioner's account of what that has actually been like, including the parts that did not work, because those turned out to be the instructive parts.
KEY INSIGHT The hardest problem in our deployment was not technical. It was that the person running the business cannot simultaneously build the systems — the work requires sustained, uninterrupted attention, and operating a business is interrupt-driven by definition. Every meaningful technical failure we hit was a configuration or verification failure rather than a capability one. But the failure that cost the most time was structural: trying to do both jobs at once.
If you own a lower-middle-market business and are weighing AI, the useful transfer is not our tool list. It is the failure modes, because you will hit the same ones.
One thing this article is not. Our sector research is written by people. AI has a role in our firm, and we are specific below about where — it is in the operating back office, not in the analysis we publish or the advice we give clients.
Section 1: What We Actually Run
Call reception and scheduling. Answers inbound calls, qualifies the caller and books meetings directly into the calendar. For a single-principal firm, this is the difference between a missed call and a booked introduction — and missed calls are pure lost revenue in an advisory business where the first conversation is the whole funnel.
Financial aggregation. Clients send information in whatever form they have it: spreadsheets, PDFs, exports, photographs of statements. This system digests that material and turns it into a consistent, usable format. Anyone who has run a diligence process knows how much time disappears into exactly this, and how little of it is analysis.
Bookkeeping and payroll automation. QuickBooks and payroll running with minimal manual intervention. Unglamorous, high-volume, rule-bound, and the clearest payback of anything we operate.
Design and marketing production. Graphics and campaign workflows produced end to end rather than briefed out and waited on.
The pattern is deliberate. Every one of these is narrow, repetitive, and measurable, and every one operates on internal or client-supplied data under review. None of them decides anything. That is not timidity — it is where the returns actually are.
Section 2: What Genuinely Works, and Why
The best candidates are boring. In every case above, we could state precisely what "correct" looks like before we started. A meeting was booked or it was not. A statement was parsed correctly or it was not. Payroll ran or it did not. That property — a verifiable definition of success — is the single strongest predictor of whether an AI deployment works.
Scoping narrowly beats scoping broadly. A general-purpose assistant given every tool and permission is worse than a narrow one with three tools and a clear brief. More decisions mean more places to go wrong. Our scheduling system cannot touch financial data. Our bookkeeping system cannot send email. That restriction improves output quality rather than limiting it.
The gains show up where nobody was looking. The measurable return was not in doing existing work faster. It was in work that previously did not happen at all — calls answered that would have gone to voicemail, client material processed the day it arrived rather than the week it arrived. For a small firm, capacity is the constraint, and that is where the value landed.
Section 3: What Broke
The failure that cost the most was not technical at all
We spent months getting this wrong, and the mistake had nothing to do with models, tools or configuration.
We tried to run the firm and build the systems at the same time. It does not work, and the reason is structural rather than a matter of discipline. Building an agent system requires sustained, uninterrupted attention — you hold a lot of context, you test, something breaks, you trace it. Running a business is the opposite by nature: a client calls, a deadline moves, a deal needs attention today. Every time those two collided, the build lost. Not because it was less important, but because it was never the most urgent thing in front of us.
The result was months of a project that was perpetually eighty percent finished. Each restart cost the time to rebuild the context we had lost since the last session, so the actual progress per hour kept falling.
What fixed it was putting the build in the hands of someone disconnected from running the business. Someone whose only job that week was the system, who did not get pulled into a client call halfway through, and who could hold the whole problem in view long enough to finish it. The work went from stalled to shipped, and nothing about the technology changed.
We would state that as the strongest practical finding in this article. If you are the person running the business, you are the wrong person to build the system — not for lack of capability, but because the attention profile the work requires is precisely the one your job denies you.
The technical constraint was almost always ours
The failures we spent the most time on were not the model struggling with a task. They were limits we had set ourselves — a ceiling on how much information a system could hold at once, a permission profile intended for different work that had quietly removed a capability, a timeout shorter than the job required.
In each case the system was capable of the work and configured to be unable to finish it. When an agent fails, the first question is not whether the model is good enough. It is what you capped, and whether you capped it below what the task needs.
Status is a claim, not evidence
We have had a system report a task complete having done most of it. We have also had the opposite — a task finished correctly and reported as failed.
Both are the same underlying problem. An agent's report on its own work is generated by the same system that did the work, and it can be wrong in either direction. Trusting it in the optimistic direction means shipping errors. Trusting it in the pessimistic direction means throwing away work that was fine.
Every meaningful task in our firm now ends with a check against the artifact itself — does the record exist, does it contain what it should, does the number match the source. That one practice has caught more problems than everything else combined.
Long tasks fail differently from short ones
A short task fails visibly. A long, multi-step task fails at step nine of twelve, having produced eight steps of good work that then get discarded along with it. Anything with more than a handful of steps needs checkpoints, or a single late failure costs you all of it.
Confidence is not accuracy
The output that worries us most is not the obvious error. It is the plausible, well-formatted, confidently-worded output that happens to be wrong. Nothing about the presentation signals a problem. The only reliable defense is a person who knows the domain reading it — which is why we do not use these systems where we lack that person.
Section 4: The Lessons That Generalize
- Verify the output, not the status. Check the artifact. "Done" is not evidence of done.
- Scope narrowly. Fewer tools, tighter brief, one clear output.
- Assume the constraint is yours. Limits, permissions, timeouts. The model is rarely the bottleneck.
- Checkpoint long tasks. Or accept losing all of it when one step fails.
- Keep a human who can tell. The review step is not a formality around the system. It is the system.
- Deploy where you can define correct. If you cannot state what a right answer looks like before you start, you are not ready to automate it.
- Separate building from operating. The build needs uninterrupted attention; running a business does not allow it. Give the work to someone who is not also holding the day job — internally if you can, externally if you cannot.
Section 5: What This Means If You Are Considering AI for Your Business
Start with one repetitive, well-defined, expensive process. Not a strategy, not a platform. Dispatch scheduling. Invoice matching. Inbound call handling. The applications that work are boring by design, and that is the point.
Budget for the verification, not just the tool. The license is the cheap part. The expensive part is the person who checks the output and the routine that makes checking habitual. Businesses that skip this do not save money — they defer the cost until the first undetected error surfaces.
Expect the first attempt to fail. Ours did, more than once, and this is our own infrastructure. Assume one abandoned attempt before something works, and do not begin that cycle inside twelve months of a sale process.
Do not build it yourself while running the business. This is the failure we watched most closely, because it was ours. The owner is almost always the person who understands the process best and therefore seems like the obvious builder — and is almost always the person least able to give the work the continuous attention it needs. Whether you solve that with a dedicated internal person or outside help matters less than recognizing that doing it in the gaps between client work does not finish.
Do not confuse a tool with a capability. Roughly 89% of U.S. small businesses say they use AI; under 9% use it in the production of goods or services. The gap between those two numbers is precisely the work described in this article — and an acquirer will test which side of it you are on.
Be clear about where you will not use it. We do not use these systems for analysis we publish or advice we give clients. Deciding that in advance is easier than deciding it under deadline pressure, and it is the decision clients care about most.
Neo Advisory's View
What follows is opinion drawn from operating these systems, and we have separated it deliberately.
1. The interesting question is not what agents can do. It is what you can safely let them do unsupervised.
Capability is advancing quickly and is not the constraint for most business tasks. Trust is. The design work worth doing is deciding which outputs can go straight out, which need review, and which should never be automated. We have answered that conservatively and do not regret it.
2. Where you refuse to use AI matters more than where you do.
Every firm now claims AI capability. Very few will tell you where they have deliberately kept it out. For an advisory business, that boundary is the thing a client is actually asking about, and stating it plainly is worth more than any capability claim.
3. Publishing your failures is the only credible way to write about this.
A great deal of AI content is written by people with no working deployment, and it shows. If a firm cannot tell you what broke, they have not run anything at scale. We would apply that test to anyone pitching AI implementation, ourselves included.
4. The productivity gain is real and it is not where people expect.
It is not in doing existing work faster. It is in capacity — the calls that get answered, the client material that gets processed the day it lands. For an owner-operated business, that is the binding constraint, and it is where the return actually shows up.
5. Small firms have a structural advantage here, and most squander it on the wrong constraint.
We deployed these systems without an IT department, a change-management program or a committee. A large organization cannot move that way. The advantage is real.
But the constraint is attention, not capital — and most owners try to solve an attention problem with their own already-committed attention. That is why so many small-business AI projects sit permanently near completion. The businesses that finish are not the ones with the biggest budget or the most technical owner. They are the ones that gave the build to someone who was not simultaneously running the company.
Conclusion
The technology works, and it works on narrower ground than the marketing suggests.
The hard part is not getting an answer out of a model. It is building the checks that tell you whether the answer is right, and keeping them in place once the novelty wears off. Every failure we have had was a configuration failure or a verification failure. None was a capability failure — and we suspect that ratio holds in most businesses.
Which means the work that determines whether AI pays back is not technical at all. It is deciding what to automate, defining what correct looks like, and being honest about where a machine has no business making the call.
A Note on This Article
This is a practitioner account of our own back-office deployment as at August 2026, not a general survey. Our systems and configurations change; the failure modes are what we expect to generalize, not the particulars.
Our published research and client advice are produced by people. The systems described here operate in the firm's back office.
Adoption figures are from the U.S. Chamber of Commerce and the U.S. Census Bureau via the JPMorgan Chase Institute, examined in more detail in our companion piece.
Related Neo Advisory research
- Does AI Adoption Increase Enterprise Value? What Buyers Actually Pay For
- Four Roll-Up Sectors, One Playbook
- 2026 Car Wash Sector Market Overview
Prepared by John-Michael Tamburro, Founder, Neo Advisory.
This article is prepared for informational purposes only. It does not constitute investment, financial or technology advice.