77% Can Inventory Their AI Agents. 44% Can Verify It.

A survey of 700 engineering leaders found 77% say they can inventory every agent in production, while 44% run tooling that could verify it.

The figures come from Harness's State of Agent DLC 2026 report, published September 10, based on research Sapio Research conducted in July across the US, UK, France, Germany and India. Two pairs of rows carry the whole story.

The confidence gap, in four numbers

Claim	Share of respondents
Confident they hold a complete inventory of every agent, MCP server and LLM in production	77%
Run active discovery or inventory tooling that could verify it	44%
Believe they could disable a misbehaving agent in under 15 minutes	76%
Have an instant kill switch in place	33%

Read the rows in pairs and the pattern is the same twice: roughly three quarters of teams are confident about a property, and roughly a third to a half have a running system that could establish it.

Harness reduces the test to one question in its accompanying post: "What, specifically, would surface an agent nobody registered? If the answer is a process rather than a running system, you are describing an intention."

Why a registry is not an inventory

The distinction that makes those numbers concrete is between a database row and a live check.

A developer writing about the same survey walked through a version of the bug in their own product. Sessions registered a row when they started and got a close timestamp when the process exited. Until a September 12 release, that timestamp was the entire liveness model: no close timestamp meant live.

The failure modes are the ordinary ones. A laptop that went to sleep, a kill -9, a machine that lost power, a process that never got to send its close call — each left a row that said online, indefinitely. As the write-up puts it: "The inventory was complete. It was also wrong, and nothing in the system could tell you which rows were wrong. That is the 77% column."

The fix was to ask a running system instead of trusting the absence of a timestamp. Three details in that design generalize beyond one product:

• An unreachable checker is not a negative result. A network error, a non-200 response or a malformed body becomes an explicit unknown state surfaced as "Status unavailable" — never collapsed into Finished. The comment on the catch block states the rule directly: "An unreachable relay is not evidence that the process ended."
• Never fetch a target supplied by the record. The stored row already contains a URL, and the service ignores it, rebuilding every request from the operator's configured origin plus an id that must match a fixed pattern first — because "A registry row is caller-supplied data and must never become a server-side fetch target."
• Put the checking on a budget. Each list request checks at most two sessions, ordered by which were checked longest ago, capped at thirty checks per minute, with a 2.5-second timeout and results cached for thirty seconds when certain and five when not.

The author is explicit about the limit: this is reconciliation, not discovery. The list only contains processes someone registered in the first place, so it answers the 77% question and not Harness's harder one about the agent nobody registered.

What the vendors are shipping

The same gap is showing up on cloud provider roadmaps. AWS has published details on AgentCore Evaluations, a capability for monitoring agents after they go live, paired with its DevOps Agent for automated response.

The problem statement will be familiar to anyone who has shipped an agent: teams building on Bedrock AgentCore typically test extensively before launch but have limited tooling to track performance once the agent handles real traffic, and behavior can shift from model updates, changes in retrieved data, or edge cases testing never covered.

AgentCore Evaluations runs continuous scoring against configurable metrics covering task completion, response relevance and safety, surfacing results through dashboards and alerts. The DevOps Agent adds automated triage: when scores drop below a threshold, it can trigger investigation or remediation rather than waiting for a human to notice a dashboard.

Two caveats are worth stating plainly. No pricing or general availability timeline was confirmed beyond the announcement, so check current AWS documentation before planning around it. And this is scoring for agents already running on one platform — it measures quality, not the existence of agents nobody registered.

What this means if you run agents in production

The survey pairs suggest a specific and cheap diagnostic. For each claim your team would make about agents in production, name the system that would produce the answer and the last time someone ran it. Where the answer is a runbook, a spreadsheet or a person, you are in the 77% column rather than the 44% one.

Three checks follow from the failure modes above. Confirm that your inventory distinguishes "we checked and it is gone" from "we could not check" — collapsing the second into the first is what turns a monitoring system into a source of false confidence. Confirm your kill switch is a mechanism someone has fired recently, not a procedure someone has written. And confirm that your discovery path can surface an agent that was never registered, because every registry-based approach, by construction, cannot.

What to watch

Watch whether the next wave of platform releases moves from evaluation to discovery. Quality scoring for registered agents is the easier feature to ship and the one that sells, but the survey's sharper finding is the 33% kill-switch row: the gap is widest exactly where the tooling is least glamorous.

Until that changes, treat every agent inventory number — including your own — as a claim about a system, and ask which system.