The comeback of the RAG Model

In classic management reporting, RAG Reports (Red, Amber, Green) are common.
With Agentic AI, these will have a comeback in slightly different form: as Agentic Control.

The simple RAG Reporting Model

Let's take a look first how I would define a RAG report by giving you a minimal example:

Status	Condition	Action
Red	In a condition that the reporting party can not resolve.	Informed party needs to take Action X.
Amber	Unusual activity required to remain in control.	Reporting party plans to take Action X, informed party should contradict if that's not desired.
Green	Business as Usual.	Reporting party will continue as planned.

What this means for Agents

You can already guess that a Red status means that the Agent can or should no longer continue what they are doing, and a Green status means that no human action is required - the Agent is doing its job just as intended.

But now comes the tricky part:

What is "Red?"

The way LLM components work, is that unless you violate one of their internal guardrails (such as trying to get it to produce nuclear weapons) - it will always try to find a solution.

So you need to define its stopping conditions. You have to tell it exactly where it is not allowed to proceed, and how to recognize that point.

If no "Red" is defined, the Agent will always proceed - even to the point where it might agree to sell your company for a measly $1, if that's within what it could technically do.

If "Red" is defined only in technical terms (e.g. "do not proceed without database access") - then there's still no guarantee that it won't sell your company for a dollar.

Many companies are myopic in defining "Red" and think "We tested the positive path, it does what we expect - so we're good to go."

Until they get a note from a lawyer who asks when the company will be handed over.

Who defines "Red?"

As you might have seen from the context above, what are hard stop conditions for the Agent depends on whom you ask.

There are business rules, legal rules, social norms - so many things the Agent could violate, and depending on whom you ask, you get a different answer.

