In almost every enterprise AI conversation right now, someone eventually says the same thing: “Tokens are basically free.” I understand why people say it. If the expensive part of building with AI was inference, then cheaper tokens should unlock everything. But that assumption hides a bigger problem. The real cost of enterprise AI was never just the tokens. It was the messy human work required to turn a probabilistic answer into something a business is willing to bet on.

I’ve started seeing the same pattern play out in enterprise agent deployments. A team lets an advanced coding agent loose on a sprawling, decades-old monolithic service, targeting a move to a modern microservices architecture. The agent spends hours autonomously iterating on a large pull request, running local test suites, and fixing its own syntax errors. When the run finishes, the compute bill is often the smallest part of the exercise.

The real invoice arrives the next morning. A senior architect inherits a massive PR with thousands of lines of modified code. Because the agent iterated blindly against the compiler simply to get the tests to pass, it introduced architectural debt: it duplicated data structures, bypassed established caching patterns, and broke shared utilities. The architect spends the next day untangling the mess, tracing regressions, and ultimately rejecting the PR. The tokens were cheap, but the task itself was incredibly expensive.

For most of modern computing, the race was about making computation cheaper and faster. Now we are entering a world where the computer can generate changes faster than the organization can safely absorb them. AI isn’t eliminating the enterprise bottleneck. It is reversing the historical economics of software. Computation is becoming the easy part, and human coordination is becoming the scarce resource.

The uncomfortable realization is that we spent the last decade trying to remove humans from software delivery, only to discover that humans were not the bottleneck we thought they were. They were the control system. When you treat intelligence as an effectively unlimited resource, the operational friction doesn’t disappear. It simply migrates up the stack. We’ve spent years assuming that if we could just automate the code generation, the governance would take care of itself. It just won’t.

The irony is that the first problems appear exactly where we expected the magic to happen: inside the loops themselves. We assume this cycle is free because the tokens are cheap. But errors in these systems compound. The next decision is built entirely on the assumptions created by the previous one. If an agent makes the wrong assumption early, the next several iterations can become an expensive exercise in fixing the consequences of that original mistake. You aren’t scaling capability. You are spending more compute and latency cleaning up mistakes the system created for itself.

The raw economics here are deeply deceptive. The system doesn’t eliminate cost; it simply transfers it from GPUs to people. The model finishes its run in a few hours, but the humans inherit the uncertainty. They now have to reconstruct the reasoning, validate the assumptions, and decide whether the output is safe to ship. Ultimately, the bottleneck has moved from creation to trust.

If you push this architecture to its logical endpoint, you end up with agents optimizing other agents, adjusting prompts, retrieval strategies, and evaluation criteria overnight. The assumption is that another layer of AI can evaluate and improve the first layer. But enterprise software rarely has a perfect definition of success. The danger is that the system starts optimizing what it can measure instead of what the business actually values. It learns how to pass the tests, not necessarily how to preserve the architecture. This is the enterprise version of Goodhart’s Law.

The counter-argument sounds compelling: run enough experiments, and one breakthrough will justify all the failures. Platform developers will tell you that a mature agent architecture operates in an ephemeral sandbox, meaning unsuccessful runs can simply be deleted without leaving a single line of messy code behind. But enterprise software is not a lottery where losing tickets disappear without cost. Even if the code branch is cleanly deleted, the human time spent defining the task, managing the system, and reviewing the failure logs to understand why it missed the mark is still a massive tax on engineering velocity.

The other defense is that AI will simply review AI, relying on an ensemble of specialized judge models or rigid pipeline checks to audit the output. Proponents argue that if your CI/CD and regression testing suites are robust enough, bad architecture will be caught automatically. This assumes enterprise systems possess perfect, exhaustive test environments that capture subtle structural intent, which is almost never true for a legacy codebase. A system can easily pass every automated integration test while still producing structurally unmaintainable garbage that requires a human to untangle.

Without deterministic verification layers, entire ensembles can become highly confident about the same incorrect conclusion. Many enterprise AI deployments will fail not because the models aren’t intelligent enough, but because leadership is rather blind to the sheer cost of coordinating intelligent systems.

