Here's a pair of numbers that shouldn't sit together comfortably. In a survey published on 22 September, 96.4 percent of IT decision makers said they were confident their organisation had a complete and accurate inventory of its AI agents. In the same survey, 66.7 percent of organisations running agents said they'd had an agent-related operational consequence in the past twelve months.
The survey came from Guild.ai, which sells a control plane for managing AI agents, and it polled US IT decision makers. That's worth keeping in mind: vendor research tends to find the problem the vendor solves. But the specific gaps it reports match closely what implementation teams see on the ground, and a few of them are hard to argue with.
The Numbers That Matter Most
Confidence isn't the interesting finding. The operational detail is. According to the survey, only 42.7 percent of organisations have a centralised dashboard or monitoring tool for their agents. Only 39.8 percent have logging or audit trails. And just 31 percent can immediately stop a malfunctioning agent with an automated kill switch.
Read that last figure again. More than two thirds of organisations running agents in production, on these numbers, can't reliably stop one quickly when it goes wrong.
Why This Matters More Now
Until recently, most enterprise agents ran when a person asked them to. That's changing fast. On 24 September, Microsoft made routines in its Foundry Agent Service generally available, letting agents run at a set time, on a recurring schedule, or automatically when a GitHub issue or Microsoft Teams event fires. Other platforms are heading the same way.
Unattended agents are genuinely useful. They're also exactly where a missing kill switch stops being a theoretical gap. An agent that only acts when someone is watching has a built-in brake. An agent that runs at 2am because an event fired doesn't.
What to Build Before Agents Run Unattended
The practical sequence is fairly short, and most of it isn't technically difficult. It just tends to get skipped.
Start with an inventory that's generated, not declared: agents discovered from platforms and logs, rather than a list someone keeps in a spreadsheet. Then make sure every agent has a named business owner, because the survey's finding that no function clearly owns agents rings true in most organisations we see. Add logging that records what each agent did, what it had access to and what triggered it. And build a way to stop any individual agent quickly, tested before it's needed, not designed during an incident.
Test the Kill Switch Like a Fire Drill
Having a stop mechanism isn't the same as knowing it works. Organisations that take this seriously test it the way they test backups: on a schedule, with someone recording how long it took to identify the agent, stop it and confirm it had stopped. If that exercise takes hours rather than minutes, the organisation has a management gap, whatever its inventory says.
What This Means for Your Organisation
What we see across implementation engagements is that agent management gets treated as something to add once agents prove their value. By then, several are usually running with different owners, different logging and no common way to stop them. Building the inventory, ownership, logging and kill switch into the first deployment is a small job. Retrofitting them across a dozen agents after an incident is a much bigger one.
Key Takeaways
- A Guild.ai survey published on 22 September found 96.4 percent of IT decision makers believe their agent inventory is complete, yet 66.7 percent of organisations with agents had an agent-related operational consequence in the past year.
- The survey is vendor research, but its operational findings are telling: only 31 percent could immediately stop a malfunctioning agent and fewer than 40 percent had logging or audit trails.
- Scheduled and event-triggered agents, such as routines in Microsoft Foundry made generally available on 24 September, make kill switches and logging far more important.
- Organisations should build a generated inventory, named ownership, action logging and a tested stop mechanism before agents run unattended.
How Trusenta Can Help
AI Agents and Automation builds agents with inventory, ownership, logging and a tested kill switch from the first deployment.
AI Integration Services connects agent activity across platforms into consistent monitoring, so an organisation's agent inventory reflects what is actually running.
Risk Management tracks the operational risk of each agent and links it to the controls, owners and tests that treat it.
Conclusion
The gap between confidence and reality in this survey is the most useful part of it. Most organisations believe they know what their agents are doing. Far fewer could prove it, or stop one quickly if they had to. As agents start running on schedules and triggers rather than on request, closing that gap stops being good practice and becomes a basic operating requirement.
