Risk-Aware Degraded-Mode Orchestration for Resilient Cloud–Edge AI Agents: From Containerized Fault Injection to Heterogeneous Kubernetes Validation

Imagine a world where your favorite apps aren't just single programs, but teams of tiny, invisible robots working together. One robot fetches the news, another checks the rules, a third writes the code, and a fourth talks to a giant brain (an AI) to make sense of it all. This is how modern "Cloud-Edge AI" works: a complex chain of services running across the internet and on your local devices. Usually, these teams are tough. If one robot trips, the others might retry, wait, or switch to a backup plan. But here's the catch: sometimes, just finishing the job isn't good enough. If the robot that checks the rules is missing, the team shouldn't just guess and keep going, because they might accidentally break something important or do something they aren't allowed to do. This is the tricky balance between "staying online" and "staying safe."

Enter a new idea called DMO-AI (Degraded-Mode Orchestration for AI). Think of it as a super-smart traffic cop for these robot teams. Instead of just saying "keep going" or "stop everything," this cop looks at the specific job the team is doing. Is it a low-risk task, like writing a fun story? Or is it a high-risk task, like moving money or changing a medical record? If the "rule-checker" robot is sick, the cop might say, "Okay, for the story, let's use an old rulebook we have on hand. But for the money transfer? Absolutely not. Stop and ask a human." This paper tests whether this smart, risk-aware traffic cop can keep more jobs running safely than the old, dumb ways of handling failures.

The Problem: The "All or Nothing" Trap

Imagine you are driving a self-driving car. The car needs to talk to a cloud server to know if the road is safe. Suddenly, the connection to the server gets spotty. What should the car do?

Old-school systems usually have two modes:

1. Fail-Open: "Keep driving! Maybe the road is fine." This is risky because the car might drive into a wall if the server was actually saying "Stop."
2. Fail-Closed: "Stop immediately!" This is super safe, but it means you sit in traffic forever, even if the road is actually clear and you just had a bad signal for a second.

The problem is that AI agents (like our robot teams) do many different things. Some are low-risk (like summarizing a news article), and some are high-risk (like deleting a database). A "one-size-fits-all" rule doesn't work. If you treat a low-risk summary the same way you treat a high-risk bank transfer, you either get unsafe results or you stop useful work unnecessarily.

The Solution: The Risk-Aware Traffic Cop

The authors of this paper, Albert Adusei Brobbey, Narayan Bhosale, and Dan Bamfo, built a new system called DMO-AI. Instead of just checking if the internet is working, this system asks three questions before letting a task continue:

1. How risky is this job? (Is it a fun story or a bank transfer?)
2. What is missing? (Is the "rule-checker" down, or just the "news-fetcher"?)
3. What can we do instead?

The system has a menu of "degraded modes" (backup plans) it can choose from:

• Normal: Everything is working.
• Local Model: If the giant cloud brain is down, use a smaller, simpler brain on the local device (but only for low-risk jobs).
• Cached Policy: If the rule-checker is down, use an old rulebook, but only if it's fresh enough for the risk level.
• Read-Only: If the tool that changes things is broken, just give advice without actually changing anything.
• Handoff: If it's too risky to guess, stop and ask a human.
• Block: If nothing safe can be done, just stop.

The key innovation is that the system chooses the right backup plan based on the risk. It won't let a high-risk job use a "local brain" just because the cloud one is down. It won't let a bank transfer use an old rulebook if the rulebook is too stale.

The Experiment: A Digital Obstacle Course

To see if this works, the researchers built a giant digital obstacle course. They created a test environment with four main services: a model (the brain), a retrieval service (the memory), a policy service (the rule-checker), and a tool service (the hands that do things).

They then used a tool called Toxiproxy to simulate disasters. They would freeze the "brain," disconnect the "rule-checker," or slow down the "hands" on purpose. They ran this simulation 141,000 times in a single computer setup and then 8,000 times in a more realistic setup with a real cloud server and a real edge device (like a Raspberry Pi or a small server).

They compared their new DMO-AI system against five other common ways of handling failures:

• Fail-Open: Just keep going.
• Fail-Closed: Stop everything.
• Retry Budget: Try again a few times, then give up.
• Circuit Breaker: Stop if things are broken, try once if they are slow.
• Service Mesh: A standard network traffic manager that doesn't know about AI risks.

The Results: Safety Without the Stop Sign

The results were clear and exciting. In the big test with 8,000 events, the standard Service Mesh (the traffic manager that doesn't know about AI risks) managed to complete tasks safely only 64.70% of the time. It either let unsafe things happen or stopped too many useful things.

The new DMO-AI system, however, achieved 93.95% safe completion. That is a massive jump of nearly 29 percentage points.

Here is what happened in the details:

• Zero Unsafe Outcomes: In the main tests, DMO-AI had 0.00% unsafe outcomes and 0.00% policy violations. It never let a high-risk job go through without the right rules.
• Better than "Fail-Open": The "Fail-Open" system completed more tasks overall, but 9.67% of them were unsafe (like writing a bank transfer without checking the rules). DMO-AI completed fewer unsafe tasks but kept the useful ones running.
• Better than "Fail-Closed": The "Fail-Closed" system was safe, but it blocked 41.57% of all tasks, even the easy ones. DMO-AI only blocked 1.13% of tasks.

The researchers also tested what happens if you remove the "risk awareness" from the system. When they turned off the part that checks if a job is high or low risk, the safety score dropped, and unsafe outcomes appeared. This proved that the "risk brain" is the most important part of the system.

They also checked the cost. The system added a tiny bit of delay (about 19 milliseconds on average in the real-world test), but this was a small price to pay for keeping the system safe and running.

What This Means

This paper shows that we don't have to choose between "stopping everything" and "letting anything happen." By teaching the system to understand the risk of the task, we can keep low-risk jobs running even when things break, while strictly stopping high-risk jobs from doing dangerous things.

The authors are careful to say this isn't a magic bullet for every problem in the world yet. They tested it in a controlled environment with specific types of failures. But the results suggest that for the future of AI agents, we need a "traffic cop" that knows the difference between a fun story and a bank transfer, and can make smart choices when the internet gets shaky.

In short: DMO-AI is a new way to keep AI agents safe and useful, even when parts of their brain or memory go offline. It's like having a guardian angel that knows exactly when to say "go ahead," "wait," or "ask a human," ensuring that the robot team never gets into trouble.