In the last two weeks, the three leading frontier labs have each reached for the same instrument. OpenAI launched the OpenAI Deployment Company with more than $4 billion in backing at a $10 billion valuation, anchored by TPG, Bain Capital, Brookfield, Goldman Sachs, McKinsey and Capgemini. Google Cloud CEO Thomas Kurian announced plans to hire hundreds of forward deployed engineers to form a new team inside Google Cloud. Anthropic partnered with Blackstone, Hellman & Friedman and Goldman Sachs on a $1.5 billion venture to embed engineers inside private equity portfolio companies and redesign workflows around Claude. The framing in each case is roughly the same: enterprise AI is hard, customers need help, send the engineers. This is a symptom of where we are in the adoption curve, not the answer to it. So what does the answer actually look like, and what are customers actually buying?

This rise of the forward deployed engineer tells us that the market has found a real problem: AI does not become valuable just because a model is available, a workflow has been demoed, or an integration exists in theory. The hard part begins when the system meets the customer’s actual operating environment, where the real process is not quite the documented process, handoffs are messy, ownership is unclear, approvals depend on context, and exceptions are often known by everyone but written down by no one.

In that environment, it makes sense that companies are sending engineers closer to the customer. Someone has to understand how the work actually happens before software can do anything useful with it. The mistake is to assume that because forward deployment is often necessary at the beginning, it is what the customer ultimately wants to buy.

The customer does not wake up wanting a forward deployed engineer. They do not want another technical team embedded in their business, another delivery model to manage, or another standing implementation function that quietly becomes part of the operating model. What they want is simpler and much harder: they want the work done, inside the environment where the work already happens, with enough reliability and control that they can trust the outcome.

The first use case is allowed to be messy

There is nothing wrong with using people to get the first use case right. In enterprise AI, it is often the only honest way to begin.

The first deployment is where the real workflow is discovered. It is where you learn which system is trusted, which process is mostly performative, which exception matters, where the risk sits, and what evidence the customer needs before they will let the software act with confidence. These things are not always available in a requirements document because the requirements document is often a partial fiction. It captures what the process is supposed to be, not necessarily how value, judgment, and accountability actually move through the organization.

That is the useful role of the FDE. They get close enough to the customer to expose the context that the product does not yet know how to capture for itself. They translate operational reality into something software can understand, and they find the gap between the demo and the deployment.

But that should be the point of the motion: to teach the software. If every new deployment requires the same amount of human discovery, bespoke configuration, and engineering effort to make the customer successful, then the company has not found a scalable AI model. It has found a consulting model with a better interface.

Consulting starts where product learning stops

The line between forward deployment and consulting is not the title on the team, it is whether the work compounds.

If an engineer sits with the customer, understands the workflow, builds around the exceptions, and leaves behind a system that makes the next use case faster, more reliable, and less dependent on human interpretation, that is product learning. If the same engineer, or another one just like them, has to come back and repeat the same exercise again and again, that is consulting.

This distinction matters because AI companies can easily hide a services business inside a software story. They can call it deployment velocity, customer obsession, outcome orientation, or any other phrase that makes the human effort feel strategic. Some of it is strategic. The danger is not being close to the customer; the danger is becoming permanently dependent on that closeness.

Customers will accept human help when it accelerates value, but they will not confuse it for the outcome. A long-running FDE engagement may feel reassuring at first because it means smart people are paying attention. Over time, though, it starts to look like exactly what customers were trying to avoid: another project, another dependency, another team whose knowledge lives partly in software and partly in people’s heads.

The promise of AI in the enterprise is not that customers get a more technical consulting team, it is that more of the work can move into software without losing the context, control, and judgment that made the human process work in the first place.

Forward deployed software

That is why the more interesting idea is forward deployed software.

Not software that waits for the customer to adapt to it, and not software that sits outside the workflow asking people to come to yet another place to get value. Forward deployed software enters the customer’s operating environment, learns how work is actually done, and gradually takes on more of the deployment burden that would otherwise sit with an FDE.

This does not mean pretending every workflow can be fully automated. That is usually where AI products become either brittle or irresponsible. In many enterprise processes, judgment still matters. Subject matter experts still matter. Review, escalation, auditability, and deterministic controls still matter. The point is not to remove humans from the loop everywhere; it is to stop using humans for work that software should be able to handle once the first deployment has taught it what matters.

Forward deployed software should learn the workflow, remember the exceptions, and understand where probabilistic reasoning is useful versus where deterministic logic is required. It should know when a task can be completed automatically, when it needs human review, and what evidence must be preserved so the customer can trust the result. In other words, software should start taking on the tasks that made forward deployment necessary in the first place.

That is what changes the economics for the customer. The first use case may require a heavier lift, but the second should be easier and the third should be faster. By the tenth, the customer should not feel like they are starting again. They should feel the return compounding.

The customer buys the outcome

Context graphs, integrations, and workflow memory all matter. But they are not what the customer is buying. They are the machinery behind the outcome. The customer buys the confidence that the work will happen correctly, consistently, and with less human effort over time.

That is the useful way to think about the infrastructure layer. It matters because enterprise AI cannot own real work if it does not understand the environment it is operating inside. It needs access to the systems, rules, exceptions, permissions, approvals, and prior decisions that shape how work actually gets done. But those things only matter if they make the outcome faster, safer, cheaper, or more repeatable.

No customer is buying a context graph because they want a graph. They are buying fewer stalled processes, faster approvals, cleaner handoffs, less operational drag, and more confidence that the same result can be delivered again without assembling another project team around it.

