Diagnosis Before Build
Before You Hire Anyone to Fix Your AI Problem, Figure Out What the Problem Actually Is
The market teaches businesses to choose the provider before they have named the problem.
Natalie de Groot & NatGPT · September 2026
IN THIS PIECE
INTRODUCTION
The market taught us to shop for the solution first
Technology and intelligence are not the same purchase
The same problem appears at very different scales
Before the build, answer three questions
Diagnosis is not the free part before the real work
INTRODUCTION
For the last few years, I have watched the meaning of “we need AI” change almost in real time.
In 2023, many of the people around me were still treating AI as something slightly embarrassing to be interested in. I had already spent a year experimenting with it, while plenty of otherwise intelligent people were still responding with some version of: absolutely not, I am a real person.
In 2024, curiosity started winning. I spent much of that period inside workshops and companies where people were willing to dip a toe in, although willingness is probably generous. Some were fascinated. Some had been sent by their employer. Some seemed mainly interested in arguing with the machine. What they had in common was that they knew something consequential had arrived, but they did not yet have a useful way to separate the different problems hiding inside the word AI.
By 2025, that uncertainty had begun to turn into confidence, and sometimes into something closer to overconfidence. People had discovered what their LLM could do. They were building custom instructions, agents, workflows, automations and increasingly elaborate systems around themselves. The prevailing instinct was often additive: generate more, connect more, ask more, build another layer, regenerate it, try another model, add another tool.
The extraordinary capability of the models made it easy to believe that almost any problem could be solved by adding enough computation around it. What was much harder to see was the rubber-band drawer forming underneath. Context was fragmenting. Decisions were becoming difficult to reconstruct. People were solving for outputs without always knowing which parts of their own judgment the system was supposed to carry.
The technology was becoming more capable while the question of what, exactly, they were building remained strangely unresolved.
That is still where many AI investments begin. Someone says they need an agent. They need automation. They need training. Their API costs are too high. Their employees are using ChatGPT badly. Their content sounds generic. Their workflows are inefficient. They need an AI strategist, an automation agency, a software team, a company chatbot, a better prompt, a better model. These may all be legitimate needs. The problem is that by the time someone names one of them, they have often already made the first strategic decision without realizing it: they have decided which layer contains the problem.
That is a dangerous place to begin spending money.
The market taught us to shop for the solution first
There is nothing uniquely AI about this behavior. I have spent more than two decades in marketing, and businesses have always arrived with solutions disguised as problems. We need a new website. We need SEO. We need a rebrand. We need a campaign. We need social media. The requested deliverable can be perfectly sensible, but good strategic work has always started one step earlier: what are you actually trying to change, and what is preventing that change from happening now?
I used to describe this to clients as building a house. You can make the rooms beautiful, but if the house was built on the wrong foundation, decorating it more aggressively does not improve the structure. AI raises the stakes because we can now operationalize weak assumptions extraordinarily quickly. We can automate them, reproduce them, connect them to other systems and give them enough polish that they begin to look structural. A beautiful workflow can still be carrying the wrong decision. A sophisticated agent can still be missing the context that makes the task meaningful. A perfectly functioning software layer can still be solving a problem that never required software.
This is why “AI problem” is not a useful diagnosis. The failure might live in strategy, workflow, memory, tools, team behavior, decision rights, context, architecture or some combination of them. Sometimes the technology is genuinely inadequate. Sometimes the technology is working exactly as designed and the missing intelligence is elsewhere. Those are materially different situations, and many buyers do not yet know that they are separate.
Technology and intelligence are not the same purchase
I once came into an engagement specifically to review an AI system that an outside technical team was proposing to build for a company. The development proposition was polished, technically credible and expensive enough that the decision mattered. During the review, one idea kept bothering me: the intelligence was being treated as something effectively included in the system.
If a vendor tells you the intelligence is included, ask what they mean by intelligence. Immediately.
The technical team may be excellent. They may build the wrapper, connect the APIs, create the interface, configure retrieval, automate the workflow and make the whole thing feel beautifully effortless. But very often, “your intelligence” enters the build through a much thinner doorway: scrape the website, ingest a stack of documents, add a company profile, perhaps load some FAQs, and call the system informed. That can be useful source material. It is not the same thing as capturing the human intelligence that actually runs the business.
A website rarely contains what your best people notice before they make a decision. It does not reliably contain the exceptions they have learned through experience, the customer signal that changes the answer, the history behind a strange-looking process, the trade-offs they make when two priorities collide, the work they deliberately refuse to automate, the founder’s pattern recognition, or the judgment that tells someone when the obvious answer is wrong. Those things are often distributed across people, conversations, habits, old documents, operating memory and years of accumulated context. If nobody has decided how that intelligence becomes usable by the system, the infrastructure can be finished while the intelligence problem is still sitting untouched.
That is where the economics get ugly. The client receives a polished machine and discovers that the hard cognitive work has landed right back in their lap. Only now the engineers are booked, the implementation is underway, licenses are live, integrations already exist and the meter is running. Every unanswered question about context, memory, authority, judgment or ownership is more expensive to answer after the build has hardened around an assumption.
This is not an argument against technical builders. Good engineers are doing exactly what good engineers should do. If I hire an extraordinary plumber, I do not expect the plumber to decide what kind of house I want to live in. The mistake is hiring the plumber and assuming the blueprint is included.
A foundation model brings an extraordinary amount of general intelligence into an environment. That does not mean it arrives carrying the specific intelligence required to become your system. This is also why a technical symptom can send an organization toward the wrong intervention. If an agent is expensive to run, perhaps you genuinely need technical optimization. But perhaps the system is consuming unnecessary context because nobody decided what context belongs there. Perhaps humans are repeatedly compensating for missing instructions. Perhaps several agents are reproducing work that should have been resolved upstream. Perhaps the model keeps taking the scenic route because the system has never been given a sufficiently clear map.
You can spend a great deal of money making a confused system faster. Sometimes the cheapest token is the one you never needed to send because the thinking had already been done.
The same problem appears at very different scales
This is not only an enterprise problem. A writer can arrive through exactly the same door. “I need AI to sound like me.” Maybe. But perhaps the real issue is that the writer has reduced twenty years of judgment, rhythm, taste, subject matter, aversions, references and lived experience to a prompt containing six adjectives. Feeding the model more adjectives is unlikely to recover what was never made available to it.
A founder might say, “I need an agent.” What they actually need may be continuity between the systems they already use. A consultant might think they need better memory when the real problem is that they have never decided which information deserves to become durable context. A creative business may want automation when its process is still changing every week. An organization may ask for an AI policy when nobody has mapped how employees are already using AI to make decisions. The scale changes. The diagnostic principle does not.
This is part of what changed in my own work during 2025. Authentic AI Marketing had been the natural commercial home for me because marketing had been my professional language for two decades. But the deeper I went into working with AI, the clearer it became that I could not keep forcing every problem through a marketing frame. The work had expanded into questions of memory, identity, decision architecture, human judgment, system behavior and the structure surrounding the models themselves. Eventually I bought HumanAISystems.com because I needed a separate place to think and build at that level. Authentic AI Marketing did not become wrong. It became clearer once I stopped asking it to contain everything.
That same act of separation is often what a client needs first. What belongs to strategy? What belongs to the human? What belongs to the model? What belongs to software? What belongs to memory? What belongs to workflow? What belongs to training? What belongs nowhere because it should not be built at all? Once those distinctions become visible, the solution space gets considerably less magical and considerably more useful.
Before the build, answer three questions
Before approving a build, I want three things to be clear:
- What does this system need to know that a generic model does not?
- Where is that intelligence currently living?
- Who is responsible for making it usable by the system?
Those questions are simple enough to take into a vendor meeting tomorrow, but they are not small questions. If the answer to the first is vague, you may be buying infrastructure before you have defined the intelligence it needs to carry. If the answer to the second is “our website,” look harder. If nobody owns the third, that work does not disappear because the proposal says the intelligence is included. It waits for you on the other side of the contract.
Diagnosis is not the free part before the real work
There is a commercial habit I dislike in consulting: diagnosis is often treated as the appetizer. A short discovery call, a questionnaire, a few polite questions, and then everyone rushes toward the thing that can be scoped, priced and delivered. With AI, I think that logic is backwards. The diagnosis may be the highest-leverage intervention.
If somebody comes to me expecting to spend tens of thousands on a system and leaves knowing that the proposed technical build is appropriate, that is useful. If they leave knowing they need a different specialist, that is useful. If they discover that their problem can be solved with training, a change in process or clearer decision rights, that is useful. If they find out that the smartest move is not to build anything yet, that may be the most economically valuable answer in the room. The diagnosis did not fail because nothing was built. The diagnosis prevented the wrong thing from becoming expensive.
That is the logic behind my Human-AI Orientation. It is not a disguised sales call and it does not begin with the assumption that your organization needs more AI. We look at what you are actually doing, where the thinking currently lives, which parts are working, where context or judgment disappears, what the humans are carrying, what the technology is carrying and which layer is creating the friction. Then we determine what kind of problem you actually have.
Sometimes the answer is architecture. Sometimes it is automation. Sometimes it is training. Sometimes you need an engineer. Sometimes you need to change the way the humans are working before another system gets anywhere near them. And sometimes the answer is: not yet.
There is an enormous amount of AI capability available now. That is no longer the scarce part. The harder question is knowing which capability belongs where, what intelligence it should carry and whether the thing you are about to solve is actually the thing that is broken.
So before you hire somebody to fix your AI problem, it is worth doing one piece of work first.
Figure out what the problem actually is.
HUMAN-AI ORIENTATION
Not sure what actually needs fixing?
You do not need to know what should be built before you arrive. Bring what you are seeing. We map the problem, identify the layer creating the friction, and determine the next intervention.
€950 · 2.5 hours · nothing is sold in the room
FIELD CONNECTION • hUMAN-ai sYSTEMS
Go deeper only when the thought needs another room.
Authentic AI Marketing opens the commercial door. Human-AI Systems holds the deeper architecture, artifacts, and system thinking behind the work.
DEEPER SYSTEMS. RICHER CONTEXT.
Watch / Listen
Read / LLM Ingestion
Who Owns the Thinking?