Approval Is Not a Formality: The Four-Eyes Principle for AI Actions

Tuesday, shortly after nine. A request arrives in support: a customer reports error E-217 on their filler FL-200 and asks whether replacing the seal is covered by the warranty. A workflow reads the request, searches the knowledge base and writes a draft reply. The draft is neatly worded, names its sources and contains one sentence nobody explicitly asked for: “The replacement is of course free of charge.”

The example is explicitly fictional. The documents come from the demo data on our industry pages, and this is not a customer case. The situation behind it is real. Whether a replacement falls under warranty is a commitment made in the company's name. A model can phrase it. It cannot be held accountable for it.

In a well-built workflow, a step stands between the draft and the customer. It pauses the run and asks a human: the approval. This article is about exactly that step. Our thesis: An approval is a product, not a checkbox. It only protects when it is rare enough to be taken seriously, clear enough to be understood in seconds, and independent enough that nobody judges their own work.

When an Approval Makes Sense

The question is not whether a model can be wrong. It always can. The question is what an error costs and whether the damage can still be corrected. Three questions help with every step of a workflow:

1. 1.Can the action be taken back? A draft can be discarded, a sent message cannot.
2. 2.Does it reach the outside? Whatever reaches customers, suppliers or authorities is carried by the company, not by the model.
3. 3.Does it bind the company? Commitments on price, deadline, warranty or contract are statements somebody has to stand behind.

The answers lead to a simple classification. The table below shows it with examples from a support workflow. It is a guide for case-by-case review, not a fixed rule.

Enlarge

Two things stand out. First, most of the work stays free of approvals: researching, summarizing, drafting and classifying can run fast and automatically. That is where the time savings are. Second, approvals do not sit at the start of the chain but right before the effect. Whoever checks the draft after it is finished checks what will take effect later, not every intermediate step.

Two Kinds of Confirmation

TheroAI has two mechanisms that should not be confused. The first is tool permissions: for every tool it is defined whether it is allowed, asks first or stays blocked. The second is the approval step in a workflow, which you place yourself at a specific point, with a title, a description, approvers and a deadline. Tool permissions describe what a tool may do in principle. The approval step describes where, in this particular process, a human should decide. You can find more about permissions on the page about AI tools.

The Example Workflow: Approve Customer Reply

The workflow “Kundenantwort freigeben” (Approve Customer Reply) consists of three steps: draft the reply, request approval, output the reply draft. A person starts the run, the agent drafts the reply including its sources, and then the run stops. That is not an error state but a status: “Wartet auf Freigabe” (waiting for approval). Nobody has to keep a window open. The run rests until a decision arrives or the deadline passes.

Enlarge

The following capture shows what this looks like in the product.

Enlarge

The capture shows the moment that matters. The draft is shown in full, with subject and named sources, and below it three buttons: approve, decline, comment. The deciding person does not have to search for anything or load anything. Everything they need to judge sits in one place. That is the first design rule: The approval shows what takes effect, not a summary of it.

One detail in the picture deserves attention: “1 von 3 Schritten fertig” (1 of 3 steps done). The run is neither aborted nor finished, it stands at a deliberately placed station. That is what separates an approval from an error. How triggers, agents and steps work together is described on the page about workflows.

Anatomy of a Good Approval

In the workflow editor, the approval step consists of five settings. Each one answers a question, and each can be answered well or badly.

Enlarge

The capture shows the same step in the workflow “Support-Anfrage beantworten” (answer a support request), with one approver and the four-eyes principle switched off. The right-hand column of the table is by contrast a design suggestion for the example workflow, not a picture of the demo: team lead and deputy are freely chosen examples.

Title and Description

The title says what is being decided, ideally as a verb with an object: “Approve reply to the customer” instead of “Please check”. The description says what matters. “Check tone, promises and sources” points the eye at the three places where a draft typically goes wrong. Without that hint, the approver reads the whole text with the same attention or the same haste. With it, they read with a purpose.

Title and description can pick up details from the running workflow, such as the error number. Use that. An approval that names the case gets decided faster and better than one that reads the same for every case.

Enlarge

Approvers

Choose people who can judge the content and are reachable, and name more than one. When one person decides, the approval is settled and a second decision is ruled out. That way a vacation does not block the run. Open approvals show up in the approvers' inbox. Organization administrators can decide as well, without being on the list. Avoid lists in which nobody feels responsible: whoever assumes someone else will decide often means that nobody does.

Deadline and four-eyes principle get their own sections below, because most bad decisions hang on these two.

The Four-Eyes Principle: Who May Not Decide

The four-eyes principle is familiar from areas where a single mistake is expensive: two people look at the same thing before it takes effect. The core is not the number of eyes but their independence. Two eyes belonging to the same person are not two eyes.

