Picture a reasonable request. Inventory looks wrong for one region, so somebody asks the AI agent they’ve been given to go and reconcile it. It works out that it needs transaction records, finds the source, and starts pulling.
Good question, sensible answer. The only problem is the hour. The financial close is running, that database is already under load, and it has no idea. Neither does the person who asked.
Nobody in that story did anything careless. No single place knew about both pieces of work.
One note on the word, because it collides with one we already use. Through this piece an AI agent means software that works out its own next step. It is not the platform agent sitting on your hosts running scheduled work. Those carry on doing exactly what they have always done.
The gap is older than AI
Most environments picked up their automation the way houses pick up extensions: a scheduler for the batch, something lightweight the data team built themselves, scripts on individual machines, monitoring with holes in it. Every one of those decisions made sense to the person making it at the time.
What changes with AI agents is the rate. Adding a scheduled job is a deliberate act with a change record behind it and somebody’s name on it. Giving a capable AI agent access to a system is one act, and it keeps going on its own schedule afterwards, at a volume nobody sized for. An estate that was already hard to describe gets harder faster than the team tracking it can keep up.
Start with what runs, and what it can reach
Which puts an unglamorous job at the front of the queue. Somebody has to write down what runs here, what triggers it, what it touches and who owns it. Teams always find things they’d forgotten during that exercise, and usually one or two nobody can account for at all. That’s normal. It’s also the point.
The second half of that question is reach. An AI agent gets to your systems the same way everything else does, through service accounts, stored credentials and the connections your jobs already use. Whatever those can touch, it can touch. Most teams have never had to look at that list as a list, because until now nothing was making decisions with it. If you cannot say what a given account can get to, you cannot say what the AI agent can get to either, and you will not find out from a log, because nothing failed.
When the intelligence gets applied
There’s also a question of timing that doesn’t get asked enough. Using AI to help design a workflow and then running that workflow deterministically gives you the benefit once and leaves you with a predictable artifact you can read. Putting the intelligence in the runtime means paying for it on every single execution, in cost and in elapsed time, and accepting that the answer might come back different tomorrow. For a workflow with a deadline on the end of it, that’s a real trade, and most teams make it by accident rather than on purpose.
Drift is quieter than failure
Then there’s watching the thing once it’s running, where most monitoring quietly lets you down. Monitoring is built to catch failure. A job that hasn’t failed and is simply taking longer than it should will keep every dashboard green while the critical path slips underneath it. Nobody gets paged, because on paper nothing’s wrong. You find out when the deadline arrives.
Knowing what normal looks like for each piece of work is what turns that into a warning instead of a surprise. It depends entirely on the inventory being right, which is why the boring job comes first.
Keep a person in the path
The other thing we’d argue for is a human checkpoint at the points that matter. Not a review board, and not an approval on every step, because that defeats the purpose of automating any of it. Where an AI agent is about to do something that touches production and can’t easily be undone, the design should stop and ask. That works best when the structure around it is deterministic, because a known sequence gives you somewhere obvious to put the check. Something improvising its own path gives you nowhere to stand.
Teams push back on that as friction, and it is friction. The question is where you’d rather spend it. A pause before a heavy job runs against a loaded database costs somebody a few minutes. Finding out afterwards costs a good deal more than that, and the people who pay it are usually the ones who were never asked.
The judgment stays with people. Deciding what should be automated, what shouldn’t, and what a system is allowed to do without asking first needs somebody who knows the environment well enough to be right about it. We’re not in the business of taking that decision off anyone. Ownership sits with whoever owns the environment. It gets settled before the work starts and it doesn’t move once things are underway.
AI agents are going to end up in these environments either way. Start the inventory now, so you know what they’re walking into.
If you would rather not start it from a blank page, that inventory is what our consultants build in a digital ecosystem assessment. Book one at automworx.com.
AutomWorx does workload automation consulting, migration planning and post go live support. automworx.com