Most of what is sold to small businesses as “AI agents” right now is workflow automation wearing a costume. I don’t mean that as an insult to workflow automation. A well-built workflow is often exactly what the business needs. The problem is when a vendor charges you for the costume.
Here is the specific claim I want to put through a test: “Our AI agent will handle your customer intake end-to-end, autonomously.”
Keep that sentence in mind. We will come back to it.
What “agent” actually means
Anthropic, the company that makes Claude, published an essay in late 2024 called “Building Effective Agents.” Its core distinction, workflows versus agents, has become the closest thing the industry has to a shared vocabulary. The three-tier version below is my simplification of their framing:
- A task is a single model call: “Summarize this email.”
- A workflow is multiple model calls in a sequence you define. The system follows predefined steps; the model fills in the outputs at each step.
- An agent is a system where the model itself decides what steps to take, which tools to use, and in what order. You hand it a well-defined goal and it figures out the path with whatever it has access to.
Most of what small businesses are being sold as “agents” is the second thing: a predefined sequence of steps with an AI model somewhere in the middle. That is a workflow. Workflows are useful. Calling them agents is marketing.
Gartner, the research and advisory firm whose reports enterprise IT departments pay serious money for, has a name for this: agent washing. As of mid-2025, Gartner estimated that of the thousands of vendors claiming to sell agentic AI, only about 130 actually qualified under a rigorous definition. Their analysts put it directly: “Many use cases positioned as agentic today don’t require agentic implementations.” The same firm predicts that more than 40 percent of agentic AI projects will be canceled by the end of 2027.
So when a vendor tells you their system is an AI agent, the first question is: does the model decide what to do next, or do you? If a human or a developer already decided the steps and the model is just filling them in, you are looking at a workflow.
The reliability problem behind the label
This distinction is not just semantic. It has real consequences for how often the system works.
If a system takes 10 sequential steps and each step succeeds 99 percent of the time, the chance that all 10 complete correctly is about 90 percent. Still pretty good. Stretch that to 100 steps at the same per-step accuracy and you are down to about 37 percent. Two honest caveats make this worse, not better: on real tasks, per-step accuracy is usually below 99 percent, and while agents can sometimes catch their own mistakes, recovery is itself a step that can fail.
Carnegie Mellon researchers built a benchmark called TheAgentCompany that tests AI agents on 175 real workplace tasks: scheduling, admin, HR, finance, software work. In the original December 2024 results, the best model completed about 24 percent of tasks fully on its own. An update the following year with newer models brought that to 30.3 percent. The researchers’ conclusion was plain: current agents are a long way from autonomously performing most of the work a human employee does.
That number is not the failure of one model. It is consistent across independent benchmarks of open-ended, multi-step office work. When a vendor claims their agent handles your intake “end-to-end, autonomously,” that is the context they are not giving you.
Established practice: for tasks that follow a stable, repeatable sequence where you can verify the output at each step, a well-built workflow outperforms an autonomous agent on reliability, cost, and debuggability. You own the control flow. When something breaks, you know exactly where it broke.
Now look at your intake process. There is no test suite for “classified this customer’s urgency correctly.” A misrouted request doesn’t fail to compile. It sits quietly in the wrong queue until someone notices, and by then the someone is usually the customer.
Agents work where the environment verifies their work and mistakes are reversible. Most business operations offer neither.
Autonomy is also an attack surface
There is a second cost to autonomy that almost never comes up in the sales conversation, and it is the one I care about most professionally.
A workflow has fixed steps, which means you can scope its permissions tightly: this function can read this bucket, write to this table, and nothing else. An agent that decides its own steps needs access to everything it might decide to do. That is a fundamentally different security posture.
It gets worse! The top-ranked risk on OWASP’s list for LLM applications is prompt injection which is instructions hidden inside content the model processes. For agents, the dangerous variant is indirect injection, where the malicious instruction arrives in something the agent reads (an email, a web page, an attachment) rather than from the person operating it. The attacker doesn’t need access to your systems. They need access to something your agent will eventually read. At that point, every tool the agent can call is a tool the attacker can call, with your permissions and none of your judgment.
In McKinsey’s 2026 AI Trust survey of roughly 500 organizations, security and risk concerns were the single most cited barrier to scaling agentic AI, ahead of regulatory uncertainty and ahead of technical limitations. The people deploying these systems at scale have noticed. Securing agent deployments deserves its own post!
For now, a small business buying an “autonomous end-to-end” agent is buying that attack surface, usually without a security team to watch it.
What intake automation actually looks like when it works
A customer intake process is a good candidate for automation. It happens often, it follows a pattern, and the information involved (name, contact, service type, date) is structured enough that a system can handle it without judgment on most passes.
But “good candidate for automation” is not the same as “ready for an autonomous agent.”
A large language model is a probabilistic system. Every word it produces is a statistical prediction of what comes next, including the numbers. When a model writes “12 × 34 = 408,” it isn’t calculating. It’s predicting text that looks like the answer to that calculation. Most of the time the prediction is right. “Most of the time” is the problem, because in content with a verifiable right answer, an error rate that’s tolerable in a chat window becomes unacceptable when multiplied across thousands of generated items.
Two things follow from this, and they shaped how I built a production system for verifying AI-generated math problems and geometric figures.
First: turning the randomness down doesn’t fix it. You can set a model’s temperature to zero and get nearly the same output every time, but a repeatable answer isn’t a correct answer. Reproducible and correct are extremely different properties. What correctness-critical work needs is a second system that computes the actual answer deterministically and checks the model against it. In that pipeline, every calculation the model produces (worked examples, answer keys, unit conversions, physical constants) is verified by code that does real math: a symbolic math engine, a dimensional-analysis checker, published scientific constants. The model proposes; deterministic code verifies. When they disagree, the content never reaches a user. It is regenerated or flagged to a human reviewer.
Second: images are worse than numbers. Ask a model to draw a triangle with a 37° angle and you’ll get something triangle-shaped with a “37°” label. Whether the drawn angle actually measures 37 degrees is a question the model never answered. The drawing is one prediction, the label is another, and nothing forces them to agree. So I don’t ask the model to draw. It outputs a structured description of the figure, parameters only, and deterministic code computes the coordinates and renders it. The figure, its labels, and the answer key can’t contradict each other, because all three derive from the same computed values instead of three separate acts of prediction.
Intake has the same shape with different stakes. Names get transposed. Urgency gets misread. A record that doesn’t match reality sits in your CRM until it costs you a customer. Nothing in the model will ever notice on its own.
And here is what I usually find before I build anything: the process has not been written down clearly enough to automate. There is a step someone handles in their head, that implicit knowledge. There is a decision that depends on context not captured in any form. There is a handoff that works because one person knows to check a specific inbox.
Before that process is automated, it needs to be mapped. Where does the work start? What information has to arrive before the next step can happen? Who reviews what, and when? What is the fallback if something is missing?
This is process work, not software work. And it is the part most vendors skip, because it is slower and less impressive than demoing a chatbot.
Something I always ask: how much of the business’s judgment can be safely handed to a model before the cost of wrong answers (missed context, misclassified urgency, records that don’t match) outweighs the time saved? For most small businesses doing intake, my answer is that the model should handle data collection and routing, and a person should still make the first real decision about the customer.
The question to ask any vendor
Here is a question you can ask verbatim:
“What is the per-step success rate of your agent, and how many steps does a typical task involve?”
Most vendors will not have a clean answer. The usual move is to cite a generic benchmark score and hope the number does the convincing. What I would want to know is whether that benchmark tested tasks that are short and controlled, or tasks that resemble the actual length and messiness of the real work.
A vendor who gives you a straight answer, including the honest caveats, especially when it’s not what you want to hear, is worth talking to. A vendor who pivots to a demo is telling you something.
What is actually worth building right now
In my opinion, the most useful AI systems for small businesses in the next two years will not be autonomous agents. They will be well-built workflows with one or two bounded AI steps inside them: a model that describes an uploaded file, drafts a reply, classifies an incoming request, surrounded by deterministic logic that you own and can debug.
This is not hypothetical for me. One production system I built runs more than 200,000 media assets through exactly this pattern: an event-driven pipeline that transcribes video and audio, writes AI descriptions for images and footage, generates embeddings, and indexes everything for semantic search. You can ask it for “students working in a greenhouse” and it finds the footage, even though no human ever tagged it. Every AI step in that pipeline is bounded. The model describes what it is handed; deterministic code decides everything that happens next. By the definitions above, it is not an agent at all. That is exactly why it runs unattended at that scale.
The automation that removes the most pain is usually not the flashiest. It is the step that someone on your team has to chase every week. Find that step, write it down clearly enough to explain to a new hire, and then decide whether it is worth building software around. Often a checklist solves it. Sometimes a form solves it. Occasionally the software is worth it.
Back to that claim
“Our AI agent will handle your customer intake end-to-end, autonomously.”
Run it through everything above.
An agent? By the working definition, probably not. And if it truly is one, the follow-up is why intake, a stable and repeatable process, needs a model choosing its own steps at all. End-to-end? That is a long chain, and the compounding math punishes long chains. Autonomously? That means broad permissions, an open attack surface, and no human at the first real decision about a customer.
The claim fails on all three counts. Not because AI has no place in intake. Because the version worth buying is smaller, more bounded, and less impressive in a demo than the pitch.
If you’re not sure which category your problem falls into, that is exactly the conversation to have before buying anything. If you want to think through where your intake or operations process is actually leaking time, reaching out is a good place to start.
