Does Your Business Automation Have a Watchdog?
Nvidia's plan to put a watchdog chip next to every AI agent points to a real gap in business automation: most systems have no independent check on what they're actually doing. Here's what that check should look like.
Nvidia is reportedly working on a watchdog chip that sits next to an AI agent and checks what it's doing before it does it. The detail doesn't matter much to a business owner in Sheffield or Solihull. The idea behind it does. It's an admission that an AI agent, left alone, will happily do something stupid at full speed and full confidence. Something needs to sit next to it and ask "are you sure".
Most of the automation I build or inherit for clients has no version of that check. It has a trigger, some logic, and an action. Nothing in between watching for the moment the logic goes wrong.
The gap isn't intelligence, it's supervision
People tend to worry about whether an automation or AI agent is "smart enough". That's rarely where the damage happens. The damage happens when something perfectly ordinary changes upstream, like a field going blank, a filter returning every row instead of ten, or a loop that should run once running four hundred times, and nothing in the system is positioned to notice before the action fires.
A few real shapes this takes:
- An email automation that's supposed to send a renewal reminder to customers due this week, but a date filter fails silently and it sends to everyone in the database.
- An integration that syncs stock levels between a website and a warehouse system, and a malformed API response gets read as "zero stock everywhere", pulling every product off sale.
- A billing job that retries a failed payment run and, because nothing tracks what already succeeded, charges a batch of customers twice.
- An AI agent handling support replies that offers a discount or a refund because it interpreted a vague policy document too generously, with nobody reviewing it until a customer mentions it.
None of these need the automation to be smarter. They need something else in the system whose only job is to notice when the normal shape of things has been broken, and to stop before the action lands.
What a watchdog actually looks like for a business system
It's not one thing. In practice it's a handful of deliberately boring checks, built in alongside the automation rather than bolted on afterwards.
Volume limits
If a process normally sends 20 to 50 emails a day, it shouldn't be able to send 5,000 without something pausing it and asking for confirmation. The same goes for records updated, refunds issued, or API calls made in a short window. A hard ceiling, even a rough one, catches the runaway loop before it reaches every customer instead of ten.
Spend and action caps
Anything that moves money, whether that's a refund workflow, a discount an AI assistant can grant, or an automated reorder from a supplier, should have a limit on what it can do without a human confirming it. Not because the logic is untrustworthy day to day, but because the one time it is wrong, you want the size of the mistake capped.
A dry-run mode
Before a change to an automation goes live, it should be possible to run it against real data and see exactly what it would have done, without anything actually happening. This is the difference between finding a bad filter in a test log and finding it in a customer's inbox.
An off switch that actually works
This sounds obvious and is skipped more than you'd think. If an automation is misbehaving at 6pm on a Friday, is there a way to stop it in one step, or does someone need to work out which of three connected services is the actual source and disable each one manually? I've covered how badly designed retries can turn a small hiccup into a full outage in more detail in a piece on retry storms in business automation, and the same principle applies here: the moment you need to stop something, you don't want to be reading code to find the switch.
This applies to AI agents specifically, but not only to them
AI agents get more attention because they're newer and their failures are novel enough to make headlines. But a badly filtered spreadsheet import can do exactly the same damage as an overconfident AI agent, and it's been able to for twenty years. The watchdog idea isn't really about AI. It's about accepting that anything acting on your behalf, without a person watching each individual action, needs limits designed in from the start rather than added after something goes wrong once.
Where AI does change things is speed and plausibility. A broken spreadsheet macro tends to fail loudly and obviously. An AI agent that's slightly wrong tends to produce something that reads as reasonable, which is exactly why it can run further before anyone notices. I've written before about how easily an AI agent fills a gap with an assumption instead of asking a question, and that habit is precisely what a watchdog layer is meant to catch before the assumption becomes an action.
A question worth asking before anything goes live
When I scope an automation or an integration for a client, I try to ask one plain question about every action it can take on its own: what happens if this runs on bad data, or runs too many times, or runs against the wrong record? If the honest answer is "nothing stops it", that's the bit I build before the rest, not after.
It's not a glamorous part of the work. It rarely shows up in a demo. But it's the difference between an automation that saves you admin time and one that, on the one day it goes wrong, costs you a lot more than it ever saved. If you're already running automation or AI tools that touch customers, money or stock, it's worth checking whether anything sits between the trigger and the action asking "are you sure", and if the answer's no, that's a conversation worth having before the next thing you automate, not after it.