Gartner’s $234 billion - the pricing anxiety I wrote about in May now has a name

In my May roundup I described Salesforce running three pricing models simultaneously (per conversation, per action, per user) that reflected the fact that the market had not settled on how to purchase agentic outcomes. On July 1, Gartner estimated that up to $234 billion of enterprise application software spending is exposed to what it calls „agentic arbitrage“ between now and 2030, roughly 20% of enterprise application SaaS spending by the end of the decade.1

Agentic arbitrage is Gartner’s name for what happens when agents complete tasks across multiple systems and the humans stop opening the interfaces those systems charge seats for.

according to George Brocklehurst, Managing VP at Gartner, because agents deliver outcomes directly and some software apps simply become invisible. So, the link between user growth and revenue growth breaks (Gartner Says $234 Billion in Enterprise Application Software Spend Is at Risk from Agentic AI).

Two things are worth noting about agentic arbitrage.

First, the $234 billion is not spending that will vanish. It is spending that gets repriced away from seats, toward consumption and outcomes. That is exactly the transition Salesforce’s three parallel pricing models and Microsoft’s “seats as entitlement to consumption” are.

Second, we need to notice where the arbitrage happens. It pertains to AI agents completing work across multiple systems, so the value does not leak out of any single application. It leaks out of the seams between applications - the re-entering data, the “let me check in the other system.” Which means the companies most exposed are not the ones with the worst software. They are the ones with the least-designed processes spanning the most systems.

The seat model is not being killed by better AI. It is being killed by the process layer that will finally get an execution engine in the form of agents.

If you run a system of record, eg CRM, the question your 2027 budget should answer is no longer “how many licenses.” Instead it should be:

“Which processes will agents execute end-to-end, and what are we actually paying for when they do?”

The AI Act moved

In my first article I wrote that enforcement of the AI Act’s high-risk obligations begins on August 2, 2026 and that companies deploying agents on undocumented processes would “spend 2027 paying lawyers what they should have spent in 2026 paying process designers”. The first half of that sentence is now outdated and the second half aged better.

The European Commission proposed the Digital Omnibus on AI in November 2025. Parliament and Council reached provisional agreement on May 7, 2026. Parliament formally endorsed it on June 16, the Council gave final approval on June 29, and the final act was signed on July 8, with publication in the Official Journal expected before the original August 2 deadline, precisely so the amendment takes legal effect in time.2

And this change means slightly different and unclear things to the AI Act in Europe:

1. Some things are deferred

   Mainly, the heavy high-risk compliance machinery. Stand-alone high-risk systems under Annex III, the list that covers employment decisions, credit scoring, access to essential services now come due on December 2, 2027 (a 17-month extension). High-risk AI embedded in regulated products (Annex I) moves to August 2, 2028 (2 years).

2. Some things are not deferred

   Article 50 transparency obligations, disclosing to people that they are interacting with an AI system, marking synthetic content, labeling deepfakes, still take effect on August 2, 2026. So do the Commission’s enforcement powers over general-purpose AI models. Penalties in this tier reach 15 million EUR or 3% of global annual turnover, whichever is higher.

So, now, as of August 2, 2026, the timeline looks as follows:

Now if we read this change through Agentic CRM and Agentic Enterprise lens (service bots, voice agents, outbound sequences drafted by AI), then the obligation that applies to them is the one that was not delayed. The heavy machinery that got pushed to 2027 mostly governs a different class of systems.

The delegation gap is getting its own product category

In June I defined the delegation gap (the distance between the identity that requests an agent action and the identity that executes it) and I wrote that authorization, not hallucination, is the agent risk that actually materializes in production:

In July, the market started shipping infrastructure to cover that gap. On July 16, 1Password announced an integration that lets AI agents, starting with Anthropic’s Claude, securely use a person’s credentials without exposing those credentials to the model itself. It is de facto a dedicated credential layer for AI delegation - the agent can act as a user without ever holding what makes it that user.

So, secrets management for humans officially became a product category (Vault, Key Vault, 1Password). Credential brokering for agents validates the architectural claim underneath the delegation gap: the fix is not a more careful prompt or a more cautious model. It is a separate, auditable layer that owns the mapping between requesting identity and executing identity. Microsoft’s addition of Azure Key Vault credential management to computer-using agents in May was the platform version of the same move; 1Password’s launch is the cross-platform version.

If your AI agent still handles this with a service account that the agent uses for everything, you are on the wrong side of the tooling.

Agentforce goes shopping: agents enter the buying channel

The platform move of the month (actually announced in the end of June) came from Salesforce: Agentforce Commerce reached general availability, with three named agents (Shopper, Buyer, and Merchant)3 and planned native integrations into ChatGPT and Gemini channels.

The three-agent split maps to the three parties in a commerce transaction, but the integration plan is the strategic part. Salesforce is accepting that the conversation surface where buying decisions happen may not be a Salesforce property and is positioning its agents to execute inside someone else’s channel. That is the same logic as Gartner’s arbitrage argument, run in reverse: if outcomes detach from interfaces, then a vendor’s defensible asset is not the storefront UI. It is the agent that can check inventory, confirm the cutoff, and close the transaction against the system of record, wherever the customer happens to be typing.

For CRM practitioners this extends the migration path I described in May. Wave 1 was front-office copilots. Wave 2 was back-office operations (Agentforce Operations, April).

Wave 3 begins now, and it is agents operating in channels the enterprise does not own.

Every question from my previous articles about permissions, scope, and process ownership gets harder in Wave 3 because the execution environment is only half yours.

Summary of the current state of Agentic Enterprise

July was a pretty important month for Agentic AI.

The price tag indicates that the seat-license model incurs up to 20% of enterprise SaaS spending to agents who execute across various systems. This translates to a staggering $234 billion, highlighting the shift in value towards the process layer.

On the legal front, the transparency rules for customer-facing AI are set to take effect on August 2, 2026, while the complex high-risk machinery is deferred to December 2027.

Both stories reward the same behavior: knowing your processes well enough to know where the agents, the money, and the obligations actually are. The vendors will keep shipping, analysts will keep pricing and the regulators will keep deferring / enforcing. What is still optional for a few more quarters is whether your organization does the inventory before the incident does it for you.

On Sunday night, while most of the world was watching the World Cup 2026 final, an 87-year-old mathematical conjecture died.

