Over the past year at Zamp, working in the founder’s office, I’ve helped Fortune 500 companies across healthcare, banking, and finance take agentic AI from pilots into production.
In this piece, I’m laying out why you must have branching, approvals, and audit trails in place before a hundred people start using an agent.
The hundred people problem
When multiple people within an enterprise start interacting with an AI agent, they need clear governance around who can update it, what approvals are required, and how mistakes will be handled.
The agent becomes part of the company’s operational infrastructure. And the people who eventually own the agent are business owners, operators, managers, and analysts, and more than a hundred distinct roles you might not have imagined.
Suddenly you have a claims manager adjusting an eligibility rule after a policy update. A finance analyst changing an approval threshold because a vendor contract changed. A compliance lead pulling every decision the agent made on a regulated account last quarter.
Some of whom may be interacting with an agent for the first time, while trying to do their job without breaking anything critical.
Now when something goes wrong here, it’s not like a normal software bug.
From what I’ve seen, an entire function at global scale can be at risk.
- A claims manager tweaks a rule to fix one edge case; within a day the agent is denying legitimate claims across every region it runs in.
- Pull a report at the wrong moment and you might trigger a rerun that overwrites the decision logs a regulator will ask for next quarter.
- One contractor deleted what looked like a test agent while cleaning up a workspace. It turned out to be the production agent behind the whole flow.
Depending on the industry, that one mistake can cost millions, sometimes tens of millions, once you add regulatory fines, customer remediation, and the audit that follows.
That is exactly why the agent interface cannot treat every role the same. Without clear boundaries, a routine operational change can alter the behavior of an entire production decision flow.
Safe experimentation
Business owners need a way to test changes in a separate copy of the agent before those changes go live. They need to see what would happen, compare outcomes, and get approval before anything is merged into production.
That is why branching and version isolation should be core requirements in any agent platform. It gives business teams the freedom to keep improving the agent without putting the live version at risk.
Otherwise, one of the two things will happen:
- Either the business owner stops iterating and the agent stalls at ~60% automation because nobody dares improve the hard cases.
- Or they edit the live agent directly, risking silent breakages that only surface months later.
Maker-checker and audit trail
Every industry I have worked with, whether it’s banking, insurance, or pharma, runs on a maker-checker principle. You don’t change something meaningful on your own; someone proposes, someone else approves. It’s how regulated organizations scale while keeping error rates and compliance risk under control.
That discipline must apply to agents too. You need accountability on three different timelines:
- Proactively: a maker‑checker approval before any change to an agent’s behavior or prompts reaches production.
- Retroactively: an immutable log of every change that records who made it, who approved it, the exact diff, and how runs behaved after the change.
- Preventively: versioning that lets you roll an agent back to a known good state in minutes when a change slips through, instead of spending days reconstructing what happened from Slack and screenshots.
None of this is new. Version control, approval workflows, and audit logs are what every serious engineering team has run on for two decades. Agentic AI doesn’t get a pass just because the model is new.
If anything, because the model is probabilistic and can behave differently on the same input twice, the guardrails around it need to be tighter than what a normal software team runs.
Leadership and dashboards
The piece most vendors get wrong is what leadership sees.
A CEO isn’t reading run logs. A chief procurement officer cares about vendor onboarding cycle time, how many exceptions got routed to humans, and where that trend is headed.
A business owner needs to see which sub-flows are failing and why. A compliance officer needs one view of every decision the agent made on a regulated dataset last quarter.
These are four different views on the same underlying data.
If you build one dashboard and label it “analytics”, none of these four people are going to use it after the second week. What works is one dashboard, built differently for whoever’s looking at it.
It should identify a run that’s behaving strangely, say, an unusually high rejection rate on one sub-process, or a spike in exceptions routed to humans, and surface it on its own. Not wait for a business process owner to notice the numbers look off three weeks later while pulling a routine report.
Accountability
Every enterprise buyer should be asking their vendor one question directly. When the agent gets it wrong, who’s accountable?
- If an operator in their first month deletes a production agent because they had admin privileges nobody thought to restrict, is that on the operator?
- If a manager approves a change and misses one guardrail out of the hundred that should have been in place, because their prompting was a little off that morning, is that on the manager?
- Or is it on the vendor, who built a system where a single change could take down a global function without any of the controls that every other piece of enterprise software has had for twenty years?
In my view, accountability sits with whoever decided what an operator, manager, or contractor could do without another sign-off.
Almost always that’s the vendor or the internal platform team. The agent was built on the assumption that everyone using it had the same context as the person who built it.
It must be designed for the person with the least context, because they will be the one using it most of the time.
Non-negotiable guardrails
Enterprises want agentic AI to move fast, but not at the cost of operational stability. Nobody wants every small logic change queued as an engineering ticket, yet unchecked edits expose the business to real cost: downtime, remediation, regulatory fines, and customer harm.
The answer is a platform built for the people who actually use the agent: operators, managers, business owners, analysts, and leaders, with role‑specific experiences and guardrails that reflect each role’s authority.
That means:
- UI and permissions tuned to the least‑experienced user who will use the agent.
- Maker‑checker approvals embedded into everyday change flows so improvements don’t require developer time.
- Dashboards that surface anomalies to the right person automatically, and not a generic “analytics” screen.
- Versioning and immutable logs that let you validate, rollback, and prove what happened in minutes.
I’ve seen what works, and what fails. Enterprise business owners need a safe way to test changes, a clear approval step, visibility into when something looks off, and a reliable record of what changed.
That is the foundation I would insist on before greenlighting an agent rollout.
Originally written for Limitless by Zamp on Substack.
Read more here: https://limitlessbyzamp.substack.com/
