Field Notes

Why Your First AI Project Disappointed You

The short answer

Most first AI projects disappoint because someone sold you a role and delivered a node. You were promised something that would handle a person’s job. What showed up handles one step of it, and the gap between the two felt like failure.

If you’ve had that experience, you’re not alone. Most of the owners I talk to have one. They bought Copilot seats nobody uses for real work. They set up a chatbot that answered three questions well and the fourth one wrong. They tried an automation that saved an hour a week and somehow made everyone’s job a little more annoying.

The usual conclusion is that AI isn’t ready for a business like theirs. That’s usually the wrong conclusion.

Roles are bundles. AI takes nodes.

A job isn’t one thing. An estimator’s week might involve pulling numbers from four places, checking last year’s pricing, drafting the quote, calling the customer, catching the one detail that makes this job different, and deciding what the margin should be. That’s a dozen tasks stapled together under one title.

AI is very good at some of those tasks and not ready for others. It can pull the numbers and draft the quote in minutes. It can’t automatically know that this customer always pays late and the price should reflect it, unless someone teaches it that rule and checks its work.

Think of each task as a node in a larger system of work. AI can take on individual nodes, but a role is the entire network of tasks, decisions, and relationships surrounding them.

When a vendor pitches “an AI estimator” and delivers a quote drafter, the tool might be perfectly good at its one node. But you were expecting a role, so it reads as a letdown. Your estimator, who heard “AI estimator” too, may have spent the whole rollout worried about the wrong thing.

What a node looks like in a real business

Take an office manager who handles incoming invoices. Broken into nodes, part of that job looks like this:

  1. Open the invoice and pull out the vendor, amount, and due date.
  2. Match it against the purchase order.
  3. Enter it into the accounting system.
  4. Flag anything that doesn’t match.
  5. Decide whether a mismatch is a typo or a real problem, and call the vendor if it’s real.

Steps one through four are largely structured and repeatable. A system can extract the information, match it against the purchase order, enter the approved details, and flag discrepancies for review.

Step five is different. It requires context, judgment, and knowledge of the relationships behind the transaction. Knowing whether a discrepancy is a harmless typo or a sign of a larger problem often depends on information that isn’t sitting in the invoice.

The result isn’t that the office manager disappears. It’s that their role shifts from doing every step to overseeing the process, resolving exceptions, and focusing on the work that needs a person. That’s a smaller promise than “AI will handle accounts payable.” It’s also one that actually gets kept.

How to get it right the second time

If your first project let you down, the fix usually isn’t a better tool. It’s a better starting question.

  • Start with the real week, not the job description. Sit with the people doing the work and write down what they actually spend their hours on. The job description always leaves out the parts that eat the day.
  • Break the work into steps. Then sort them: repetitive and rule-based on one side, judgment and relationships on the other.
  • Build for one step first. Pick the one that costs the most hours or causes the most errors. Get it working and trusted before touching anything else.
  • Follow the work across departments. The invoice might arrive in accounting, but the purchase order started in operations, and the approval might belong to someone in management. A system that works perfectly in one department can create a mess in another. Understand the handoffs before you build.
  • Keep a person checking the output. That’s not a limitation. It’s how the system earns trust, and how it gets corrected when it’s wrong.

The bottom line

Your first AI project probably didn’t fail because AI doesn’t work for businesses like yours. It failed because it was sold as a replacement for a person and built as a tool for one step.

That’s how I approach this work. I start by understanding what you’ve already tried, where it fell short, and how the work actually gets done. Then I find the opportunities worth building around.

Sometimes the answer is AI. Sometimes it isn’t. Either way, you should know before you spend another dollar.

If your first AI project left you wondering what went wrong, let’s talk.

All field notes