Who Gets to Build Agents? Governance for Self-Service AI That Does Not Slow Everyone Down

Picture a Friday afternoon in the customer service department of a machinery maker. An employee is tired of answering the same questions about error E-217 on the filler FL-200. She describes in two sentences what an agent should do, and before she leaves she has a workflow that drafts replies and sends them by email. It works well. On Monday, three people ask three questions. IT wants to know who allowed this. The team lead wants to know who may change the workflow from now on. And the managing director asks what happens when the employee is on vacation and a reply is waiting for approval.

This is a thought experiment with fictitious documents, not a customer case. But it shows what self-service AI is really about: building has become fast, while responsibilities have not. Anyone who can assemble an agent without programming skills no longer needs a project to set something in motion. That is exactly why you need rules beforehand about who may set what in motion.

Our thesis: self-service AI does not need a brake, it needs separation. Building, sharing, publishing and acting are four different rights. If you separate them cleanly and give each one to a named role, you can open up building to many people and still let a few places decide what actually reaches the outside world. This article walks through the dividing lines one by one: the four roles, sharing, the path from draft to publication, versions, tool rights, and the deputy for approvals.

Two Paths That Both Fail

When companies introduce AI agents, they usually end up at one of two extremes.

The first path is the central team: only a small group, usually in IT, may build agents, and everyone else files requests. That feels safe. In practice a queue forms, and the business units that understand the problem best wait for a team that knows it only second hand. You know the pattern from other tools: people work around it, with private accounts, free services and browser extensions. What you do not make possible happens anyway, just without a log.

The second path is the open field: everyone may do everything, as long as it is quick. The first weeks are impressive. After half a year there are agents whose creators have moved to another team, workflows that send emails to customers, and nobody remembers who reviewed them. That is no accusation against the employees. It is the result of missing structure.

The third row is our recommendation. It is neither the most comfortable nor the strictest, but it is the only one that does not play speed against control. That works only if the tiers are not a matter of feeling but are built into the tool: as an access level, as a publication status, as a tool right.

Four Roles Instead of One Permission

Most rulebooks fail on one word: “admin.” If there are only users and admins, everyone who should be able to do more than read becomes an admin, and admins can then do everything. In practice a model with four roles works well. It is a proposal that you adapt to your organization, not a product rule. One person can hold several roles. Just not, for the same agent, the roles of builder and approver at the same time.

Enlarge

How does TheroAI map this? Each agent has three access levels: “Can view,” “Can edit” and “Can manage.” The roles of users and builders sit on these. The approver role shows up in two places. For publication, there are release reviewers, whom owners appoint separately from the right to edit. Inside a workflow, there are the approving people of an approval step. The administrator role lives in the organization settings and the reports area, where tool rights, connectors and the audit log are found.

The core of the model is the right-hand column of the table: every role has something it may not do for its own agents. That is not an expression of distrust. It is the same idea as with a bank transfer above a certain amount: not because the person is unreliable, but because a second pair of eyes finds mistakes that stay hidden from the first when you check your own work.

Sharing: Who May View, Change and Manage an Agent

“Share” sounds harmless, but it is the point where a personal helper becomes a shared tool. In TheroAI, the Share dialog answers who may view and edit an agent. The narrowest setting is “Private.” From there you can add individual people, open the agent to the whole organization, or withdraw access again.

Two rules help in everyday work. First: share to view by default, not to edit. Editor access is the invitation to build along. It makes sense when two people work on one workflow or when someone is meant to step in as a deputy. It is too generous when it was merely convenient. Second: the circle of users is itself a change that deserves attention. TheroAI reflects this. Withdrawn access takes effect immediately. New audiences, however, can use an already published agent only after the extended access has been reviewed and published. If you want to widen an agent to the whole organization, you go through the same door as for a change of content.

Draft and Publish: The Switch Between Trying and Taking Effect

The most important dividing line in the whole model runs between what someone tries out and what applies to others. In TheroAI, every agent is first saved as a draft. You can test the draft in the editor without anything triggering anywhere: the next test message uses the saved draft, and a test run shows the steps. One sentence in the editor is decisive: triggers only run on a published version. A schedule, a form or an event takes effect only when someone deliberately clicks “Publish.”

