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.

AI Estimation - helping you understand Architectural Quality

Artificial Intelligence can be a blessing and a curse. While developing VXS, I have come upon a personal reflection exercise:
At the end of every working day, I tell my IDE AI to "please explain all the changes we have made today."
Then, I feed the output into chatGPT and ask it, "Please provide for me a conservative estimate for this backlog."
The result is usually something like this:

The Evening Ritual

Every evening I close the laptop with a simple ritual. I ask my IDE's assistant to explain, in plain language, everything that changed today: which modules moved, which interfaces shifted, which tests were added or deleted, where the seams tightened or tore. It replies with a neutral, factual log. No heroics, no storytelling, just the anatomy of the pure code work.

I take that log and hand it to an external estimator (I use chatGPT) with a fixed prompt: "Give me a conservative effort estimate for the following backlog:" The prompt never changes. The intent never changes. Only the code does. And I'm not asking for a plan or a deadline. I'm asking for a mirror.

The estimator returns a number and, more importantly, a decomposition of why the number is what it is. I archive the result alongside the day's log. Tomorrow I'll do it again. Over weeks, a pattern emerges: sometimes the estimated effort grows; sometimes it shrinks; sometimes it holds steady. The numbers are not my speedometer. They're my oil pressure gauge.

How I do it

Consistency makes this work: I use a consistent source description (the IDE's explanatory log) and an identical estimator (same prompt, same assistant). The descriptive prompt helps keep things consistent. The only variation I tolerate is that I separate either by user-facing behaviour (for anything that has user impact) or technical behaviour (things that affect structure or technical arrangements rather than users) - the point is categorical comparability, not theatrics.

My git commit logs are the source of truth. I don't talk about work that is not visible in the codebase. So it excludes anything that does not lead to a technical change: and that's on purpose. We will get to that soon.

I never doubt the estimate. I never ask for a second-guess unless chatGPT made obviously wrong assumptions. I do not think I'm a hero if the number is high. Nobody knows the real numbers - except me and my dev diary. I am interested in a single question: "What did today's work say about the architecture's ability to accept change?"

Why I do it

Most development "estimation" is theater. I don't have time for theater. I am not in a situation where it matters how long something takes - what matters is that it's done, and it works. I don't care how fast other people work - I care what I accomplish. I don't care what is easy or difficult - I care for the results I produce. So the estimates themselves are not the value.

And I don't care for quantity of output - what I am concerned with is malleability - the rate at which the system can absorb change. This one property tells me whether the system is getting better or deteriorating over time. The result might look like this:

Interpreting AI estimates as "architectural telemetry" flips the estimation narrative on its head. When the estimates rise over time, it means the system is able to absorb larger changes than before: The boundaries are clear, the tests reliably catch issues, the code is adaptive, and the coupling of components is honest. However, a decline in estimates is caused by poor changes: Poor modularity, Clean Code Violations, WET code, "unidentifiable bugs," unfixable tests, non-working features. These are all things that steal my time and result in fewer changes integrated over the course of the day.

So what I end up with is not a developer performance metric - it's an architectural quality metric, and an extremely powerful indicator of Technical Debt. This measure is much more connected to business value than anything that others measure before: If I can do 3 days of work in 1 day, it means that my engineering efforts are highly valuable. If it were 1/2 day, I'd better throw away the entire codebase and start from scratch.

Additionally, this routine also helps me check cognitive drift. Immersion blurs judgment. The AI, as an external estimator, given a fixed description, stays objective enough to challenge my gut. It stays neutral and unbiased. It has no incentive to make me feel good or bad about the work I do. It is pure consequence. This removes the emotional justification from the process.

How you can use this

You do not need a specific tool to adopt this. All you need is a rhythm: a factual daily log, a consistent external estimator, and a small note about your architectural intent. Done steadily, the series becomes a quiet diagnostic of design health. You will discover whether your system starts resisting meaningful change, and you can see the payoff of investments into code quality long before defect curves become visible.

There's a temptation to optimize the number, and managers may be tempted to look for high numbers. But: Goodhart's Law is inevitable if you try. The entire approach only works because it's not about making numbers go up. The number is just a mirror. And it helps you reflect on key design questions: "Why was this so hard, when AI said it should be easy?" - "What can we do to make it easier without getting ourselves into a pickle tomorrow?" - "What prevents or causes deterioration of change integration?" The answers will relentlessly point out the weak spots in both your architecture and your development approach.

Over time, you will notice the codebase becoming calmer. Working in this way and asking these questions frequently leads to Relentless Improvement. No tests? You did poor. Tight coupling? You blew the estimate. Hardcoding? You can't keep it. And that's the value of the exercise: a leading indicator of architectural quality that you can gather with nothing more than honesty and repetition.

Tips & Tricks

When the estimates of today's work increase after a deliberate cleanup, that's the right track. Keep going. You've unlocked leverage: the same unit of intent now reaches farther into the system.

When estimates decrease without special causes (e.g., you had a lot of meetings, were sick etc.) - stop and look for debt: hidden coupling, missing tests, undocumented contracts.

When estimates stay constant while scope expands, confirm that your boundaries are carrying their weight; if they are, you've found equilibrium worth defending.

The point of the AI Estimation metric is not to go faster. The point is to stay flexible. True agility in software development is "the ability to achieve more tomorrow than you could today, with less sweat or fear." When used in this way, AI estimates will tell you whether you're creating or losing that freedom.