The Ostrich Problem industry problems no one talks about in AI transformation.
When in 2022 Vstorm evolved from pure Data & AI engineering towards Agentic AI transformation using LLMs, we did not know we were creating a new professional services segment.
The biggest difficulty about our business model is that you have to connect two different worlds: business strategy and technical execution. Simple to say. Very hard to do well. And in trying to connect them, you start seeing how broken the existing models really are.
The main narrative on the market is that “80%… 90%… or even 100% of AI initiatives fail.” I won’t speak about it, I promise. I will leave it to the Big 4 and other tech creators.
Instead, I want to talk about something nobody seems willing to say out loud. Based on literally hundreds of meetings with mid-market and enterprise companies, I have a few conclusions about the biggest problems in our niche. I did not do a deep research study, but it seems that no one speaks about these problems in a frank way, and not many companies address them directly. I call this the ostrich approach: companies are burying their heads in the sand, pretending the problems do not exist.
And I get it. These are uncomfortable things to say publicly. Many of us, myself included, work inside this industry. Some of these problems touch our own businesses. But we cannot keep avoiding the conversation.
I segmented the industry problems into three areas: consulting, software development outsourcing, and Agentic AI transformation. Each has its own set of issues, but I want to articulate only the most important ones. I am not going to focus on problems that are too small. The problems I’ve discovered are global and impact all companies working in this field.
They are also cumulative. The problems of consulting become the foundation for the problems of outsourcing, and together they create the conditions for everything that goes wrong in Agentic AI transformation today.
Consulting industry problems
Implementation is disconnected from strategy
Let me start with a story.
In 2025, I was visiting one of our clients in Saudi Arabia, where we were delivering an Agentic AI solution with WeDo Solutions, our Riyadh technology partner. We spent an hour and a half listening to a person with no practical implementation experience explain how we should implement the entire architecture. Guess how many slides the presentation had, and how many people were engaged on behalf of the consultancy? Over 100 slides in a lovely PowerPoint and five people in the room. The multi-agent architecture was presented as a must-have from day one, not because the problem required it, but because it was trendy at the time.
I sat there thinking: these are smart people, the presentation is polished, the logic on the slides makes sense. And yet none of it will survive contact with reality.
That is the core problem. Traditional consulting engagements often end with strategies, roadmaps, recommendations, and presentations instead of implemented business outcomes. The people defining the strategy are rarely the ones responsible for execution. As work moves from strategy to implementation, business intent is gradually diluted, and the final solution often differs significantly from the original vision.
I am not against consulting firms. But people without hands-on experience in the field cannot tell an engineering team how to implement a solution based on a process map designed in a slide deck. A beautiful presentation and a working system are two very different things.
Misaligned economic incentives
Traditional consulting firms are typically rewarded for selling more hours, larger teams, and longer engagements. The commercial model naturally favors larger and more complex projects, while clients benefit from solving problems as quickly, efficiently, and permanently as possible.
These two goals are in direct tension. And nobody talks about it.
I have a wide network of people working in large outsourcing companies and consultancies. We know them all. One of their recurring issues these days is the obsession with “utilization rate,” how much of a consultant’s time is billed to a client project. The higher the rate, the better the business looks. To compare with our model: we don’t focus our attention on utilization rate and don’t build our business model around it. This has its own pros and cons. I won’t pretend our approach is without trade-offs. But the main logical point is simple: our goal is not to sell time and effort. It is to focus on business results and transformational effect.
The difference sounds small. In practice, it changes everything about how you staff a project, how long you stay, and when you leave.
These two problems, strategy without implementation and incentives that reward effort over outcomes, have existed in consulting for decades. They were tolerable when the deliverable was a strategy document. They become dangerous when the deliverable is supposed to be a working system.
Engineering industry problems
Cost became the primary selection criterion
As offshoring expanded, outsourcing decisions were increasingly driven by hourly rates and labor-cost reduction rather than quality, business understanding, or long-term value. Providers started competing primarily on price. The result: weaker senior oversight, inconsistent delivery quality, and higher hidden costs from rework, communication overhead, and slower execution.
In conversations with prospects, I usually ask transparently about their budget expectations and initiate the conversation upfront to understand their mindset. Luckily, I rarely hear that price is the most important factor. For Agentic AI this is becoming less problematic, because the value is pretty clear once you deliver a well-designed Agentic workflow solution aligned with the business needs.
But from time to time, I do hear from prospects that they are looking for price-first companies. And that is fair and respectful, not every company needs what we offer. In most of these cases, though, it is not a way to cooperate with Vstorm. Not because we demand high prices, but because these companies are optimizing for the lowest hourly rate for a generic developer.
The problem with that approach is simple. Most offshore companies sell code. They sell hours. They sell a commodity. And when you buy a commodity, you compare on price. That makes sense for commodities.
But Agentic AI transformation is not a commodity. It is like building a house. You can spend all your time looking for the cheapest company to deliver bricks to your plot. You can negotiate every brick down to the last cent. But you are not thinking about the foundation. You are not thinking about the design. You are not thinking about how this house is going to change the way you live. You are focused on bricks, and nobody is focused on the house.
That is what happens when prospects bring pure pricing sensitivity into a field where the value comes from results, not from lines of code.
Requirements are disconnected from business context
Clients define requirements and pass them to an outsourcing team expected to deliver with limited understanding of the underlying business problem. This separation creates slow feedback loops, repeated misunderstandings, and technically correct solutions that fail to produce the intended business outcome.
I can’t count how many times we start a conversation from a Scope of Work, Statement of Work, strategy, vision, or some other document that precisely articulates the requirements on the client’s side. The document is always well-structured. It looks professional. Sometimes it is 20 pages long.
And then, after conversation with me or our transformation managers from Vstorm, at the end of the conversation, they say: “Treat this as a starting point, and please advise if we need to change anything. We don’t know what we don’t know.”
That single sentence tells you everything.
They don’t know what they don’t know. And it is impossible to gather complete requirements upfront in a field that is evolving this fast. Unfortunately, in roughly half of these cases, the document is a purely AI-prompted output. And honestly, useless. You can tell. The structure is too perfect, the language too smooth, and the substance is missing.
To advocate for the other side of the coin, sometimes these documents are very helpful, especially when they are prepared in cooperation with a business and technical person. In those cases, they serve the first stage of the conversation well and help both sides align on strategy and vision. I don’t want to dismiss the effort. But the structural problem remains: outsourcing models are built around executing predefined requirements, not around understanding the business problem first.
These engineering problems, cost over quality and requirements over context, sit on top of consulting’s existing gaps. Together, they form the foundation that AI transformation gets built on.
And the foundation is already cracking.
Agentic AI industry problems
The consulting gaps and the outsourcing gaps do not disappear when you move into Agentic AI. They carry forward. But this segment also has problems that are entirely its own. And honestly, these are the ones that keep me up at night, because this is the field I work in every day.
Agentic AI engineering is treated like traditional software development
Many companies approach Agentic AI projects as conventional software builds, using the same methods, teams, and quality standards. But agentic systems behave less predictably and require specialized evaluation, context management, guardrails, monitoring, and continuous improvement. This misunderstanding produces applications that work in demonstrations but fall apart in real business operations.
Remember the Saudi Arabia story? The multi-agent architecture that was a must-have because it was trendy? That is this problem in action. Someone treated a fundamentally new kind of engineering challenge as a traditional system design exercise. It looked great on the slides. It would not survive production.
The demo works. The production system does not. And the distance between those two is where most AI projects go to die.
We believe that this is exactly the reason behind most failed initiatives. And to make it concrete, let me walk through the questions I hear most often.
- Why do leaders put pressure on the team to implement, and it still fails? Because the leadership team does not understand how Agentic AI technologies and transformations actually work. They set expectations based on what they know from traditional IT projects, and those expectations do not apply here.
- Why do PoCs look great, but once deployed to production they do not work? Because the team working on the agentic workflow does not realize the difference between software development and AI engineering. Perhaps it worked well back in the day when we delivered a PoC mobile or web application and the only things we dealt with in production were small bug fixes on the front end and straightforward back-end logic. But with Agentic AI it is different. Production is where the real work begins.
- Why did our data or software development team fail the initiative? Because data engineering and software development are different disciplines from Agentic AI engineering. Yes, they are part of the Agentic AI world, but there is a missing component: the Agentic AI engineering capability itself. Again, it is a different discipline.
- Why can’t we rely on the agentic workflow, and why is there a trust deficit? Because the system was designed badly and does not provide the necessary accuracy. And why does it not provide the necessary accuracy? Because software developers need to learn how to work with LLMs and then iteratively build and refine the system. Trust deficit also appears when leaders, under pressure from their own leadership, rush to deploy something to show the C-level that the investment was worth it. Speed replaces quality, and the result is a system that nobody trusts.
And what is behind all of this? Inertia. The most dangerous force in strategy. Inertia can hold you from learning and approaching new things. It can hold you from changing anything in the company, and in your life. It can cause the gap between a strategic plan and its execution. The plan usually looks smart. But execution is the crucial element of success, and inertia is what kills it.
All of humanity tends to think in an inertial way, but being open to a new discipline requires humility and an open mindset.
Everyone claims to do AI
The rapid growth of the market has led consultancies, software companies, and outsourcing providers to reposition themselves as AI experts, often without substantial production experience. For those who claim they do AI, it seems easy, because they treat it as the next vanilla software development discipline (see the first industry problem in this section). Clients struggle to distinguish genuine expertise from marketing claims, prototypes, and repackaged traditional services.
I understand why it happens. AI is the biggest market opportunity in a generation. Of course everyone wants in. But the gap between “we have an AI offering” and “we have deployed agentic systems in production that actually work” is enormous. And the client is the one who pays for that gap.
We have seen the cost of that gap up close. Multiple times now, clients have come to us after a failed AI transformation with another provider. The pattern is almost always the same: the company was already working with a software development shop on other projects. When AI came onto the agenda, they did not want to go outside that relationship. They did not look for a specialized company. They just asked their existing dev shop to add one more developer to take care of the AI side.
It does not work. I have seen this enough times to say it without hedging: it always fails. The reason is that Agentic AI engineering and traditional software development are different disciplines. A good backend developer is not automatically a good AI engineer, the same way a good electrician is not automatically a good architect. But because clients often do not understand that difference, they treat it as one more software task. And by the time they realize the mistake, they have lost months.
In 2025 alone, three of our new clients came from exactly this situation. One of them wrote to Bartosz, our Chief Transformation Officer:
— a client, in an email to Bartosz, 2025“Thank you, Bartosz! Starting fresh with you from the ground up was absolutely the right call. In just a few weeks, you accomplished what another provider couldn’t manage in an entire year…”
The point is that the previous provider was never equipped for this kind of work in the first place. They were a software company asked to do something that requires a completely different set of capabilities.
Change management has become harder
AI does not simply introduce another technology. It changes workflows, responsibilities, decision-making, and sometimes the purpose of entire roles. Organizations must redesign how work is performed while addressing uncertainty, resistance, governance, and employee adoption.
Because Agentic AI transformation is a relatively new field, most organizations do not treat it as a transformation at all. They treat it as another technology to implement. Install the platform, configure the agents, connect the data, done. But AI does not simply add another tool. It changes workflows, responsibilities, decision-making, and sometimes the purpose of entire roles.
The technology part is becoming commoditized. We know how to build the systems. But telling someone that the way they have worked for 15 years is about to change in ways they cannot yet picture? That their role might look completely different in six months? That requires a very different conversation than configuring a platform.
Don’t get me wrong. Implementing the technology in a reliable way is still a tough challenge. You are working with non-deterministic systems. Think about that for a second: 10 times you ask an LLM the same question, you get 10 slightly different answers, and it never flags that something is wrong. Building something production-grade on top of that behavior takes real engineering discipline.
But the hard second half, the one that most projects underestimate, is getting the organization to actually absorb the change. And most companies simply do not have the internal capability to do that. Organizational change at this level is a tectonic effort. It takes time, dedicated people, and a way of working that most organizations have never had to build before.
What makes it worse is that companies often get the basics wrong from the very beginning. They don’t build a transformative coalition, the group of people across the organization who will carry the change forward. They don’t communicate the transformation in a way that the whole organization understands and believes in. They build a vision that serves the CEO and shareholders but not the people who actually need to change how they work every day. And they don’t create any sense of urgency, which is usually the only force strong enough to move an organization out of its comfort zone.
The system works. The organization does not change. And the project is quietly labeled a failure.
Misaligned incentives: lock-in vs. sovereignty
Tech companies want to lock you in. That is not an accusation, it is a business model. The longer a client stays dependent, the more predictable the revenue. Dependency can be reinforced by proprietary platforms, custom frameworks, undocumented architecture, vendor-controlled cloud environments, and systems that are difficult for another team to maintain. The commercial model naturally favors deeper dependency and increasing switching costs. Clients benefit from the opposite: owning their infrastructure, their data, their decisions, and their ability to change providers without rebuilding from scratch.
The world is moving in the opposite direction. Across all areas, including technology, the need for sovereignty is rising. Organizations want to own their infrastructure, their data, their decisions, and their ability to change providers without rebuilding everything from scratch. The incentive of the client is to stay independent. The incentive of the vendor is to make that independence as expensive and painful as possible.
This creates a slow-motion trap. Over time, changing providers or bringing the capability in-house becomes increasingly expensive, risky, and operationally disruptive. The client’s flexibility and negotiating power quietly erode. And by the time they notice, they are already locked in.
This is especially critical for companies that use Agentic AI to extend or evolve their business model. For them, the AI system is not a back-office tool. It is part of how they create value. They need to fully control their IP: the techniques, data, prompts, architecture, guardrails, security layers, infrastructure, all of it. Without that control, they end up paying what I call a “lock-in tax,” a growing cost that becomes especially painful once the system is live and scaling.
We have experienced this from multiple angles. Lock-in comes in layers, and each one traps you differently.
- Price. You build on a platform, you launch your first workflows, everything looks good. Then after the 20th workflow, they significantly raise the price. You are already in production, your business depends on it, and your negotiating power is gone. (That’s the real case, one of our existing clients experienced this.)
- Intellectual property. Whatever you built stays with the platform. In practice, you do not own the IP that is critical for your business. It is similar to a European wanting to build a house in Thailand or Vietnam. You can lease the land for 30 years, but you do not know what comes after that. The better the house you build, the more you stand to lose. And there is a second side of the coin: what if the owner of the platform where you built your system decides to use your know-how and build a competing product? Coming back to the Thailand example: you build a house, the government decides you can no longer lease, and you have to leave. Then you realize someone else is going to live in your house without any of the building effort.
- Limits. All closed-source platforms have their limits. Quite a few of our clients built something with low-code or no-code platforms and then realized they needed to move away because of limitations. Others started tinkering with a platform during the evaluation phase and realized it would not be sustainable to build their entire agentic system on it. It is always a trade-off, but the problem is that most companies discover the limits after they have already committed.
- Capability. The deepest layer of dependency is fully relying on another company to build and maintain your agentic system, with no plan or willingness to build that capability internally. If you look at the Business Model Canvas, specifically the “Key Activities” and “Key Resources” sections, we believe that within the next 3-5 years every business will need to onboard this capability: building, and at the very least maintaining, the Agentic AI operating system that runs their operations. It will become a standard part of any business model. Companies that treat this capability as something to permanently outsource are building their future on someone else’s land.
I feel strongly about this one. It is one of the reasons we built our entire approach around the principle that the client should be able to walk away from us at any point and still own everything we built together. Not every company in this space operates the same way. And the client usually does not realize the difference until it is too late.
Strategy and engineering are fragmented across the market
Agentic AI transformation requires both business strategy and technical execution, but these capabilities are often provided by different companies. Strategy consultants define what should be done, software or AI firms are responsible for building it. This creates handoffs, coordination problems, and unclear accountability for the final business outcome.
This problem exists because the Agentic AI transformation market is still in its early majority phase. There is no clear leader in the field yet. No one can answer the basic questions: what are the standards of Agentic AI transformation? What are the standards of Agentic AI implementation? These standards are being shaped right now, but the picture is very fragmented and no one can see it whole.
Because of that, professional services companies rarely combine strategy and engineering under one roof. For a software development company, it is much easier to pivot to AI engineering than to add transformation consulting, or to combine both capabilities. There are a few practical reasons for this.
- The back-office processes are already established for writing code. A software dev shop can hire a good AI engineer with relatively little disruption. But designing a separate consulting practice requires rethinking operations from the ground up.
- The pivot to AI engineering does not require redesigning the business model. If we write code, we will still write code. We do not need to redesign how we work with clients or how we package our offering. Providing transformation consulting is a completely different discipline than writing code.
- And even if a company did redesign the offering and hired a few strong transformation consultants, they would still have to deal with marrying engineers with consultants. Because the consultants are fresh in this business model, they won’t carry enough weight in the conversations that matter. We passed through that stage ourselves, so I can say from experience: it takes time, and most companies are not willing to go through the pain.
You can see the same picture in reverse for consulting companies trying to add engineering.
The result is that the market has settled into three business models from the service perspective:
- Consulting without executing and without responsibility for the final outcome.
- Development without a strategic phase and without responsibility for the final outcome.
- Full ownership, taking responsibility for the final outcome end to end.
Most companies sit in model one or two. Very few attempt model three, because it requires capabilities, culture, and a business model that most professional services firms were never built to support.
By the way, this industry problem, the lack of shared standards, was one of the reasons Vstorm joined the Agentic AI Foundation (AAIF) a few days after it launched in December 2025. We felt that we are on a mission to co-build and contribute to the industry standards rather than wait for someone else to define them.
The gap
These nine problems, two inherited from consulting, two from outsourcing, five that belong to Agentic AI, are not independent failures. They are structural and they compound.
They all point to the same conclusion: the market needs a model that does not exist in any of the three traditional categories. Strategy that carries through to implementation. Implementation that understands the business. AI that includes change management. Technology delivery that does not lock the client into permanent dependency.
The industry can keep burying its head in the sand.
Or it can start building something different.
Want to talk through this?
30-minute call with Antoni. No pitch, no deck — just the conversation this essay opened.
BOOK A CALL