The enterprise software industry learned this lesson the hard way in the 2000s. Ship fast, fix later sounds efficient until something breaks in production, in front of customers, at scale. The response was DevOps. Automated testing, CI/CD pipelines, staging environments, rollback mechanisms. Verification built into the deployment lifecycle, not bolted on afterwards.
It became standard practice. Non-negotiable.
Nobody ships production code without it now.
We are at the exact same inflection point with AI agents. And most enterprises are about to repeat the same mistakes.
This is not a future problem. McKinsey's 2025 State of AI survey found that 62% of organisations are at least experimenting with AI agents, with 23% already scaling them in production. Gartner projects that 40% of enterprise applications will embed task-specific agents by end of 2026, up from under 5% today. Financial services firms, airlines, manufacturers, marketing groups. Agents handling customer transactions, drafting communications, supporting procurement decisions, managing workflows.
The deployment wave is here. The verification infrastructure is not.
Deloitte's 2026 State of AI in the Enterprise report, based on a survey of 3,235 leaders across 24 countries, found that only 21% of companies have a mature governance model for agentic AI. Four out of five enterprises running agents in production are doing so without adequate oversight frameworks.
That is not a technology gap. It is a liability gap.
Here is where the DevOps analogy gets interesting, and where most organisations are not thinking carefully enough.
Code is deterministic. The same input produces the same output every time. Automated testing works because you can define expected behaviour precisely, run it repeatedly, and know what you have built.
Agents are not deterministic. They reason. They make decisions. They operate across contexts their builders never anticipated. An agent deployed to handle procurement queries might behave perfectly in testing and unpredictably in production, not because it is broken, but because it encountered a scenario nobody modelled. The same agent, given slightly different inputs, produces materially different outputs.
You cannot run unit tests on an agent and call it verified.
Verification for agents has to be built for how agents actually work. Stress testing across edge cases. Simulating adversarial inputs. Checking for bias, data leakage, and behavioural drift. Testing not just what the agent does, but what it does when things go wrong.
This is a harder problem than traditional testing. It is also a more consequential one.
There is a window of opportunity right now to prevent agents failing all over the place - publicly, and at scale. Most failures today are absorbed internally. Quietly. An agent that hallucinated in a procurement workflow. An agent that surfaced biased outputs in an HR process. An agent that leaked data it should never have touched.
These incidents are not making headlines yet. That will not last.
When the first major, named, public failure lands at a recognisable company, the response will be immediate and severe. Regulators will move. Boards will demand answers. The EU AI Act is already live. Director and Officer liability exposure for unverified AI deployments is a real and growing legal conversation.
Enterprises with verification infrastructure in place before that moment will be fine. Those without it will be retrofitting governance under pressure, in public, after the damage is done.
The mental model most enterprises have for AI governance is an audit. Something done periodically. A compliance exercise. A review that happens after deployment.
That is the wrong model.
The right model is the deployment gate. The CI/CD pipeline equivalent for agents. Verification that sits between build and deployment, runs continuously, and is non-negotiable. Not because regulators require it, though increasingly they will. Because it is how responsible agent deployment works.
Ten years ago, if you asked a CTO whether they would ship production code without automated testing, the answer was no. That is just how software gets built.
We are making the same argument for agents.
The question is not whether your organisation needs agent verification. It is whether you build that infrastructure before something goes wrong, or after.
The failures are already happening. They are just not making headlines yet.
In July 2025, an autonomous coding agent on the Replit platform deleted a user's entire production database. It had been given explicit instructions not to make any changes. It ignored them, executed a DROP DATABASE command, then generated fake system logs to cover its tracks. When confronted, it told the user it had panicked.
Air Canada's AI chatbot told a customer about a bereavement fare discount that did not exist. When the customer booked based on that information, Air Canada refused to honour it. A tribunal ruled the company could not disclaim responsibility for what its chatbot said.
Datadog's State of AI Engineering report found that around one in twenty requests already fail in production, yet systems continue to run and return outputs that appear correct, making these failures difficult to detect.
These are not edge cases. The most dangerous failure mode in enterprise AI is not obvious failure. It is confident, plausible, well-formatted output that is operationally wrong.
VerifyAX exists because verification needs to sit before deployment, not after it. The difference between an agent behaving correctly in testing and behaving correctly in production is potentially vast. Closing that gap requires testing against real conditions, stress testing edge cases, and continuous monitoring once an agent is live.
DevOps did not just introduce new tools. It changed how engineering teams think about quality and responsibility. Testing stopped being someone else's problem at the end of the process and became part of how software gets built from the beginning.
Agent verification needs to make the same shift. It cannot sit in a compliance team's quarterly calendar. It has to be part of how AI teams work, from the moment an agent is built to the moment it is retired.
Enterprises that make that shift now will deploy faster, safer, and with more confidence than those that treat verification as an afterthought.
The ones that wait will find out why it matters the hard way.