Everyone is demonstrating AI automation. Almost nobody talks about the engineering underneath it.
The demo is always the same. An agent reads a ticket, checks a system, takes an action. Thirty seconds, very clean, a room full of people seeing the future.
I build this kind of thing, so I watch those demos making a different list in my head. The list of everything standing between that demo and production. None of it is the AI.
Identity
The first thing I always ask about is identity.
That agent needs credentials to touch a network environment, cloud workloads, and managed services. Whose credentials? If the answer is a service account with standing privileges, that is a breach waiting for a headline.
Non-human actors need scoped, short-lived, auditable access, and most identity architectures were never designed for anything like that.
Data
Then there is the data the agent acts on.
If the ticket data is inconsistent, if the configuration database is stale, if two systems disagree about the state of the same device, the agent automates the disagreement.
Garbage in used to mean a bad report. Now it means a bad action.
Failure
Failure is the part that keeps me up.
When my change fails halfway, I notice and I adapt. When an agent's change fails halfway, what happens next? Rollback, idempotency, safe failure states. Boring words. They are the difference between automation and an outage generator.
Accountability
Somebody also has to answer for what the agent did.
Not in the demo. In the postmortem, and in front of the auditor asking who approved the change. If you cannot reconstruct what it touched and why it decided to, you do not have automation, you have a mystery.
Scope
And the question I always push is the one no demo ever shows: what is this agent not allowed to do?
Scoping an agent's actions is harder than enabling them. That is where the real engineering happens.
None of this is a reason to slow down. The AI is the easy twenty percent. The engineering around it is the eighty that decides whether it ships.