The Jacobian conjecture, stated by Ott-Heinrich Keller in 1939 with roots going back to an 1884 paper by Ludwig Kraus, was one of the central open problems in algebraic geometry. Problem 16 on Stephen Smale’s list of mathematical problems for the 21st century. It is famous for two things: being simple enough to state to anyone who knows calculus and for the graveyard of published “proofs” that all turned out to contain subtle errors. For over eight decades, some of the best mathematicians alive tried and failed.

Then, on 20th July 2026, Levent Alpöge posted a polynomial map on X. Three variables, constant Jacobian determinant of −2 and three distinct points land on the same output. Non-injective and not invertible. Result is that the conjecture was shown false.

According to Alpöge himself, the counterexample was generated by Claude Fable 5.

Now, two narratives immediately occurred after this breaking math news:

Narrative 1:

“AI just solved an 87-year-old open problem. Mathematicians are obsolete. Everyone is obsolete.”

Narrative 2:

“It’s a stochastic parrot doing matrix multiplication. It got lucky. This means nothing.”

Both narratives are wrong and they are wrong in the same way. They erase the most important person in the story.

Who was actually at the keyboard

Levent Alpöge is not “a guy with a Claude subscription”. He is a world-class mathematician, who won the Morgan Prize (the award for the best mathematical research done by an undergraduate in America). His Princeton PhD work was in arithmetic geometry. In 2025 he co-authored the resolution of Hilbert’s tenth problem over rings of integers of number fields (a problem posed in 1900). He was a Junior Fellow at Harvard.

Then Alpöge decided to join Anthropic and to work on frontier models. So, the configuration that killed the Jacobian conjecture was not “a model”.

It was a world-class mathematician, working in a frontier lab, prompted by a question from another world-class mathematician (Akhil Mathew asked about the problem), working with the best model available with the depth to recognize a real answer when he saw one.

Alpöge described how it happened - the counterexample emerged from what he called the model “ideating about a bunch of random stuff.”

Random stuff is what generators produce, results are what humans filter

A reasoning model exploring a hard problem produces a bunch of random stuff. Wide, nonlinear search across a space of ideas. Most of it is noise. Some of it is nonsense that looks plausible and occasionally there is a candidate that might actually prove or close things.

The AI models are the generators. The frontier models are phenomenal generators, better than anything we have ever built. But a generator without a filter produces noise at scale.

Now, let’s see what the human filter did in this story:

1. Someone had to choose the problem

This is the part almost everyone misses. The Jacobian conjecture could plausibly fall to a counterexample: a concrete object you can write down and verify by direct computation. That makes it a fundamentally different target than, say, the Riemann hypothesis, which requires a proof, a different class of artifact and one that today’s models cannot produce for problems of that depth. Knowing which type of result is within a model’s reach, on which problem, is itself deep expertise. Alpöge didn’t point the model at a random famous problem. He pointed it at one where the achievable artifact matched the model’s actual capability.

2. Someone had to recognize the candidate

In a stream of “random stuff,” a specific polynomial map in three variables does not announce itself as historic. To a non-expert it would look like every other line of algebra the model produced. Recognizing that this one might close required an experienced eye, ideally one built over fifteen years of doing mathematics at the highest level.

3. Someone had to verify it

The Jacobian conjecture’s graveyard is full of proofs, long chains of reasoning where errors hide in subtle places. A counterexample is the opposite: verification is arithmetic. Compute the Jacobian determinant symbolically and it comes out to a constant −2. Substitute three points (0, 0, −1/4), (1, −3/2, 13/2), (−1, 3/2, 13/2) and they map to (−1/4, 0, 0). Non-injective map, constant nonzero Jacobian, conjecture false. I ran the check myself in SymPy because when you know the points, it takes seconds.

Knowing that this check suffices, and what it means, is pure and high level mathematics, not prompting.

Why I’m writing about this on a Substack about enterprise Agentic AI

The dominant enterprise AI narrative right now is Narrative 1 from above, dressed in procurement language: buy the best model, roll out the copilots, deploy the agents, and results will follow. The model will solve it.

Enterprise processes are not the Jacobian conjecture, but the structure of the problem is identical. An agent operating inside your order-to-cash process, claims handling, customer service dispatch, is a generator. It will propose actions. The questions that decide whether this creates value or damage are the filter questions:

• Who chose which process the agent operates on and whether it was the right one?

• Who defined what a correct outcome looks like?

• Who can verify that what the agent produced actually closes and catch the plausible-looking nonsense before it hits a customer or a ledger?

Those questions are not answered by a model.

They are answered by people who have spent years inside the process - who know where the bodies are buried in your CRM data, why the exception path exists for customers with gold status, or who decides on the outcomes.

Process depth is to enterprise AI what Alpöge’s 15 years in arithmetic geometry were to Sunday night - the difference between random stuff and a result.

This is why I keep repeating that agentic AI is a process engineering discipline, not a licensing exercise or a model thing.

The organizations that will capture value are not the ones with the most seats and best models. They are the ones that pair frontier generators with the deepest domain filters and treat the filter as the scarce asset, because it is.

Processes before prompts. Filters before generators. Always.

IMPORTANT NOTES:

1. The result is days old at the time of writing. There is no paper and no peer review yet, although the verification is elementary enough that multiple mathematicians have independently confirmed the computation.

2. Precision matters - the counterexample kills the conjecture in three variables and above. The original two-variable case, the one Kraus actually wrote down in 1884, remains open.

The attackers simply sent a message to Meta’s AI support assistant asking it to link a new recovery e-mail to the target account. The agent, rolled out in March with real operational privileges and marketed as delivering “solutions, not just suggestions,” did exactly what it was asked to do. It had the permissions to modify recovery e-mails and… it used them.

The agent did not hallucinate and it did not go rogue.

According to the company, the tool itself worked properly and functioned as intended, and the failure was a bug in a separate code path, which never verified that the e-mail address provided by the requester actually matched the account. The agent held execution privileges, and the one deterministic check that should have stood between its intent and the action was broken. Nothing in the conversation layer could compensate, because nothing in the conversation layer is built to.

In my last article (“The button that broke the agent”) I described a small, harmless failure, when someone clicked a button, upgraded Microsoft Planner to Premium, and as a result my agent went silent. Fail-stop, narrow scope, human in the loop. Thus, the failure cost me a few uncreated tasks and several minutes of debugging.

I promised to break down the engineering of the foundation agents stand on. This is the first piece of that foundation: authorization.

The Meta case is what fail-continue scenario that I warned about, at global scale. The agent doesn’t stop. It keeps executing with permissions nobody should have given it and completed actions for requesters nobody verified.