If spinning loops doesn’t automatically reduce the total cost of delivery, we have to change how we build. The answer isn’t longer execution loops; it’s a completely different control architecture. We need systems that preserve state instead of repeatedly reconstructing it. We need ways to summarize intent rather than syntax, so humans review decisions instead of thousands of generated lines. And we need deterministic boundaries where software takes over: business rules, financial limits, and termination conditions should not be negotiated by another language model. If a system detects a strict logic circle, such as executing multiple consecutive iterations without a change in environment state, the infrastructure should kill the loop instantly.

The history of computing has largely been about reducing the cost of computation. AI changes the problem. Computation is becoming abundant. Coordination isn’t though. As token prices collapse, coordination costs increasingly become the dominant constraint in many enterprise AI systems. The companies that win this phase won’t be the ones running the biggest models or the longest loops. They’ll be the ones that understand where autonomy helps, and where another loop is simply avoiding a decision.

The irony is that the companies that win enterprise AI may not be the ones that automate the most work. They may be the ones that build the best judgment systems around the work machines can already do.

Cheap intelligence is abundant. Reliable outcomes aren’t. That’s the real loop trap.

One of the easiest mistakes in technology is assuming the most valuable asset is the most visible one.

For the past three years, that asset looked like GPUs.

Every headline tracked NVIDIA shipments. All funding rounds celebrated larger clusters. Every single discussion about AI infrastructure turned into a count of compute.

But visibility is not value !!

AI infrastructure is not a silicon story. It is a capital allocation story. And capital, especially when systems come under stress, follows a consistent rule.

It systematically migrates toward the slowest-scaling constraint in the system.

Not the most exciting technology. Not the biggest market. Not the highest margins. The constraint !

What matters is not where innovation is happening. What matters is where scaling is breaking.

And this is the inversion most people miss.

Capital does not reward what is best. It rewards what is bottlenecked. Because in large systems under pressure, bottlenecks determine throughput. And throughput determines value creation.

---

The Pattern Beneath Industrial Cycles

This is not unique to AI. It is a recurring structure in every major industrial buildout.

The details change. The constraint does not.

In oil, the early constraint was drilling capacity. Capital rushed into extraction. But once production scaled, the bottleneck shifted downstream into pipelines, refineries, and export terminals. The constraint was never the well. It was the ability to move molecules.

In railroads, the focus was locomotives. But value accumulated in rights of way, corridors, terminals, and bridges. Trains were replicable. Geography was not.

In the internet, early scarcity sat in compute. Then bandwidth. Then fiber and backbone infrastructure. Eventually the constraint shifted again to data centers and interconnect density.

In smartphones, it was not demand or design. It was advanced semiconductor manufacturing, concentrated in a small number of foundries like TSMC.

The pattern is consistent. Capital does not stay where it enters. It moves to what cannot scale fast enough.

---

The Infrastructure Velocity Gap

AI makes this pattern visible because the system mismatch is extreme.

Software moves in weeks. Silicon moves in multi-year cycles. Physical infrastructure moves in decades – Utility planning, transmission buildouts, substations, permitting, interconnection queues. These layers do not move together. They operate on different orders of magnitude.

When demand accelerates, capital does not flow evenly. It is pulled toward the slowest-moving constraint in the stack.

For a time, that constraint was GPUs.That phase was real. Compute scarcity defined the first wave of AI scaling. But compute did what compute always does in a supply response cycle. It scaled faster than the rest of the system.

Now the constraint has shifted.

It is energy !

Not because compute is less important. But because compute is no longer the slowest-moving part of the system. This is why the conversation is shifting from GPU counts to contracted gigawatts. Because power is not just another input. It is the gating function.

If you control long-duration power, you can acquire compute. If you do not, GPUs are just stranded inventory.

This is already showing up in the system as stranded compute. Hardware is arriving faster than it can be activated. The constraint is no longer procurement. It is activation.

---

The Imbalance Loop

Capital does not identify constraints cleanly. It discovers them through overshoot.

It floods into a visible bottleneck. Supply catches up. Scarcity disappears. Returns compress and then capital moves !

Find constraint. Over-invest. Normalize into abundance. Move on. This is not efficient nor coordinated. But it is consistent. And it explains why constraints appear to move over time, even though they are layered inside the same system.

The system does not shift suddenly. It reweights where scarcity sits.

---

Two Structural Distortions

The first is whiplash.

Capital rushes into the constraint once it becomes visible. It overshoots. What was scarce becomes abundant in a short window.

