I Tested an AI Agent on My Live Systems. Here Is the Blast Radius Assessment Every Engineer Is Skipping.

An AI agent went viral last week. The creator got hired by OpenAI within days of the announcement. Instagram reels with seven-figure view counts are telling engineers to wire the agent into their inbox, their CRM, their project tools, and then step back. The pitch is simple. Autonomous execution. Zero oversight. Hours of your week handed back.

I built an isolated Mac environment and ran the agent through every task I could think up.

The software worked. The concept did not survive contact with a real operational context.

The agent can do the work. That was never the question. The question is what happens when it does the work wrong, and whether you find out before your client does.

So this is not a review of OpenClaw. It is an analysis of the deployment decision itself, and of why the question most engineers are asking is the wrong one.

The Wrong Question#

The wrong question is: what can this agent do?

The demo answers that one cleanly. It summarizes emails. It updates CRM records. It drafts replies and pushes Notion updates. Every one of those runs fine in a controlled environment with clean data, clear intent, and no ambiguity to trip over.

Production is none of those things. It carries relationship context the model cannot see. It runs on implicit rules the team enforces but never wrote down. And it lives in communication threads where tone, timing, and word choice carry business consequences that no training set has fully encoded.

The right question is: what can this agent break, and what is the recovery time?

That is an architectural question. Most of the engineers buying Mac Minis this weekend are not asking it.

Blast Radius: The Metric That Determines Safe Deployment#

Blast radius comes out of system reliability engineering. Applied to an agent, it measures the maximum damage that agent can do with the permissions it holds right now, and whether that damage is reversible inside a recovery window you can actually live with.

Every permission you grant is a ceiling on that radius. Read access to one email thread sits low. Write access to the primary inbox does not. Its ceiling includes unauthorized client commitments, archived active deals, and reputational damage that no rollback command will undo.

Before an agent touches a live system, every permission gets its own assessment:

What is the worst action this agent can take with this permission? Is it reversible? In under ten minutes?

If the answer to either of the last two is no, that permission does not belong in production.

Why Slack and Email Are the Highest-Risk Starting Points#

The hype cycle reaches for email and messaging as the first integration. Architecturally, that is backwards.

Slack#

Slack carries organizational hierarchy in every channel. Say the agent reads a ticket thread. It does not know that pinging a VP in a public channel about a P3 issue is a career event, not a notification. It does not understand that some threads are politically loaded, or that a confident summary dropped in front of leadership shifts the conversation in ways no rollback touches.

A misclassified priority, escalated on its own, in front of the wrong audience, is not an automation failure. It is a political incident with your name on it.

Email#

Email carries relationship context stretching back months or years. The agent reads a thread. It does not know this client is mid-negotiation. It does not know the last message you sent was deliberately vague to keep the conversation open. It answers with precision, reads the literal text, and misses the intent entirely.

An autonomous send from your address, to a client, misreading an open negotiation, is not an automation failure. It is a business incident. It may be a legal one.

These are the systems that should get agent write access last, not first.

The Deployment Framework#

1. The Empty Mandate Test#

Before anything ships, the agent has to pass the Empty Mandate Test. You define the task in one sentence. Not a category. Not a workflow. One specific, repeatable task.

1
✅  "Summarize tier-1 support tickets into a daily Slack brief."

That one gets a deployment date.

1
❌  "Manage my communications."

That one does not.

If you cannot write it in a single sentence, the agent has no job description, and it should not be near your systems.

2. The Staged Promotion Model#

Safe deployment runs through a promotion model. It is never a single-step connection.

Stage 1 → Read-Only Observation. The agent can reach the system but cannot write, send, or modify anything. It observes, summarizes, surfaces patterns. You study its output across at least thirty real interactions. You write down where it hallucinates, where it misclassifies, and where the context window hands you a confident summary that happens to be wrong.

Stage 2 → Draft-Only Access. The agent produces outputs that need human review and explicit approval before anything happens. Every email draft gets read. Every CRM note gets read before it is saved. The agent proposes. The Architect approves. This is not friction. It is validation data.

Stage 3 → Supervised Execution. Once Stage 2 behavior holds up, the agent gets scoped write access for one defined, low-blast-radius task. One task. One system. Logged, and reviewed weekly.

Stage 4 → Earned Autonomy. Autonomy is a reward for proven reliability. It is not a switch you flip at install time. You extend it in small increments, and a revocation plan stays live at every stage.

In any high-stakes context, most agents never reach Stage 4. That is the correct outcome. Controlled output at Stage 2 or 3 beats uncontrolled autonomy at Stage 4 every time.

The Notion Problem Nobody Is Talking About#

Notion sits at the center of most knowledge-heavy workflows. It holds architecture decisions, project context, client notes, and institutional memory built up over years.

An agent with write access to a live Notion workspace is operating on the organizational brain.

It will reorganize. It will deduplicate. It will decide some pages are redundant and merge them. And it will do all of this with total confidence, on pattern matching alone, with no idea why a page exists in its current shape or who leans on that shape.

You do not see the damage right away. It shows up three weeks later, when someone opens a page that got rewritten and finds the original context gone.

Notion needs the most conservative assessment of anything in a typical stack. Read-only on specific databases is where you start. Unrestricted write access is not on the roadmap until the behavior has been validated in isolation for a long stretch.

The Architectural Verdict#

Agents are a real capability. The use case is legitimate. At the right scope, the efficiency gains are measurable.

The deployment philosophy being sold in this hype cycle is not. It skips the blast radius assessment outright. It treats autonomy as a feature to switch on, not a property to earn.

The architect’s job is not to chase the demo. It is to map the worst case before the first API key gets issued.

Read-only first. Draft-only second. Scoped writes after validated behavior. Earned autonomy last, if at all, in high-stakes systems.

That sequence is not caution. It is architecture.

The engineers who skip it will have their recovery story inside six months. The Architects who follow it get a deployment they can stand behind.

Vladimir Mikhalev

Docker Captain · IBM Champion · AWS Community Builder

The Verdict — production-tested analysis on YouTube.

YouTube GitHub LinkedIn