That is the customer-centric test for AI deployment. Did the work get done? Did it happen in the environment where the business already operates? Did it require less human effort over time? Did the next use case benefit from the last one?

If the answer is yes, then forward deployment has done its job. If the answer is no, then the FDE has become the product, and the customer is back in the world of consulting, even if everyone is using more modern language.

The real prize

The real prize is not more forward deployed engineers. It is software that can do more of what forward deployed engineers are currently being asked to do: understand the customer’s environment, translate messy workflows into executable systems, preserve the right controls, involve experts where judgment matters, and turn the first deployment into a faster path for the next one.

That is the difference between a services motion and a compounding software-based outcome. It is also the difference between a customer buying another project and a customer buying repeatable ROI.

Forward deployed engineers can be the bridge, but if you need them for too long, the bridge has become the destination. Customers do not want the bridge. They want to get to the other side.

The common thread isn’t really about pricing or packaging, it’s about rerunning the same playbook. These incumbents are taking the org chart we built for scarce human intelligence and laying it down as the template for abundant machine intelligence, and the framing is intuitive enough that most buyers aren’t questioning it.

Anthropomorphism was a useful bridge but it’s the wrong destination.

When ChatGPT launched, making AI feel human (conversational, personable, a little quirky) was a smart move because it lowered the barrier. People talked to it like a colleague and it worked. The anthropomorphism served a purpose: it made an alien technology approachable.

The problem is what happened next. A UX choice that worked at the chat interface got promoted into an operating model, and the metaphor that helped a single user feel comfortable talking to a chatbot is now being used to describe how entire enterprises should deploy, govern, and manage AI at scale. That’s a much bigger claim, and the metaphor doesn’t stretch that far. Making something feel familiar to a first-time user is not the same thing as designing how an organization should run.

Roleification places unnecessary limits.

“Paul the Paralegal” and “Sally the Salesperson” are agents defined by the specialization constraints of existing knowledge workers: an HR Agent that can only do what an HR person does, a Finance Agent bound by the walls of the finance department.

When you “onboard” an agent into a role, you are telling it to think within those walls. Of course, the agent does need to respect the access controls, data boundaries, and policies that define the task, and that part genuinely matters. But beyond those guardrails, the whole promise of generalized intelligence is that the thinking doesn’t have to be bound by the same walls that the job description is. Within what it’s permitted to see, the agent should be free to reason across whatever the work requires. Roleification optimizes for familiarity, making AI look like something a manager already understands, and familiarity is not the same as capability. The gap between the two is where all the value leaks out.

The work, not the worker.

The reframe that matters is this: stop thinking about what agents are and start thinking about what work needs to get done.

Take employee onboarding, which doesn’t really live in HR. It touches recruiting, IT provisioning, facilities, payroll, compliance, and the hiring manager’s calendar, and it’s slow today precisely because it’s distributed across six departments with their own systems, handoffs, and queue times. The HR Agent framing doesn’t fix this, it just automates HR’s slice and leaves the handoff friction untouched.

The more useful approach isn’t deciding which department an agent belongs to, but what outcome the business actually wants, what information is needed to get there, and what the fastest path to completion looks like. That path will almost always cut across the silos you’ve built, which is the whole point. The organizations starting to see real returns from AI aren’t the ones that bolted agents onto existing processes, they’re the ones willing to rethink the processes underneath.

This is process reengineering, not headcount planning.

Vendors don’t lead with this message, because process reengineering is hard, unsexy, and impossible to sell as a per-seat license, but it’s where the value actually sits.

Some of the incumbents are starting to acknowledge, at least in their marketing, that the game is moving. Salesforce going headless is the most visible example: the company that invented per-seat SaaS is repackaging itself as an API surface for agents, which is a recognition that the agent is the interface and the data layer is where the value will be captured, while also being a move to make sure they remain the ones capturing it. Our view has always been that the systems of record were going to have to become data companies, and exposing the API surface is the price of admission rather than a gift to the ecosystem.

When intelligence becomes abundant, and any node in your enterprise can reason, synthesize, and act, the binding constraint changes. It’s no longer whether you have enough smart people in the right roles, it’s whether your information architecture is set up to let intelligence flow to where the work actually is. That’s a fundamentally different question, and it demands a fundamentally different investment: not in agent personas, but in data flows, in breaking down the information silos that were built for a world where intelligence was scarce and expensive and had to be rationed into departments.

Your company’s competitive advantage was never the org chart anyway. It was the institutional knowledge, the customer relationships, and the proprietary processes, the things that actually differentiate you. Agents don’t protect that advantage by mimicking your current structure, they unlock it by making that knowledge actionable across every surface of the business.

The real infrastructure investment.

Getting this right starts with the layer underneath the agents. Before you deploy anything that calls itself an agent, you need a runtime that can govern what it sees, what it does, and what it’s allowed to conclude. Your proprietary data, business rules, and strategic priorities need to be extracted, structured, and made available as living context, rather than trapped inside department-specific tools or siloed in applications that don’t talk to each other. The question isn’t which agent you deploy, it’s whether any intelligence, human or machine, can access the right context, act on it safely, and be held to account for the outcome.

That means investing in how your organizational knowledge is modeled, how context is delivered to the point of work, how memory accumulates across interactions, and how every action an agent takes can be governed and audited. The cross-cutting layer where all of that lives cannot be owned by any single vendor whose data it’s governing access to. It has to sit on your side of the line, portable across models and across systems, or the independence you think you’re buying is an illusion.