We have seen this in telecom fiber during the dot-com cycle, in shipping capacity, in lithium supply chains, and in solar manufacturing.

The second is efficiency shocks.

Technology reduces cost faster than physical systems can adapt.Software becomes more efficient. Models compress and Hardware improves.

But efficiency does not reduce demand. It expands it.

That expansion pushes the constraint downstream into slower parts of the system that cannot scale at software speed. Efficiency does not remove bottlenecks. It relocates them.

---

The Real Signal

Most investors try to predict the next breakthrough. That is the wrong signal in my opinion.

The more durable signal is simpler : Find the next constraint !

Because every cycle follows the same structure.

Technology expands what is possible. Demand accelerates faster than physical infrastructure can respond. Capital concentrates at the slowest-scaling constraint. That constraint becomes the center of value creation.

Railroads were not about locomotives. Oil was not about drilling. The internet was not about servers. Each system is remembered for the part that could not scale fast enough.

---

The Enduring Rule

The most visible asset is rarely the most important one.

Systems reveal their constraint under stress – capital follows it. Technology changes. Constraint changes. Inevitably, value always forms at the bottleneck !

Usual caveat: These are strictly my personal opinions and have nothing to do with my past or present employers.

Almost every discussion about the slow adoption of enterprise GenAI eventually becomes a discussion about deployment. The narrative is familiar: today’s models are remarkably capable, but they start struggling when they collide with fragmented enterprise data, decades-old ERP systems, and the way large organizations actually operate.

The industry’s response has become equally familiar. Build larger customer-facing engineering organizations, embed technical talent inside customer environments, and call them Forward Deployed Engineers (FDEs).

It’s an appealing story.I also think it’s missing the bigger lesson.

Part of the reason this conversation is happening now is that enterprise AI has changed the nature of implementation. Moving workloads to the cloud was largely an infrastructure challenge. Deploying AI agents is increasingly a workflow challenge. The models aren’t failing because they can’t generate text or write code. They struggle because they have to operate inside decades of accumulated enterprise complexity.

That’s a very different problem.

The tech industry is discovering that the era of “touchless” enterprise SaaS—the plug-and-play playbook that defined the last decade—is hitting a structural wall. Deep data heterogeneity means AI cannot be delivered via a standard browser login alone. It requires a return to high-touch, localized execution.

If you’ve spent time building enterprise software or running a professional services P&L, you learn pretty quickly that changing a job title rarely changes the underlying unit economics of the business. The success of the FDE model has less to do with the brilliance of the engineer on-site than what happens to the code after they leave.

That’s the distinction I think much of the industry is missing.

What Palantir Actually Built

Most conversations about FDEs focus on the engineers themselves. I think the more interesting question is why the overall system works.

What Palantir built wasn’t really an implementation organization. It was a product organization that happens to deploy engineers into customer environments.

The company appears to have recognized early that mission-critical enterprise data is messy, political, and full of unwritten business rules. No software platform can anticipate every edge case before it is deployed in the real world.

Its answer was to pair two complementary roles that function less like standard consultants and more like a tightly coupled product-and-implementation team embedded inside the client environment.

Forward Deployed Engineers, internally known as Deltas, solve the immediate technical problems. They write production code, connect fragmented systems, and build what has been described as the initial “gravel road.”

Deployment Strategists, internally known as Echos, operate as domain heretics. Rather than acting as passive change-management advisors, they challenge the client’s existing assumptions, surface institutional constraints, and identify the real operational metrics that justify the deployment in the first place.

But the vital product mechanics happen back at headquarters.

If an FDE team simply copied every customer workflow into the core platform, the software would quickly degrade into an unmaintainable system. To be clear, some enterprise environments are so shaped by legacy decisions that clean abstraction is impossible anyway.

Instead, the central engineering team acts as a ruthless generalization engine. They don’t look to copy bespoke logic; they look across dozens of deployments to isolate the underlying structural friction and abstract those patterns into reusable primitives. What started as a customer-specific gravel road becomes a foundational data abstraction—a paved highway that future customers can use without repeating the same work.

That changes the economics entirely, though it is a long, margin-heavy R&D phase that requires years of organizational patience to bear fruit.

The deployment team isn’t just implementing software.It is teaching the product how to improve itself.

If a customer deployment uncovers a reusable primitive, the next implementation should require fewer integrations, fewer workarounds, and fewer engineering hours. Over time, the platform becomes more capable precisely because it has been exposed to real-world complexity the core team could never fully anticipate in advance.

