Everyone Talks About AI Agents. Almost No One Knows How to Create High Performance Ones
Agent Born · Episode 01
Most AI agent projects fail before they even begin. The problem usually starts long before build or deployment, at the conception stage.
Here’s what nobody tells you about why that happens, and what actually changes it.
The Hype Problem
AI agents are everywhere: in roadmaps, in demos, and in executive conversations. They promise autonomy, acceleration, and transformation. Yet behind the enthusiasm lies a recurring gap that most organisations never see coming.
Many people can talk confidently about building agents. Very few can clearly explain how those agents actually come into existence, or what defines them before they are built. The real challenge is not whether they are deployed, configured, or demonstrated. It is whether they are properly conceived in the first place. That lack of clarity is rarely visible at the outset, but it is where most initiatives stall and ultimately fail.
The Fundamental Mistake
You have probably already heard this Gartner statistic: up to 80% of AI initiatives fail to deliver value. While the reasons vary, one pattern appears consistently: organisations often begin with a solution before fully understanding the problem they are trying to solve.
“We should build an agent to find information faster.”
“Let’s create an AI assistant for our teams.”
It sounds innovative. It feels like progress. But starting with the agent rather than the problem leads to the same outcome every time: a vague scope, unclear value, unrealistic expectations, and solutions that are fragile from day one.
I have seen ideas for agents emerge around automating error detection in supply chain processes, only to discover that the detection itself was already possible using existing tools. The real problems were unclear ownership, limited trust in the outputs, and no agreed response once errors had been detected. An agent would not have solved those issues. It would simply have added complexity on top of unresolved fundamentals.
An agent conceived in this way has no real foundation. Without a clear design framework, it becomes a concept searching for a purpose.
What an AI Agent Really Is
An AI agent goes beyond a chatbot, a prompt, or a clever automation. At its core, it is a system designed to make decisions, and decisions require strong foundations.
An AI agent understands context, evaluates options, takes action towards a goal, and operates with a degree of autonomy. This means its success is determined long before any technology is chosen.
Before anything is built, an agent’s DNA must be clearly defined across five dimensions:
- Problem – What specific friction or inefficiency does it address?
- Decisions – What decisions does it support or make autonomously?
- Data – What information does it rely on, and is that data accurate, relevant, and trusted?
- Actions – What is it allowed to do, and where does human oversight remain essential?
- Success – What does good actually look like in practice?
Without clear answers to these questions, the result is often additional complexity rather than a meaningful agent, much like adding more people to an underperforming team without addressing the root cause.
The Missing Step: Envisioning Before Engineering
Most organisations skip the stage where this DNA should be defined. They jump straight from “we should build an agent” to “let’s implement it”. But between those two steps lies the phase that determines whether the agent will ever succeed.
Envisioning.
This is more than brainstorming or early solution design; it is a series of structured conversations with leadership teams and end users before technical teams even enter the room. This is where difficult but essential questions emerge early: where does autonomy actually create value in day-to-day work? Which decisions are genuinely complex or inconsistent? What data would the agent rely on, and does that data actually exist?
In several situations I have worked on, agent concepts only began to unravel when this final question was asked. Sometimes the data was not being captured. Sometimes it was not accessible. Sometimes it was simply not reliable enough to support autonomous decision-making. Without envisioning, these realities would have surfaced much later, after investment, expectations, and momentum had already built up.
This is where an agent’s DNA is formed or exposed.
What This Looks Like in Practice
A client once wanted to build an agent to help employees find information more quickly. On paper, it made complete sense. However, during envisioning discussions with business teams, a very different reality emerged. Employees did not have access to the same information. Data was fragmented across multiple systems, and some teams were not even using the official sources. The issue was not speed; it was inconsistency at the core. An agent would not have solved that problem. It would have inherited it and amplified it.
In another situation, an organisation asked for a chatbot to retrieve documents from a specific database. Technically, the database existed. Operationally, it was not being used. Documents were stored across parallel systems and informal shared drives. The problem was not retrieval. It was the absence of a shared, trusted source of truth.
Across organisations, the same patterns appear again and again: optimising access to systems that people do not actually use, proposing agents where automation already exists, and expecting autonomy where data is missing or unreliable. These issues rarely stem from the technology itself. More often, the foundations were never properly defined.
How We Actually Create Agents at Hitachi
Most organisations begin with the technology. At Hitachi, we prefer to start with the operational challenges and decision points that people encounter every day.
At Hitachi, agents are not built from scratch. They are designed before they are born. We observe where work slows down, where information breaks down, where decisions rely on tribal knowledge, and where people act as human connectors between systems. If there is no meaningful friction, there is no reason for an agent to exist.
From there, we turn problems into decision opportunities. Where are decisions delayed or inconsistent? Where does context matter more than rules? Where are people compensating for system gaps? Because decisions, not tasks, define an agent’s role.
Then, before any discussion of models or tools takes place, we define the agent’s DNA across all five dimensions: what it is accountable for, where it can act independently, where humans remain in control, and what success actually looks like. This is where the agent takes shape — structurally, not technically. And this is what makes the difference between an agent that succeeds and one that stalls.
The Real Takeaway
Everyone is talking about AI agents, yet the decisions that determine their success are usually made long before a developer writes a single line of code. If you cannot clearly explain the problem your agent solves, the decisions it owns, and why autonomy makes sense, then the issue is not the technology. It is the starting point.
Most agents do not fail at build time. They fail at birth.
Now that we know why most agents fail before they exist, the next question is: how do you actually build one that performs? In Episode 02, Dr. Oliver Höllriegl from our Germany team shares what he has learned from building AI agents in the field. His starting point might surprise you: technology is the easy part.
Episode 02 – How to design and build a performant AI agent: coming next week.