Hallucination is visible and over-authorization is not

The industry has spent three years training executives to fear the wrong failure mode.

A hallucination announces itself - a user reads a wrong answer, laughs or complains, screenshots it, sometimes posts it on LinkedIn. The feedback loop is measured in minutes. Embarrassing, sometimes expensive, but loud.

An authorization failure announces nothing. An agent with write access produces correct-looking outputs on top of an access model that is quietly wrong. Nothing looks broken. You discover the problem at an audit, or after an incident, and by then the question is no longer “did the agent perform the task correctly?” but “should it have been able to perform it at all?“

The 2026 data says this is now the dominant failure mode, not the edge case:

• Gravitee’s State of AI Agent Security 20261 (900+ executives and practitioners): 88% of organizations reported a confirmed or suspected AI-agent security incident in the past year. Only 21.9% treat agents as independent, identity-bearing entities. 45.6% still authenticate agents with shared API keys.

• The Cloud Security Alliance / Zenity research I cited in my May roundup: 53% of organizations had agents exceed their intended permissions.

• EY’s Responsible AI Pulse survey2 (975 C-suite leaders at companies above $1B in revenue, published October 2025): 99% reported financial losses from AI-related risks, and 64% suffered losses exceeding $1 million — conservatively averaging $4.4 million per affected company.

• Teleport’s 2026 research reports3 the single most persuasive delta I have seen this year: organizations enforcing least-privilege access for agents report a 17% incident rate; those without it, 76%.

The delegation gap

Traditional IAM answers one question: who is this user and what may they do?

An agent breaks that model in both directions at once because it inserts a second identity between the requester and the action:

1. The agent may hold more permissions than the human it acts for
   A seller asks the agent to summarize an account. The agent, running on a service principal with organization-wide read access, happily includes data from accounts that seller was never entitled to see. The human just used the agent as a privilege-escalation path, without even knowing it.

2. The action is attributed to the agent, not the human
   Audit logs show the agent’s identity did the write. Who asked? Why? Under what authority? The log does not say. And in most organizations it structurally cannot say: when 45.6% of teams authenticate agents with shared API keys, incident response cannot even determine which agent acted, let alone which human asked it to.

I call this the delegation gap. It’s the distance between the identity that requests an action and the identity that executes it. Every agent deployment has one.

In CRM systems the delegation gap is not an abstract security concern. It is the difference between an agent that respects your sales territories, your GDPR data-subject boundaries, and your Chinese-wall obligations and an agent that flattens all of them into one god-mode service account because that was the fastest way to make the demo work.

This is why we keep insisting that when we built our voice agent for Dynamics, the permission model was the longest single piece of work longer than the voice pipeline, longer than the prompts. Every tool call executes in the security context of the actual user, not the agent’s. If the seller cannot see the record through the UI, the agent cannot see it on their behalf through MCP.

Least privilege is necessary but no longer sufficient

Zenity’s research argues that least privilege alone fails for agents, because an agent can act within its granted permissions and still act wrongly - the Meta support assistant is the proof. Its permission to modify recovery e-mails was, arguably, correctly scoped for its job. The failure was not scope but verification: there was no independent, deterministic check that the requester owned the account, and no separation between conversational interaction and operational execution. Least privilege was satisfied and the account still fell.

The emerging answer, visible across Zenity, the OWASP agentic security work, and the NIST NCCoE concept paper on agent identity published in February, is a third authorization layer:

Not just who is this agent (authentication) and what systems may it touch (API authorization), but should this specific action execute, right now, under this policy, for this requester (action authorization).

Notice what that third layer is. It is not a model capability and it is not a system prompt.

It is deterministic code sitting between the agent’s intent and the system of record. It’s the same deterministic backbone I argued for in the 35.8% article, now applied to safety instead of workflows. Telling the agent to “be careful” in the system prompt is not a control. Prompts get overridden by injection, compacted out of long contexts, and eroded over multi-turn sessions. Caution is not an architecture. Neither is a system prompt.

What to do before your agent’s first audit

Regulatory pressure makes this concrete. The EU AI Act’s high-risk obligations become enforceable on August 2 (weeks from now) and a regulator examining an AI-involved incident will expect you to reconstruct what your agent did, for whom, and under whose authorization.

Five checks, in order of leverage:

1. Give every agent its own identity. No shared API keys, no reused service accounts.

2. Propagate the human’s identity to every tool call. The agent acts as the requester, within the requester’s entitlements. This is the single control that closes the delegation gap, and in most CRM platforms it already exists - impersonation, on-behalf-of flows, row-level security. Use them.

3. Enforce least privilege at the tool surface. API, table, record, field. Then assume it is not enough.

4. Add action authorization for irreversible operations. Anything that mutates state a customer would notice (sent, deleted, paid, changed) gets a deterministic policy check, and above a defined threshold, a human checkpoint outside the conversation.

5. Put the audit trail below the agent, not inside it. An audit layer embedded in the calling application disappears exactly when you need it. Log at the data layer, attribute both identities.

In my May roundup I quoted Gartner’s prediction that 40% of enterprises will demote or decommission their agents by 2027 not because the agents don’t work, but because of governance gaps discovered after an incident. The Permission Problem is that gap.

Your agent will pass every demo and it might pass the pilot. The question that decides whether it survives contact with production (and with a regulator) is not “does it answer correctly?” It is the question nobody asks until it is too late:

Not “did the agent do it right?” but “should it have been able to do it at all?”

If you cannot answer that today, you might end up with a delegation gap with agentic enterprise slogan on top.

Then someone upgraded the Planner plan to Premium by… clicking a button shown by Microsoft in the Planner web, stating innocently that this plan can be upgraded to premium. One button and a perfectly rational decision to access better features. The person who clicked it was acting in good faith and did nothing wrong.

And the agent… went silent.

The reason? A Copilot Studio agent can’t create tasks in Planner Premium the same way it can in standard Planner. I’m fortunate enough to know both sides of this, because this is the ecosystem I live in as a Microsoft MVP and a hands-on CEO. With Planner Premium, I need to bypass the standard out-of-the-box Planner actions and instead configure the agent to use Dataverse / Project schedule API actions directly, or build an Agent Flow in Power Automate that handles the proper Dataverse-backed task creation.

Fine - that’s a platform limitation, and platform limitations are not interesting. What’s interesting is the part I keep coming back to:

