Skip to content
← BlogStrategyAnalysis6 min read

40% of enterprise apps will ship an embedded agent this year — governance isn't the easy part

Gartner's forecast that 40% of enterprise apps will feature task-specific AI agents by end of 2026 is on track, but uniform governance is what actually fails.

By Gabriel Lara, Developer Relations, Norbelys

Founder-reviewed ·How we research and correct articles

A year ago, Gartner put a number on something most people building software could already feel happening: by the end of 2026, 40% of enterprise applications will ship with a task-specific AI agent embedded in them, up from under 5% in 2025. That’s not “companies experimenting with an AI feature” — it’s the default expectation shifting to “the CRM, the ITSM tool, the ERP module ships with something that acts on your behalf, out of the box.”

The more useful follow-up came nine months later, and it’s less flattering. In May 2026, Gartner warned that by 2027, 40% of enterprises will demote or decommission autonomous agents they’ve already deployed — because the governance gaps only get identified after a production incident. The adoption curve and the governance curve are not moving at the same speed, and the gap between them is where the actual risk sits.

The mistake Gartner says everyone is making

“Enterprises are treating AI agent governance as binary, either locked down or fully trusted, and that is the root cause of failure,” said Shiva Varma, Senior Director Analyst at Gartner, in the same release. The failure mode runs both directions: over-restrict a simple, low-stakes agent and you slow delivery until teams route around it with unsanctioned tools; under-restrict a highly autonomous one and you’ve handed it operational, security, or compliance exposure nobody signed off on. An agent that summarizes a document and one that sends emails, modifies records, or triggers a workflow are not the same risk, but a lot of governance policy is currently written as if they were.

What “governance isn’t keeping pace” means in practice

Strip the analyst language and three concrete gaps show up whenever an embedded agent does something wrong:

Accountability. When a human employee makes a bad call inside a piece of software, there’s a name attached to the action and a manager who owns the outcome. When an embedded agent takes an action a vendor built and your team merely enabled, “who’s accountable” splits three ways — the vendor who shipped the agent’s default behavior, the admin who turned the capability on, and whoever approved the workflow it operates inside. Most contracts and internal processes were written before this question needed an answer.

Audit trail depth. Traditional application logs capture what changed. An agent’s consequential decision is often the reasoning that led to the action — which records it considered, why it picked one path over another, what it decided not to flag. A log line that says a record was updated at a timestamp doesn’t reconstruct why an agent updated it, which is exactly the information you need during an incident review.

Uniform controls on non-uniform risk. This is Varma’s point directly: a permissions model built for “the agent is on or off” can’t express “this agent can draft, but not send” or “this agent can read the pipeline, but not modify a deal stage above $50k.” Buying or building agent-embedded software without that granularity available is buying the binary-governance failure mode by default.

What to actually check before you buy or ship

If you’re evaluating agent-embedded software — or deciding how much autonomy to give one you’re building — the governance gap turns into a short list of concrete questions:

  • Does the vendor log enough about why an agent acted, not just that it acted, to support a post-incident review?
  • Can you scope what the agent is permitted to do at a granularity finer than “on,” short of writing custom code to enforce it?
  • Is there a fast, obvious way to pause or revoke an agent’s ability to act, separate from turning off the whole feature?
  • Who, contractually, owns the outcome of an action the agent took inside a workflow your team approved but didn’t individually review?

None of these are exotic asks. They’re the same governance questions any new automation earns before it touches production data — AI agents just make the answer matter faster, because the volume and speed of what an agent can do outpaces what a human reviewer can watch in real time.

A few things worth clarifying

Does 40% by end of 2026 mean nearly half of all software will act autonomously?

No — Gartner's figure covers task-specific agents: narrow automations handling one job inside an application, like triaging a support ticket or drafting a summary. It's a much bigger jump than the under-5% baseline from 2025, but 'embedded agent' spans everything from a low-stakes autocomplete-style helper to something that can modify records on its own, and the governance questions differ sharply across that range.

Isn't this just normal software governance with an AI label on it?

Mostly the same discipline, with one real difference: traditional software logs what changed, and that's usually enough to reconstruct why. An agent's consequential decision often lives in reasoning that a standard change log doesn't capture, which is why 'log what changed' isn't sufficient on its own for agent-embedded features the way it was for deterministic automation.

Where this lands for a sending program

The same logic applies to any AI step inside your own outreach stack, not just the big enterprise software categories Gartner is forecasting about. If an agent is drafting copy, choosing send timing, or touching your contact data, the guardrails around what it’s allowed to do to a sending domain and where the line sits between an agent and a human’s judgment on your CRM data aren’t abstract governance theory — they’re the difference between an agent that saves your team time and one that becomes the incident Gartner’s 2027 number is describing.

Ask the same four questions of Norbelys specifically, and the answers are concrete rather than aspirational. Consequential actions — sending, launching, resuming, deleting, erasing, archiving — carry an explicit confirmation requirement in the agent tooling itself, not a policy document someone has to remember; an agent can draft and stage a campaign, but a human is the one who launches it. API keys can be scoped down to specific resources and actions instead of granted as a single all-or-nothing credential, which is the granularity Gartner’s research says most agent governance is missing. And an agent’s proposed campaign doesn’t get treated as done on creation — an audit pass checks its steps, audience, and rendered output before launch, which is closer to a reviewable decision trail than a log line saying a record changed. None of that makes an AI layer risk-free. It’s what “governance that isn’t binary” looks like when it’s actually built into the product asking the questions, rather than left to whichever team remembers to ask them — and it’s the standard worth holding Norbelys, or any tool embedding an agent in your outreach stack, to before it’s the incident Gartner is forecasting.