Companies deploying AI agents right now are going to fail and rebuild

The question everyone is asking

There is a conversation happening in boardrooms and portfolio reviews right now that is less about chasing the next shiny thing and more about a genuine strategic anxiety. The question is not necessarily how to get ahead of the curve, but rather how to not get left behind. Leaders are watching the technology move fast, seeing competitors make moves, and feeling real pressure to answer a question they are not yet sure how to frame: what does this mean for our business, and what do we do about it?

That anxiety is legitimate. The urgency is real. But the organizations that respond to it by moving fast without the right foundation are the ones that will spend the next several years rebuilding something they rushed to deploy.

This article is for leaders thinking about what agentic transformation actually requires inside their organizations, and for boards who want to understand what they are asking when they direct portfolio companies to move on AI.

What we mean when we say agentic transformation

AI transformation comes in more than one shape, and understanding the distinctions matters before any plan is built.

The first is workforce AI adoption. Getting an organization comfortable with tools like Copilot, Claude, or GPT as part of daily work. This can produce measurable individual productivity gains and, perhaps more importantly, it can be the cultural on-ramp for organizations that are resistant to change. People who start using AI tools in their daily work are probably more likely to trust and engage with more autonomous systems later. Risks also exist at this level. Without discipline and clear norms, widespread AI tool adoption can introduce what some are calling organizational slop, inconsistent outputs, unchecked AI-generated content, and a false sense of productivity that masks quality problems.

The second is agentic transformation, which is what this article is about. This means autonomous systems embedded in real workflows, doing real work, taking real actions without a human initiating each step. Agents that monitor, decide, execute, and report. Agents that handle the repetitive judgment work, the coordination overhead, and the keep-the-lights-on operations that currently consume an organization's most expensive resource, which is its people's time and attention.

Both transformations matter and neither replaces the other, but what follows is specifically about the latter.

Agentic transformation is genuinely possible, but also genuinely complex and often technical. It requires a foundation that most organizations have not yet built.

The four readiness questions

Before any serious agentic deployment, a leader needs honest answers to four questions. Each one is a prerequisite for the next.

1. Is your data accessible?

Agents are only as good as the information they can reach. This is nothing new for those familiar with process automation. For an agent to do meaningful work inside an organization, it needs access to relevant, company-specific data, whether that is customer records, transaction histories, operational logs, service notes, or documents. Unlike traditional process automation, that data does not need to be perfectly structured for an LLM to be effective, but there are limitations.

Modern agents can reason over emails, transcripts, and free text in ways that earlier automation could not, but it does need to be accessible, reasonably complete, and trustworthy. In most organizations, the honest answer is that data is more fragmented than anyone wants to admit. It lives in CRMs, ERPs, spreadsheets, email threads, shared drives, and legacy systems that were never designed to talk to each other.

The right question is not just how fragmented the data is, but what the agent needs to do with it. If the agent is primarily reading and synthesizing, summarizing customer sentiment, surfacing risks, generating a briefing, it can often work with messier data and still deliver meaningful value. If the agent needs to take action, updating a record, posting an invoice, triggering a workflow, the bar is significantly higher. Agents acting on unreliable, incomplete or conflicting data will make consequential errors, and those errors are harder to catch and more expensive to fix than errors made by humans doing the same work.

There is some low-hanging fruit organizations can grab with minimal data access. Simple automation, basic summarization, narrow task completion. But real agentic transformation, the kind that meaningfully changes how a business operates, requires agents that can reason across the business and act reliably on what they find. Getting there often requires investment, either in connecting existing systems or building new architecture, and that investment is a prerequisite, not an afterthought.

2. How mature are your processes?

Agents automate work. In practice, if the work is not well-defined, agents will automate the chaos. This is one of the most common failure modes in early AI deployments, and it is entirely preventable.

The question here is not whether an organization uses AI today. It is whether its workflows are mature enough to benefit from AI automation. An organization with disciplined, well-documented processes and some existing deterministic automation, or robotic process automation (RPA), is in a very different position than one that still runs primarily on human judgment, manual data entry, and tribal knowledge.

Neither starting point is disqualifying, but they require different sequencing. The most mature organizations can move directly to agentic workflows that enhance what is already working. Less mature ones need to build process discipline first, or risk amplifying their existing inconsistencies at scale.

The highest-ROI targets are usually the workflows that touch customers, drive revenue, or keep operations running. Customer service, sales operations, service delivery, financial close activities. These are also the workflows where failure is most visible, which is why process maturity matters so much before automating them.