Shadow dependencies in production at their worst:
the person who clicked that button had no idea an agent was running on the other side of it

They didn’t break the agent out of carelessness. They broke it because, as far as the org was concerned, the thing the agent depended on wasn’t a foundation for an AI agent running somewhere else. It was just a setting - the plan still exists, it will now be a premium plan. Nobody had a picture of what was quietly using it and that it was my agent.

This is the reality of production AI.

The failure was ultimately harmless because the agent was narrowly scoped (but its goal is not achievable with “standard” automation) and highly supervised. It operated in a fail-stop paradigm with a human in the loop who noticed the missing outputs within 24 hours. The worst-case outcome was a few tasks that didn’t get created and my anger until I found out what caused the error.

When an agent is narrow and its dependencies are traceable, failures are cheap.

The danger of fail-continue

Now keep the exact same mechanism - a silent dependency on a layer nobody is monitoring, that anyone can change with one click - and apply it to an autonomous system.

Let’s consider agents everyone is now racing to build. Not a transcript-to-task helper, but autonomous agents working around the customer: reading the account, pulling context, deciding what to do next, and acting on it without a human watching each step.

If someone clicks a button like in our case, in a distant space, or if someone changes a single permission, migrates a list, or enriches a record, or even swaps a connector to a “premium” version, the autonomous agent does not go silent.

It experiences state drift and keeps running.

It keeps acting on the customer, except now it’s acting on a foundation that quietly shifted underneath it - a permission it shouldn’t have, a record that’s now incomplete, context that’s subtly wrong. It doesn’t stop. It makes decisions based on truncated data, elevated permissions it shouldn’t possess, or corrupted context.

There’s no “that’s weird” the next morning because nothing looks broken. The agent is functioning perfectly on top of a broken foundation. This is a fail-continue scenario, and it is the most dangerous state for an autonomous system.

Architecture over caution

The industry response to these risks is often a vague call to “be careful with AI.” This is a useless directive because caution is not an architecture.

The agent in my story did precisely what it was supposed to do. The autonomous one in the hypothetical does too. Neither of them is the problem.

The problem is that we are building autonomy on top of a layer we never decided to treat as a foundation.

We continuously expand agents’ capabilities by implementing deeper integrations, granting broader read / write access, and higher degrees of freedom. Yet, we implement zero architectural integrity in the ground it stands on.

An autonomous agent is exactly as smart, and exactly as safe, as the data layer beneath it. Giving AI agents more autonomy without giving them a grounded, governed, deliberately-owned foundation does not add features. It simply scales risk.

The foundation is inverted

The uncomfortable part is that the whole industry is now building top-down. Agent first because the CEO wants agents. Autonomy first because we have to have autonomous agents. Organizations prioritize the agent layer because autonomy is the strategic mandate, while treating the underlying data and integration layer as a secondary detail to be resolved later.

We are building the systems that act before securing and locking the environments they act upon.

Defining that foundation and engineering it so that no single user interaction can quietly shift the ground beneath an active agent is complex. It requires explicit data contracts, dependency mapping, and rigid state management. This is the actual engineering challenge of the AI era, and it is exactly what I will break down in the next article.

Leave a comment

On May 26, Gartner predicted that by 2027, 40% of enterprises will demote or decommission autonomous AI agents - not because the agents don’t work, but because of governance gaps discovered after a production incident. On May 27, Salesforce reported a genuinely strong quarter: Agentforce ARR is up 205% year over year. Despite this, its stock is down 30% year to date.

That is the agentic enterprise in May 2026, in one frame.

The money is real now, and so is the doubt about pricing models

For most of the last eighteen months, the agentic market ran on projections. May was the month the numbers got large enough that the debate stopped being abstract. Salesforce closed Q1 FY27 with Agentforce ARR at $1.2 billion, up 205% year over year. Combined AI and Data ARR reached nearly $3.4 billion (worth noting: that figure includes roughly $1.1 billion of Informatica Cloud ARR, so it is not all “agentic”). The company reported 3.8 billion Agentic Work Units delivered to date, up 111% quarter over quarter, and more than 28.6 trillion tokens processed, up 152% quarter over quarter. More than half of Agentforce and Data 360 bookings came from existing customers. It means expansion inside the installed base, not new logos.

And yet, just before the earnings, Bank of America reinstated coverage at Underperform with a $160 target, well below the ~$268 Street consensus, and named the structural fear out loud, calling it an “AI-driven structural reset.“ Salesforce built a $30-billion-plus business selling one seat per human. If agents do some of that human work, the seat model shrinks.\

This is the central tension of the agentic enterprise in 2026, and it is no longer theoretical. The companies selling agents are watching their own pricing model get questioned in real time. Salesforce’s response is to run three pricing models simultaneously:

• per conversation

• per action via Flex Credits

• per-user under the Agentic Enterprise License, plus the new Agentic Work Unit metric.

That’s a similar story to what I described in my previous article (“Microsoft’s 35.8% problem with Copilot is a category problem”) and what happens at Microsoft - trying to monetize the right model for work being done by agents.

Apparently, the market has not yet settled on how to procure agentic outcomes. Vendors are forcing customers to self-select, allowing us to watch the transition from deterministic software seats to probabilistic compute consumption play out live. (important note: a meaningful share of what vendors now report as “agentic” usage was running under different product names before the agentic relabeling. Gartner’s own term for the broader pattern is “agent washing.” The Salesforce numbers are real ARR, but the year-over-year comparisons sit on top of a category that has been redefined while it grew).

Governance stopped being a slide and became an operating problem

The most important number in May wasn’t financial. It was the above mentioned Gartner’s number about 40% of enterprises projected to demote or decommission autonomous agents by 2027, because of governance gaps found after an incident.

What makes the framing sharp is why Gartner says agents fail. Not because governance is absent, but because it’s applied uniformly. Treating every agent as either locked down or fully trusted produces two failure modes: over-restrict the simple agents and you slow delivery and push teams into shadow deployments. Under-restrict the autonomous ones and you discover the access scope was wrong only after the agent has already acted. Gartner’s distinction is between an agent’s ability to act and the scope of access it was granted. Most enterprises aren’t separating the two.

The supporting data from this year is bracing.

A Cloud Security Alliance study (published April 21) found 65% of organizations had at least one cybersecurity incident in the past year caused by an AI agent2.

A separate CSA study with Zenity found 53% had agents exceed their intended permissions and 47% experienced an agent-related security incident. Across these surveys the recurring theme is identical: the risk is not the model hallucinating.