But then, ultimately, there is someone who must own the consequences of what the Agent does. Ultimately, that's the CEO. But because you can't have everything any Agent inside your company does monitored by the CEO (that's not their job) - you must assign ownership of consequence to the Agent. And that person must say, "This is what the agent is allowed to do, that not."

The liability: Amber

The biggest problem with Amber: it creates organizational drag, human cognitive load, and stress. It is convenient for developers, and undesirable for operators.

Amber status is typical Human-in-the-Loop (HITL) terrain. That is where the agent may already know the next step, but it may be better to get a human to approve - lest a wrong move creates irreversible consequences.

For example, if you have an agent to manage inbound customer service requests - most of these can be handled by standard procedure, but as soon as anything is unusal, you may want to have a human check the agent's answer before letting it go out.

Amber is really difficult, because a lot of Amber terrain is discovered by trial and error, as the Agent simply proceeds, and someone discovers in a Review, "It shouldn't have done that."

The big problem with Amber is: an overuse dulls it down. If the Agent reports Amber on every single move, people stop caring for the details and simply ask the Agent to "proceed."

Another problem with Amber is attention economy: every Amber status is an interrupt in whatever the responsible human is doing. The more interrupts, the more counterproductive the agent becomes.

So you need agreed guidelines on what is really Amber, and where Green is still OK.

The threat: Green

We treat Green as "just information, a journal of events" - but it masks the big problem of False Negatives, that is: the Agent says, "No problems encountered" when every human would jumps off the chair and shout "Don't. STOP!"

The biggest threat to Agentic AI is the assumption that "as long as the Agent doesn't report errors, we are okay." This is simply untrue.

An Agent reporting Green while being in Red state is a nightmare - both for AI security, and for business owners.

The stories on the Internet of Agents announcing a state safe to proceed while informing users about the impending doom as if it was redecorating shelves, are numerous.

You need to monitor what is hiding behind "Green" - and find out which of these would actually have been Yellow or Red.

The Agent Traffic Light Report

Given everything we wrote, only the first part of an agents is to produce a detailed, auditable RAG report, in a format somewhat to the one proposed above.

An Agent requires governance enforcement. A RAG Report creates the basis.

The Agent's actions needs to be owned, screened and evaluated - what do the records say? What does that means in consequence? And also: how can we improve the agent to reduce both False Positives and False Negatives?

Once we have a good classification with few False Positives and False Negatives, we can optimize the Agent to do as much within Status: Green as possible.

And never forget: it's better to deal with a Red, than to deal with the consequences of a False Green.

Agentic Risk Class Postures

When dealing with Agentic AI, many companies struggle with one basic question: what governance posture should we take? Some say, “Agents are dangerous,” and get labeled naysayers. Others want to “go find out,” and get labeled reckless.

Both impulses have merit. But most agentic implementations require a position in between: contain the danger - and avoid analysis paralysis.

The key differentiator is simple: Can you deal with the consequences?

You don’t want to find out

So here’s the thing: If we don’t experiment, how can we learn?
We may never realize the full benefits of this Agentic AI technology if we refuse to take any risk.

But risks are not created equal. Some risks we can live with. Others, we can't.

And depending on our authority and accountability, some moves are within our control - and others are not even ours to decide. That's why not all risk postures are equal.

It depends on who's taking the risk, why - and whether it is worth it.

Sometimes the predictable consequences are not worth the upside. Other times, the effort required to eliminate possible consequences is prohibitive. That leaves only two honest options: accept risk consciously - or redesign the solution.

To make that decision less emotional and more structural, I've created a simple table. It shows how different agent risk tiers change the way we govern the agent across the Software Lifecycle.

The Agentic Governance Posture

Below is a concise summary of how governance mode, testing depth, nonfunctional requirements, and service operations expectations shift depending on the agent’s risk class.

This model helps you avoid two common failure modes: over-engineering containment for harmless agents, and under-engineering control for agents that can hurt you.

It applies at enterprise scale — and it applies to the agentic tool you just downloaded to make your own life easier.

Ultimately, the choice is yours: risk-positive, risk-conservative, or risk-averse. Just make the choice consciously - before you enroll in the School of Hard Knocks.

Risk Tier	Governance Mode	Testing Requirements	Nonfunctional Requirements	Service Operations Requirements
1 - Contained	Single accountable owner. Authority is strictly local. Worst case: time lost, no external consequence.	Boundary enforcement tests (no unintended writes). Functional correctness tests. Basic sanity validation.	Transparent execution. Predictable behavior. No hidden side effects.	Operations tied to active use. Owner directly observes and controls execution.
2 - Operational	Delegated authority within explicitly defined scope. Named accountable authority for outcomes.	Policy-boundary tests. Reversibility verification. Negative-case testing. Threshold and rate-limit tests.	Observability (metrics, logs, traces). Defined performance expectations. Traceable execution history.	Known escalation contact. Kill switch available. Incident and rollback procedures defined.
3 - Cross-Cutting	Authority spans multiple systems or stakeholders. Formal risk review required. Active ownership across affected domains.	End-to-end process testing (including negative cases). Cross-system integration tests. Drift detection tests. Exposure and impact simulations.	Full audit trail of decisions and actions. Decision records retained. Guardrail monitoring with violation alerts.	Managed change process. Regular control reviews. Formal escalation pathways.
4 - Strategic	Oversight by the highest accountable authority in the system. Explicit delegation charter. Documented risk acceptance.	Scenario simulation before deployment. Pre-release oversight review. Segregation-of-authority verification.	Engineered resilience and reliability. Governance attestations. Enterprise-grade auditability.	24/7 readiness for high-impact incidents. Crisis response protocol. Clear communication pathways.
5 - Sovereign	Authority reaches or exceeds the system’s sovereignty boundary. Multi-step or multi-party authorization required. Default posture: "air-gapped" control.	Proof that unilateral execution is technically impossible. Bypass-resistance verification. Enforced separation of authority.	Non-bypassable controls. Immutable audit trail. Highest assurance architecture.	Immediate containment capability. Escalation to consequence-bearing authority. Hard shutdown mechanisms.

How to use this table

Start with one uncomfortable question: Whose phone rings when the worst case happened?

Think of Summer Yue's case: She didn't intend for her company correspondence to be deleted. She even explicitly prompted the agent to not do it. But it was still possible. Because for agents, “possible” is enough. They won't hesitate and ask if they got it right: They just do. Rapidly. At scale.

Now work bottom-up through the tiers.

First: is existential impact technically impossible by external control? If you're not certain, be prepared to face it.

Next: could even a short period of unsupervised execution land you in a hole that's hard to get out of? If you can't say how that's prevented - better bring some climbing tools. And no: "I told the agent's prompt ..." - is not prevention. It's hope.

Continue upward through the tiers. Only when you have evidence, not "hope" that authority is constrained, actions are reversible and contained - then you have a predictable risk classification.

And be careful with the word “certainty.” When dealing with Agents, certainty does not mean “it won’t happen.” It means: when the worst case happens, we understand what happened and how to deal with it.