When that foundation is in place, you don’t need to “hire” an HR agent or a Finance agent. You compose capabilities (reason, research, draft, decide, escalate) dynamically around whatever the work demands. You give your agents a goal and guardrails.

Where we think things will go.

The companies that will look back on this era and wonder what they were thinking are the ones building agent org charts today, meticulously onboarding digital employees into the same departmental silos that have been slowing them down for decades. Right behind them will be the ones who accepted a vendor’s headless pivot as the whole answer, and only discovered later that the runtime governing their agents was never really theirs.

The ones that will win are doing something less photogenic but far more consequential: rewiring how their business thinks. Not adding AI to the machine but rebuilding the machine around what AI makes possible.

Your agents don’t need job titles. Your enterprise needs intelligent plumbing.

That is why I increasingly think LLM agnosticism is becoming a strategic requirement for enterprise AI, not a technical preference or a purity argument. The recent Information Report on Anthropic’s changes to enterprise pricing for heavy business usage is significant because it shows how quickly the economics can shift once workloads become serious. Providers will price for their own compute constraints, capacity limits, and margin objectives, and they will work hard to pull customers deeper into their own hosted agent ecosystems. That is entirely rational from their side. It is simply not a stable basis on which to build the rest of your company’s operating mode in a market this volatile, this politically exposed, and this fast-moving.

The durable asset is not the model endpoint. It is the agentic system that governs how models interact with your data, memory, context, tools, and policy. If that layer belongs to you, providers compete for your workloads, the best models can be chosen task by task, and switching remains an engineering exercise rather than a strategic crisis. If that layer belongs to them, your economics, privacy posture, and exit costs are all downstream of somebody else’s platform strategy. Avoiding that trap requires more than a gateway. It will require owning the runtime.

Why This Is Becoming Urgent

The Anthropic pricing change is a useful signal because it exposes a deeper truth about agentic AI economics. Once usage shifts from seat-based productivity into long-running coding agents, scheduled work, tool use, retries, and autonomous workflows, pricing stops being a clean per-user abstraction and starts to reflect raw consumption. The Information piece suggests that some heavy Claude Enterprise users could see costs double or even triple under the new structure, and it notes similar usage-sensitive moves elsewhere in enterprise AI. This is probably not an outlier, but what happens when providers discover where the expensive workloads are.

And price is only one axis of dependency. The frontier model market is moving too quickly, its economics remain too unsettled, and its policy environment is too uncertain for any serious company to commit its architecture to one provider’s roadmap. You do not know which firms will still be structurally advantaged in three years, whose gross margins will hold, which models will end up constrained by regional regulation or procurement rules, or where governments will decide strategic control points need to sit. Frontier models are already close enough to strategic infrastructure that export controls, access restrictions, or safety interventions can no longer be treated as remote possibilities.

That is too much uncertainty to absorb passively. The practical response is to make model choice reversible.

The Best Model Depends on the Job

This matters because different model families genuinely excel at different kinds of work, and the best answer is rarely “pick one and standardize everything around it.”

In many enterprise teams, the picture has already shifted noticeably over the last three months. For coding workflows in particular, many teams have begun moving from Claude toward Codex, not because Claude has stopped being useful, but because OpenAI is often better at following precise instructions, operating inside tighter agentic control loops, and using tools in a more disciplined way over longer execution chains. Claude still has a distinct strength of its own: it is often better at finding a user’s underlying intent inside messy, ambiguous conversation, which matters in workflows where the hardest problem is understanding what was actually meant before any action is taken.

Neither choice should dictate the architecture of the whole company.

There is another advantage to model plurality that is still underused: one model can check another’s work. A model that proposes an action is often a poor judge of its own blind spots, especially if the same family is also being asked to validate the output, grade the result, and decide whether to continue. Once you let a second model from a different provider review the work, or better still attack it, you reduce correlated failure. One model writes the code change, another looks for the edge case; one proposes a customer action, another searches for the compliance or policy problem; one drafts the plan, another tries to break it. What matters is not merely a second opinion, but a second failure distribution.

That diversity also gives you a more rational cost structure. Not every step justifies the most expensive model, and not every task should be solved with the model you happened to start with six months earlier. The ability to route by task, validate across families, and change those choices without a replatform is what low switching cost actually looks like in practice.

The Real Lock-In Is Where Enterprise Meaning Lives

The strongest form of lock-in is not the API call. It is where your memories, context, ontology, and workflow semantics end up living.

Hosted agent frameworks are attractive because they compress months of work into days. They ship with managed memory, built-in tracing, default planners, integrated evals, native tools, and smooth developer ergonomics. That convenience is real, but so is the functional limit. Most are optimized for their own abstractions, their own storage assumptions, their own tool semantics, and their own view of governance. They tend to treat context as a provider-native payload rather than a governed architectural layer, which is exactly why they feel so productive at the start and so constraining later.

This is where sovereignty stops sounding abstract and becomes operational. Data sovereignty in this sense does not just mean “keep the files private.” It means the enterprise owns its memories, context layers, business ontology, approved tools, versioned queries, access rules, and audit trail. It means a model can invoke a reviewed and approved query by name rather than inventing live query logic in production. It means credentials remain at the gateway or data-access layer rather than inside the agent loop. It means the map of enterprise meaning, how customers, products, policies, mandates, exceptions, and actions are actually defined, stays on your side of the boundary.

That is the layer that compounds with use, and it is the layer you do not want to hand away.