There is an interesting parallel worth noting. The organizations that successfully offshored work over the past two decades had to do something most companies never bother with: they had to codify their processes well enough to hand them to someone with no tribal knowledge of the organization. Runbooks, SOPs, defined inputs, clear handoff points. That documentation discipline turns out to be a great starting point to what agents need to be effective. If an organization offshored successfully, it may have a head start on agentic transformation that it does not fully appreciate yet.

3. Are your people ready?

Technology deployments fail for technical reasons less often than they fail for human ones. The third readiness question is about the workforce, and it is the one most organizations underinvest in assessing.

It is important to note that when most people hear agentic transformation, they jump to job loss. That anxiety is understandable, but it incorrectly frames what the most valuable deployments actually accomplish. The major use cases for agents are often things the organization was never able to prioritize before: software upgrades that have been deferred for years, back-office processes that were constraining higher-value work, document processing that nobody had capacity to do at scale. The more accurate frame is growth. Agents extending what the organization can do, not simply reducing headcount. That does not make the change management effort smaller, but it does change it. People still need to understand how their work is changing, what they are responsible for, and where the agent ends and their judgment begins.

Even framed as a growth initiative, agentic transformation still represents meaningful change for the people inside it. How work gets done changes. How decisions get made changes. What used to require a person may not anymore, even if that person moves on to higher-value work. The change management effort needs to account for that reality honestly, not paper over it with optimistic framing.

There are practical workforce questions every organization needs to answer before deployment. What is the current sentiment toward AI? Has the company recently gone through layoffs? Is the industry and culture tech-adjacent or deeply traditional? And critically, how technically capable is the workforce of actually working alongside these systems?

That last question deserves more attention than it typically gets. The most powerful agentic deployments are still largely technical in nature. Interacting with agents through command line interfaces, terminals, and developer tooling is second nature to a software engineer and genuinely foreign to most business operators. That gap does not make deployment impossible, but it does define the size of the enablement effort and the timeline to value. An organization with a technically curious team that has been asking for better tools is a fundamentally different deployment context than one where the workforce has never opened a terminal.

4. Is the leadership team ready?

The first three questions are about organizational capability. This one is about leadership conviction.

Agentic transformation is not a short-cycle initiative, and it should not be treated as one. It is a response to a real strategic imperative: the organizations that figure this out will operate differently than the ones that do not, and the gap will compound over time. But being on the cutting edge of something genuinely new means being okay with getting humbled. The technology is moving faster than any deployment plan can anticipate. First attempts will be imperfect. Some will fail outright. Leaders and boards need to know that going in and be willing to stay in anyway.

That requires a different kind of conviction than most technology initiatives demand. It is not the conviction that comes from certainty. It is the conviction that comes from understanding why the direction is right even when the path is unclear.

So before the plan is built and the investment is committed, the leader and the board need to answer a harder question than whether the technology is ready. They need to answer whether they are.

Why is the organization doing this? If the honest answer is that the board asked about AI strategy and something needed to be said, that is not a foundation for transformation. If the answer is that there is a specific operational problem, a specific cost structure, a specific capability gap that agents can address, and the leadership is willing to resource it properly and protect it through the difficulty, that is a different conversation entirely.

The organizations that succeed with this are the ones where leadership understood what they were signing up for before they signed. Where the CEO was willing to stand behind the initiative when the change curve got steep, when a key employee pushed back, when the first deployment did not go as planned. Not because they were certain it would work, but because they understood why it was worth doing and were committed to seeing it through.

There is something worth saying to the leaders who are still hesitant. Even a deployment that does not go as planned produces something valuable. The organization learns how its data is actually structured, where its processes break down, and what its workforce is and is not ready for. That knowledge has real value for the next attempt, and there will be a next attempt. The technology is not going away. The organizations that engage with it now, even imperfectly, will be better positioned than the ones that waited for certainty that never comes.

An AI deployment without conviction is not a transformation. It is an experiment that will be quietly shelved when something more urgent comes along. The only thing worse than a failed deployment is not learning anything.

What a plan looks like

Once those four questions have honest answers, a plan worth building can take shape. Most organizations skip this step and move straight to tooling. That is where things start to break.

A real plan does not simply list what you want to automate. It starts with grounding in where the organization actually is today, and charts a sequenced path toward where it can realistically be. Some components of the plan address what is possible now. Others lay the groundwork for what becomes possible as the data gets cleaner, the processes mature, and the workforce builds confidence with the technology. The goal is not to plan for a perfect organization that does not yet exist. It is to meet the organization where it is and build toward where it is going.

Three components, and a clear build approach

