I’ve been working with large language models since 2022, long before “AI agents” became the phrase everyone wanted to put into a strategy deck. Over the last few years, I’ve had the opportunity to implement AI solutions for several Fortune 500 companies. Today, through ODS, I’m doing that work much more directly with small and mid-sized businesses, including companies in fintech, payments, and retail, helping them figure out where AI can actually solve a business problem and then building those systems with them.
That shift has given me an interesting perspective on AI adoption. In larger companies, I saw the technology through enterprise implementations, where architecture, governance, security, and scale were major considerations. At ODS, I’m often much closer to the actual business problem and the people experiencing it every day. We can identify a problem, build something, put it in front of users, and very quickly find out whether AI is actually making their lives easier.
The technology itself has changed dramatically during that time. Models are faster, cheaper, more capable, and much easier to integrate into real business processes. Things that would have required a specialized machine learning team a few years ago can now be prototyped by a good engineer in a few days.
Yet after building more of these systems, I’ve become convinced that one of the biggest challenges in implementing AI has very little to do with the models themselves.
It’s expectations.
Strangely, the better AI gets, the worse this problem seems to become.
The Demo Problem
One of the things I’ve become increasingly skeptical of in AI is the demo.
The industry has become incredibly good at demonstrating what AI can do. Every week there is a new agent that can operate a computer, write an application, analyze thousands of documents, replace a customer support team, conduct research, or automate some complicated business process. You watch the demo and it is hard not to come away thinking that a huge part of knowledge work is about to be automated.
The problem is that demos are usually showing capability under ideal conditions. Production systems have to deal with everything else.
A demo might show an agent successfully completing a complicated task five times. A business needs to know what happens when it performs that task 50,000 times. What happens when the data is incomplete? What happens when a user does something unexpected? What happens when an API is unavailable, the context is ambiguous, or the model confidently makes the wrong decision? What happens when the cost per transaction suddenly matters, or when a process that took thirty seconds during the demo becomes painfully slow when hundreds of people are using it?
None of this makes the demo dishonest. The capability being demonstrated can be completely real. The mistake is assuming that because an AI system can do something, it can therefore do it reliably enough to become part of a business process.
I see this expectation with clients as well. Someone uses ChatGPT or Claude, gets an incredible result, and naturally asks why an internal AI system can’t behave exactly the same way every single time. I understand where the expectation comes from. These products are extraordinary. But a great interaction with an AI assistant and a production system processing thousands of transactions are two very different things.
The gap between those two worlds is where a lot of the actual work in AI implementation happens. It is less exciting than the demo because it involves evaluations, validation, guardrails, fallbacks, monitoring, latency, cost, data quality, and deciding what should happen when the AI doesn’t know the answer.
We also unintentionally create unrealistic expectations by how we talk about AI. We celebrate the successful run. We share the impressive output. We post the video of the agent completing a task from beginning to end. We rarely post the other attempts where it got stuck, misunderstood the context, or confidently did something completely different.
This doesn’t mean the technology isn’t extraordinary. It means capability and reliability are two different things, and right now I think we are frequently confusing one for the other.
Sometimes the Better AI Solution Is Less AI
One of the projects that really reinforced this lesson for me at ODS was an invoice receiving system for liquor stores.
The workflow sounds simple. A store receives a shipment from a distributor, and an employee needs to understand what was delivered and enter the products, quantities, prices, taxes, discounts, and other information into the inventory system. It is exactly the kind of repetitive process where you look at it and immediately think: AI should be able to do this.
And it can.
We built an agent that could take an invoice, interpret it, and return structured data that would populate the receiving interface automatically. Instead of an employee manually entering everything, the system could do most of the work for them. On many invoices, the results were excellent.
Then came the real-world scenarios.
Invoices are not standardized. Different distributors use different layouts. Products have unusual naming conventions. Units and cases are represented differently. Discounts appear in strange places. Some documents are clean PDFs, while others are scans or photos. Information that seems completely obvious to a human can require surprisingly complicated reasoning from a model.
Our natural reaction was to keep making the agent better. We improved the prompts, added context, tested different models, created validation rules, and started building increasingly sophisticated logic around it.
Eventually, I found myself asking a different question: are we actually making the business process better, or are we just making the AI more complicated?
That question changed the way I looked at the problem.
We started moving more of the document extraction toward OCR and deterministic document-processing techniques, while reserving the LLM for the places where language understanding or reasoning actually added value. It was a useful reminder of something that gets lost in the current excitement around AI: not every problem needs an LLM.
If I need to know exactly what number appears in a particular field on a document, I don’t necessarily want a probabilistic language model interpreting that document for me. I want reliable extraction. If I need to understand that “12 PK 750ML” corresponds to a particular inventory concept despite how a distributor described it, that may be a much better place for an LLM.
These technologies don’t need to compete. OCR can extract information, traditional software can validate it, business rules can enforce what should and shouldn’t be allowed, LLMs can interpret ambiguity, and humans can resolve uncertainty.
In many cases, the best AI architecture isn’t the one with the most AI in it. It is the one that solves the business problem with the fewest unnecessary points of failure.
The Human Is Part of the System
The invoice experience has also changed the way I think about human-in-the-loop systems.
There is sometimes an assumption that the ultimate goal of an AI agent is complete autonomy, and that if a human still needs to review something, the implementation somehow isn’t finished. I don’t agree with that.
For the invoice system, the ideal experience may not be invoice to AI to inventory. It may be invoice to extraction, AI interpretation, validation, and then human review whenever the system encounters something uncertain.
If an employee previously spent fifteen minutes manually receiving an invoice and now spends two or three minutes reviewing what the system already prepared, that is a huge improvement. It doesn’t particularly matter that we didn’t achieve “full autonomy.”
The human isn’t there because the AI failed. The human is part of the system.
The business problem was never that a human touched the invoice. The business problem was that the human was spending fifteen minutes doing something that could mostly be automated.
That distinction becomes even more important when the consequences of an incorrect answer are financial, operational, legal, or customer-facing.
We Are Trusting AI Too Much
I think we are currently developing an extraordinary amount of confidence in AI systems based on relatively small samples.
We ask ChatGPT twenty questions and get nineteen great answers, so our brains naturally begin treating the system as reliable. But 95 percent accuracy means something very different at scale. If your system processes one hundred transactions, maybe five errors are manageable. If it processes one hundred thousand, you potentially have five thousand problems.
What makes this even more difficult is that the models are becoming incredibly convincing. An LLM can be intelligent, articulate, and completely confident without necessarily being correct. As the quality of the responses improves, our instinct to question those responses can actually decrease.
There is a reason ChatGPT and Claude still remind users to verify important information (If you haven’t notice, check the disclaimer in the bottom of either app). Yet somehow, when companies take similar underlying technology and put it behind an API, we sometimes start designing systems as if that warning no longer applies.
It does.
None of this means I’m pessimistic about AI agents. Quite the opposite. I use them constantly, including inside my own company.
I built my own CRM because I wanted something that worked around the way we actually run ODS. Everyone on my team has access to the projects they are assigned to, where they can add status updates, reminders, notes, and anything else related to the work we are doing. Over time, that creates something much more valuable than a traditional CRM record: it creates context.
That data is what makes the AI useful.
I have multiple agents running on top of it that generate insights and help me understand what is happening across the business. I also built a Q&A system where I can simply ask questions about our projects, clients, or work and get answers based on the information my team is already maintaining. Instead of going through project updates, messages, and notes myself, I can ask what is happening with a particular client, what needs my attention, or what has changed recently.
I also have several agents integrated directly into Slack that surface information and automate smaller pieces of work for the team.
None of these agents are particularly useful in isolation. They work because there is good data underneath them and because they are integrated into workflows that people are already using. The CRM gives the agents context, the team continuously adds new information, and the agents make that information easier to understand and act on.
That experience has reinforced another lesson for me: sometimes companies become so focused on which model or agent framework they should use that they overlook the thing that will ultimately determine whether the system is useful at all — the data and context you give it.
I don’t expect one giant autonomous agent to run my company. I would rather have several focused agents, each with a clear responsibility, operating on top of data I trust and workflows that already make sense.
That architecture is much less exciting to describe than an autonomous AI employee.
It is also much more useful.
At the Same Time, Building Software Is Changing Completely
There is another side to all of this that makes the current moment particularly interesting. While I’ve become more cautious about what I’m willing to trust an LLM to do autonomously in production, I’m becoming more impressed by coding agents almost every week.
They are getting remarkably good, and they are lowering the barrier between having an idea and actually building something.
I saw a great example of this recently with someone I know who isn’t technical at all. He runs a construction company and started experimenting with AI tools on his own. The next time we spoke, he showed me several things he had built for his business to solve problems he was dealing with every day.
None of them were massive enterprise applications, but that was exactly what made it interesting. He understood the problems because they were his problems, and suddenly he had tools that could help him turn those ideas into working software without needing to know how to build software himself.
At one point he pulled up his Obsidian graph with all of his notes, connections, and workflows mapped out and showed it to me like he had just invented the internet. I had to laugh, but I also thought it was pretty incredible.
A few years ago, someone like him would have needed to explain an idea to a developer, get an estimate, decide whether it was worth spending thousands of dollars, wait weeks or months for something to be built, and probably go through several iterations before discovering whether it was actually useful. Now he can sit down with an AI coding tool, describe a problem he understands intimately, and start experimenting.
That may end up being one of the most consequential parts of this AI wave. We spend a lot of time talking about AI replacing software engineers, but I think an equally interesting story is how many people who never considered themselves software builders are suddenly going to start building software.
There is an interesting contradiction in that. I trust AI more and more as a tool that helps humans build, while becoming more cautious about AI systems that are expected to operate autonomously without human judgment.
Those two things can be true at the same time.
The models are getting dramatically better. Coding agents are getting better. The cost of creating software is falling. People who couldn’t build something two years ago can now build surprisingly sophisticated tools. At the same time, a model being capable of doing something is not the same as a production system being reliable enough to do it thousands of times without supervision.
That distinction between capability and reliability is probably one of the most important things I’ve learned from actually implementing AI systems.
The better question for companies, then, isn’t necessarily what they can automate or which AI agent they should build. It is much simpler: what business problem are we trying to solve?
Maybe employees spend fifteen minutes entering every invoice. Can we make that three? Maybe a salesperson spends an hour every morning figuring out which clients need attention. Can an agent surface the five that actually matter? Maybe information about a company is spread across project updates, notes, and conversations. Can AI make that information easier to understand and act on?
Those aren’t particularly futuristic ideas. They are business problems.
AI is simply one of the most powerful tools we now have to solve them.
I remain extremely bullish on AI. I see what these systems can do every day, and I think we’re still very early in understanding how much they will change the way companies operate. But being bullish on AI doesn’t mean believing AI should do everything.
Sometimes the best solution is an agent. Sometimes it’s OCR. Sometimes it’s a database query, a validation rule, or fifty lines of normal software. Sometimes AI’s most valuable role is helping a human make a better decision. And sometimes the right answer is simply to ask a human.
The goal was never to build the most impressive AI system.
The goal was to solve the business problem.