We have seen this pattern before in the cloud. Single-provider choices did not usually hurt in year one; they became painful in year three, when data gravity, egress, proprietary services, and rewrite costs converted earlier speed into later dependency. AI providers are now trying, quite sensibly, to move up the same stack. They do not want to provide only inference; they want the hosted agent framework, the memory layer, the eval system, the tracing surface, and the developer workflow that makes your application harder to move. The easiest architecture to start with is becoming, again, the hardest one to leave.

Agnostic Does Not Mean Generic

There is, however, one important caveat that gets missed in simplistic “multi-model” discussions: an LLM-agnostic system is not just a gateway.

The transport layer is the easy part. The hard part is behavior. Different model families want different prompt structures, tool descriptions, context packing strategies, result validators, retry policies, stop conditions, and cache behavior. Real agnosticism does not mean pretending Claude, OpenAI, and a local open model are interchangeable. It means keeping the invariant layers, your data fabric, memory, ontology, policy controls, audit, and tool execution, on your side, while versioning prompt packs and task variants by model family and even by model version so each one is optimized for the work it is doing.

If you want low switching cost without dropping into lowest-common-denominator behavior, you need a canonical internal representation of prompts and tasks, with provider-specific translation at invocation time, and you need different prompt versions retained for different families because the same task often performs differently across them. In other words, low switching cost is not achieved by denying model differences; it is achieved by containing them.

This is one of the reasons we designed our ContextOne architecture in the way we did. The runtime is LLM-agnostic, but it does not assume identical behavior across model families. It preserves the enterprise’s control over memory, ontology, audit, and policy while allowing prompts and tasks to be optimized for specific providers and versions. That is the appropriate kind of complexity, because it buys flexibility where it matters and specialization where it pays.

Local Open Models Belong Beside the Frontier Loop

Once you own orchestration, smaller local open models stop being ideological and start being practical.

They can run in side-chains alongside the main agentic loop, handling tasks that are narrow, repetitive, privacy-sensitive, or simply not worth frontier-model pricing. A local model can classify inbound documents, normalize entity names across messy systems, rerank retrieved passages, or perform first-pass policy and code checks before the frontier model is called.

These side chains can run in parallel with the main loop, which means the gain is not only lower cost but also lower latency and reduced exposure. The frontier model spends its budget on reasoning rather than housekeeping, while the most sensitive or repetitive steps remain inside the enterprise boundary. For regulated businesses, that hybrid pattern is usually much better than the false choice between “everything hosted” and “everything local.”

Board-Level Takeaway

The strategic question is not which model vendor looks strongest this quarter. It is whether the company owns the runtime that governs data, memory, ontology, tools, and policy, because that layer determines pricing leverage, privacy posture, resilience, and exit cost. It is the layer that compounds with use. A company that owns it can let model vendors compete inside its system; a company that does not is effectively underwriting the platform risk of the vendor it chose first.

Conclusion

For most serious enterprises, the disadvantages of running their own agentic system in-house are front-loaded and manageable, while the benefits compound over time. You take on more architecture, more governance work, and more operational discipline up front; in return, you get lower structural risk, better cost control, stronger privacy, clearer ownership, reduced lock-in, and the freedom to use the best model for each task rather than the model you happened to standardize on early.

None of this means provider ecosystems are useless. They will remain valuable learning surfaces, and for many teams they will still be the fastest way to get started. But as soon as AI touches core workflows, proprietary data, and real budgets, convenience stops being the right optimization target. Risk, cost, lock-in, ownership, and privacy move to the front of the queue.

That is why the more durable pattern is to keep the context and control architecture on the enterprise side of the boundary, let frontier and local models work together inside it, and make model choice reversible. We build around that principle: LLM-agnostic at the runtime layer, optimized by model family where it matters, and structured so the enterprise keeps the memories, ontology, and controls that actually become more valuable with use.

The companies that benefit most from this cycle will not be the ones that guessed the eventual winning model provider. They will be the ones that refused to bet the rest of their architecture on that guess.

I don’t mean we hid it behind a feature flag or stopped talking about it. We removed it from the product, ripped out the code paths, and stopped designing around it. It wasn’t a rage decision. It was the end of a slow, unmistakable realization: the builder was training us to solve the wrong problem.

When we first shipped it, it felt like progress. Engineers could point to a canvas and say, “This is what happens.” Boxes, arrows, a clean sequence from input to output. It made the system easy to grasp, especially for people seeing it for the first time. But easy to grasp isn’t the same as correct.

Not all “agents” are the same

At some point we had to admit we were mixing up different categories of “agentic” products. From a distance, it can look like everything is an “agent” now. But under the hood, it’s really a few distinct paradigms wearing the same label.

The first is the classic visual workflow builder. But it’s not really an agent. It’s a workflow: a structured, predefined sequence where the user specifies the path up front - usually with drag-and-drop blocks. It’s great when the operation is repeatable and the world stays stable. But it doesn’t reason. It doesn’t adapt. It mostly just advances.

The second is what I’d call the framework-first approach - the ecosystems where you wire up tool calls, loops, and multi-step behaviors with prompts and orchestration code. Those tools made “agent development” accessible. But they also push the hard problems into the least reliable place: the model’s behavior. The more you rely on prompt compliance for governance, the more your security and policy guarantees become aspirations instead of structure.

The third is the power-tool category: things like coding agents and lightweight task runners. They can be shockingly capable in a constrained environment. But they usually don’t give you the things organizations need when the work matters: centralized policy enforcement, reproducibility, consistent audit logs, and a way to explain why it made the decisions it did.