In a workflow there are two people who are systematically biased. The creator of the workflow (the interface speaks of the agent's creator) wrote the instructions that led to this draft and tends to consider the result correct. The trigger of the run has a stake in the outcome: whoever started a customer reply usually wants it to go out. With the four-eyes principle switched on, neither of them may decide this approval, even if they are on the list of approvers. The system rejects their decision. The same applies to administrators if they are the trigger or the creator themselves.

Enlarge

Two practical notes follow. First, the list must contain at least one person who neither built the workflow nor started the run. If only the creator is listed, they cannot decide with the four-eyes principle on, and the run waits until somebody else decides or the deadline passes. Second, the switch is not a substitute for permissions. It regulates who may decide this one approval, not who may start or change the workflow in the first place.

When is the effort of an independent second person worth it? Where a decision cannot be reversed and someone may have a stake in the result: commitments with financial or legal effect such as warranty, price or a contract change, changes to master data that feed other processes, and messages to authorities. For an internal note or a draft for your own team, a second reviewer is more friction than protection.

Fatigue: When Approvals Become a Reflex

Every approval costs attention, and attention is limited. Anyone who confirms dozens of requests a day with the same wording will eventually confirm without reading. The approval then remains as a step but no longer protects. It creates a feeling of safety without safety. That is worse than no approval, because everybody believes someone looked.

An example calculation makes the mechanism visible. The assumption: a person has 30 minutes a day for approvals, so 1,800 seconds. This is a round assumption, not a measurement.

Enlarge

The numbers are an assumption, the arithmetic is not. The consequence holds regardless of the values: the more approvals, the less time per approval. What helps:

• Approve only before the effect. Drafts, research and summaries run without approval. The station sits before the send or before the change.
• One approval per decision. Do not stack three approvals in a row for the same reply. One well-designed approval is enough.
• Permissions instead of questions. What must never happen, block through tool permissions instead of having it waved through every time. What is always fine, let it run. Only what lies in between deserves a question.
• Name the case. A title with the error number and a description with a review hint cost seconds to build and save minutes when deciding.
• Watch the declines. An approval that is never declined is either harmless or inattentive. Both are reasons to review it: if it is harmless, nobody needs it. If it is just waved through, it protects nobody.

The Deadline: What Happens When Nobody Decides

Every approval needs an end. In a workflow, the default deadline is 72 hours. If it passes without anyone deciding, the approval is treated like a decline and the run continues. No answer means no here as well. For direct actions in chat, where a person sits in front of the screen, the deadline is much shorter at five minutes. Workflows, by contrast, often run at night, on weekends or during a vacation. That is why they count in days rather than minutes.

The deadline is a design decision, not a default setting. If it is too short, approvals lapse because nobody was at their desk in time. If it is too long, the context is stale by the time someone finally clicks. An example calculation: if the approval is requested on Friday at 4 PM, a deadline of 72 hours expires on Monday at 4 PM. The weekend lies in between. For a customer reply that should arrive on Monday morning, that is unfortunate: the approval is formally still open and the customer waits. Either a shorter deadline with a deputy on the list helps here, or planning so that no run that has to finish by Monday morning starts on Friday afternoon.

Choose the deadline from the effect: how long may the customer, the supplier or the team wait for the answer before the waiting itself becomes the damage? And plan the case “declined or expired” from the start. That is what the next section is about.

Comment and Decline: The No That Teaches Something

Approve, decline, comment: the three buttons are deliberately plain. The comment makes the difference between a bare no and a no that someone can work with. It is stored together with the decision and is available to the following steps as the result of the approval step.

Important for building a workflow: a decline does not abort the run by itself. The approval step delivers the decision (“approved” or “declined”) and the comment, and the run continues. What happens next is up to you, ideally with a step that reacts to the decision. In the example workflow a sensible setup would be: only an approved reply is output. On a decline, the comment goes to the person who started the run so they can revise the draft.

The decision is recorded: who, when, with which comment. That is the proof that the approval took place, and at the same time the basis for understanding later why a reply went out the way it did.

Declining must come easily. If every decline feels like a conflict with the colleague who started the run, people approve rather than decline. Design the workflow so that a no is a normal intermediate state: a draft goes back, gets better and comes again. Then the no is not a failure but the point of the exercise.

Legal Context

Approvals produce data about people: who decided when, how fast and with which comment. That is intended, because it creates traceability. At the same time it can allow conclusions about behavior and performance. Where a works council exists, section 87(1) no. 6 of the German Works Constitution Act (Betriebsverfassungsgesetz) can give it a co-determination right over technical systems intended to monitor the behavior or performance of employees. Involve employee representatives early, ideally with a clear description of what is logged and what the data will not be used for.

If personal data is processed by a service provider, data processing under Art. 28 GDPR also belongs on your list. This is not legal advice, clarify the individual case with your legal counsel. For data storage in Germany and AI processing in the EU, read the page on security.

Our Position: Few Approvals, but Real Ones

We consider a few well-designed approvals more effective than many generic ones. A workflow should do as much as possible automatically and stop only at the few points where an action is irreversible, reaches the outside or binds the company. At those points the approval should show the content, name the case, ask a reachable and independent person, have a deadline that fits the process and allow a no that has an effect.

Then the approval is not a brake. It is the reason a workflow may do things that reach the outside at all. And it is honest: it does not claim that the model works without errors, but makes sure a human looks before a mistake becomes a commitment.

What You Can Take Away

Check every workflow that reaches the outside with eight questions:

1. 1.Which steps cannot be reversed, reach the outside or bind the company? An approval belongs only there.
2. 2.Does the approval show what takes effect, meaning the full draft with its sources, and not a summary?
3. 3.Does the title name the case, and does the description say what to look for?
4. 4.Are at least two reachable people on the list who can judge the content?
5. 5.Is the four-eyes principle switched on where commitments or effective changes are decided, and is at least one person on the list neither creator nor trigger?
6. 6.Does the deadline fit the rhythm of the process, including weekends and vacations?
7. 7.What happens after a decline or an expired deadline: does the trigger find out, and is there a defined next step?
8. 8.How many approvals does one person decide per day, and how many of them are never declined?

A start for next week: pick a workflow with an external effect, rewrite the approval's title and description, name a second person, and after two weeks check how many runs were declined or sent back. You will learn more from that number than from any policy.

If you would like to see what an approval step looks like in the editor and how a waiting run feels in practice, we are happy to show you in a demo, without obligation.