The engineers are not the moat. The learning loop is.

Why This Is Hard for the Hyperscalers

It’s easy to understand why Microsoft, AWS, and Google are expanding customer-facing engineering as enterprise AI deployments become more complicated.

The question isn’t whether those engineers create value.They almost certainly do.

But hyperscalers are structurally and financially optimized for a very different economic engine. Public markets value them on predictable, high-margin infrastructure consumption. The true FDE model requires a deliberate financial trade-off: accepting heavy human operational costs in exchange for long-term operational dependency. This is fundamentally different from adding raw cloud infrastructure.

Furthermore, their feedback loop is designed to look for different things. When a hyperscaler’s customer engineering unit or partner motion uncovers an integration pattern, the goal isn’t to build a unified operating system; it is to harden infrastructure and developer tooling primitives (like security layers, data pipelines, or vector databases) so *any* developer can build faster.

Even so, the organizational coordination loop remains the hardest part.

Palantir operates around a relatively unified software platform. When deployment teams discover something new, there is a direct path for that insight to become part of the platform.

Hyperscalers operate across sprawling portfolios that include infrastructure, developer platforms, security, databases, AI models, analytics, and enterprise applications. A field engineering team may discover an important pattern around enterprise data orchestration, but where does that insight belong? Which separate product team owns it? Which distinct roadmap gets changed?

That is not primarily a technical problem.It is an organizational coordination problem.

None of this means the model cannot work for them. It simply means the value created by these engineers may end up strengthening localized customer relationships and developer tools more than systematically evolving a unified enterprise platform. Those are two very different feedback loops.

The System Integrator Problem

The challenge for traditional system integrators is different.

It is mostly about incentives.

The economic engine of a traditional consulting business rewards utilization. Success is measured by keeping talented people billable for as long as possible.

A successful FDE model tries to do almost the opposite.

Imagine an engineer builds an abstraction that reduces future data-mapping work by 80%.That is a strong product outcome because every future deployment becomes faster, cheaper, and more repeatable.

It is a much more complicated outcome for a services business whose revenue depends on billable implementation effort.

This is not primarily a technology problem. It is an incentive problem.

Many Global System Integrators (GSIs) will argue they are already navigating this by investing into “asset-based consulting” and proprietary accelerators. But there is a difference between using reusable artifacts to speed up delivery and building a system that continuously abstracts deployment work into a shared product core. If the firm’s P&L is still fundamentally driven by headcount, the incentive to expand labor almost always wins.

If system integrators genuinely want to build an FDE model, they need to change two things.

First, shift revenue toward outcomes rather than hours. The firm must benefit when automation and productization reduce implementation effort instead of losing revenue because fewer consultants are required.

Second, enforce real product discipline. Deployments need to strengthen a shared software platform. If every engagement produces another collection of client-specific, bespoke integrations, the organization gets better at delivering isolated projects but not better at building a scaling product.

Those are two very different businesses.

The Hardest Part May Be the People

There is another constraint that does not get discussed enough. True FDEs are unusually difficult to hire.

You need engineers who can write production systems under pressure while also earning the trust of executives, operations teams, and domain experts.

That is a rare combination.

More importantly, many of these people want to build products, not just complete projects. They want the solution they built for one customer to become part of something used by thousands of customers.

The operating model matters because the best engineers usually care about the structural trajectory of what they are building, not just the immediate engagement.

The Takeaway

Enterprise AI absolutely has a deployment problem. The models are advancing faster than most enterprises can absorb them, and embedding technical talent inside customer environments will often be necessary.

But I do not think the lesson is simply to hire more Forward Deployed Engineers.

The lesson is to build organizations that learn from every deployment.That is what made the model powerful in the first place.

If your deployment teams are helping the platform become smarter with every customer, you are building a compounding moat. If they are primarily helping close deals, retain customers, or deliver custom implementations, they may still create enormous value. But you are running a fundamentally different operating model.

That is why I think the conversation around FDEs is slightly misplaced.Everyone is debating how many engineers to hire.The harder question is whether the organization is designed to learn from those engineers.

Without that feedback loop, an FDE is just another implementation consultant with a more modern title.

Many companies are copying the surface mechanics of the FDE model.

I am not convinced they are copying the system that makes it compounding.