The risk is the agent being too good at executing something it should never have been permitted to do, gaining write access it was never scoped for, taking actions nobody authorized.

If you’ve read my previous articles, you know this is the argument I keep returning to: in production, governance is not a legal document, it’s a permission model expressed in code. May was the month the analyst forecasts and the breach data caught up to it.

Microsoft moved the architecture ceiling just before Build

While the market focused on the June 2 Build keynote, the most consequential news for enterprise agent builders actually shipped in May. On May 13, computer-using agents reached general availability in Copilot Studio, rolled out across all commercial Power Platform geographies (sovereign clouds excluded). These are agents that operate websites and desktop software through the UI rather than through APIs. That matters more than it sounds, because most enterprise software does not expose a documented API for the operations employees actually do all day. The GA build added secure credential management (Azure Key Vault), model choice across OpenAI and Anthropic, Purview audit logging, configurable human-in-the-loop review, and the ability to embed these agents directly into multi-step workflows.

When combined with April’s Work IQ intelligence layer, which provides organizational memory and enables Agent-to-Agent (A2A) communication, Microsoft’s direction is clear. The company is packaging the grounding, Dataverse integration, and coordination plumbing into a managed surface. Context reasoning and agent delegation are becoming native Microsoft-operated layers, eliminating the need for teams to stitch together custom cognitive architectures.

Salesforce pushed agents into the back office

The other notable platform move came at the end of April and shaped the May conversation: Agentforce Operations went generally available on April 29, built on the platform built by Regrello acquired by Salesforce and aimed at back-office bottlenecks, ie. process coordination, data verification, compliance clearing, approval chasing, rather than the front-office customer interactions where agentic CRM started.

This aligns with the migration path we have tracked for months. The first wave of agentic CRM focused on sales and service copilots. The second wave is everything behind them: the unglamorous operational tasks where work actually stalls. By framing this as the “agentic enterprise,” Salesforce is acknowledging a core truth: the durable ROI of AI is not a smarter chatbot, but the total redesign of the underlying business processes.

What it adds up to

May 2026 was the month the agentic enterprise stopped being a forecast and became a balance sheet, with all the scrutiny that brings.

The revenue is becoming real. The pricing model is genuinely unsettled, and the market is pricing in that uncertainty. The platforms keep raising the architectural ceiling: computer use at GA, managed grounding and agent-to-agent coordination, back-office process automation. Simultaneously, the governance reckoning is here. Unexamined access scopes are leading to real-world breaches, guaranteeing that a significant percentage of today’s agents will be pulled offline by 2027.

The dividing line between the AI agents that survive their first security incident and those that are quietly decommissioned remains exactly what it has always been: whether the engineering team defined the boundaries in code before the agent went live, or waited to discover them after something broke.

The diagnosis is the easy part but the harder question, and the one that I try to address in this article, is what actually engineering a real agent should look like and how it’s different from dragging and dropping steps on a beautiful canvas.

Demo works, pilot works… production doesn’t. The post-mortem usually ends with the word “hallucination.” That word does a lot of unhelpful work, because it makes the failure sound like it was the fault of LLMs. In reality, it is the lack of LLMs in the right places and missing engineering decisions.

That is the topic of this post - the engineering decisions nobody is making, and why the easy drag and drop “agentic” platforms are not going to make them for you.

The democratization that nobody warns about

