Diagnosis Before Build
Do You Need an AI Strategist, an Automation Builder, or Neither?
Choosing the provider before naming the problem can harden the wrong solution. Start with the problem, then route the work.
Natalie de Groot & NatGPT · September 2026
IN THIS PIECE
INTRODUCTION
Different specialists are solving different kinds of problems
Sometimes you need both. The order is the important part.
Visibility is not the same thing as depth across every layer
Good automation is brilliant when automation is actually the answer
Sometimes the answer is neither
Start with the problem, then route the work
INTRODUCTION
One of the stranger things about buying AI help right now is that the market asks people to choose between categories they often have no reason to understand yet. AI strategist. Automation consultant. AI architect. Agent builder. Prompt engineer. Transformation consultant. RAG specialist. Trainer. Developer. Systems integrator. The titles multiply faster than most buyers can reasonably learn what sits underneath them, and because the field is still young, two people using the same title may be doing completely different work.
I do not think buyers should be embarrassed by that. If your business has a problem with tax, you are not expected to become an accountant before deciding whom to call. If something is wrong with your plumbing, you do not first need to become fluent in pipe fittings. Expertise is useful precisely because somebody else has already spent the time discovering the distinctions, the failure points, the expensive mistakes and the questions you would not know to ask yet. AI should not be different.
The difficulty is that the market currently encourages buyers to begin with the provider label. You decide you need an automation agency because automation sounds like the solution. You look for an AI strategist because your problem feels strategic. Someone shows you what an agent can do, so suddenly the project becomes an agent project. A vendor demonstrates a particular platform beautifully, and now the problem is being interpreted through the capabilities of that platform. That sequence is backwards.
The first question is not who should I hire. It is what kind of problem am I actually trying to solve?
Once that is clear enough, the provider decision gets much easier.
Different specialists are solving different kinds of problems
An automation builder is usually most useful when the underlying process is already understood. The inputs are reasonably stable, the rules are clear enough, the desired output can be described, and the main problem is that humans are spending time repeatedly moving information or performing work that could be handled by software. In that situation, connecting systems, building triggers, creating retrieval, wiring APIs or automating a sequence can create enormous value. That is real expertise.
An AI strategist is useful earlier when the organization still needs to determine where AI belongs, what should change, what should remain human, which problems are actually worth solving, how the technology affects decision-making, and how different interventions relate to one another. The work may involve workflows, data, memory, people, ownership, operating behavior, architecture or business strategy, but the central job is not necessarily to build something. It is to create enough clarity that the organization knows what should be built, changed, stopped or left alone.
A trainer solves a different problem again. Sometimes the technology is perfectly adequate and the gap is human capability. People do not understand how to use the systems they already have, teams are developing wildly different practices, managers do not know how to supervise AI-assisted work, or employees do not know what good judgment looks like when a model enters the process. A technical build will not solve a skills problem.
Then there are situations that genuinely require software engineering, technical infrastructure, custom retrieval, security work, deeper data engineering or a specialist who understands a particular platform. In those cases, the problem may already be well defined and the organization needs somebody who can make the technical object real.
None of these categories is inherently better than another. They are useful at different moments. And sometimes the right answer is more than one of them.
Sometimes you need both. The order is the important part.
I have seen businesses arrive already committed to a particular tool because the tool was the thing they knew. “We want to use ChatGPT” can sound like a requirement, but ChatGPT is a product, not a business outcome. When you begin asking what they actually need the system to do, the answer may turn out to be reliable retrieval across a defined body of knowledge, a structured knowledge environment, a workflow between existing systems or something that could be housed much more efficiently somewhere else. The buyer was not wrong to mention the product. That was simply the language available to them. The danger comes when the product becomes architecture before the problem has been examined.
I have had clients arrive with technical plans already taking shape and, after looking at the data and the desired outcome, my concern was not that the developers were incapable of building what had been requested. The concern was that the organization was not yet ready for the object it had asked them to build. The information was not understood well enough. The operating behavior had not been decided. The intelligence the system would eventually depend on had not been made usable. A technically excellent team can faithfully construct the wrong answer if the question it receives is premature.
That is why sequencing matters. You may need a strategist and an automation builder. But if the strategist’s job is to determine what should be automated, hiring the automation builder first can lock a still-unclear problem into technical decisions. Once the company has spent money, connected systems, migrated information, trained employees and organized work around a tool, changing direction becomes harder. The decision gains gravity because the investment has already happened.
Choosing a provider too early can harden the wrong problem.
That is one of the most expensive forms of AI confusion because the system can work exactly as specified and still fail to produce the result the business actually wanted.
Visibility is not the same thing as depth across every layer
There is another complication for buyers right now: public authority in AI does not necessarily tell you which layer of the work someone understands deeply.
I have been approached by people with substantial AI audiences who wanted to white-label parts of the work I do because their expertise sat somewhere else. Some were very strong in prompting, demonstrations, automation, sales or a specific technical layer and needed support with the systems thinking underneath it. I do not think that automatically makes anyone fraudulent. It makes the category “AI expert” almost useless unless we ask the next question: expert at what?
A person can be extraordinary at automation and not be the person I would ask to design organizational memory. Someone can understand model behavior deeply and have no interest in building technical infrastructure. A brilliant developer may be able to construct almost anything you specify while reasonably expecting you to know what you want constructed. A strategist may be excellent at diagnosis and terrible at implementation. Someone may be a superb educator without being the person you should hire to redesign the operating system of a company.
Follower counts do not solve that distinction. Neither do titles. The responsibility is not to discover who is the “real AI expert.” I am not sure that category is useful anymore. The better question is whether the provider’s actual depth matches the layer where your problem lives.
That is also why I become uncomfortable when any provider treats their specialty as the inevitable answer. If you sell automation, every problem can begin looking like something that should be automated. If you build agents, agents start appearing everywhere. If you sell training, capability gaps become the diagnosis. If you sell custom software, custom infrastructure can begin to look necessary long before simpler options have been ruled out. That does not require bad intent. It is ordinary professional bias. We tend to see problems through the instruments we know how to use.
A good diagnosis should be able to survive the possibility that the person diagnosing you is not the person you eventually need to hire.
Good automation is brilliant when automation is actually the answer
I have experienced both ends of this personally.
Like most people with a visible professional profile, I receive automated outreach. Much of it is obvious. The message claims to be personal while reading like thousands of nearly identical messages sent at scale. The sender tells me they studied my work when the message itself demonstrates that they did not. If challenged, the defense is sometimes simply that outreach is a numbers game. And yes, sales has always contained numbers. But scale is not the same thing as relevance.
I once experienced an automated outreach sequence that was so well designed that I became fascinated by it. I did not respond to the first contact, but the system clearly registered my behavior and continued across several touchpoints. It approached me through different surfaces, adapted without becoming invasive, and eventually became interesting enough that I replied partly because I wanted to know how the system worked.
That is what good automation can do. The underlying goal was clear. The behavior was observable. The sequence was deliberate. The triggers made sense. The system knew enough about my responses to alter what happened next without pretending to possess intimacy it had not earned. Eventually the human behind the system entered the conversation, and we ended up discussing the mechanics because I was genuinely impressed.
I would absolutely hire an automation specialist for that kind of problem.
If a company already knows its sales process, understands the audience, has established acceptable behavior, knows what should trigger the next action and wants to execute that process at greater scale, automation may be exactly the right intervention. But compare that with a company asking, “How should AI change the way our sales organization works?” Those are not the same assignment.
One is asking someone to execute a defined operating model. The other is asking someone to help define the operating model. The difference matters.
Sometimes the answer is neither
This may be the least commercially exciting answer in the AI market, but sometimes a company does not need an AI provider at all.
The process may not be stable enough to automate. The data may need cleaning or organizing first. The actual problem may be a management decision that leadership has avoided making. The team may need to stop experimenting and consolidate what already works. A business may discover that ordinary software solves the problem perfectly well without a generative model anywhere near it.
There are also situations where the answer is simply: do not build this yet. That is not failure. It is often the cheapest useful conclusion available.
The purpose of expertise should not be to manufacture a reason for expertise to remain in the room. Sometimes the most valuable thing somebody can tell you is that the problem belongs to another specialist. Sometimes they should tell you that you already have what you need. Sometimes they should send you to an automation engineer, a data person, a trainer, a developer or someone whose expertise is much narrower and more appropriate than theirs.
That is what I want a Human-AI Orientation to be able to do.
Start with the problem, then route the work
An Orientation is not designed around proving that every business needs a Human-AI system. It is a routing layer.
We look at what the business is trying to make happen, what it already has, where the data lives, what people are doing now, what keeps breaking, what decisions have already been made, what has not been decided yet and what kind of intelligence the future system would actually need to carry. The questions are part of the work because people are often too close to their own operating environment to see which layer is creating the friction.
That is one of the reasons I think of orientation differently from an ordinary discovery call. A discovery call usually begins with a provider whose category has already been chosen. The conversation is therefore partly about whether the buyer fits that provider. Orientation works in the opposite direction. The problem gets examined before the route is chosen.
The useful outcome might be strategy, architecture, automation, training, a technical build, another specialist or no build at all. It may also be a sequence: first clarify this, then stabilize that, then bring in the technical team once there is something sufficiently coherent to build against.
You do not need to know the mechanics before you walk into that conversation. That is what expertise is supposed to save you from having to know. You need to be able to describe what is happening, what you are trying to change and where the current situation stops making sense.
From there, somebody with enough range should be able to help separate the problem into parts and show you which category of work belongs where.
Do not choose the provider and then make your problem fit their service. Understand the problem well enough to choose the help that fits it.
And if the right answer is somebody else? Good. That means the diagnosis worked.
HUMAN-AI ORIENTATION
Not sure which kind of AI help you actually need?
Bring the problem, the tools, the proposals, and the work as it exists now. We separate the layers, identify the right sequence, and route the next move to strategy, automation, training, technical build, another specialist, or no build yet.
€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