We realized what we were building is closer to a fourth category: an enterprise-aware agent system. The experience should feel as immediate as the best power-tools - type a goal, give it tools, watch it work - but with the operational guarantees that make it deployable in the real world: enforceable boundaries, evidence and lineage, and auditability.

The First Shift: From Steps to Outcomes

Back to our visual builder. The first cracks didn’t show up in the demo environment. They showed up in the unglamorous places: the runs where the data didn’t match the happy path, where a tool returned something plausible but incomplete, where a downstream system changed a response shape without telling anyone. The builder did what it was built to do: it moved forward. It advanced to the next box.

And that’s exactly when we started losing the plot.

Because the system we were trying to build wasn’t supposed to “advance.” It was supposed to reach a goal reliably, even when the path wasn’t the one we expected.

That was the first shift: we stopped thinking in steps and started thinking in outcomes. In a builder, the path is the artifact. In an agentic system, the path is disposable, a means to an end.

Once you see that difference, you can’t unsee it.

We tried to reconcile the two worlds for a while. We added more structure. More branches. Retries. Validation blocks. Error handlers. We made the canvas smarter the way everyone makes canvases smarter: more boxes. The diagrams got impressive—dense, “enterprise,” serious.

They also got fragile.

Every new block was a commitment to predict the future: which failure modes matter, which recoveries are safe, which validations are sufficient, which conditions are worth branching on. And as soon as production taught us a new lesson, we encoded it as another node. That created a familiar pattern: the canvas wasn’t representing reality; it was chasing it.

Here’s the distinction we couldn’t escape: workflow graphs are execution plans. You pre-author a path. Agentic systems are control policies—they observe, decide, act, and verify against the goal. Adding boxes just hard-codes yesterday’s lessons; it doesn’t buy you adaptation.

The Second Shift: From Calls to Actors

The second shift made the decision inevitable: we stopped treating the model like a single call and started treating it like an actor in a system.

The best runs shared a simple shape:

• give the model a goal

• give it tools and skills

• constrain it with guardrails

• let it cook

The surprise was how often the right path differed. The model changed tool order based on what it found, recovered from failures, asked clarifying questions when needed, and validated intermediates because the goal demanded it.

A concrete example made this obvious.

Take onboarding. Not “fill in a form” onboarding, real onboarding where inputs arrive as emails, PDFs, spreadsheets, and half-structured notes. One run is clean; the next has mismatched identifiers, missing evidence, or a policy threshold that changes what checks are required. The system has to ask a question, route to a reviewer, pull a source of truth, re-check assumptions, and then prove the outcome is supported.

In a canvas world, that’s not one workflow. It becomes a library of workflows: branches for every policy fork, variants for every product line, region, customer type, evidence format, and exception path. Over time it turns into hundreds of slight variations, most of them identical except for one step, one validation, one integration edge case.

An agentic system treats those variations differently. The goal is stable. The constraints are explicit. The tools are bounded. The agent decides the path at runtime based on what it sees, and it can explain why it took the route it did.

That’s what “agentic” meant in practice. It is not a buzzword, but a behavior: understanding the environment, adapting to change and error, and staying oriented to the goal.

And that’s where the canvas became more than inconvenient. It became actively counterproductive.

A visual workflow builder rewards certainty. It rewards pre-definition. It encourages you to treat the journey as sacred: draw it carefully, lock it in, and the system will follow it faithfully.

But effective automation isn’t faithfulness to a plan. It’s faithfulness to an outcome.

The builder was making the journey more important than the destination.

We felt this most sharply in debugging. With a canvas, a run “fails” when a node errors. But many of the worst failures in automation don’t throw errors, they produce outputs that look reasonable. A workflow graph can happily deliver something that passes through every box and still be wrong, because the world changed and the flow didn’t notice. The diagram stays clean. The result quietly degrades.

To solve that, you don’t add more arrows. You add a control plane: explicit checks, verifiable tool boundaries, consistency tests, and guardrails that stop the system from “hallucinating to completion.” You make the system able to say: I can’t support this conclusion with evidence. Or: I need clarification. Or: This output fails validation; I’m taking a different approach.

Those are not canvas nodes. They’re governance primitives.

The Third Shift: Operations Change Everything

The third shift was operational: supporting deployments over time means living in continuous change. Data formats drift. Vendors update. Policies and thresholds move. Exceptions emerge. Tools develop new failure modes. Teams change how approvals and escalations work.

Once you account for that, the math is brutal: every diagram is an artifact you now have to keep in sync with a moving world. It starts as “a few workflows,” becomes a library, then a forest of near-duplicates.

Onboarding makes the cost obvious. If step X exists in 500 variants, a small upstream change isn’t one fix, it’s 500 edits, 500 tests, and 500 chances to miss a corner.

In an agentic system, the unit of change is smaller and more powerful. You improve a tool. You refine a prompt. You add memory. You tighten a guardrail. One change, applied everywhere. The system adapts at runtime instead of demanding that engineers pre-adapt it in diagrams.

The Decision to Delete

Once we accepted that, keeping a workflow builder around wasn’t harmless. It was pulling the product toward a worldview we no longer believed: that the primary job of automation is to predefine the path.

So we deleted it.

Not as a rejection of visual builders in general, just an acknowledgment of what we were actually building. In an agentic-native system, the interface isn’t a canvas. The interface is principles, intent, constraints, tools, and a trace of decisions that you can inspect, audit, and replay.

The goal stays fixed. The route is allowed to change because the world does.

And after we committed to that, a workflow builder wasn’t a feature anymore. It was a contradiction.

So how do you actually translate this shift into shipped systems?

Start With the Right People

