A note from the founder
If you've landed here you're probably somewhere in the middle of putting AI agents to work, and running into the part nobody warns you about. This is a note about what's going on, and what we built about it.
Two findings frame the problem well.
The first is about getting agents live. Deloitte's Tech Trends 2026 reports a survey in which 38% of organizations were piloting agentic AI solutions, while 11% were using them in production. Plenty of agents work in the demo. Far fewer make it into the work.
The second is about what happens after they ship. Gartner forecasts that by 2027, 40% of enterprises will demote or decommission autonomous AI agents, because of governance gaps found only after a production incident.
Neither of those is a model quality problem, and you can't fix either one with a better prompt. Both come down to whether the people accountable for an agent can say what it's allowed to do and show that it stayed inside the lines.
From that same Gartner release: enterprises are treating agent governance as binary, either locked down or fully trusted, and Gartner calls that the root cause of failure.
The diagnosis is that organizations don't distinguish between an agent's ability to act and the scope of access it's granted, then apply one level of control across everything. The recommendation is governance in tiers, proportional to what each agent does.
That matches what we'd been seeing. A guardrail that can only permit or block is binary by construction. It can't express "allowed, but flag it," or "allowed with this field corrected," or "a person needs to decide this one." So teams end up with a control that's either too tight to be useful or too loose to be evidence, and they find out which during an incident.
The agents are new. The problem underneath them is not.
We've spent about thirty years building and running regulated applications in production, going back to the beginning of the commercial cloud. Long enough to have made most of the mistakes personally, and to watch the same pattern repeat through several waves of technology. What stops enterprise software is rarely whether it works. It's whether the organization can put its name on it.
What that teaches you is unglamorous. Running software in a regulated business depends on properties that are painful to retrofit: a record written whether or not anyone remembered to, a decision made by a person with the authority to make it, evidence somebody outside your company can verify, and a change history that outlives the people who made the changes.
We've built systems that had those properties from the start, and systems that acquired them under duress after an audit. The first way is considerably cheaper.
We looked hard at what already existed, because building this is a lot of work and we'd rather not have.
There are a lot of good tools for the developers building agents. Guardrail libraries, evaluation frameworks, gateways, observability. If you're the engineer shipping the agent, you're well served, and we're not here to argue otherwise.
The gap is everyone else. The business owner who funded the agent and has to defend what it does. The compliance officer who has to map it to a requirement. The reviewer who gets the exception. The auditor who shows up later.
None of those people read traces, and none of them live in an observability console. The tools that serve developers produce nothing for them, and the governance platforms that do speak their language never see the action.
Strong at intake, risk assessment, framework mapping and the documentation an assessor asks for. But a policy document describes what should happen. It can't stop an agent from doing something else, because it never sees the action.
Good at checking a step before it runs. But they produce traces rather than evidence, they have no answer for the moment a person has to decide, and they only reach agents somebody built with that library.
What's missing is the record of what the agents did, in terms the business uses, and the work around it that lets each of those people do their actual job.
One loop, covering the full distance from a rule to something an auditor accepts.
A proposed action gets checked against your rules while it can still be changed. Most of the time the answer is Allow, and it goes straight through. Sometimes it's Warn, and the work continues with a note on the record. Sometimes it's Transform, and it continues with a corrected version. Escalate sends it to somebody with the authority to decide, not a ticket queue, and their answer comes back into the workflow. Deny stops it. Whatever happens, the request, the rule, the review and the outcome your application reported stay linked as one record.
Five possible answers instead of two, which is what tiered governance looks like in practice. And the record is built so somebody outside your team can check it without trusting you, which is what turns "we have logs" into an answer.
We're not going to put a number on how much that moves the figures above. Nobody has good data on that yet. What we will say is that both failure modes are governance failures, both can be addressed before an incident rather than after, and that was the design brief: agents that get out of pilot, into production, and stay there, with the tenth as easy to govern as the first.
Most tools in this space are built for one person and handed to everybody else. We built a portal for each of the six roles an agent depends on, and the handoffs that move work between them.
You funded the agent, and you answer for it. Your portal shows whether the work is getting done and where risk is building, without asking an engineer for a screenshot. When compliance proposes accepting a risk, the decision lands with you by name.
You're asked to approve something you can't inspect. You should be able to inspect it. Your portal ties requirements to the evidence behind real decisions, and when a control isn't met you assign the fix with an owner and a due date.
You turn a requirement into something testable, and you can try a new or changed rule in Shadow first. When it's for a production agent, an administrator or compliance officer approves it, so you never change a live limit alone.
You need a connection, not a six-month project. Your application keeps control of its own execution. When a rule needs data the agent doesn't send, you get a fix request instead of a meeting.
You work inside an engagement scoped to the applications and dates under review. You can follow the evidence without changing the work, and verify it without going through the vendor.
You make sure each person's access matches their work, so the exception reaches someone who holds the authority for it.
One of those handoffs is the one everybody asks about: an exception goes to the person who holds the authority, wherever they already work (the VeriProof Inbox, email, Slack, or Teams), with reminders and escalation if it sits. If a governance tool only works when a developer's in the room, the business never gets visibility. That shaped a lot of what we built. Follow one exception through all six portals.
A few things we believe, set out so you can disagree with them.
That the blocker on agentic AI is accountability rather than capability, and that it stays that way.
That governance has to be proportional rather than binary. Gartner's point, and ours.
That it has to reach the agents your developers didn't write, too. A control that only wraps your own code covers a shrinking slice of a growing estate.
That records should speak the language of the industry they came from. A compliance officer at an insurer shouldn't need a developer to translate a field name.
And that the cost of the second agent matters more than the cost of the first. Governance priced per workflow caps a program at however many projects it can fund.
You don't have to take any of this on faith, which is more or less the point of the product.
Look at a week of one agent's work from the business owner's side: what it finished on its own, where it needed a person, and the record behind each exception. Or open the portal and switch between the six roles to see what each person works with.
If you own an agent that works in the demo and is waiting on approval, start a free Developer evaluation. Invite the people who own the workflow, test your rules, and review the evidence together.
Thanks for reading. Glad you're here.
Bob Janacek, founder, RJR Labs
Evaluate the full system free with Developer, or see what one agent did this week and why.