Agents your developers build
The check sits inside the application your team wrote. The easy case.
Agents across the business
The agents you did not write
Ask a platform team how many agents are running in the company. Then ask someone in operations. The two numbers are never the same, and the gap is the interesting part.
Where the gap comes from
Most agent governance is a library. You import it, wrap your calls, and it checks things before they run. That works well, and for the agents your developers wrote, it's a reasonable answer.
The trouble is that it only reaches agents somebody deliberately built with it.
Meanwhile, someone in claims put together an agent in Copilot Studio without writing a line of code, because that's what the tool is for. Somebody in finance has one clicking through a supplier portal, because there's no API. A vendor shipped an agent inside a product you already pay for.
None of those imported your library. None of them ever will.
This gets worse on its own
The whole point of low-code agent builders is that people who aren't engineers can use them. They're succeeding at that. Which means the share of your agents that came out of a developer's editor is going down every quarter, not up.
So a control that only covers code your team wrote isn't holding steady at partial coverage. It's covering a shrinking slice of a growing estate.
The surveys already show it. In Gravitee's State of AI Agent Security 2026 report, organizations said that on average only 47.1% of their AI agents are actively monitored or secured. Some of that gap is agents that arrived through a door the governance tooling doesn't have a key for.
And it's the wrong slice. The agents your platform team built are the ones with careful engineers attached. The one somebody assembled in an afternoon to chase invoices is the one you'd actually want a policy check on.
What coverage has to include
Four shapes. Leave one out and you're back to a number nobody trusts.
Agents your business builds
Someone assembles a workflow in a maker studio. It never touches your repo, and its connected business actions still get checked against your rules.
Agents working through a screen
Filling a form, submitting a payment in a browser. Those actions connect to the same policies and the same review, with the screen context a reviewer needs.
Agents reaching your systems through tools
Connected calls arriving over MCP get checked where the work happens, not where somebody hoped it would.
Why this belongs in the same record
You could govern each of those separately. Some organizations do, and end up with four consoles and no way to answer "what did our agents do last quarter" without a spreadsheet.
It also reintroduces the failure Gartner points at, one console at a time. Uniform controls applied without regard to what an agent actually does, because each tool only sees its own slice and none of them can weigh an agent's ability to act against the access it's been given.
The reason to put them in one decision history isn't tidiness. It's that your compliance team, your risk owners and your auditors are asking questions about the company, not about a framework. "Show me every agent action over fifty thousand dollars that a person approved" is a completely normal question. If the answer depends on which tool the agent was built in, you don't have an answer.
Coverage isn't a property of your SDK. It's a property of your estate.
See what connects, and how
SDKs, Copilot Studio, computer use and MCP, all landing in the same decision history.