Not every developer will thrive in this new model. Some have always coded for the beauty of code itself rather than for the goal of producing working business systems. AI agents will displease those who love coding for its own sake, and empower those who love to ship real outcomes.

Find a handful of those people and experiment with them first. I don’t believe there’s a strong level of experience correlation here; what matters is mindset. Specifically, look for developers who:

• Are curious and willing to learn. Working with AI agents is a new discipline. The people who will succeed are those who approach it with genuine curiosity and a willingness to experiment.

• Are driven to ship business value, not just code. The agent handles much of the raw coding. What remains is the harder, more critical work of translating business problems into working systems.

• Understand the business itself. People who grasp what the organization is trying to accomplish will be far more effective at steering agents toward the right outcome. This matters more than ever, because the bottleneck is no longer typing speed, it’s judgment.

• Have used AI coding tools and can talk about what they’ve done. There’s simply no excuse for not having used a number of tools at this point. If you meet someone who hasn’t committed to that growth mindset and at least done personal work with it, start to ask a lot of questions.

Pick the Right Problems

Once you have one or more small teams, the challenge is finding the right kind of problem to experiment with. AI agents work best on greenfield projects, though they absolutely help with legacy systems too.

Regarding scope, the obvious answer is often the right one - you should start small with a single end-to-end feature. However, more importantly, you must start with something verifiable. AI agents shine when they can validate their own work. Focus on problems with clear, measurable results - a well-defined API, a calculation that can be checked, a workflow with observable outputs. Avoid anything ambiguous where success is subjective and hard to confirm.

Recognize Where the Pain Shifts

This is a point that catches many organizations off guard. The development itself is no longer the long pole. The pain moves upstream and downstream: to specification and to review.

Before an agent can build the right thing, someone needs to clearly articulate what the right thing is. This loops back to having developers with a solid handle on the business problem being solved. They should also have a strong understanding of architecture, organizational standards, and deployment constraints so that the agent doesn’t produce something technically impressive that can never actually ship.

On the other end, review becomes the critical bottleneck. AI agents can generate substantial volumes of working code, but someone still needs to verify that it does the right thing, in the right way, within the right guardrails. Plan for this. Build review capacity into your workflow from the start - and that doesn’t have to be manual.

To make this a bit more concrete: inside the product engineering team at AI One, we have shifted design reviews to the left: the story initiator writes the initial design document (AI-assisted), one or more other team members review it and provide feedback, and then we assign a single developer to take it forward from that point to production. During development, we use AI tooling (alongside heavily automated, high coverage end-to-end testing) to perform reviews across a number of different dimensions: correctness, functionality, and security. Then, once the developer has proven the story is in a state of readiness, they submit the PR for another team member to review. The team member then reviews the evidence and the high risk areas of the PR before approving it (or requesting changes). This sits around level 3 to level 4 of Dan Shapiro’s Five Levels of AI coding. As a SOC II compliant organization, we require at least some human oversight of the code so this approach fits well into a highly regulated context.

Invest in Infrastructure and Test Environments

This follows naturally from the review constraint. AI agents perform dramatically better when they can interact with real systems in controlled environments. If you’re building something that connects to a custom internal API, give the agent access to a live instance of that API in a sandbox. If this cannot be achieved, build as close a digital twin as you can. Then, let it validate that API calls actually did what it expected.

Agents are remarkably good at feeling their way around systems and figuring out how best to use them once given real access. Static documentation alone is a poor substitute.

A Practical Example: Building Integration Gateways

We recently needed to build gateways for both Google Workspace (authentication and access to Drive, Sheets, Calendars, and more) and Microsoft 365 (authentication, Teams, SharePoint, and related services). Rather than handing agents documentation and hoping for the best, we stood up full sandbox environments for them to work against.

We populated these environments with real data - files in SharePoint and Drive, channels in Teams, calendar entries - and gave the agents well-defined tasks: authenticate, retrieve a file from SharePoint, list items in a Drive folder, post to a Teams channel. The agents had full access to these sandbox environments, access to the internet for API documentation, and crucially, the ability to verify every step of their work against real system responses.

The result was high-quality integration gateways that were proven from the start to work correctly. They weren’t built in theory and then tested, they were built through testing, with the agent iterating against live systems until everything behaved as expected. We still reviewed the output for security, architectural fit, and edge cases, but the heavy lifting - the tedious, iterative work of getting OAuth flows, API pagination, error handling, and data mapping right - was all done by the agents.

This is the pattern that works: give agents real environments, clear objectives, and the ability to validate their own results. The quality of the output is dramatically higher than what you get from agents working blind against documentation alone.

Then, critically, ensure the agent builds out the tests necessary to enable quick and safe changes in the future. The first build is just the beginning - the test suite is what makes it sustainable.

Don’t Overthink Costs - Invest to Experiment

It’s surprisingly uncommon for developers to be given truly high-quality tools - whether that’s powerful laptops, top-tier IDEs, or $200/month subscriptions to AI agents. Use your small teams to experiment and build the business case - it’s a very small investment for a potentially massive return.

As a closing piece of advice, I’d also strongly encourage organizations not to be too restrictive about letting curious developers use their subscriptions at home for personal projects. Building a small side project, automating something in their own life, experimenting with a new framework - this is all part of learning to work effectively with the tools. That fluency will flow directly back into their professional output. Treat it as professional development, because that’s exactly what it is.

The number itself is less important than the precedent. The implicit demand is clear: if AI made you faster, I want the discount.