The first is a prioritized workflow map. A ranked set of workflows tied to measurable outcomes: throughput, customer impact, new capabilities the organization could not support before, error reduction, and cost efficiency. The constraint is not ambition, it is execution. The right starting point reflects where the organization's current data access and process maturity can support reliable automation without introducing downstream risk.

It is also worth noting that enterprise-wide agentic transformation across all processes at once is not just inadvisable, it is not realistic. The complexity, the data work, the change management, and the build effort required across an entire organization simultaneously would be unmanageable for even the most prepared companies. The highest-value deployments start with specific, well-scoped workflows, prove them, and expand from there. An organization that successfully automates one critical workflow and learns from it is in a far better position than one that attempts to transform everything at once and stalls under the weight of it.

The second is a systems and data flow plan. This is where most early deployments fail. Agents do not operate in isolation. They depend on how data moves across systems, where it is stored, how it is updated, and what can be trusted. This plan makes that explicit. What needs to be connected, cleaned, or rebuilt. This is also where the real investment lives. When this work is treated as a follow-on step, it becomes the reason the deployment stalls.

The third is a people and change management plan. This is not a communications layer on top of a technology rollout. It is an operating requirement. Agents change how work gets done, how decisions are made, and how accountability shows up in the system. That shift needs to be designed and managed with the same rigor as the technology itself. Without it, even technically sound deployments stall at the point of adoption.

Finally, the plan needs a clear build approach. Whether that is custom development on top of APIs, a managed platform, a vertical solution, or some combination. Each path comes with tradeoffs in speed, control, cost, and long-term flexibility. Those tradeoffs should be explicit up front, not discovered after the organization is already dependent on a decision it did not fully evaluate.

A plan that does not address each of these elements is not a plan. It is a starting point for rework.

What boards specifically need to understand

For boards and PE operators directing portfolio companies to move on AI, a few things are worth internalizing before that conversation happens.

Depending on the answers to the four readiness questions, a meaningful agentic deployment takes longer than most leadership teams expect. The organizations that try to compress that timeline without building the foundation first are the ones that pay to learn lessons the hard way.

There is real investment before the ROI. Data infrastructure, process work, change management, and the build itself all require capital before the returns appear. That investment needs to be scoped, approved, and understood as a prerequisite.

The economics need to make sense at the unit level. AI agents have real operating costs. API usage is billed by token. Active sessions on managed platforms carry per-minute charges. Those costs are subject to change, and they have changed rapidly in this space. A deployment that pencils out today at current pricing may look different in twelve months. The ROI analysis needs to account for this, and the build approach needs to account for the risk of pricing changes. There is also a budget reality worth understanding. Most organizations operate with fixed annual OpEx budgets, which means AI token usage and compute costs need to be planned for, not discovered mid-year. Some organizations are already having internal discussions about how to allocate compute budget across competing priorities. That conversation should happen before the deployment plan is finalized, not after the first invoice arrives.

Platform decisions create lock-in. An organization that builds its agents on top of a single provider's managed platform gains real benefits in speed, reliability, and integration. It also becomes dependent on that provider's roadmap, pricing, and longevity. Model-agnostic platforms offer more flexibility but introduce their own complexity and vendor risk. There is no free lunch, and the decision deserves more scrutiny than it typically gets in an initial deployment conversation.

And finally: not every vendor in this space is going to survive the next consolidation cycle. The AI agent market right now has some characteristics of the early internet boom. Promising technology, real use cases, genuine value being created, and a lot of infrastructure being built by companies that will not exist in three years. Betting a portfolio company's operational backbone on a platform that may not be around is a risk that belongs in the investment thesis.

The bottom line

Here is the thing worth sitting with even if the deployment goes well. Rebuilding is not just a consequence of failure. It is a feature of the environment. The organizations deploying agents today are deploying version 1.0. Version 2.0, with meaningfully greater capability, is closer than most deployment timelines assume. The organizations that will navigate that transition well are the ones that built version one with the right architecture, the right foundation, and the right partners. Not because they knew exactly what version two would look like, but because they built something that could evolve rather than something that would have to be replaced. The window for thoughtful deployment is not closing. It is opening. The technology is maturing, the platforms are improving, and the organizations that take the time now to answer these questions honestly will be in a fundamentally better position than the ones that chased the first wave and are now rebuilding.

The competitive advantage in this moment does not belong to whoever deploys first, it belongs to whoever deploys right. That means understanding the data before building on it, knowing the processes before automating them, reading the workforce before asking them to change, and having the conviction to see it through when the path gets difficult.

The transformation is available. The question is whether the organization is ready to receive it on terms that will last.