In 2019 I wrote an article about risks of AI democratization titled “Why are progressing AI democratization and data-first approach not necessarily good things?” (https://medium.com/data-science/why-are-progressing-ai-democratization-and-data-first-approach-not-necessarily-good-things-50220607c453). At that time we were not even talking about Generative AI and its risks…

And today, the situation with democratization is even stranger - Microsoft Copilot Studio shipped voice agents last year, Salesforce Agentforce 3 is in market, ServiceNow finished its Knowledge 2026 conference in May 2026 telling its audience that every Now Assist workflow is an agent now, HubSpot ships Breeze, SAP ships Joule, Workday ships Illuminate.

The barrier to assembling an agent has fallen through the floor. That is good news but it also is the source of the trap.

However, it’s worth pointing out that what got democratized is the assembly layer.

The architecture, the governance, the evaluation, the production engineering - none of that got democratized.

That work still has to be done by humans who understand how a language model actually breaks, what a tool call’s failure modes are, and what “permissioned” means when an autonomous process is acting in your CRM at 3am without your involvement.

When the assembly is easy and the engineering is hard, you get a market saturated with people who can configure an agent and a real shortage of people who can engineer one.

That gap is the single most expensive mistake I am watching enterprises make this year.

The work that didn’t get democratized

The agent platform vendors will keep making assembly easier. Copilot Studio will keep adding orchestration primitives, Agentforce will keep adding workflow types, and startups like Sierra will keep raising.

The bottleneck is the gap between people who can assemble an agent and people who can engineer one. It determines who ships and who pauses.

It determines which Microsoft and Salesforce partners actually deliver enterprise value and which ones generate beautiful slideware. And it determines, in our own market, which Dynamics 365 implementations move from “Copilot-enabled” to “agent-mediated”, which is the move every executive reading this should be planning for.

The platform is necessary but it’s the discipline that is often missing. Most teams will keep buying platforms and skipping the discipline, because the platform is what gets sold and the discipline is what needs to get done quietly and it’s not sexy.

Five engineering competencies that are needed to build an AI agent

I have been arguing this for months - what separates the partner who ships a production agent from the partner who ships a brilliant demo is not the model, not the platform, and not the prompt. It is five concrete engineering competencies that have to be present in the building team:

1. Fundamentals

Fundamentals include knowing what an autoregressive model actually does, what context rot looks like in a 200k-token window, what the difference between a hallucination born of insufficient retrieval and one born of conflicting tool outputs is. Also, knowing which reasoning pattern (eg. ReAct, plan-and-execute, reflection) your workflow actually needs. Without this, every architectural decision downstream is cargo cult.

2. Architectural choices

Anthropic’s December 2024 essay “Building Effective Agents” is the best piece of writing in the field on this point and remains required reading. Its central, unfashionable claim is that in the large majority of cases, a single well-tooled agent beats a multi-agent system. Most enterprise AI architecture decks I see right now assume the opposite. Consultants draw seven boxes connected by arrows because seven boxes look serious. And those seven boxes are usually seven failure modes you have not thought about yet.

3. Governance and safety

Permission models that follow least-privilege for the agent’s tool surface. Human-in-the-loop checkpoints at the points where the agent’s actions become irreversible. Audit trails that are forensic, not decorative. Rate limits, cost limits, and a kill switch that someone actually knows how to use. This is the single biggest gap in every enterprise project I have reviewed this year. Most teams think governance is something the legal team writes. In a production agent system, governance is code.

4. Understanding evals and eval-driven development

Hamel Husain has done more than anyone to make this its own discipline, and his insistence that you cannot improve what you do not measure is the right insistence. Real evals for real and useful AI agents are hard and they might require:

• golden datasets

• LLM-as-judge with calibrated rubrics

• regression tests on every prompt change

• A/B in production with task success, cost per task, human-intervention rate as three most important metrics

Without this you are building in the dark and shipping by vibes. Ask any “agent builder” in a random enterprise and you’ll be surprised that they don’t even know what these things are. The fact is that most enterprises right now are shipping by vibes.

5. Production engineering

Apart from proper CI/CD for agent deployment there are also tasks needed where an agent is ahead in production. These are hard tasks that very few current agent builders have a clue about:

• idempotency on every tool call that mutates state

• retry logic that distinguishes a transient failure from a logically failed step

• state persistence and checkpointing so that an agent run can resume rather than restart

• observability through Langfuse, LangSmith, Arize, or whatever your stack chooses, but observability that actually answers the question “What was in the agent’s context when it made that decision?”

This is the boring layer that determines whether your agent survives its first incident and will be useful in production or it will end up as a nice demo for the board.

A word on protocols

The five competencies above assume a stack where tool calls, memory, and agent-to-agent handoffs can actually be made to work in production. That stack is finally getting standards. MCP, Anthropic’s Model Context Protocol, has reached critical mass as the interop layer between agents and the tools, data sources, and resources they need to act. Microsoft shipped MCP support across many products and platforms last year. Google’s A2A (Agent2Agent) is the emerging protocol for agent-to-agent coordination.

This matters more than it sounds. It is the difference between an agent locked into one vendor’s connector library and an agent that can speak to your whole stack without a separate integration each time. It is the difference between a multi-agent system whose handoffs you have to invent and one whose handoffs follow a protocol your governance team can audit.

The real life cases

We have been in intelligent automation for a long time, mostly working within the CRM space, where automation touches either customers directly or processes involved in how companies manage their customers. In 2023 one of our projects (a natural language bot for insurance) was selected by Microsoft as one of the most transformational globally and was featured at their conferences and on Microsoft product websites.

We do not ship intelligent automations, bots and AI agents because the platform let us. We ship them because we ran the five competencies listed above for months before our agents touch any process.

In our work we also learnt the following lessons:

1. Governance is harder than the model. Building the permission model so that the agent could not touch records the user or customer was not entitled to was the longest single piece of work in the project, and the most consequential.

2. Evals are what made improvement compound. Every prompt change ran against a golden set before it merged.

3. The architecture starts single-agent on purpose. We tested a multi-agent version and watched coordination overhead consume the latency budget. We ship the simplest architectures possible in terms of governance, multi-agency and observability.

Conclusion and suggestions

So when your board asks where the AI agents are, and which platform you're buying, point them to a better question:

"Who on this team can engineer an agent, not just assemble one?"

The discipline is the part that gets skipped, because it's quiet, unglamorous, and invisible on a slide. That's exactly why it's the new moat. The teams closing the gap between assembling an agent and engineering one aren't waiting for a better canvas. They're doing the unglamorous work behind the UI that the SaaS “agentic” platforms will never do for them.

Tom was reacting to a deleted post by Jacob Andreou, Microsoft’s new EVP of Copilot. The wider context: Windows and Apps teams (Notepad, Snipping Tool) had quietly stripped Copilot branding from Windows 11 a few weeks earlier.

Also, a few days earlier, Satya Nadella mentioned that “the seat-based pricing is just entitlement to some consumption”.

It might look like Microsoft’s AI bet is wobbling.

However, the correct reading is probably that Microsoft is the first enterprise software vendor-turned-hyperscaler publicly admitting that prompt-as-a-product has a structural ceiling and that the next phase of enterprise AI value will not be unlocked by Copilot in every product, but by agents inside every process.

The AI adoption numbers that should be on every executive dashboard in 2026 Q2

1. Microsoft now has over 20 million paid Microsoft 365 Copilot seats, and that would sound fantastic if not the fact that over 450 million people use Microsoft M365 every month. That means that only 4.4% of them use paid Copilot. Three years after huge launch and tens of billions of capex spent, fewer than 1/20 Microsoft 365 commercial users pays for Copilot.

2. According to Recon Analytics' survey of 150,000+ U.S. respondents published in the report titled “AI Choice 2026: Why Licenses Don’t Equal Adoption”1 Microsoft Copilot's workplace conversion rate stands at just 35.8%, while ChatGPT converts at 83.1% workplace usage. Gemini is at 34%. A 47-point gap, so whatever is going wrong did not happen in the model layer.

3. Of users who tried Copilot and stopped, 44.2% cite distrust of Copilot’s answers as the primary reason - higher than ChatGPT (40.6%) or Gemini (42.8%). Recon’s accuracy NPS for Copilot deteriorated from −3.5 in July 2025 to −24.1 in September, recovering only partially to −19.8 in January 2026.

So, the natural question is why is M365 Copilot so poorly perceived, considering it’s essentially ChatGPT (OpenAI’s models) integrated into an enterprise product? It’s the same model but there is huge difference - ChatGPT is used by knowledge workers on a blank page where intent is declared in natural language. Microsoft Copilot meets that same worker in every possible place and every possible app, from a SharePoint site built in 2008, an Excel file with seven hidden tabs, in a Word document with suggestion to sum up a document not yet written, to a CRM form designed in 2013.

I took part in two workshops in April for clients who planned to resign from Copilot (several hundred users each), quoting “lack of usability” as the main reason. We ran a series of meetings during which we showed what Copilot Cowork can do and how Copilot custom agents could be embedded into processes, rather than forcing users to go to Copilot chat windows. It worked. The customers stayed and engaged us in further process redesign to increase Microsoft Copilot adoption. It’s twelve months after they bought hundreds of licenses from a “licensing partner” disguised as an “AI company”, during agreement renewal. A bit late.

The 35.8% problem is a category problem, not a Microsoft problem

It is a process problem masquerading as a Microsoft problem. Salesforce has the same problem, ServiceNow has it too. So does HubSpot, Oracle, SAP and Workday - you name them. Every system-of-record vendor is now shipping agents over data models designed before the agents existed. They and their customers will quickly discover that the agent’s adoption ceiling is set by the data model and the business workflow, not by the LLM.

Klarna learned the dark version of this lesson the expensive way in May 2025, when its CEO, Sebastian Siemiątkowski, publicly walked back the full AI customer-service replacement and started hiring humans back: “investing in the quality of human support is the way of the future for us.” The lesson is not that AI failed.

Companies that will win value from agentic AI in the next 24 months are the ones that stop treating AI as a feature and start treating it as a forcing function for redesign. The ones that don’t will be running M365 Copilot pilots, wondering why their 35.8% never moved.

Why no amount of prompt engineering will close the 47-point gap

Here is the thing nobody wants to say out loud at AI conferences:

enterprise work is not prompt-shaped - it is process-shaped.

A typical B2B seller does not want to ask questions in a chat window - he/she has a 16-step renewal workflow embedded in a CRM and spanning through Teams and SharePoint lists.

A claims adjuster does not have a question - he/she has a regulator-defined sequence with mandatory legal capture and a hard SLA.

A contact-center agent does not have a question/response need - he/she has a script, a compliance checkpoint, and a quality scorecard.

The blank page that makes ChatGPT magical for individuals is exactly what makes Copilot frustrating for enterprise users.

For an agent to create value at work, several things have to be true at once:

• An intent must be declarable in natural language by a human or another agent

• The agent needs a permissions-aware environment because it must act in the system of record, with the right scope, on behalf of the right identity

• There has to be a deterministic backbone behind the stochastic narrative

This is exactly the architecture that vendors must start converging on. At TrailblazerDX (TDX) 2026 in April, Salesforce open-sourced Agent Script, an agent definition language built as Madhav Thattai, COO of Salesforce AI, had explained - precisely because LLM reasoning wavers as workflows get more complex (an interview at Salesforce Ben from January 2026 titled “Is Salesforce Losing Confidence in LLMs?”) 2

Decagon ships the same idea under the label Agent Operating Procedures.

The pattern across both: LLMs handle communication and intent; deterministic code handles execution and guardrails.

Working with AI is a different shape of work

Capturing voice straight into Dataverse or Salesforce CRM instead of asking a seller to open a form is not a feature - it is a different shape of work. Microsoft’s latest natural voice features, including Hands‑free note capture in the Sales agent in Outlook mobile might be the first official acknowledgment from Redmond that the form itself is the bottleneck.

The customers who insist on preserving the existing form of work will get a beautiful demo and a stalled rollout. The difference between a pilot that converts and one that dies is almost never the model. It is whether the customer was willing to redesign the underlying process.

Sangeet Paul Choudary made the architectural point cleaner than I can in his February 2026 HBR article3:

“AI’s greatest economic impact will come not from automating tasks but from dramatically lowering the ‘translation’ costs that keep teams, tools, and data from working together.”

In an AI-adopting company, the person is the node and AI is the tool. In an AI-native company, the system itself is the node, and work gets redistributed to wherever intelligence, human or artificial, is more effective.

Sarah Wang at a16z, in Big Ideas 20264, calls the same shift the moment:

“the traditional system of record slips into the background as a commodity persistence tier — its strategic leverage ceded to whoever controls the intelligent execution environment employees actually use.”

Microsoft is reorganizing to better align with industry needs (and to catch up?)

On March 17, Mustafa Suleyman moved off day-to-day Copilot product leadership to focus on what Microsoft now labels “Superintelligence.” Jacob Andreou, formerly SVP at Snap, then CVP of Product and Growth at Microsoft AI, was promoted to EVP of Copilot, reporting directly to Satya Nadella.5

Exactly two weeks later, on March 31, Mary Jo Foley wrote her GeekWire post, “What the heck is going on with Microsoft lately?”, which was a polite way of asking the question everybody from the industry was already asking.

Then, on April 27 the Microsoft / OpenAI agreement was restructured:

• non-exclusive license through 2032, AGI clause removed

• OpenAI free to ship in any cloud, Microsoft’s revenue share to OpenAI ended

• OpenAI’s share to Microsoft capped through 2030

The default media quote is that Microsoft is “losing the AI race”. There's also a reading where this is retreat, not strategy. I think the strategic reading is closer to the truth, although both are partially true. I am in the camp that Microsoft is resetting the value model from Copilot in every app to agents in every process. And it is doing it in front of us on the living organism, after M365 Copilot adoption sucked billions and did not bring significant market penetration.

The questions that we need to answer in 2026

The HFS Research and Genpact study released the same day as Microsoft’s earnings call „Autonomy Requires Trust in AI“6 found that 33% of respondents identify business processes not ready for agentic integration as the leading barrier to scaling agentic AI. So, process readiness, not data, not governance, not talent, is the number 1 obstacle.

The important questions that come to my mind:

1. Which 3 of your top 10 business processes will not exist in their current form in 24 months?

2. Where is your system of record investing - in better forms, or in agent-mediated intent capture?

3. Who is the owner of each process you want to extend with agentic AI?

Eight times out of ten the answer is like, “Well, we have different processes, what do you mean?“

That pause is where most agent projects die before they arrive - in the gap between what a company thinks its process is and what its process actually is.

This is my first post on this Substack and the title is also the thesis. Processes Before Prompts. I’ve been saying it to clients for some time, when we started do help with intelligent automation and later with building agentic capabilities. Time to write it down because the decisions made over the next 12 months will determine whether your firms come out of the agentic era as what Microsoft calls Frontier Firms or as the next generation of cautionary case studies titled “We tried AI, it didn’t work”.

Important numbers about agentic AI

According to MIT1, mid-2025: 95% of corporate generative-AI pilots produce no measurable P&L impact.

McKinsey’s „The state of AI in 2025: Agents, innovation, and transformation“2 shows that 88% organizations report regular AI use in at least one business function and 39% report EBIT impact at the enterprise level, whilst only 6% of organizations qualify as “high performers” who see significant enterprise-wide value.

BCG in their “The Widening AI Value Gap”3: 60% companies are reaping hardly any material value, reporting minimal revenue and cost gains despite substantial investment.

IBM’s CEO study “Rewiring the C-suite: The fast track to 2030”4: 16% of AI initiatives have been scaled enterprise-wide and only 25% have delivered the expected ROI.

Gartner forecasts that by the end of 2027, more than 40% of agentic AI projects will be cancelled, killed by escalating costs, unclear business value, and lack of risk controls.

So, it looks like a pattern.

It is the same disease that was causing CRM failures

Technology was never the bottleneck. Processes were.

In 2026, we are about to make exactly the same mistake like many companies did with treating CRM systems as software, not strategy. They license a platform, contract a partner to „implement it“, instruct users to “use“ the system, and 6 months later wonder why adoption is flat and the pipeline forecast is still being managed in Excels.

This time, however, the mistake will be more expensive, faster and with dramatically higher consequences. Because an agentic CRM does not behave like a traditional CRM. A traditional CRM is a passive system of record - it lets you store data. An agentic CRM is a system of action, which executes actions on this data. And it executes whatever process it was handed. If you haven’t handed it one, it improvises off the mess.

As Bill Gates once said, automation applied to an inefficient operation will magnify the inefficiency.

The agentic enterprise, what Microsoft has rebranded as the Frontier Firm, is not a software upgrade. It is a deliberate and controlled re-design of a process.

Processes before prompts

Processes Before Prompts means that before any company deploys an AI agent into production, three things have to happen and they have to be owned by the business and not by IT.

The first is that the process has to be discovered, mapped, and named. Not the imagined process from the playbook, bu the actual process, observed in the data. Process-mining tools such as Celonis, Microsoft’s own Power Automate Process Mining, SAP Signavio exist because most companies do not know how their work actually flows. Wil van der Aalst, Chief Scientist at Celonis, ran a tutorial at the 28th European Conference on Artificial Intelligence 2025 titled “No Enterprise AI Without Process Intelligence! Using Process Mining as the Lens to Address Performance and Compliance Problems”. The argument is that an agent without process context is an autonomous actor in a building with no floor plan.

The second is that the process must have a human owner with the authority and the budget to redesign it. Not a “champion“ and not a “stakeholder” - an owner. McKinsey is clear on this, stating that of the 25 organisational attributes they tested, the one most strongly correlated with measurable EBIT impact from generative AI is workflow redesign. AI high performers are more than 3x more likely to fundamentally redesign work than the rest. Direct CEO involvement in AI governance is the second strongest variable. Implementing AI is not a technical project. It is a leadership project, and the one of the causes of failure is treating it as a technical one.

The third is that the process must be instrumented for measurement before the agent is deployed. You cannot improve what you cannot see. You cannot trust an agent whose outputs you have nothing to compare to.

Bill McDermott of ServiceNow opened his Knowledge 2026 keynote on Tuesday with a story about an AI agent hitting a credential error and deleting the entire production database in 9 seconds at one of the startups. McDermott's conclusion is concise:

Governance isn't a feature, it's the whole ball game. Because without it, your whole company can come down.

Here we arrive at the three main pillars: discovery, ownership and telemetry.

Specifically about agentic CRM

I run a firm that has been implementing enterprise CRM systems since 2008 and now builds agentic CRMs on the Microsoft stack. Our voice agent connected with MCP servers is already in the future - it can take meeting notes in natural voice, link opportunities to quotes, generate tasks based on meetings and customer overlook - all permission-aware, all anchored in the actual CRM record. We did not build that without first defining with the customer what a qualified opportunity means, where tasks are stored and who owns the conversion.

Every week we educate our clients and potential clients that giving every salesperson an AI agent, when they are not even consistent when a specific sales stage should switch, is not a strategy. It is a delegation of strategy to chaos, potantially with a Microsoft Copilot or Salesforce Agentforce logos on top.

Building an agent is just new programming, a technical task. A fairly easy piece for experienced developers and AI practitioners. Aligning on the process and building a helpful agent is the hard piece.

Salesforce’s assessed agent performance honestly in their own paper from 2025. On their CRMArena-Pro benchmark frontier LLMs scored 58% on single-step CRM tasks and 35% on multi-step ones. 35% on multi-step workflows is, as one analyst put it, a non-starter for enterprise. And that was in laboratory conditions without the technical debt of a real organization.

The European (and Polish) angle

I am writing this from Warsaw and most of the leaders and our clients reading this run businesses across the world. The Polish and European context shows the urgency. According to Eurostat only 8,4% of Polish enterprises had adopted any form of AI in 2024. It is the third-lowest figure in the European Union. And yet the Polish edition of Microsoft’s Work Trend Index5 reports that 84% of Polish business leaders plan to deploy AI agents within the next 12 to 18 months, slightly above the global average. We are, in other words, about to leap from one of the lowest AI adoption rates in Europe to mass deployment of autonomous systems in 12 months, on top of companies that have not done the process work.

Add the EU AI Act, whose enforcement against high-risk systems begins on 2026-08-02 and Article 22 of the GDPR, which already prohibits significant decisions taken solely by automated means without meaningful human oversight. Add the overlapping NIS2 obligations across regulated sectors.

Companies that introduce agents on undocumented processes will probably spend 2027 paying lawyers what they should have spent in 2026 paying process designers.

What to do next?

Stop implementing AI agents, because “everyone does that”. Instead, ask each business unit owner two questions:

1. In which of our processes do we want an agent to operate?

2. Can we describe that process in enough detail that a new hire could perform it on day one?

If the answer to the second question is no, you do not have a process.

Designate a single accountable owner per process, not per agent. Agents will multiply, retire, and be replaced by better agents with better model next quarter. Processes are durable and their owners outlive tools. That is the lesson of twenty five years of my CRM history applied to the next decade of agentic history.

Treat the AI Act not as a compliance enforcement but as a discipline-forcing one. Article 14, with its requirement for “human oversight” of high-risk systems, read correctly, is an instruction: know your process well enough to know where the human belongs in it. This could mean that companies that take this seriously will end up with better agentic AI than their American competitors whose board members pay for AI with their credit cards without proper process redesign first…

Conclusion

Microsoft’s 2026 Work Trend Index summarises the moment in a sentence I have already quoted at several boards: “the workers are ready; their organisations are not”. Jared Spataro, who runs Microsoft’s AI at Work efforts is right - the constraint on the agentic enterprise is no longer what the AI can do. It is how we have structured the work around it.

The companies that come through the next 18 months will not be the ones with the best prompts, or the most agents, or the largest token budgets. They will be the ones whose CEOs and COOs decided, before the rest of the market did, that the answer to the question “which model should we pick?” was always “how does the process really work?”.

Processes Before Prompts. Welcome to my Substack. Subscribe if you’d like to argue.