That demand exposes a long-standing economic tension. The buyer’s instinct is understandable, but it rests on an assumption that has always been fragile: that hours billed are equivalent to value delivered. The billable hour has historically functioned as a proxy for value in professional services, not the value itself. But in reality, clients do not purchase time; they purchase judgment, accumulated context, risk transfer, and accountable outcomes. When AI compresses the hours required to produce an audit, a diligence report, or a strategic memo, it does not automatically compress the expertise or liability embedded in the final deliverable.

What the KPMG example illustrates is not just fee pressure in auditing. It signals that “AI pass-through” is becoming a baseline expectation. Wherever a buyer can point to a visible process and ask, “How many hours is this still taking, and why?”, pricing models anchored to labor time will come under scrutiny.

The mechanism will vary by industry, but the pressure is similar. In software and professional services, AI reduces labor minutes. In operational settings—factories, logistics networks, supply chains—it reduces variance: fewer defects, fewer returns, less downtime, tighter inventory. In both cases, measurable efficiency gains create procurement leverage.

Service providers will respond by arguing that AI does not merely make the same output cheaper; it shifts the quality frontier. A faster audit that surfaces anomalies with greater precision, a compliance workflow with stronger traceability, or a supply chain with materially lower variance is not strictly the same product at a lower cost. It is a product with different performance characteristics. From the vendor’s perspective, the relevant question is not “How many hours did this take?” but “How much risk was removed, how much upside was unlocked, and how much better is the outcome?”

The problem is that procurement teams rarely price on abstract improvements in quality when visible cost savings exist. The adjustment is unlikely to be linear. The adoption path more closely resembles a J-curve followed by an S-curve.

The J-curve is the awkward phase in which efficiency gains exist but are difficult to monetize cleanly: duplicated workflows, model risk controls, data integration overhead, security reviews, and persistent edge cases that pull manual work back into the loop. During this period, prices may not fall meaningfully, and in some cases may even rise as vendors absorb transition costs.

The S-curve follows once tooling standardizes, model workflows are audited, and AI is embedded in operating procedures. At that point, procurement gains confidence in the stability of the new process and begins pricing against unit economics rather than prototypes. Explicit AI discounting becomes harder to resist. Once a few vendors concede, peers risk appearing overpriced overnight.

This creates acute pressure for firms that lag in implementation. Vendors unable to demonstrate credible efficiency gains—or unable to absorb pass-through pricing—will struggle to compete.

Yet the long-run dynamic is more complex than simple deflation. When technology meaningfully increases the productive capacity of expertise, demand often expands. As AI raises the ceiling on what a professional can analyze, oversee, or optimize, the binding constraint shifts from labor time to judgment and accountability. Pricing anchored purely to hours becomes increasingly incoherent, but total value creation may grow.

Whether buyers pay for that expanded capability or simply capture the efficiency gains depends largely on market structure. In highly competitive markets, savings are more likely to pass through, producing pockets of disinflation even as quality improves. In concentrated markets, vendors may retain a larger share of the productivity dividend, expanding margins while performance rises.

For firms early in their AI implementation cycle, the practical constraint is not model performance but proof. Efficiency gains that cannot be measured, governed, and allocated are difficult to defend in pricing negotiations. Buyers demanding discounts will increasingly demand evidence: auditable trails that separate real throughput improvements from shifted risk or hidden rework.

The evidentiary standard cannot stop at hours saved. If the debate is framed purely in terms of cycle time or headcount compression, the buyer’s logic dominates. The more durable strategy is to make surplus legible across multiple dimensions: throughput, error reduction, variance compression, regulatory defensibility, risk transfer, and outcome quality.

When a buyer can quantify not only cycle time and exception rates, but also control strength, auditability, and decision quality with the same rigor applied to financial metrics, the conversation changes. It shifts from “How much labor was removed?” to “What new level of assurance or performance is now possible?”

The audit fee reduction is therefore less about one negotiation and more about a structural question that will echo across sectors: when AI increases productive capacity, who captures the surplus? The answer will depend on competitive intensity, evidentiary discipline, and how effectively vendors re-anchor pricing away from time and toward accountable outcomes.

This is why the concept of “context graphs” entered the conversation, and why they matter. The recent framing is precise. Context graphs are not knowledge graphs. They are decision trace graphs. They preserve what mattered at decision time so that justification, precedent, and accountability do not dissolve into chat logs.

That is a meaningful advance. It is crucial to include historical decisions, exceptions, and edge cases when making decisions about how to act. But over the last year, when actually implementing enterprise wide production systems, we quickly found that it is not the end state.

The mistake many teams make is subtle. They correctly observe that decision traces are consulted during agent reasoning, and then quietly slide from “informs action” to “authorizes action.” Once that line is crossed, the architecture starts to accumulate risk in ways that only appear months later.

What follows is the perspective that emerged when we treated decision traces as advisory reasoning surfaces, and deliberately placed authority elsewhere.

Why The Context Graph Concept Invites Overreach

In practice, the strongest solutions in this area are active participants in agent reasoning. They are queryable during planning and execution in order to surface precedent, exceptions, constraints, and prior approvals. Used this way, decision traces materially improve reasoning quality. They ground agents in organizational memory, reduce hallucination, and make decisions legible after the fact. This is precisely what makes the graph concept so tempting to treat as a source of authority. Graph nodes look executable. They encode conditions, actions, and rationale. It is easy to slide from “this informs what we should do” to “this permits us to do it.”