Enlarge

The editor helps with simple checks. If the name is missing, the instructions are missing, a workflow has no steps yet or a schedule is invalid, it reports “Not ready to publish” and lists the open issues. There is also a rule that is easy to overlook: the way of working, free-form or workflow, is fixed after publication. An agent does not quietly switch from one kind to the other.

What Happens on Submission

For agents that are shared with others, a second stage comes in: review. The builder submits a version “for review” and describes in a sentence what changes and why. From then on:

• The version is frozen. Later changes to the draft stay separate and change nothing in the submitted version.
• The review shows the difference. The reviewer sees the current live state next to the submitted version, optionally only the changes, plus access, triggers and history.
• Test evidence belongs to the version. If no execution test is attached to this version, the interface says so openly: an earlier or later test does not prove this specific state.
• There is more than yes and no. The review can publish, request changes or reject, and the builder can withdraw the candidate.
• Stale candidates stand out. If the live state has changed in the meantime, the candidate should be withdrawn and resubmitted on the current base.

Not only texts are reviewed. The version includes name and description, instructions, tools and knowledge or the steps of the workflow, trigger and schedule, audience and access, the tools allowed without supervision, the execution identity, the delivery of results, and the connection identities and permissions. In other words, the very dials that make an agent more powerful also go through the review.

Who Reviews

Owners appoint reviewers separately from the right to edit. For shared agents, a person other than the author is required. If you want personal agents reviewed as well, you can require that as a policy. We would recommend it for every agent that writes to the outside, and we would skip it for pure research helpers. What matters is that the distinction is made deliberately and does not depend on chance.

Enlarge

Versions: Restoring Is Possible, Undoing Is Not

In TheroAI, every publication creates a version that you can restore later. That takes the fear out of publishing, but only if you understand exactly what “restore” means.

Restoring overwrites the draft with the name, description, trigger and steps of the chosen version. The active version stays unchanged until you publish again. The way back therefore has two steps: first restore, then deliberately publish again. If you only want to discard the draft, you can choose “Back to published” and see beforehand which fields will be discarded. And because every run records which version it ran with (in the history, for example “ran with v2”), you can later trace which state produced a particular answer.

Enlarge

Besides that, there is revoking a publication. It stops new chat starts, schedules and event runs. Running operations keep their version and remain subject to the current policies. What has already gone out, such as a sent email, is not reversed by this. That is the honest limit of any versioning: it can turn back the configuration, not the effect. That is why versions and approvals belong together. The version catches mistakes in building, the approval catches mistakes before the effect.

Tool Rights: The Organization's Frame and the Room Per Agent

An agent is only as powerful as the tools it may use. That is why the question about tool rights is really the question about the risk boundary. In TheroAI they work in three levels that nest like shells.

Level 1, the organization. In the settings under “AI Tools” (“KI-Tools” in the German interface), administrators decide per service or action what is allowed, what requires confirmation and what stays blocked. These settings apply to everyone in the organization. Writing tools are marked, and for them “Ask” is the obvious choice. In the demo environment, the overview shows 236 tools allowed, 138 with a prompt and 0 blocked.

Enlarge

Level 2, the agent. An agent that works continuously in the background has its own list called “Allowed on its own”. It holds the actions the agent may carry out without asking. Only tools that change or send something can be chosen, and every execution is logged. In addition, the “In the background” area shows honestly what is currently possible: ready, with approval, chat only, access missing. This list is part of the version that gets reviewed. Whoever gives an agent more independence changes something that a second person gets to see.

Level 3, the run. Even for allowed actions, a workflow can demand an approval before the effect. That is the level of the approvers, and it is the subject of the next section.

Enlarge

The rule behind the shells is meant like this: each level may become narrower than the one above, never wider. For a blocked tool, the interface says it plainly: the tool is not available to the agent. Check with one example in your own environment that this also holds for the “Allowed on its own” list before you rely on it. How you choose the defaults depends on the reach of an action. The following table is a proposal for getting started, not a product rule.

More on tools and their settings is on the page about tools, and the overall picture of protection is on the security page.

Deputy: So Approvals Do Not Stall During Vacation

