+1 (248) 723-7903
+1 (248) 723-7903
A colleague sent me an interview with Eli the Computer Guy last week, saying it would be worth my time. He wasn’t wrong. Eli’s argument, in short, is that the singularity talk misses the point, and that a lot of what gets sold as AI is the science fiction story that has fascinated people for decades. I absolutely agree.
I’d add one thing. The story does more than entertain. It changes how a project gets scoped, and by the time anyone realizes, the money is already committed.
Projects scoped that way fail often enough that analysts forecast it. Gartner expects more than 40% of agentic AI projects to be canceled by the end of 2027, and the reasons it gives are escalating cost, unclear business value, and weak risk controls. Model capability appears nowhere on that list.
That matches what I see, and the trouble starts before the project does. Normally, a business finds a problem worth spending money to solve and then funds the project. With AI, that order often gets flipped. Nobody wants to be late to this one. So budgets get approved for the category, and then someone in tech is asked to find a problem to spend it on.
From there it goes one of two ways. Some companies can’t name a first candidate they’d defend in a room, so nothing starts. Others commit to one, get four months in, and find it needed far more than just an AI model.
Those look like different problems from the inside, but they’re the same error, just caught early or caught late.
Identify bottlenecks, automate workflows, and build fast.
Get Started TodayPart of what makes this hard is that the word “AI” covers two distinct things that are routinely treated as one, and almost nobody says which one they mean.
The first is a technology stack – language models, retrieval, vector search, orchestration, evaluation. These are components you can buy, integrate, measure, and replace.
The second is a cultural idea about machines that can think. That one has been with us since long before the current technology, through fiction and mid-century speculation. It carries weight the components don’t.
These are siblings, not strangers. They share a name and a history, but progress on one is not progress toward the other. That’s the conflation Eli is objecting to. Once you know which one you’re dealing with, the questions change. “What can AI do for us?” gets you a demo. “What would it take to automate this one process?” gets you an estimate.
What’s new here is language capability. A model can take a sentence somebody typed and turn it into values a machine can act on, then take what the machine returns and put it back into words a person can use. No previous generation of software could do that at all.
The way it does that is by predicting likely words. Give it the same input twice and you can get two different answers. That’s what makes it good with language, and it makes the model the only part of a working system that guesses.
Everything that turns those guesses into reliable work is ordinary engineering that has existed for decades:
None of that is AI. They’re different technologies that work alongside it, and your company may already run most of them. The ERP, the ticketing queue, the access rules, the nightly job that reconciles two systems. Most organizations are further along toward a working AI system than they think, because they’ve been building the other nine-tenths for twenty years under different names.
Picture an interpreter at your front desk. They’re fluent in every language a customer might speak; they’re quick, tireless, good at turning a rambling complaint into a clear request your back office understands, and good at turning your back office’s answer into something the customer can act on. That interpreter has no keys to the warehouse. No access to order history. No authority to approve a credit. Hire the best one alive and not one order gets filled. What fills orders is the warehouse, the inventory system, and the rule about who can authorize a refund.
So the model translates at the edges. That’s the new part. The system is what does the work.
Say you want to ask a system which customers are more than sixty days past due, and have it draft a note to each one.
That feels like a single act of intelligence. In reality, it’s four things.
The model reads your sentence and turns it into structured parameters: an aging threshold, a date range, an output format. A query runs against your accounting system and returns rows, and it returns the same rows every time, because a database is deterministic. Business logic decides which of those rows are eligible for a notice, since the ones already in a payment plan or in dispute are not. Then the model writes the drafts, in your voice, one per customer.
The model appears twice, at the beginning and at the end. It translated a request in, and it translated results out. The part that determines whether the answer is correct is the query and the eligibility rules. Your aging report is the thing that has to be right. If it isn’t, the model will only help you be wrong faster and in complete sentences.
The story centers the model because that’s where the commercial incentive sits. It’s the part you can impress someone with in a minute. Integration, data work, and access control don’t demo. So the model is what gets sold.
The cultural idea takes it from there. When a product claim borrows weight from the idea, the model starts to sound like the whole answer, and the surrounding system disappears from the conversation.
Let’s be clear, though – this is a phenomenon, not a plot. Given the incentives and the head start the story had, you’d expect exactly this. The trouble is what it does downstream. The story misrepresents what the model does on its own, and every decision after that inherits the error.
Plan against the story and the distortion shows up before anyone builds anything. Projects get chosen for how much they sound like AI rather than for operational fit. Work that conventional automation already handles gets relabeled as a model problem and priced like one. Workflows nobody has ever written down get treated as ready for automation, which automates the mess and makes it move faster.
Timelines get anchored to model evaluation when integration is what takes the greater time investment. Teams get staffed for experimentation when the work is plumbing. Success gets defined at the demo rather than at the point where daily operations meaningfully change.
Ownership fragments. Innovation runs the pilot, IT owns the infrastructure, operations owns the process, and nobody owns the finished workflow. The problem with this is that the workflow is the only unit that returns money.
MIT’s research on enterprise generative AI found the same divide. What separated the small group getting P&L impact from everyone else tracked to integration and organizational learning rather than to model quality.
The second-order risk is worse than a wasted quarter. When a project fails this way, the technology takes the blame, the budget gets cut, and a company writes off a capability it never tested. I’d rather see a company do one small thing correctly than one large thing at speed, because the first teaches you something useful while the second just teaches you to stop. One small thing done correctly earns the next project.
You can place any candidate project with four questions:
1. Can you describe the process precisely enough for a new hire to run it on their second day? If the answer lives in one person’s head and shifts with conditions, you’ve found your first project, and it isn’t a model project. Writing the process down is the work. It’s also cheaper than the pilot that would have encoded the improvisation.
2. Which systems does the work have to reach, and does anyone have access today? Answer it one system at a time. For each, can software other than a person get data in and out, and will whoever controls that system allow it? Some vendors offer a connection, some charge for it, and some don’t offer one. Finding out costs a phone call and can save you a quarter.
3. What happens when the model is wrong? Who sees it, what stops it before it reaches a customer, and what does the record show afterward. Every governance framework now applied to these systems exists for that question, and NIST’s generative AI profile treats confident wrong answers as a named category of risk to be managed rather than an edge case.
4. Who owns the workflow once it runs? Name a person, not a committee. Innovation, IT, and operations can each own a piece and still leave the thing itself unowned.
Answer those four and you have a project you can size. You also have the build list, and most of it is the ninety percent. The model is the last item on it and the easiest to change your mind about. Everything else gets expensive to fix late.
The story of AI belongs to the people selling it. The stack belongs to whoever does the work of building on it. Knowing which one is under discussion is the first operational discipline, and it’s free.
Pick one thing: the initiative you’re closest to funding, or a process people complain about every week. List what has to exist before a model can help. A process someone can describe, systems it can reach, a rule for when it’s wrong, and a person who owns the result. If you can write that list, you’re planning against the stack. If you can’t, that list is the first project.
If you’d find it useful to run these questions against something you’re evaluating or already living with, I keep time open for exactly that kind of conversation. No deck and no pitch, just a working session on what the system has to do and what it would take to get there. You can book a free consultation with me here.
Identify bottlenecks, automate workflows, and build fast.
Get Started Today
I’d love to help you with your tech needs. Just let me know how to reach you and when’s a good time to talk.
"*" indicates required fields