That slide is where risk accumulates. A true context graph would preserve what mattered at decision time, but would not enforce what is valid now. When allowed to authorize action, three failure modes reliably appear. Precedent outlives policy because time is represented but not enforced. Rare exceptions become reusable templates as agents optimize for citation rather than validation. As graphs grow richer, systems become better at justifying actions than at checking whether they are still allowed. These are not flaws in graph design. They are the natural outcome of treating memory as control.

Separately, in our practical experience, we found that trajectories solve a different and equally important problem. A trajectory is the time ordered trace of how work actually unfolds, including goals, actions, failures, escalations, overrides, and outcomes. Reasoning over trajectories shifts agents away from inventing plans and toward reproducing successful ones. Recovery improves because failure patterns are visible. Planning becomes empirical rather than speculative. But trajectories are descriptive, not normative. They explain how work gets done here, not what is permitted to run.

Behavior Before Permission

The missing primitive is executable authority. Rather than storing justification as narrative memory, we embedded it into time versioned units of execution - skills. A skill is not a suggestion. It is an enforcement point. Each skill defines the action it permits, the preconditions that must hold, the authoritative sources it may consult, and the subsequent deterministic validations that must be passed, including business rules, policy constraints, and risk controls. It also specifies any approvals or exceptions required, the evidence that must be emitted, and the window in which the skill is valid. Skills are evaluated synchronously at execution time and fail closed. If the rules no longer pass, the policy no longer applies, or the justification has expired, the action does not run. This is the moment where “why” stops being an explanation and becomes control.

Time bounding is the property that turns governance from an aspiration into a system behavior. Without it, organizations slowly accumulate what we came to think of as precedent rot. Temporary workarounds harden into defaults. Policy interpretations linger long after their intent has expired. Nothing breaks loudly, but authority quietly drifts. By contrast, a time bound skill expires in the open. It must be refreshed from sources, revalidated against policy, or deliberately replaced. Drift becomes visible and actionable instead of silent. Decision traces remain invaluable in this process because they preserve the history of how and why decisions were made. But they can only observe drift. Skills are what stop it.

When combined deliberately, the division of labour becomes clear. Different primitives serve different roles, and problems that once felt entangled separate cleanly. Trajectories ground agents in how work actually succeeds by exposing real sequences of action and recovery. Decision traces ground reasoning by preserving precedent, rationale, and explanation. Skills sit at execution time and decide what is allowed to run now, under current conditions. Agents consult all three continuously, but only one has the authority to say yes. This resolves a tension many teams feel but rarely articulate. Decision traces (or implementations of context graphs) should absolutely influence what an agent proposes to do. They simply should not be the thing that permits it.

From Reasoning to Control

The enterprise choice is straightforward. Either reasoning is allowed to imply permission, or permission is enforced independently of reasoning. Only one of these scales safely. Systems built on trajectories and skills are much easier to transition from prototype to production, and far harder to break once they are there.

But the more interesting question is not whether forward-deployed work is dangerous. It’s when it becomes dangerous, and what actually separates a compounding platform from a high-end delivery shop in an era where software itself is getting cheaper and faster to build.

In practice, many of the most valuable enterprise AI problems still demand real proximity to the customer. The hardest work lives in messy, high-stakes domains where production outcomes matter: reconciling exceptions across fragmented systems, continuously monitoring disparate systems for early risk and next-best-action signals, and capturing the “in-between” context - decisions, SOPs, undocumented overrides - that determines whether automation is explainable, auditable, and trusted. These are not problems that vanish with better models alone.

The mistake is assuming that because this work is necessary, it should be permanent.

Forward deployment should be a use-case scaling strategy, not an operating model. The first phase - going from zero to one - benefits enormously from tightly integrated field and platform engineering. But that phase only creates leverage if it is explicitly designed to end. The purpose is not to deliver forever; it is to extract a repeatable pattern that can be scaled with far less human involvement.

This is where the article’s warning is most important, and where execution discipline matters more than rhetoric. Time-boxing initial deployments, constraining customization to the edges, and protecting a stable, upgradeable core are not nice-to-haves. They are the mechanisms that force compounding. Without them, every new customer quietly fragments the product, and the organization accumulates entropy rather than advantage.

Where the piece feels underweighted is on how moats actually form in the 2026 timeframe.

The traditional platform moat, large inventories of bespoke integrations and proprietary primitives, made sense when software was expensive and slow to build. That world is fading. AI-assisted engineering is collapsing development time and cost, which means static platforms are easier to replicate and harder to defend. The connector layer, by itself, is no longer durable.

What compounds now is not the surface area of the platform, but the operational playbook behind it. The ability to repeatedly drive real 0→1 outcomes, transition those outcomes to 1→N scale, and feed the resulting learnings back into the system. Most critically, it is the accumulation of context and memory: entity maps, workflows, decisions, state, and institutional knowledge that make each deployment smarter than the last.

That “context layer” becomes a durable advantage for customers, much like data did in prior eras, but only if the system remains modular and upgradeable. Lock-in through rigidity is brittle; advantage through adaptability is not.

Finally, the article implicitly treats SaaS as the default endpoint business model. That assumption is increasingly questionable (and probably requires its own post based on the stock market events of this week!). As reliability improves and margins converge toward software economics, outcomes-based pricing becomes viable - first in hybrid form (platform plus outcomes), and increasingly outcomes-weighted over time.

The key distinction is that outcomes cannot simply be layered on top of bespoke delivery. The winners will be companies that can tie outcomes to platforms that genuinely compound, where each success lowers the cost and increases the reliability of the next one.

The real risk in enterprise AI isn’t forward deployment. It’s mistaking early momentum for durable leverage, and failing to design for compounding from day one.