Back to the managing director's question from the beginning: what happens when the employee is on vacation and an approval is waiting? The answer is unspectacular, but it has to be settled in advance. For agents that work continuously in the background, TheroAI has a deputy. The owner names the deputy in the agent's settings, and the deputy decides on approvals and standing assignments while the owner is away.

Three details show how precisely this is meant. The deputy must already be entered as an editor for the agent. This is where the rule from the sharing section pays off: whoever has never entered anyone as an editor cannot name a deputy either. The deputy is chosen only by the owner. And the deputy lapses if the person's access is withdrawn or reduced to “Can view.” That way, no deputy is left over whose rights are long gone.

Within the workflow itself, each approval step defines who decides and by when. In the example workflow “Support-Anfrage beantworten,” that is one approving person and a deadline of 72 hours. The first decision counts. And when the four-eyes principle is switched on, the trigger and the creator of the agent may not decide, not even as an admin. That is the technical side of the sentence that nobody approves their own agent.

Why the deputy is not a detail becomes clear in an example calculation. The times are assumed, the deadline comes from the example workflow.

Enlarge

What happens technically once a deadline passes is deliberately not claimed here; the calculation only shows the time in which nobody has decided. It proves nothing about your processes. It only makes visible that the deadline of an approval step and your team's absences have to fit together. A deadline without a named deputy is an appointment with nobody. A good deputy knows the agent, has editor access and is not the same person who built it, otherwise the second pair of eyes is missing during vacation too.

How approval steps are built inside a workflow is described on the page about workflows.

Where Self-Service Governance Fails in Practice

The rules themselves are rarely the problem. It is the habits around them. Five patterns to watch for:

• Agents without a living owner. The person has changed teams, the agent keeps running. Check regularly that every active agent has a reachable owner and a deputy.
• Editor access as a shortcut. It is easier to enter someone as an editor than to clarify what the person actually needs. The result is many co-builders without shared responsibility.
• All approvals with the same person. Someone who confirms twenty requests a day eventually stops looking. Distribute approvals by expertise and make sure a deputy exists.
• Tool rights that are set once and never looked at again. New connections and new tools change the overall picture. A review every quarter is often enough, provided it is scheduled.
• What gets published is what worked, not what was reviewed. Yesterday's test does not apply to today's version. Require that the evidence and the submitted version belong together.

Works Council and Law: A Note

A role model with logging touches codetermination. In Germany, technical equipment designed to monitor the behavior or performance of employees is subject to the works council's right of codetermination under section 87 (1) no. 6 of the Works Constitution Act (Betriebsverfassungsgesetz). Whether and to what extent this applies to your logs depends on the individual case. Our recommendation is practical: show the works council the role model before you introduce it, and explain who sees what and why. This is not legal advice, so clarify the individual case with your legal counsel.

What You Can Take Away

Our position in one sentence: open up building widely, keep publishing narrow, and make independent action a justified exception with a name attached. Then self-service AI is not a risk you have to tolerate but a procedure you can explain.

Five steps for the coming weeks:

1. 1.Name the roles. Who are the builders, who the approvers, who the administrators? Write down names, not job titles.
2. 2.Set the sharing default. New agents stay private, access to view is the normal case, and editor access needs a reason.
3. 3.Appoint release reviewers. At least two people per department, so that nobody decides alone and nobody becomes a bottleneck.
4. 4.Go through the tool rights. Writing tools on “Ask,” dangerous ones on “Block,” and read the “Allowed on its own” list line by line with the team.
5. 5.Enter deputies. For every agent that works continuously, with editor access, and match the deadline of approval steps to the reality of absences.

And seven check questions you can put to any agent:

Who is responsible, and who stands in for that person?

>

Who reviewed this version, and was it someone other than the author?

>

What reaches the outside, and is there an approval in front of it?

>

Which tools may the agent use without asking, and who decided that?

>

Which version can we go back to, and what can this not undo?

>

Who can pause the agent if something goes wrong?

>

How would we explain this to internal audit and the works council?

If you would like to see how draft, sharing, approval and tool rights feel in TheroAI, we are happy to show you in a demo session, with your own examples and without any preparation on your side.