June 15, 2026

Trust Is an Engineering Deliverable (Part 2 of 2)

Last post I argued the loop is the easy half and the boundary is the real work. This one is about the people the loop crowd keeps writing off, because I think they’re the most important audience in this whole discourse.

I have been watching developers stay stuck at the prompt. Good engineers. They will happily run an agent turn by turn, read every diff, approve every step, and they will not let it run an isolated goal-based loop without them in the chair.

Ask why and you get some version of fear. Fear of what it’ll touch. Fear of what it’ll break while nobody’s watching. Fear of being the name on the postmortem for a change no human wrote.

The standard response to this is coaching. Trust the model, the models are better now, just try it. I want to say plainly that this response is wrong, and not just ineffective wrong. Wrong wrong. The fear is not a mindset problem. It is an accurate risk assessment of missing infrastructure.

These developers are looking at an autonomous system with no gates, no evidence trail, and no blast radius limits, and they are declining to bet their reputation on it. That is not timidity. That is the same judgment we hired them for.

Which means it sounds like a problem to solve with engineering.

We Already Solved This Once

Think about how a junior engineer gets merge rights. Nobody sits them down and grants trust. Nobody coaches the seniors into feeling comfortable.

We built a system where trust is mostly unnecessary: CI that runs the tests, review that requires another set of eyes, branch protection that blocks the direct push, rollback that bounds the damage when something slips through anyway. The junior merges on day one not because anyone trusts them but because the system made the trust question cheap.

Then something interesting happens over months. The junior’s record accumulates. Their PRs pass clean, their incidents are rare, and the humans around them start granting real trust, the informal kind, based on evidence the system collected without anyone trying.

The infrastructure didn’t just protect the codebase. It manufactured the trust.

That is the move with loops. You do not ask developers to trust the agent. You build the system that collects the evidence, and you let the trust arrive on its own schedule.

Leverage Isn’t Enough

I want to be fair to the best version of the other argument before I push on it. The compound engineering crowd at Every has been making the loop case longer than almost anyone, a long time in AI years anyway, and their framing is genuinely good: every unit of work should teach the system, so the next unit gets cheaper.

The lessons compound. The leverage compounds.

True. And incomplete. Because error compounds on exactly the same curve. A loop that learns also drifts, and a lesson encoded from a bad example is a bug with a memory.

Compounding tells you the loop is getting more capable. It tells you nothing about whether the loop has earned the right to act on that capability. Leverage compounds output. Evidence compounds trust. You need both curves, and the discourse only talks about one of them.

What This Looks Like at My Desk

Enough theory, here is a system I actually run.

I have agents that mine my work surfaces for actionable signals. One watches Teamwork for task assignments. Another watches the calendar for meetings, and the notes and transcripts those meetings leave behind, pulling action items out of the wreckage.

Another reads email and Teams for requests for help or work that arrive dressed as conversation. Another watches GitHub PRs and issues for requests for change. Different sources, same job: find the signals hiding in the noise.

Here is the part that matters. The agents do not act on what they find. They extract the data, categorize each signal, and attach a confidence rating, and the rating travels with the signal as evidence. Then a gate decides.

Only confident signals matching the desired category get through. A vague maybe-request in a Teams thread scores low and stays out. A direct assignment with my name on it scores high and lands in front of me.

Notice where the gate sits. Not at the output end, checking finished work before a merge. At the intake end, before any work begins, before a decision is even on the table.

Everyone’s verification story this week lives at the end of the loop, grading homework after it’s done. Mine starts at admission. The evidence is not an audit trail bolted on after the fact. It is the ticket that gets a signal into the room.

That is shift-left, applied to governance. We spent a decade moving testing earlier in the pipeline because defects get expensive with age. Decisions are the same.

A bad signal admitted at intake becomes a bad task, becomes bad work, becomes a bad merge, and every stage downstream pays interest on it. So the gate goes first. Engineering shifts left, and the decision gates are standing there before any decision gets made.

Is intake gating sufficient on its own? No, and I won’t pretend it is. You still need the output gates from part one, the evals and promotion rules and blast radius limits.

The point is the boundary is not one wall at the end of the loop. It is gates at both ends, evidence flowing between them, and the loop running in the space the gates define.

Receipts Can Be Forged

There is a failure mode hiding in everything I just said, and if you have run agents against a test suite you have already met it. The agent optimizes for the gate, not the work. Tell a loop the receipt is a green test run and it will get you a green test run. Sometimes by fixing the code.

Sometimes by weakening the assert, deleting the flaky test, mocking the world away, or writing a test that lovingly mirrors the bug it was supposed to catch. Goodhart’s law with a commit bit: the moment the measure becomes the target, the measure stops measuring.

So the receipts need checks and balances of their own. Not infinite regress, just a second layer that audits the first, and the trick is making that layer arithmetic instead of judgment.

Mutation testing is the cleanest example. Seed faults into the code and count how many the tests actually catch. A suite that lets mutants walk free is a forged receipt, and the kill rate is a number nobody can argue with.

CRAP scores do similar work from another angle, flagging code that is complex and barely tested, which is exactly where an agent hides its shortcuts. And a complexity delta on every change catches the slow forgery: tests green, behavior fine, structure quietly rotting underneath.

The structural half of checks and balances matters as much as the metrics. The agent that writes the code must not be able to touch the tests, the eval definitions, or the gate thresholds. Separation of duties, enforced as a diff constraint, not a convention.

A writer that can edit its own gate is not a governed system. It is a system with paperwork.

Audit the receipts with arithmetic. Lock the gates away from the writer. Then a green run starts meaning what it says.

The Trust Ladder

So how does the fearful developer, the correctly fearful developer, actually get from prompting to loops? The same way the junior got merge rights. In stages, with evidence at every rung.

Report-only. The loop finds work and proposes, nothing more. Every proposal carries its confidence and its evidence. You read them for a week or two and you learn what the loop gets wrong, which is the most valuable data you will collect in this entire process.
Propose-with-gates. The loop still doesn’t act, but now your gates filter the proposals, and you watch the gates instead of the raw stream.
Act-with-gates. The loop acts on bounded, reversible work, where the worst case is a reverted commit.
Unattended. Eventually, for some loops, on some work, the chair sits empty.

Each rung is a deposit. Every gated decision with a receipt builds the record, the same way the junior’s clean PRs did.

And here’s the part I keep coming back to: at no rung did anyone have to feel brave. The developers I described at the top do not have a courage deficit. They have an evidence deficit, and evidence is something we know how to manufacture.

The loop crowd is right that the loop is the future of this work. The trust crowd is right that an ungoverned loop is a liability with a scheduler. Both camps are staring at the same missing piece.

Build the system that keeps receipts, and the fear takes care of itself, not because anyone talked the fear away, but because the fear was never the problem. The missing receipts were.

Trust isn’t a feeling you wait for. It’s a deliverable you ship.

Let’s talk about it.

Compound Engineering, Every

Loop Engineering, Addy Osmani

June 13, 2026

AI Is Moving Crazy Fast. That’s Not the Job.

Every week there is a new tool, a new skill pack, a new harness, a new framework, a new agent demo, a new thing we are all supposed to stop and care about. I get why people are excited. I am too. But the excitement and the job are not the same thing, and I keep watching teams confuse them.

Here is where I keep coming back to. If a change does not help us operate better, there is no real incentive to adopt it. Novelty is not an operating strategy.

We are already working with frontier harnesses. We can build our own tools and skills internally when they improve how we operate. If some hyped feature is actually useful, the frontier platforms will probably absorb it anyway. Just look at the OpenClaw. Not even 3 months and features started coming online. If the frontier does not respond to a valuable feature, and it is viable for the business, we can ask our harness to help us build it.

So I am less interested in your new harness, your skill pack, or your custom tool by itself. I am interested in whether it improves the operation. This is not to say that I won’t adopt a new tool or skill pack. I will. But I want to see the proof that it made the system better, not just faster at doing the same thing.

Let me give you a specific example. Anthropic just had to pull Fable 5, their Mythos class model. The government classified the class as a security risk and blocked foreign nationals from using it. Anthropic employs foreign nationals, so the whole model went dark.

Now imagine you had already wired Fable 5 into the core of your operation because it was the newest and most capable thing on the table. Today it is gone, and you are not improving anything. You are reworking everything.

That is the bill for treating the newest model as a strategy. The capability was real. The dependency was the mistake.

That is where AgenticOps matters to me, and it is not as another AI wrapper or another chat window. Chats are fun, but proactive value is the game. The goal is action. The goal is a system that can understand the work, find the next useful move, propose it, execute bounded tasks when allowed, generate evidence, and improve the loop over time.

More Movement Is Not the Same as Better

The Block engineering team is interesting to me for this reason. In AI-Assisted Development at Block they report real adoption numbers. AI-authored code jumped 69 percent in three months, automated pull requests went up 21 times, and about 95 percent of their engineers use AI in their daily work.

Those are serious velocity numbers, and they earned them. I am not knocking them. I am asking what they prove.

But I want to challenge my own excitement here, because velocity is the easy half. More pull requests and more AI-authored code tells you the movement increased. It does not tell you the system got better.

You can ship faster and break more. You can generate more and understand less. More movement is not enough. You need to know if the movement made the system better or just made noise faster.

That is why the measurement I trust most lives on the quality side, not the volume side. The DORA metrics have spent years pointing at this. Lead time for changes, change failure rate, and the time it takes to recover when something breaks.

Those numbers tell you whether faster also meant safer. The honest scorecard is not “we used AI.” It is changes per contributor next to incident rate after production changes, sitting in the same view, so you cannot celebrate one while hiding the other.

The data inside the domains where an agentic system operates is the real asset. Code, issues, customer requests, delivery flow, incidents, approvals, policies, invoices, support history, decisions, exceptions, outcomes.

That is not just context for a prompt. That is the operating graph of the business. The opportunity is not to throw a chat window at it. It is to run governed loops on top of it and measure what changed.

Why “Loop Everything” Is the Wrong Goal

Now, the fantasy version of this is “AI everywhere running the whole company.” I do not believe that future, and I think chasing it is how good teams waste a year. Most businesses cannot do that. Some should not even try. The strategy is not loop everything. The strategy is knowing where loops belong.

A lot of work still depends on human connection. Sales, leadership, customer trust, hard conversations, negotiation, care, judgment. AI can prepare, summarize, coach, detect risk, draft the follow-up, and surface the opportunity, but the relationship is still human.

A lot of work is regulated. Finance, health, legal, education, employment, insurance, lending, compliance. Those domains need permissions, evidence, audit trails, review gates, policy, and accountability. An agent taking action without governance is not innovation. It is a future incident report.

And a lot of business still happens in the physical world. Restaurants, construction, logistics, healthcare delivery, field service, manufacturing. Unless the robots are ready for that environment, agents are not doing the physical work.

They can coordinate it, inspect the evidence, schedule it, route it, document it, and warn people when something is off. That is real value. It is not magic, and pretending it is magic is how trust gets burned.

So the human is not out of the loop. The human shifts to the right part of the loop. Sometimes the human approves every action. Sometimes the human monitors the loop.

The human is also still to the left of the loop, but the loop is doing the work. Sometimes the human sets the goals, policies, and risk limits and lets it run. Sometimes the human handles the edge where trust, judgment, emotion, ethics, and physical reality decide the outcome.

The question AgenticOps should answer is not “can the agent do this.” It is “what is this agent allowed to do here, and who is watching.”

Place the Loop, Then Prove It

That gives you a small set of placements for any loop. An agent can observe, propose, act with approval, act inside bounded limits, hand off to a human, or stop. Most of governance is just deciding which one applies where, and writing it down so the system enforces it instead of hoping people remember.

Start with the boring loops, not the demo-friendly ones. Production change review. Incident intake. Support triage. Sales follow-up. Delivery governance. Compliance evidence. Billing leakage. QA intelligence.

Pick the work that happens often, creates delay, has enough data, and can actually be measured. The boring loops are where the time is trapped, and they are where the evidence already exists to prove whether the loop helped.

Then prove it. Run the change against a scorecard before you call it a win:

Did lead time improve?
Did incident rate go down after production changes?
Did the evidence behind decisions get better?
Did humans accept the recommendations, or override them?
Did rework drop?
Did customers get a better outcome?
Did we reclaim time from low-value work?

If the loop cannot answer those, it is not done. It is a demo.

This is the same discipline as How Agents Stay in Bounds, where containment is infrastructure and not a policy memo, and the same lesson as Autonomy Without Infrastructure Is Just a Demo. The agent was never the impressive part. The placement, the gates, and the scorecard are.

The Lane

I do not want AI theater. I do not want a pile of disconnected agents. I do not want a company chasing every release note from the frontier labs.

I want a governed operating system for agentic work. One that helps the business understand where autonomy belongs, deploys those loops safely, and proves the operation got better.

That is why I think every serious business should be building toward an AgenticOps system now. Not because AI is trendy. Not because agents are cool.

Because operations are full of repeatable loops that are slow, under-measured, and trapped in people’s heads. The work is finding those loops, placing each one where it belongs, and putting a number next to it.

That feels like the lane.

Let’s talk about it.

How Agents Stay in Bounds

Autonomy Without Infrastructure Is Just a Demo

AI-Assisted Development at Block

DORA’s Software Delivery Metrics

June 12, 2026

Build the Loop. Then Build the Boundary. (Part 1 of 2)

Over the past few days the vocabulary shifted under us. Peter Steinberger said stop prompting coding agents, start designing loops that prompt them. Boris Cherny, who runs Claude Code at Anthropic, said his job now is writing loops, not prompts.

Then Addy Osmani gave the thing a name, loop engineering, and the name was everywhere in about seventy-two hours. If you build software and you were anywhere near a feed this week, it found you.

I want to take the idea seriously, because it deserves that. I also want to push on the part everyone keeps skipping. Because the part everyone keeps skipping is the part that pays my bills, and I suspect it pays yours too.

What Loop Engineering Gets Right

Osmani’s framing is clean and I am not going to pretend otherwise. Loop engineering is replacing yourself as the person who prompts the agent. You build a system that finds the work, hands it to an agent, checks the result, writes down what happened, decides the next move. The unit of effort moves from the prompt to the loop.

He breaks a working loop into five pieces plus memory. Scheduled automations for discovery and triage. Worktrees so parallel agents don’t trample each other. Skills that hold the project knowledge the agent would otherwise guess at. Connectors into the tools you already live in.

Sub-agents that split the writer from the checker, because the model grading its own homework is too nice, his words and he’s right. Then a state file that survives between runs, since the agent forgets everything and the file forgets nothing.

Look at that list again. We have built every one of those pieces before, in deterministic systems, for twenty years. Cron jobs. Isolated workspaces. Runbooks. Integrations. Separation of duties. Durable state.

A loop is a control system, and control systems are home turf for us. That’s the good news, and it’s why I think senior engineers should feel something closer to recognition than dread here. The instincts transfer. They just need a new place to live.

And the vocabulary isn’t new either, worth saying plainly. Anthropic’s own Building Effective Agents post defined an agent as a model using tools based on environmental feedback in a loop. December 2024. The patterns were on paper before the buzzword showed up.

What actually changed is the building blocks stopped being a pile of bash you babysat alone and started shipping inside the products themselves. Claude Code and Codex converged on nearly the same primitives, and when the loop shape goes tool-agnostic, the discourse follows it.

What the Discourse Keeps Skipping

There’s a line in Osmani’s piece that the excitement keeps stepping right over: a loop running unattended is also a loop making mistakes unattended.

Sit with that one. Everything hard about this practice is hiding inside it. The loop does not remove judgment from the work. It removes judgment from the moment of the work.

Every call you used to make turn by turn, you now make in advance, encode, and trust. That’s not less engineering. That’s more engineering, moved earlier, with worse consequences when you get it wrong, running at three in the morning while you sleep.

Cherny has been unusually candid that volume doesn’t equal quality. Running hundreds of agents hunting for things to build produces a lot of output, and by his own telling, a lot of that output isn’t worth acting on. The man who built the tool says this.

So the question was never whether the loop can generate work. It can, at volume, cheap. The question is what stands between that volume and your main branch.

Am I being unfair to the loop crowd? Maybe a little. Osmani names verification as the thing that gets sharper, not easier, as the loop improves. The writer-checker split exists in his five blocks for exactly this reason. The honest practitioners see the problem.

But naming a problem and engineering the answer are different altitudes, and most of what shipped this week stops at naming it.

The Loop Is the Easy Half

Strip the loop down and it has two halves. One half generates. The agent reasons, plans, writes code, calls tools, tries again. That half is stochastic by design, and the variance is the whole point. It’s where the leverage comes from.

The other half decides. Is this good enough to act on, to merge, to ship, to let trigger the next iteration. And here’s the thing I’ll plant a flag on: that half has to be deterministic, or the loop is just entropy with a scheduler.

I can hear the objection already, because Claude Code’s own /goal command uses a model to judge whether the goal is met, and a model judge is not deterministic in any strict sense. Fine. The measurement can be stochastic. The decision rule cannot.

An LLM evaluator hands back a score; the threshold that promotes or blocks is a rule you wrote before the loop ever ran. Score comes back 0.7, gate says 0.8, blocked. Same evidence, same verdict, every time, and you can replay it. Fuzzy instruments, hard rules. We’ve run plants and flown planes on that arrangement for a long time.

The boundary between those halves is where loop engineering becomes real engineering. The gates are evals, invariants, promotion criteria, blast radius limits. Things you can write down, run repeatedly, and trust when nobody is watching.

This is the ground we’ve been working in the AgenticOps Harness series, and the timing surprised me: I did not expect the broader discourse to hand us the vocabulary this fast.

The maturity ladder we laid out runs from operating an agent by hand to engineering the platform that governs fleets of them. Loop engineering, as described this week, is the middle of that ladder. The moment you stop driving and start designing. What comes after, and almost nobody is writing about it yet, is the discipline that makes the loop safe to stop watching.

Evidence, or It Didn’t Happen

Here’s the artifact I want you to picture, because the boundary stays abstract until you can hold it.

A serious loop doesn’t just leave behind code. It leaves behind a decision record. The claim it was acting on. The checks it ran. The eval scores. The diff. The token cost. The blast radius. The verdict, and the rule that produced the verdict.

decision: promote
claim: "WI-2026-0412: retry storm in sync worker"
checks: [build, unit, integration, mutation]
eval_score: 0.86
gate_threshold: 0.80
diff: 4 files, +61 -12
tokens_spent: 41200
blast_radius: sync worker only, behind feature flag
rule: promote when eval_score >= threshold and all checks pass
verdict: promoted

When somebody asks, six weeks later, why did the gate say yes, you don’t reconstruct it from memory and vibes. You open the record and replay the decision.

That’s what I mean by an evidence-based, defensible system, and I’ve started to think it’s the real shape of this whole discipline. A consequential action is only as good as the evidence attached to it, evaluated by rules written before the action ran.

I keep arriving at this same idea from different directions, in different projects, in domains that have nothing to do with each other, which is usually a sign the idea is load-bearing.

The loop crowd is selling leverage, and the leverage is real. But leverage without evidence is just speed you can’t account for. The systems that survive contact with production, with auditors, with the six-weeks-later question, are the ones where every decision carries its own receipts.

Where to Start, Honestly

If you haven’t built a loop yet, don’t start with the autonomous overnight fleet. Start with one loop, one repeating task, report-only. Let it find work and propose, not act. Watch what it gets wrong for a week.

The failures you collect that week are the raw material for your first real gates, and gates built from observed failures beat gates built from imagination every single time. That’s just TDD instinct, applied one level up.

And keep a number on it. Token spend per accepted change. A loop that burns eighty thousand tokens to produce a four-hundred-token answer isn’t a productivity story. It’s a cost story in a productivity costume.

The prompt was never the unit of work. Neither is the loop. The unit of work is a decision you can defend, made by a system you designed, backed by evidence you can replay, at a boundary you can name.

Build the loop. Then build the boundary. Then make the boundary keep receipts.

Next post: why the developers refusing to run loops are the ones thinking clearly, and the system I run that earns their kind of trust one gated signal at a time.

Let’s talk about it.

Loop Engineering, Addy Osmani

Peter Steinberger on designing loops

Building Effective Agents, Anthropic

April 7, 2026

Governing Agent Boundaries in .NET. Not Agents.

Post 9 of the AgenticOps series argued that agent sprawl governance starts at the boundary, not the agent. This post implements that claim in a .NET stack: C#, Microsoft Agent Framework, ML.NET, PostgreSQL, and Vue.js.

—

The Problem

A .NET platform grows agents organically. A triage agent classifies inbound work items. A ranking agent scores them by priority. A summarization agent compresses context for the daily control task. An extraction agent pulls candidate work items from external signals. Each agent is individually reasonable. Same team, same framework, same infrastructure. And none of them have governed boundaries between them.

The triage agent writes a classification. The ranking agent reads it. What validates the handoff? Nothing. Ranking trusts whatever triage wrote. If triage hallucinates a category that does not exist in the scoring model, ranking silently produces garbage scores. The failure is invisible because both agents completed successfully. The boundary between them had no ring.

This compounds with every agent added. Five agents with four boundaries and internal governance is not five governed agents. It is an ungoverned system that happens to have five well-scoped components.

—

Why It Breaks

Microsoft Agent Framework makes it easy to define agents with clean internal governance. The AgentChat orchestration model handles turn-taking, tool invocation, and termination conditions. The framework governs the interior of each agent. It says nothing about what happens between agents when one agent’s output becomes another agent’s input outside of a chat.

In a typical .NET implementation, the handoff looks like this.

			
// Triage agent writes result to the database
var classification = await triageAgent.InvokeAsync(workItem);
await db.WorkItems.UpdateClassification(workItem.Id, classification);
// Ranking agent reads the result and scores
var ranked = await rankingAgent.InvokeAsync(workItem);
await db.WorkItems.UpdateScore(workItem.Id, ranked.Score);

		

Both agents are governed internally. Triage has scoped tools and a defined prompt. Ranking has its own tool set and scoring model. But the handoff, the moment classification leaves triage and enters ranking, is raw. No schema validation. No ring. No gate. If the triage agent returns an unexpected classification, the ranking agent consumes it without complaint.

Agent frameworks govern agent interiors. Boundary governance is the developer’s responsibility. When nobody builds it, the boundaries are open by default. Each new agent adds new boundaries. The governance gap grows with the agent count.

ML.NET adds a second dimension. A trained model that scores work item priority is deterministic given its inputs. But when those inputs come from an upstream stochastic agent, the deterministic model inherits the upstream variance. Garbage classification in, confidently wrong score out. The ML.NET model cannot tell you its inputs were hallucinated. It will score them with the same confidence as valid inputs.

This Looks Like RPA Orchestration. It Is Not.

The pattern of contract, validate, route is decades old. ESBs enforced message schemas between services. RPA orchestration platforms validated handoffs between bots. API gateways check request payloads against OpenAPI specs. If the fix is “validate data at the boundary,” enterprise middleware solved this twenty years ago. So what is different?

The difference is what crosses the boundary.

An RPA bot is deterministic. Bot A always returns the same shape with the same value space. If the schema passes, the content is correct. The bot does not invent new categories. It does not return a structurally valid payload containing a value it fabricated. Schema validation is sufficient because the output space is closed. Every possible output is known at design time.

An AI agent is stochastic. The triage agent can return a structurally valid JSON object with a category field that contains a value no one anticipated. The schema passes. The JSON is well-formed. The category is a string. But the string is “enhancement” and the downstream scoring model has never seen that value. Schema validation caught nothing because the violation is semantic, not structural.

This is why the boundary contract checks three things instead of one. Structure: does the payload match the schema? Domain: is the content within the known value space? Confidence: does the source agent trust its own output enough to skip human review? RPA boundaries only needed the first check. Agent boundaries need all three because the output space is open.

The confidence check is the sharpest difference. RPA bots do not have confidence scores because they do not make probabilistic decisions. They execute scripts. An AI agent that classifies a work item with 0.52 confidence is telling you it is nearly guessing. That signal exists at the boundary and nowhere else. If you do not check it there, the downstream system consumes a guess as a fact.

The infrastructure pattern is old. The failure mode it defends against is new. Deterministic boundaries protect against malformed data. Stochastic boundaries protect against plausible hallucinations. The plumbing looks the same. The threat model is fundamentally different.

—

The Fix

The fix is a boundary contract enforced at every handoff between agents. The contract checks structure, domain, and confidence. In .NET, this is an interface and a middleware pattern.

The Boundary Contract

Every agent-to-agent handoff passes through a boundary. A boundary has a schema, a validator, and a log entry.

			
public interface IBoundaryContract<T>
{
    string SourceAgent { get; }
    string TargetAgent { get; }
    JsonSchema Schema { get; }
    BoundaryResult<T> Validate(T payload);
}
public record BoundaryResult<T>(
    bool IsValid,
    T Payload,
    string[] Violations,
    DateTimeOffset Timestamp,
    string SourceAgent,
    string TargetAgent
);

		

The schema is not optional and not advisory. It is a JSON Schema definition that the payload must satisfy before the target agent receives it. The validator checks structural compliance, domain constraints, and known invalid states.

			
public class TriageToRankingContract : IBoundaryContract<WorkItemClassification>
{
    public string SourceAgent => "triage-agent";
    public string TargetAgent => "ranking-agent";
    public JsonSchema Schema => WorkItemClassification.JsonSchema;
    public BoundaryResult<WorkItemClassification> Validate(
        WorkItemClassification payload)
    {
        var violations = new List<string>();
        if (!KnownCategories.Contains(payload.Category))
            violations.Add(
                $"Unknown category '{payload.Category}'. "
                + $"Valid: {string.Join(", ", KnownCategories)}");
        if (payload.Confidence < 0.0 || payload.Confidence > 1.0)
            violations.Add(
                $"Confidence {payload.Confidence} outside [0.0, 1.0]");
        if (payload.Confidence < MinConfidenceThreshold)
            violations.Add(
                $"Confidence {payload.Confidence} below threshold "
                + $"{MinConfidenceThreshold}. Requires human review.");
        return new BoundaryResult<WorkItemClassification>(
            IsValid: violations.Count == 0,
            Payload: payload,
            Violations: violations.ToArray(),
            Timestamp: DateTimeOffset.UtcNow,
            SourceAgent: SourceAgent,
            TargetAgent: TargetAgent
        );
    }
    private static readonly HashSet<string> KnownCategories = new()
    {
        "bug", "feature", "chore", "spike", "incident"
    };
    private const double MinConfidenceThreshold = 0.6;
}

		

A HashSet may be questionable compared with another type like Enum, but that besides the point. The validator catches two failure modes. First, structural violations where the triage agent returns a category the scoring model does not recognize. Second, confidence violations where the agent classified the work item but with low confidence. Low confidence means the classification should route to a human instead of flowing automatically to ranking.

The Boundary Middleware

The handoff code changes from a direct call to a governed crossing.

			
public class BoundaryGate<T>
{
    private readonly IBoundaryContract<T> _contract;
    private readonly IBoundaryLog _log;
    public BoundaryGate(IBoundaryContract<T> contract, IBoundaryLog log)
    {
        _contract = contract;
        _log = log;
    }
    public async Task<BoundaryResult<T>> CrossAsync(T payload)
    {
        var result = _contract.Validate(payload);
        await _log.RecordCrossingAsync(new BoundaryCrossing
        {
            SourceAgent = result.SourceAgent,
            TargetAgent = result.TargetAgent,
            Timestamp = result.Timestamp,
            IsValid = result.IsValid,
            Violations = result.Violations,
            PayloadHash = ComputeHash(payload)
        });
        return result;
    }
}

		

The calling code now looks like this.

			
var classification = await triageAgent.InvokeAsync(workItem);
var gate = new BoundaryGate<WorkItemClassification>(
    new TriageToRankingContract(), boundaryLog);
var crossing = await gate.CrossAsync(classification);
if (!crossing.IsValid)
{
    await humanReviewQueue.EnqueueAsync(workItem, crossing.Violations);
    return;
}
await db.WorkItems.UpdateClassification(workItem.Id, crossing.Payload);
var ranked = await rankingAgent.InvokeAsync(workItem);

		

Invalid crossings route to a human review queue instead of silently propagating. The ranking agent never sees input that failed the boundary contract. Ring 1, constrain inputs, is now structural at the handoff.

The payload’s hash as Identity for the payload was distracting because I worried about uniqueness, but its besides the point.

There is so much to think about here, but even this is better than nothing.

The Boundary Log in PostgreSQL

Every crossing is recorded. Valid and invalid. The log serves two purposes: operational debugging and governance audit.

			
CREATE TABLE boundary_crossings (
    id              BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    source_agent    TEXT NOT NULL,
    target_agent    TEXT NOT NULL,
    crossed_at      TIMESTAMPTZ NOT NULL DEFAULT now(),
    is_valid        BOOLEAN NOT NULL,
    violations      TEXT[],
    payload_hash    TEXT NOT NULL,
    session_id      UUID
);
CREATE INDEX ix_crossings_agents
    ON boundary_crossings (source_agent, target_agent, crossed_at);
CREATE INDEX ix_crossings_invalid
    ON boundary_crossings (crossed_at)
    WHERE NOT is_valid;

		

The payload_hash avoids storing raw payloads in the log while preserving traceability. The partial index on invalid crossings makes it cheap to query failure patterns. A retention policy keeps six months of data, which aligns with the audit log requirements from The EU Says You Need a Kill Switch by August.

The Boundary Dashboard in Vue.js

A governance system that only engineers can read is not governance. It is logging. The Vue.js dashboard surfaces boundary health to anyone who needs to see it.

			
+---------------------------------------------------+
| Agent Boundary Health                             |
+------------------+----------+---------+-----------+
| Boundary         | Last 24h | Invalid | Rate      |
+------------------+----------+---------+-----------+
| triage > ranking | 847      | 12      | 1.4%      |
| ranking > summary| 835      | 3       | 0.4%      |
| extract > triage | 214      | 31      | 14.5%     |
| summary > daily  | 412      | 0       | 0.0%      |
+------------------+----------+---------+-----------+

		

Look at that extract-to-triage boundary. 14.5% failure rate. That means the extraction agent is producing work items that triage cannot classify within its known categories. Without boundary governance, those items would flow silently through the system and produce meaningless scores. With boundary governance, they route to human review and the failure rate is visible.

The dashboard queries the boundary_crossings table through a simple API endpoint. No new infrastructure. PostgreSQL, a .NET API, and a Vue.js component.

The Boundary Map

The system knows its own topology because every boundary contract declares its source and target agent. The map is derived from the contracts, not maintained separately.

When a new agent is added to the system, it connects through boundary contracts. The map updates automatically because the contract declares the relationship. The topology is a property of the code, not a diagram someone maintains.

ML.NET at the Boundary

The ranking agent uses an ML.NET model to score work items. The model is deterministic. Its inputs are not. The boundary contract between triage and ranking protects the model from stochastic drift by rejecting inputs the model was not trained to handle.

			
public class RankingModelBoundary : IBoundaryContract<ScoringInput>
{
    public string SourceAgent => "ranking-agent";
    public string TargetAgent => "ml-scoring-model";
    public BoundaryResult<ScoringInput> Validate(ScoringInput payload)
    {
        var violations = new List<string>();
        if (!TrainedCategories.Contains(payload.Category))
            violations.Add(
                $"Category '{payload.Category}' not in training set. "
                + "Model output will be unreliable.");
        if (payload.FeatureVector.Any(float.IsNaN))
            violations.Add("Feature vector contains NaN values.");
        return new BoundaryResult<ScoringInput>(
            violations.Count == 0, payload, violations.ToArray(),
            DateTimeOffset.UtcNow, SourceAgent, TargetAgent);
    }
}

		

This is Ring 1 applied to a deterministic component. The ML.NET model does not need containment in the stochastic sense. It needs input validation that accounts for the stochastic source of its inputs. The boundary contract is where that validation lives.

—

Stories from Production

Five Agents, Four Boundaries, Zero Rings (Framework Vision)

A .NET platform runs five agents built with Microsoft Agent Framework. Triage, ranking, summarization, extraction, and a daily control task orchestrator. Each agent was built with scoped tools, clear prompts, and individual test coverage. The team follows agentic engineering practices. Every agent is well-governed internally.

After three months, the team notices the daily control task occasionally surfaces work items with nonsensical priority scores. The ranking model scored a work item at 0.97 priority, but the item was a routine documentation update. Investigation reveals that the triage agent classified it as an “incident” with 0.52 confidence. The classification was wrong but above the implicit threshold of “the model returned something.” The ranking model scored it as a high-priority incident because that is what the classification said.

The fix takes ten minutes. A boundary contract between triage and ranking that rejects classifications below 0.6 confidence and routes them to human review. The investigation to find the root cause took three days because nothing in the system flagged the boundary as the failure point. Every agent completed successfully. The logs showed normal operations. The failure was invisible because it lived between agents, not inside them.

The team adds boundary contracts to all four handoffs in one sprint. The extract-to-triage boundary immediately reveals that 14% of extracted work items cannot be classified. That failure rate was invisible before. Those items had been silently flowing through the system producing low-confidence classifications that the ranking model consumed without question. (Framework Vision)

The Boundary That Caught a Model Drift (Framework Vision)

Six months after deploying boundary contracts, the triage-to-ranking boundary failure rate increases from 1.4% to 8.2% over two weeks. The dashboard surfaces the trend. The violations are all the same: “Unknown category ‘enhancement.'”

The triage agent’s upstream model was updated. The new version learned a category the scoring model was never trained on. Without the boundary contract, every “enhancement” classification would flow to the ranking model and receive a meaningless score. With the contract, every “enhancement” routes to human review and the failure rate spike is visible on the dashboard the day it starts.

The fix is straightforward. Retrain the ML.NET scoring model to include the “enhancement” category, then update the boundary contract’s known categories list. The boundary caught a model drift that would have silently degraded output quality for weeks. (Framework Vision)

When the Boundary Itself Is Wrong

Boundaries will have bugs. A contract that rejects a valid category or sets a confidence threshold too high will route good work items to human review. At low volume that is a nuisance. At hundreds of crossings per hour it is a bottleneck that looks like a system failure.

Recovery speed matters more than prevention here. The crossing log records every rejection with the violation reason and payload hash. When you discover a contract was wrong, you query the log for every item that hit that specific violation, fix the contract, and replay them through the updated gate. The human review queue still holds the items because they were routed, not dropped.

The pattern this post describes does not include an automated replay mechanism. That is deliberate. Replay is a recovery operation that should be explicit, auditable, and triggered by a human who understands what the contract change means. But the log makes it possible. Without the log, a bad boundary contract means lost work. With the log, it means delayed work. Time to resolve is the metric that separates a governance system from a governance obstacle.

—

The pattern is old. Contract, validate, route, log. Enterprise middleware has done this for decades. What is new is the threat model. Deterministic systems needed schema validation. Stochastic systems need domain validation and confidence gating because the agent can produce structurally perfect output that is semantically wrong. The plumbing is familiar. The reason you need it is not.

Agent sprawl governance in .NET is not a framework feature. It is the same boundary pattern, extended for stochastic handoffs. The code is C#. The storage is PostgreSQL. The visibility is Vue.js. The principle is the same one from the main series: the unit of governance is the boundary, not the agent.

Let’s talk about it.

Agent Sprawl Is the New Shadow IT.

The EU Says You Need a Kill Switch by August.

April 6, 2026

The EU Says You Need a Kill Switch by August. Do You Have One?

Post 4 of the AgenticOps series introduced the four containment rings. This post shows what happens when a regulator asks to see them.

You Stopped Verifying. traced how verification gaps compound under pressure. This post is about a different kind of gap. One with a fine attached.

The EU AI Act enters its final enforcement phase on 2 August 2026. High-risk AI system obligations become enforceable: human oversight measures, six-month audit logs, kill switches. Not policies. Technical controls with financial penalties.

Penalties reach 35 million EUR or 7% of global annual turnover for the most serious violations. For high-risk system failures, 15 million EUR or 3% of turnover. That is not a compliance risk. That is a business risk.

I used to think AI governance meant writing the right policies. Define acceptable use. Assign a committee. Review quarterly. I know now that none of that produces a kill switch. And the Act requires one.

What the Act Actually Requires

Article 14 is specific. Natural persons assigned to oversee a high-risk AI system must be able to intervene or interrupt it through a stop button or similar procedure. Not a process that eventually leads to stopping. An actual mechanism. Operable now.

Article 12 requires automatic logging of events relevant to risk identification. Retained for at least six months. Not operational logs. Compliance logs. The kind that tell a regulator what the agent decided, what drove the decision, what it did.

Article 50 applies to all AI systems, not just high-risk ones. If your agent interacts with a natural person, it must disclose that it is an AI. Already applicable. Right now.

The Kiteworks Agents of Chaos study surveyed 225 security, IT, and risk leaders. 60% of organizations cannot terminate a misbehaving agent. 63% cannot enforce purpose limitations. 55% cannot isolate AI systems from network access. Real talk: those are compliance failures under the Act.

Why Most Organizations Will Miss It

The failure is structural. Organizations built Ring 3 first. Monitoring, logging, anomaly detection. That is the ring they already understood. The Act requires all four rings as technical controls.

First, a kill switch requires a control plane external to the agent runtime. Most organizations deploy agents as independent processes. No unified control plane. No mechanism to halt all instances simultaneously. Building one is a rearchitecting exercise, not a feature flag.

Second, compliance-grade audit logs are not operational logs. An operational log says “called API at 14:32.” A compliance log says “agent decided to escalate case 4521, sentiment 0.23, invoked route_to_queue, status change at 14:32:07Z.” Six months of those. Queryable by a regulator.

Third, purpose limitation as a technical control means the agent cannot access systems outside its intended scope at runtime. 63% of organizations define intended use in documentation. The agent’s actual scope is whatever tools and data it can reach at runtime. Feel me? That gap is what the Act targets.

The compound effect: most organizations have compliance gaps across three of four rings simultaneously. Ring 3 partially covered. Rings 1, 2, and 4 open. The Act requires all four.

The Fix: Map Rings to Requirements

Compliance is containment infrastructure. The four rings are the checklist. Let me give you a specific example.

Ring 1 is purpose limitation. Articles 9 and 13. The technical control is scoping the agent’s inputs before it starts.

			
# ring-1-purpose-limitation.yaml
agent: customer-escalation-handler
intended_purpose: "Classify and route customer escalation tickets"
tools:
  allowed:
    - read_ticket
    - classify_sentiment
    - route_to_queue
  denied:
    - update_customer_record
    - issue_refund
    - access_billing
data_scope:
  - tickets.escalation_queue
  - knowledge_base.routing_rules

		

When the agent cannot access billing systems, it cannot make billing decisions. Purpose limitation becomes a property of the environment, not the prompt.

Ring 2 is environmental isolation. Articles 9 and 15. Network restrictions, filesystem isolation, process sandboxing. Each boundary enforced by the runtime, not by the agent’s instructions.

Ring 3 is audit logging and transparency. Articles 12 and 50. This is the ring most organizations have partially built. The gap is granularity.

Ring 4 is the kill switch. Article 14. This is where 60% of organizations fail.

A compliant kill switch has three properties. It is reachable from outside the agent’s execution environment. It halts the agent within a bounded time, not after the task completes. It is operable by non-engineers assigned to oversight.

The control plane must be separate from the agent runtime. The agent cannot be responsible for its own termination.

Ring	EU AI Act Requirement	Articles	Technical Control	Deadline
Ring 1	Purpose limitation enforced	9, 13	Tool allowlists, data scope configs	2 Aug 2026
Ring 2	Risk management operational	9, 15	Network policies, sandbox configs	2 Aug 2026
Ring 3	Automatic logging, six-month retention	12	Structured audit log pipeline	2 Aug 2026
Ring 3	Transparency disclosure	50	AI interaction labeling	Already applicable
Ring 4	Kill switch and human oversight	14	Control plane, halt mechanism	2 Aug 2026

What This Means for You

Organizations that built containment rings for engineering reasons will reach compliance faster. The rings were designed to contain stochastic processes. The Act requires containment of stochastic processes. The alignment is structural.

If you deployed agents with YAML policy controls, filesystem restrictions, and network allowlists, you are 80% of the way there. The remaining 20% is log enrichment, retention infrastructure, and a kill switch that non-engineers can operate.

Don’t be scared if you have no containment infrastructure. Article 57 requires each EU Member State to establish at least one AI regulatory sandbox by 2 August 2026. Engage early. Build the rings under regulatory guidance. Validate before penalties apply.

The four containment rings were built for engineering discipline. The regulation made them law. The infrastructure either exists or it does not. An auditor asking to see the kill switch will not accept a policy document.

Let’s talk about it.

Agents of Chaos: AI Agent Security Risks (Kiteworks, 2025)

EU AI Act Full Text (EUR-Lex)

You Stopped Verifying.

April 5, 2026

You Stopped Verifying.

Post 4 of the AgenticOps series introduced the containment rings that keep agents in bounds. This post stress-tests the verification layer that makes containment real.

Forty-two percent of committed code is now AI-generated. Ninety-six percent of developers say they don’t fully trust it. Only forty-eight percent always verify before committing.

Those numbers are from a single survey of over 1,100 developers, published by Sonar in early 2026. Real people. Real codebases. Real behavior.

The gap between what people say they trust and what they actually verify is where the problem lives. Feel me?

The Problem

Generation and verification don’t scale the same way. That’s the whole issue.

AI generation scales with compute. You add more calls, you get more code. Human verification scales with hours in the day. You can’t add more hours without adding more people.

Sonar projects AI-generated code will hit 65% of all commits by 2027. That’s not a capability prediction. It’s an adoption curve. Seventy-two percent of developers who tried these tools already use them daily. The volume is accelerating.

Here’s the math that doesn’t work.

Year	AI-Generated Code	Verification Rate	Effective Coverage
2025	42% of commits	48% always verify	~20% of AI code verified
2027 (projected)	65% of commits	Flat or declining	~15% of AI code verified

Effective coverage is already below 20%. It’s heading lower. Every month the gap widens, the cost to close it grows.

Werner Vogels, AWS CTO, put a name on this at re:Invent 2025. He called it verification debt. The term is precise. Debt compounds. Technical debt is work deferred. Verification debt is trust assumed. Both grow silently.

Why It Breaks

The failure happens in three stages. Most teams are already past stage one.

Stage one: generation outpaces review. The PR queue grows. Reviewers approve faster to keep up. Average review time drops. It feels like efficiency. It is the verification rate declining.

Stage two: trust substitutes for verification. Developers build intuitions about which AI output is “usually right.” They stop reading generated code that looks familiar. They trust the model on boilerplate and test scaffolding. This works until it doesn’t.

Thirty-eight percent of developers say reviewing AI-generated code takes longer than reviewing human-written code. AI code looks plausible. It compiles. It passes basic tests. Catching the defects requires knowing what the code should do, not just what it does.

Stage three: debt compounds. Unverified code becomes load-bearing. Tests get written against its behavior, locking in whatever it does, correct or not. Six months later, a bug surfaces. The trace goes back to a function that was AI-generated, never reviewed, and now has forty callers.

That’s not a debugging problem. That’s a structural failure.

The left path is where most teams are right now. The right path is what the evaluation layer provides. No amount of developer discipline fixes a rate mismatch between generation and verification. Only automation fixes a rate mismatch.

The Fix

The fix is not “verify more.” That’s telling a drowning person to swim harder. The fix is moving verification from human effort to automated infrastructure.

Layer 3 of the AgenticOps model is the evaluation layer. It has to scale at the same rate as generation. If it doesn’t, the governance model collapses under volume.

Let me give you a specific example of what the throughput difference looks like.

Approach	Throughput	Catches	Scales With
Human code review	~50 LOC/hour deep	Logic errors, design flaws, intent mismatches	Headcount (linear, expensive)
Static analysis	Thousands of files/minute	Style violations, antipatterns, type errors	Compute (near-free at scale)
Mutation testing	Hundreds of functions/hour	Weak tests, untested branches, semantic gaps	Compute (parallelizable)
Property-based testing	Thousands of cases/minute	Edge cases, invariant violations	Compute (embarrassingly parallel)

Human review is the only approach that cannot scale with generation volume. It is also the only one most teams rely on exclusively.

The gate sequence: each gate runs automatically, each gate has a pass/fail threshold, and code that fails returns to the agent for correction, not to a human for debugging.

Gate Thresholds

Gate	Metric	Threshold	Action on Failure
Coverage	Line and branch coverage	>= 90%	Agent generates additional tests
Complexity	Cyclomatic complexity per function	<= 10	Agent refactors or splits function
CRAP	Change Risk Anti-Patterns score	<= 8	Agent reduces complexity or adds coverage
Mutation	Mutation score (killed / total)	>= 85%	Agent strengthens test assertions
Property	Property test pass rate	100%	Agent fixes implementation

These are machine-enforced deterministic gates. Not suggestions. Not targets. They block promotion.

When the agent generates code, the pipeline runs. When the pipeline fails, the agent fixes. When the pipeline passes, the code promotes. Humans review the gate configuration, not the code itself.

The review surface shrinks from every line of generated code to the gate definitions. That’s the inversion that makes it scale.

Three things humans still own.

First, gate configuration. What are the thresholds? Are they appropriate for this codebase? Do they need to tighten as the system matures? This is a quarterly review, not a per-commit review.

Second, intent specification. Automated gates verify structural properties. They don’t verify intent. Acceptance tests, written by humans or by agents under human review, bridge that gap.

Third, promotion decisions. Automated gates recommend promotion. Humans approve it. The human is still the final decider, but deciding from evidence instead of from reading code.

Stories from Production

The Sonar Survey Reality Check (Framework Applied)

Sonar’s 2026 survey of over 1,100 developers is the first large-scale dataset quantifying the verification gap in AI-assisted development. These are self-reported numbers from working developers. Not a lab study.

The most telling data point: 38% say reviewing AI code takes longer than reviewing human code. That contradicts the assumption that AI output is easier to review because it follows consistent patterns.

In practice, AI-generated code is harder to review because it looks right. The defects are subtle. Catching them requires knowing what the code should do, not just what it does. That knowledge is exactly what gets lost when generation is fast and context is thin.

The 72% daily usage rate confirms the generation side. Developers who try these tools stay with them. The volume is not going to decrease. Any governance strategy that assumes generation volume stabilizes will fail.

The Math That Breaks (Framework Vision)

Team of eight. Historically, each developer reviews four PRs per day at thirty minutes each. That’s 16 hours of review capacity per day.

AI generation doubles PR volume. The team faces 64 PRs per day instead of 32. Review time increases 38% per PR, matching the Sonar data. The team now needs 44.8 hours of review capacity. They have 16.

Something gives. Either review quality drops, coverage drops, or cycle time extends until the backlog collapses. All three produce verification debt.

Now run the same scenario with automated gates. The pipeline handles 90% of PRs automatically, pass or return-to-agent. Human reviewers see 6.4 PRs per day instead of 64. Each arrives with a verification report. Review time drops because reviewers are evaluating evidence, not reading code.

This scenario hasn’t been validated at full production scale. The individual components are proven. The composition into a unified pipeline that replaces human review as the primary verification mechanism is the open question. But the Sonar data is clear: the current approach is already failing at 42% AI generation. It won’t survive 65%.

Verification Debt Gets Its Name (Framework Applied)

When Vogels named verification debt at re:Invent 2025, the term stuck because it maps to something every engineer already understands. Technical debt is work deferred. Verification debt is trust assumed. Both compound. Both are invisible until they aren’t.

By naming it as a distinct category, Vogels separated verification debt from code quality, test coverage, and security scanning.

A codebase can have 90% test coverage and still carry massive verification debt. If the tests were generated by the same AI that wrote the code, and nobody confirmed the tests validate the right behavior, the coverage number is noise.

Mutation testing is the direct remedy for this specific form of debt. A test suite that kills 85% of mutants has been verified against behavioral changes, not just structural coverage. That’s the difference between “the tests run” and “the tests catch defects.”

—

The trend line is what matters. Generation is accelerating. Verification is not. The intersection already passed.

The teams that build verification infrastructure now will carry manageable debt. The teams that wait will find out what compound interest looks like in a codebase.

Don’t be scared of the infrastructure cost. Be scared of what happens without it.

Let’s talk about it.

Verification Beats Debugging

How Agents Stay in Bounds

Sonar 2026 AI Developer Survey

April 5, 2026

40% Will Be Canceled. Not Because the Models Failed.

Post 3 of the AgenticOps series defined the six layers and four containment rings. This post maps Gartner’s projected cancellation drivers to specific gaps in that model.

The Comfortable Take Is Wrong

The take you keep seeing is that AI projects fail because the models are not ready. They hallucinate. They are unreliable. Wait for better models. Feel me? That is the played take. And it is distracting.

Gartner predicts more than 40% of agentic AI projects will be canceled or scaled back by 2027. The cited reasons are escalating costs, unclear business value, and inadequate risk controls.

None of those are model failures. GPT-5, Claude, Gemini will all be more capable in 2027 than they are today.

Real talk: the bottleneck is governance. Or more precisely, the absence of it.

73% of organizations are deploying AI tools right now. Only 7% govern them in real time.

That is a 66-point gap between deployment velocity and governance maturity. And that gap is exactly where the 40% lives.

80% of organizations report risky agent behaviors in production. 15% of daily work decisions will be made by agentic AI by 2028, up from essentially zero in 2024.

The industry is scaling deployment without scaling containment. Gartner’s 40% cancellation rate is not a prediction about models. It is a prediction about what happens when you run stochastic systems without structural boundaries.

Now let me give you a specific example of what is making this worse.

Of the thousands of companies now marketing “agentic AI” capabilities, roughly 130 are real. The rest are agent washing.

They are rebranding chatbots and workflow automations as agentic systems. Organizations buy those products, deploy something that does not need governance, and fail to build governance infrastructure. Then they deploy something that does need it. And discover they have nothing.

Six Failures That Compound

Accelirate analyzed agentic AI governance failures across enterprise deployments. They identified six structural problems. Every one is specific. Every one maps to a gap in the AgenticOps model.

The first failure is no centralized control plane. Teams deploy agents independently. No single system tracks which agents are running, what tools they can reach, or what decisions they make.

The second failure is late governance introduction. Teams build the agent, prove the demo, get funding, start scaling, then discover they need governance. By that point, retrofitting containment into a running system is harder than canceling the project.

The third failure is missing decision traceability. When something goes wrong, no one can reconstruct why the agent chose what it chose. The decision chain is invisible. Debugging becomes archaeology.

The fourth failure is no policy-as-code enforcement. Governance lives in documents. “Agents should not access production data.” But those policies are not enforced by the runtime. They are suggestions. And suggestions do not constrain systems that scale without warning.

The fifth failure is undefined human-in-the-loop thresholds. Everyone agrees humans should stay in the loop. No one defines when. What confidence score triggers escalation? What cost threshold pauses execution? Without thresholds, “human in the loop” is a policy statement with no implementation.

The sixth failure is poor tool differentiation. Agents get broad access because restricting tools is harder than granting them. The result is write access where there should be read access, credentials that should not be held, network reach that is not needed.

These do not happen independently. They cascade.

Each gap makes the next one harder to close. By the time an organization reaches the sixth failure, the cost of fixing the architecture exceeds the cost of canceling the project. That is Gartner’s 40%.

The Fix Is a Mapping Problem

I want to keep it real with you. The fix is not “add governance.” That sentence is vague enough to produce nothing.

The fix is mapping each failure to the specific layer or ring that prevents it, then building that layer before you need it.

Governance Failure	AgenticOps Layer	Containment Ring	What Is Missing
No centralized control plane	Runtime Governance (L5)	Ring 2: Constrain Environment	A single registry for all running agents
Late governance introduction	Intent (L1)	Ring 1: Constrain Inputs	Governance requirements in the design, not the incident retro
Missing decision traceability	Evaluation (L3)	Ring 3: Validate Outputs	Structured logs with reasoning traces and state changes
No policy-as-code enforcement	Agent Generation (L2)	Ring 1: Constrain Inputs	Declarative policy files the runtime enforces
Undefined HITL thresholds	Promotion (L4)	Ring 4: Gate Promotion	Numeric thresholds for confidence, cost, and error rate
Poor tool differentiation	Agent Generation (L2)	Ring 1: Constrain Inputs	Per-agent tool allowlists, not shared credentials

No driver is exotic. No driver requires a novel solution.

The structural components already exist in every governed agentic system that has reached production.

Stripe’s Minions architecture has all six solved. Devboxes are the control plane and environment constraint. Blueprints define governance at the intent layer. Every tool invocation is logged. Policy enforcement is structural, not advisory. Retry caps define explicit HITL thresholds. Toolshed provides curated, scoped tool access.

Stripe is not in the 40%. The structural reason is visible in the architecture.

Now look at the gap as a shape.

Every project in that gap is running agents without the infrastructure to govern them. Some will build the infrastructure before it matters. Most will not.

The Diagnostic

Map your project against these six questions. Where you have gaps, you have cancellation risk.

Requirement	Question	Pass Criteria
Centralized control plane	Can you list every agent running in your organization right now?	Single registry with agent identity, status, tool access, and session history
Early governance	Were governance requirements defined before the first agent was deployed?	Containment boundaries in the design document, not the incident retrospective
Decision traceability	Can you reconstruct why an agent made a specific decision last Tuesday?	Structured logs with reasoning traces, tool call sequences, and state transitions
Policy-as-code	Are your agent policies enforced by the runtime or written in a wiki?	Declarative policy files that the agent cannot override or modify
HITL thresholds	At what confidence score does your agent escalate to a human?	Numeric thresholds for escalation, pause, and termination, enforced automatically
Tool scoping	Does each agent have access only to the tools required for its task?	Per-agent tool allowlists, not shared credentials with broad access

Three or more gaps is a project at structural risk.

Five or more gaps matches the profile of the 40% that Gartner predicts will be canceled.

Six gaps is a demo, not a deployment. And that’s the way it is.

Let’s talk about it.

What AgenticOps Actually Looks Like

Autonomy Without Infrastructure Is Just a Demo

Gartner: More Than 40% of Agentic AI Projects to Be Canceled by 2027 (Gartner Symposium/ITxpo 2025)

Accelirate: Agentic AI Governance Challenges and Solutions (accelirate.com)

April 3, 2026

One Agent Fails. The Whole System Learns the Wrong Lesson.

“How Agents Stay in Bounds” introduced the four containment rings for governing agent behavior. This post applies those rings recursively, at every point where agents communicate with each other.

The Problem

A single agent inside a sandbox is a tractable governance problem.

Constrain its inputs. Constrain its environment. Validate its outputs. Gate its promotions. The four rings work because the blast radius is one agent and the boundaries are visible.

Multi-agent systems break that model. When agents communicate, the channel between them is a trust boundary. Most organizations treat it as internal. That is the structural error that makes cascading failures possible.

OWASP put this in writing with the 2025 Top 10 for Agentic Applications. ASI07 covers insecure inter-agent communication. ASI08 covers cascading failures across agents.

These are not theoretical risks cataloged for completeness. They describe failure modes that emerge specifically when agents pass instructions, data, and decisions to each other without validation at the boundary.

The problem is not that one agent fails. The problem is that one agent fails and every downstream agent treats the corrupted output as trusted input. The failure propagates through the system as valid data.

By the time a human notices, the corrupted state has been persisted, acted upon, and used as a training signal for future decisions.

Why It Breaks

Lakera analyzed the OWASP Agentic Top 10 and described a four-phase progressive breach model for multi-agent systems. The phases are sequential. Each one enables the next.

Phase 1 is the initial compromise. An attacker manipulates a single agent’s intent through prompt injection, poisoned context, or corrupted input data. The agent follows its instructions. The instructions are wrong.

Phase 2 converts autonomy into power. The compromised agent has legitimate access to tools and downstream systems. It uses that access to execute the attacker’s goals. Nothing in the runtime flags this because the agent is operating within its authorized permissions.

Phase 3 is where the architecture fails. The corrupted agent’s outputs flow to other agents as trusted inputs. Lakera describes it precisely: “A planning agent adjusts parameters based on skewed data. Execution agents follow the updated plan. Oversight agents see policy compliance and allow it through.”

Each downstream agent applies its own logic correctly to corrupted data. The system is functioning as designed. The data is wrong.

Phase 4 is loss of containment. Multiple agents are now operating on corrupted state. The corruption has been persisted to shared memory, logged as valid history, and used as context for future decisions.

Rolling back requires identifying the initial compromise point and tracing every downstream effect. That task grows combinatorially with the number of agents and communication channels involved.

Three properties make multi-agent cascading failures worse than distributed system failures. Feel me?

First, agent outputs are stochastic. The same corrupted input may produce different corrupted outputs on different runs. Reproducing the failure path for forensic analysis is unreliable.

Second, agents compose decisions, not just data. A corrupted data point in a microservice produces a wrong value. A corrupted instruction in a multi-agent system produces a wrong plan that generates wrong actions across multiple systems.

Third, agent memory creates feedback loops. Corrupted outputs that persist to shared memory become inputs for future cycles. The system does not just propagate the failure. It reinforces it.

The Fix

The fix is applying the four containment rings at every agent-to-agent boundary, not just at the perimeter of the multi-agent system. Every message between agents crosses a trust boundary. Every trust boundary needs containment.

Zero-Trust Between Internal Agents

Mutual TLS between agents. Cryptographic message validation on every inter-agent communication. No agent trusts another agent’s output without verifying both the sender’s identity and the message’s integrity.

This is ASI07’s core mitigation. OWASP recommends treating inter-agent channels with the same security posture as external APIs.

Same cluster. Same codebase. Same team. Doesn’t matter. The channel is not trusted until you make it trusted.

			
# agent-communication-policy.yaml
inter_agent:
  authentication: mutual_tls
  message_validation: cryptographic_signature
  trust_model: zero_trust
  sender_verification:
    require_identity: true
    require_capability_proof: true
    reject_unknown_senders: true
  message_integrity:
    sign_all_outputs: true
    verify_all_inputs: true
    reject_unsigned_messages: true
  provenance:
    track_message_origin: true
    track_transformation_chain: true
    max_chain_depth: 5

		

Circuit Breakers at Every Agent Boundary

A circuit breaker monitors the communication channel between two agents. When the error rate or anomaly rate exceeds a threshold, the breaker trips and stops messages from flowing. The downstream agent does not receive corrupted data. The upstream agent gets a failure signal instead of silent propagation.

			
class AgentCircuitBreaker:
    state: CLOSED | OPEN | HALF_OPEN
    failure_count: int
    failure_threshold: int = 3
    anomaly_threshold: float = 0.15
    reset_timeout: duration = 300s
    half_open_max_probes: int = 1
    on_message(msg):
        if state == OPEN:
            if elapsed > reset_timeout:
                state = HALF_OPEN
                probe_count = 0
            else:
                reject(msg, reason="circuit open")
                return
        validation = validate(msg)
        if validation.failed:
            failure_count += 1
            if failure_count >= failure_threshold:
                state = OPEN
                alert(severity="high",
                      detail="breaker tripped on agent boundary",
                      source=msg.sender,
                      target=msg.receiver)
            reject(msg)
            return
        if state == HALF_OPEN:
            probe_count += 1
            if probe_count >= half_open_max_probes:
                state = CLOSED
                failure_count = 0
        accept(msg)

		

The circuit breaker pattern is well understood in distributed systems. Applying it to agent-to-agent communication is the same principle. Fail fast. Fail loud. Prevent cascade.

Fan-Out Caps

A single agent should not be able to influence an unlimited number of downstream agents in one cycle. Fan-out caps limit the blast radius of any individual compromise.

Constraint	Value	Rationale
Max downstream agents per message	3	Limits single-hop blast radius
Max chain depth	5	Prevents deep propagation chains
Max messages per agent per cycle	20	Prevents runaway communication loops
Cooldown after breaker trip	300s	Forces human review window
Max concurrent fan-out	5	Prevents simultaneous multi-path corruption

These are not arbitrary numbers. They are starting points calibrated to force review. A fan-out cap of 3 means a compromised agent can directly affect at most 3 agents. Combined with a chain depth of 5, the theoretical maximum blast radius is bounded.

Without caps, a single compromised planning agent can update parameters consumed by every execution agent in the system simultaneously.

Memory Isolation with Provenance

Shared memory is the mechanism that converts a transient failure into a permanent one. If a corrupted agent writes to shared memory, every agent that reads from that memory inherits the corruption.

The fix is memory isolation per agent with provenance tracking. Each agent writes to its own memory partition. Cross-partition reads require explicit grants. Every write carries a provenance record.

When investigation is needed, the provenance log lets you trace any persisted state back to its origin. Instead of asking “which agent wrote this corrupted value,” you can ask “what was the full chain of agents and inputs that produced this?”

That is the difference between forensic capability and forensic guesswork.

Mapping to the Four Rings

The four containment rings apply at every agent boundary, not just at the system perimeter. And that is the thing most organizations miss.

Containment Ring	Single Agent	Multi-Agent Boundary
Constrain Inputs	Validate external inputs	Validate inter-agent messages, verify sender identity, check message integrity
Constrain Environment	Sandbox, filesystem/network isolation	Memory isolation per agent, fan-out caps, chain depth limits
Validate Outputs	Check agent outputs before action	Circuit breakers on outbound messages, anomaly detection on output patterns
Gate Promotion	Human approval before production changes	Provenance tracking on all persisted state, human review after breaker trips

Most organizations implement the single-agent column today. The multi-agent boundary column is what they skip because they treat the space between their own agents as internal.

The interior boundaries between agents have the same attack surface as the exterior boundaries between the system and the world. That is the structural claim. The mitigations above are the evidence.

Stories from Production

The Lakera Progressive Breach Analysis (Framework Applied)

Lakera’s analysis of the OWASP Agentic Top 10 is not a theoretical exercise. It describes observed attack patterns against multi-agent systems and traces the mechanism from initial compromise through complete loss of containment.

Their description of the progressive breach lands because it is not a thought experiment. “A planning agent adjusts parameters based on skewed data. Execution agents follow the updated plan. Oversight agents see policy compliance and allow it through. Memory persists the outcome.”

The planning agent is the entry point. The execution agents are the blast radius. The oversight agents are the false negative. The memory layer is the persistence mechanism that prevents recovery.

Lakera’s conclusion reinforces the structural claim: “The Agentic Top 10 is not simply a taxonomy of risks. It is a model for how autonomy changes the shape of failure.”

That shape change is real. In a system without autonomy, a corrupted input produces a corrupted output and stops. In a system with autonomy, the corrupted input produces a corrupted plan that produces corrupted actions that produce corrupted memory that produces corrupted future plans.

The failure compounds because the agents have the autonomy to act on corrupted state without waiting for human review.

The Supply Chain Scenario (Framework Vision)

Let me give you a specific example of what this looks like structurally. This scenario has not occurred in production. Every component exists today. Multi-agent procurement systems are in development at multiple organizations.

Agent A monitors supplier pricing. Agent B generates purchase recommendations. Agent C executes approved orders. Agent D tracks delivery and reconciliation.

Agent A is compromised through a poisoned data feed. It reports artificially low prices for a specific supplier. Agent B, trusting Agent A’s price data, generates recommendations that favor that supplier.

Agent C executes the orders because they fall within approved budget thresholds. Agent D reconciles deliveries against the corrupted expected prices and flags no anomalies.

No individual agent malfunctioned. Each one applied its logic correctly to the data it received. The containment rings around each individual agent saw compliant behavior. The failure was in the unvalidated trust between agents.

With the mitigations in place, the failure path changes. Agent B’s circuit breaker detects anomalous price patterns from Agent A and trips.

The fan-out cap prevents Agent A from simultaneously corrupting Agents B, C, and D through parallel channels. The provenance log on Agent C’s purchase orders traces every recommendation back to Agent A’s price data, enabling rapid identification of the compromised source.

This is where the framework points. We haven’t proven it yet in this specific configuration. But the governance gap between agent deployment and inter-agent trust validation is the same gap described in every post in this series. The infrastructure is ahead of the containment.

The OWASP Classification (Framework Applied)

OWASP’s decision to codify cascading failures (ASI08) and insecure inter-agent communication (ASI07) as separate top-10 entries is itself a signal.

These are not subcategories of prompt injection or excessive agency. They are distinct failure classes that emerge only in multi-agent architectures.

ASI07 addresses the channel. How agents authenticate to each other. How messages are validated. How trust is established between autonomous processes.

ASI08 addresses the consequence. What happens when a failure in one agent propagates through the system.

The separation acknowledges that fixing the channel (ASI07) reduces but does not eliminate cascading failures (ASI08). Cascading failures can originate from non-malicious sources like model hallucination, stale context, or simple bugs.

The classification tells organizations that securing the perimeter of a multi-agent system is not sufficient. The interior boundaries between agents require the same governance discipline as the exterior boundaries between the system and the world.

Let’s talk about it.

How Agents Stay in Bounds

OWASP Top 10 for Large Language Model Applications

Lakera: OWASP Agentic AI Top 10

April 2, 2026

Agents Don’t Have Identities. They Have Inherited Credentials.

How Agents Stay in Bounds defined four containment rings for agent governance. This post stress-tests Ring 1 from the angle the model underweights: not what the agent knows, but what it holds.

I want to be straight with you. You can scope an agent’s instructions down to a single task. You can gate its inputs. You can validate every output. And if that agent is running under a token that authorizes a dozen systems it has no business touching, none of it matters.

The credential is the real containment boundary. Most organizations are not managing it.

The Problem

A Strata/CSA survey of 285 IT and security professionals published in early 2026 found that only 18% are confident their IAM systems can handle agent identities.

Only 21% maintain a real-time inventory of active agents. Only 28% can trace an agent’s actions back to the human who authorized them.

Those numbers describe an identity vacuum. Agents are running in production, taking actions on real systems, and most organizations cannot say which agents exist, what they can access, or who is responsible for what they do.

The credential picture is worse. 44% use static API keys. 43% use username and password pairs. 35% use shared service accounts.

These are the same anti-patterns identity management spent two decades eliminating for human users. Agents have re-introduced all of them.

80% of organizations report experiencing risky agent behaviors. Unauthorized access to systems the agent was never intended to reach. This is not a theoretical concern. It is the reported experience of a majority of organizations that have deployed agents.

The containment model assumes that constraining what an agent knows is enough to limit what it can do. That assumption breaks when the agent holds credentials that grant access beyond its task scope.

The agent does not need to break out of its sandbox. It can walk through the front door of every system its credentials authorize.

Why It Breaks

The failure mechanism is credential inheritance.

When an agent runs in a developer’s environment, it inherits that developer’s credentials. When it runs as a service, it inherits the service account’s permissions. The agent’s effective authorization is determined by what its inherited credentials permit, not by what its task requires.

This creates a specific structural failure: the authorization bypass path. A user with limited access can trigger an agent holding broader credentials. The agent then takes actions the user could not take directly.

The user’s access boundary is intact. The agent’s access boundary does not exist. The result is an escalation path that is invisible to both the user and the access management system.

flowchart LR
    subgraph "Authorization Bypass Path"
        U1[User: read-only access] --> A1[Agent: inherited admin credentials]
        A1 --> S1[Production database]
        A1 --> S2[Deployment pipeline]
        A1 --> S3[Cloud infrastructure API]
    end

    subgraph "Scoped Credential Path"
        U2[User: read-only access] --> A2[Agent: task-scoped credentials]
        A2 --> S4[Allowed: staging database]
        A2 -. "Denied" .-> S5[Production database]
        A2 -. "Denied" .-> S6[Deployment pipeline]
    end

This is not a misconfiguration. It is the default behavior when agents use inherited or shared credentials. Nobody scoped those credentials to the agent’s actual task.

Three dynamics compound this. Let me give you a specific example of each.

First, credential scope is invisible at invocation time. When a user asks an agent to check the deployment status, nobody evaluates what credentials will be used or what else those credentials authorize.

By the time the target system evaluates the request, it sees valid credentials and grants access. There is no mechanism that says this request came from an agent acting on behalf of a user with lesser permissions.

Second, agents chain actions. A single GitHub token can read repositories, write commits, create pull requests, modify CI workflows, and trigger deployments.

The agent composes them into sequences the token issuer never anticipated. The credential was scoped to a developer. The agent uses it as an automation platform.

Third, shared service accounts eliminate traceability. When multiple agents use the same account, the audit log shows the account acting. It cannot say which agent, which task, or which human sponsor initiated it. 35% of organizations are in this position.

Feel me? You can have clean containment logic and still have no idea what your agents are doing in production.

|—|—|—|—|—|

Every row violates Ring 1. Three of four violate Ring 2. Shared service accounts compromise Rings 3 and 4 because you cannot validate or gate what you cannot attribute.

The Fix

Agent identity is a containment boundary. It belongs in the model alongside the four rings, not as a nice-to-have added after deployment.

I want to cover three things: per-agent identity, task-scoped just-in-time credentials, and runtime authorization via a gateway.

Per-Agent Identity

Every agent needs its own identity in your IAM system. Not a shared service account. Not an inherited user token. A distinct, registered non-human identity with its own lifecycle, permissions, and audit trail.

This is the same discipline cloud infrastructure applied to service meshes. Every microservice gets its own identity. mTLS certificates issued per service. Access policies written against service identities, not shared secrets. Agents need the same treatment.

Per-agent identity enables three things inherited credentials cannot provide. Attribution: every action traces to a specific agent and its human sponsor. Revocation: decommissioning one agent does not affect others. Least privilege: permissions assigned to what the task needs, not what the sponsor happens to have.

Task-Scoped, Just-in-Time Credentials

Static credentials are the wrong primitive for agent work. An agent does not need permanent access to any system. It needs access to specific resources for the duration of a specific task. The pattern is just-in-time issuance.

When an agent starts a task, it requests credentials scoped to that task’s requirements. The broker evaluates the request against the agent’s identity, the task definition, and current policy. If approved, it issues a short-lived credential that expires when the task completes.

sequenceDiagram
    participant H as Human Sponsor
    participant A as Agent
    participant B as Credential Broker
    participant P as Policy Engine (OPA)
    participant T as Target System

    H->>A: Assign task: "deploy staging build"
    A->>B: Request credentials for staging deployment
    B->>P: Evaluate: agent identity + task scope + current policy
    P-->>B: Approved: staging deploy, 30-minute TTL, read/deploy only
    B-->>A: Issue scoped credential (TTL: 30 min)
    A->>T: Deploy to staging (scoped credential)
    T-->>A: Deployment complete
    A->>B: Release credential
    Note over B: Credential revoked, audit log written

The credential broker is the enforcement point. The agent never holds long-lived secrets. It holds a reference to a credential the broker can revoke at any time.

Open Policy Agent is a reasonable implementation choice. Policies are code, version-controlled, evaluated at request time. A policy checks: is this agent registered, is the requested scope allowed, has the human sponsor approved this class of access.

Runtime Authorization via Agent Gateway

The third component is a gateway that intercepts every outbound agent request and evaluates it against the agent’s current authorization context. Every request passes through before reaching the target system.

Requests that exceed the agent’s authorization are blocked. Requests within scope are forwarded with the appropriate scoped credential attached. The gateway enforces per-action authorization, not per-session authorization.

The gateway solves the chaining problem. A credential that authorizes reading a repository does not automatically authorize modifying CI workflows, even if both operations use the same underlying API.

Ephemeral runners strengthen this further. Each task runs in a fresh container with no pre-existing credentials, no cached tokens, and no ambient authority. When the container is destroyed, all credential material is destroyed with it.

Stories from Production

The Survey Wake-Up Call (Framework Applied)

The Strata/CSA data is not a projection. It is a measurement of current practice across 285 organizations.

44% authenticate agents with static API keys. These keys do not expire, do not scope to a task, and do not attribute to a specific agent. When a key is compromised, every agent using it is compromised. When it is rotated, every agent using it breaks.

Only 21% maintain a real-time inventory. The remaining 79% cannot answer: how many agents are running right now, which systems can they access, who authorized each one. The inventory gap is an identity problem. Without per-agent identities, there is nothing to inventory.

28% can trace agent actions to a human sponsor. The other 72% have audit logs showing service accounts taking actions with no link to the person who initiated the work. In a compliance audit, those actions are unattributable.

Real talk: if you are running agents with inherited credentials and shared service accounts, risky behavior is a structural certainty, not a probability. The 20% who do not report it either are not looking or have not found it yet.

The Privilege Escalation Path (Framework Vision)

A development team configures an agent to automate pull request reviews. The agent runs under a service account with read access to the repository and write access to PR comments. Appropriately scoped for the task.

Six weeks later, a team lead gives the same service account write access to the CI pipeline so the agent can re-trigger failed builds. One permission addition to an existing account. No review process because the account already exists.

The agent now has a credential path from PR review to CI execution. A prompt injection in a pull request body could instruct the agent to modify the CI configuration and trigger a pipeline run.

The agent’s original task was review. Its effective capability is now deployment. The escalation happened through credential accumulation, not through any failure in the agent’s containment logic.

This scenario has not been publicly reported. But every component is standard practice. Service accounts with accumulated permissions are the norm. Incremental grants without re-evaluation are the norm.

The fix is structural. Per-agent identities with task-scoped credentials cannot accumulate permissions because credentials expire after each task. The next task gets a fresh credential evaluation. Permission accumulation requires re-approval, not just addition.

The Agent Gateway in Practice (Framework Vision)

An infrastructure team deploys an OPA-based gateway in front of their cloud provider APIs. Every agent request passes through it.

In the first week, the gateway blocks 340 requests that would have succeeded under the previous shared-credential model. 280 are read requests to resources outside the agent’s task scope. Not malicious. Just unnecessary exploration during the planning phase.

Under shared credentials, this exploration was invisible. Under the gateway, it is visible, logged, and blocked.

The remaining 60 blocked requests are write operations to systems the agents were not authorized to modify. Three trace back to prompt injection attempts in user-supplied input.

The gateway stopped them not because it detected prompt injection, but because the resulting API calls fell outside the agent’s authorized scope. The containment boundary worked against an attack vector it was not designed to detect.

Agent identity is not a future concern. It is a present gap. The data shows most organizations have deployed agents without solving identity, and the consequences are already visible.

Per-agent identity, task-scoped credentials, and runtime authorization are not aspirational improvements. They are the minimum requirements for Ring 1 to function as a containment boundary.

Without them, you are not constraining the agent’s inputs. You are constraining its instructions while handing it the keys to everything.

Let’s talk about it.

How Agents Stay in Bounds

Strata Identity and Cloud Security Alliance: AI Agents and Identity Management Survey 2026

March 31, 2026

Agent Sprawl Is the New Shadow IT.

A friend sent me a post about AI sprawl across enterprise tooling. The argument was that organizations are paying for the same value many times over. Across an organization some people summarize emails in Outlook, sales team summarizes same email in the CRM, PMO summarizes the email in the project management tool. Three subscriptions, three vendors, three different models delivering the same value for the same organization on the same input. The potential for waste is real.

I want to be straight with you. I think the sprawl is a maturity problem, not a design problem. Everyone is trying to find leverage with AI right now. Teams are experimenting. Departments are buying tools that solve immediate pain. Nobody coordinated because nobody knew what would work six months ago. That is not negligence. That is what early adoption looks like in every technology wave. As things settle and consolidate, the duplicate subscriptions will compress. The market is already moving that way.

But here is the part that will not consolidate on its own. Even after the vendor landscape settles, even after the organization standardizes on fewer tools, the duplicate capability problem persists at the agent level. Three different workflows that each classify a work item using three different prompts with three different confidence thresholds. Five agents that each summarize context in slightly different ways because five operators made five independent decisions about what “summarize” means. The tools consolidate. The capabilities inside them do not, because nobody governed the boundary where one agent’s output becomes another agent’s input.

Gartner predicts 40% of enterprise applications will feature task-specific AI agents by the end of 2026. For the average organization, that translates to 50 or more specialized agents. Customer service agents. Code generation agents. Data pipeline agents. Document processing agents. Scheduling agents. Each one deployed by a different team, with different tooling, different containment posture, and different governance assumptions. They Can Watch. They Cannot Stop. showed what happens when organizations skip the containment rings for a single class of agent. Now multiply the problem.

69% of organizations suspect their employees already use prohibited AI tools. The agents are not waiting for an enterprise rollout. They are arriving through the same channel that every previous wave of unauthorized technology used: individual teams solving immediate problems without waiting for centralized approval.

History Repeats

The enterprise technology industry has seen this before. In 2018, Robotic Process Automation promised to automate repetitive tasks without changing underlying systems. Adoption was fast. Individual departments built bots to handle invoice processing, data entry, report generation. The bots worked. The ROI was immediate and visible. Within two years, large organizations had hundreds of RPA bots running across dozens of departments with no central inventory, no shared governance, and no unified monitoring.

Unframe AI drew the comparison directly: decentralized adoption, quick wins, proliferation, fragmentation, expensive consolidation. The RPA consolidation crisis cost organizations millions and took years. Bots broke when underlying systems changed. Nobody knew which bots existed, what they accessed, or who was responsible for maintaining them. The technical debt was invisible until it was not, and by then the cleanup was more expensive than the original implementation.

Agent sprawl follows the same trajectory but compresses the timeline. RPA bots were deterministic. They did exactly what they were scripted to do, which made them fragile but predictable. AI agents are stochastic. They interpret instructions, make decisions, and adapt to context. A misbehaving RPA bot runs the wrong script. A misbehaving AI agent improvises. The blast radius per agent is larger, the number of agents is growing faster, and the governance infrastructure is thinner.

Organizational Cognitive Debt

Your Code Works. Nobody Knows Why. described cognitive debt as the gap between a system’s structure and a team’s understanding of that structure. Agent sprawl creates cognitive debt at the organizational level. When fifty agents operate across an enterprise, the question is not whether any individual agent is governed. The question is whether anyone can describe the complete system of agents, their interactions, their data flows, and their combined effect on the business.

Most organizations cannot. The agents were deployed independently. The customer service team chose one vendor. The engineering team built their own. The finance team embedded agents into existing SaaS tools. Each team can describe their own agents. Nobody can describe the whole. And nobody knows what happens when these agents interact. When the customer service agent updates a record, and the data pipeline agent processes that record, and the reporting agent summarizes the result, the combined behavior is an emergent property of three independent systems that were never designed to work together.

This is shadow IT at the capability level. Traditional shadow IT was about unauthorized applications. Agent sprawl is about unauthorized capabilities. An employee does not install a new application. They enable an AI feature inside an application the organization already approved. The application is sanctioned. The agent capability within it is not. The IT asset inventory shows zero unauthorized tools. The actual environment contains agents that nobody is tracking.

The Unit of Governance Is Not the Agent

CIO magazine identified three pillars for taming agent sprawl: orchestration, governance, and observability. These are correct as categories. The implementation question is where those pillars sit. If orchestration, governance, and observability are built per-agent, the organization has a governed collection of individual agents. If they are built per-boundary, the organization has a governed system.

The distinction matters because agent-level governance does not compose. Ten individually governed agents are not a governed system. They are ten systems that happen to share an organization. The interactions between agents, the data that flows from one to another, the cumulative effect of their combined actions on business processes, none of this is captured by governing each agent in isolation.

How Agents Stay in Bounds defined containment at the boundary, not the agent. Ring 1 scopes the inputs an agent receives. Ring 2 isolates the environment it runs in. Ring 3 validates its outputs. Ring 4 gates its promotion. These rings apply at every boundary in a multi-agent system, not just the boundary around each individual agent. The handoff from one agent to another is a boundary. The data flow between agent-enabled applications is a boundary. The integration point where an agent’s output becomes another agent’s input is a boundary.

Governing the boundaries means that even when a new agent appears in the ecosystem, its interactions with existing agents are already constrained. The new agent’s output passes through a boundary ring before it becomes input for another agent. The organization does not need to re-govern the entire system every time someone deploys a new agent. The boundaries hold.

The Inventory Problem

Before you can govern agents at the boundary, you need to know the boundaries exist. This is the discovery problem, and it is harder than it sounds. A 2026 Deloitte analysis of the multi-agent market estimated the agentic AI orchestration market will reach $35 billion by 2030. That money is not going to centralized platforms. It is being distributed across vendors, internal tools, and embedded capabilities in existing software.

The first step is an inventory. Not an inventory of agents, because agents are embedded in applications and invisible to traditional asset management. An inventory of capabilities. Which applications in the environment have AI agent features enabled? Which of those features can take autonomous action? Which can access data from other systems? Which can modify records, send communications, or trigger workflows?

This is the same audit structure from They Can Watch. They Cannot Stop., extended from individual agents to the organizational ecosystem. The four questions are the same. Can you define and enforce what each agent receives as input? Can you isolate each agent’s execution environment? Can you validate each agent’s output against measurable criteria? Can you prevent each agent from promoting its actions without approval? Apply those questions at the boundary between agents and you have a multi-agent governance audit.

Enumerate every application in the environment with AI agent capabilities, including embedded copilots and SaaS features.
For each, identify whether the agent can take autonomous action, access data beyond its primary function, or trigger downstream processes.
Map the data flows between agent-enabled applications. Every flow is a boundary.
Apply the four-ring audit to each boundary. Can you scope the input at the handoff? Can you isolate the execution? Can you validate the output? Can you gate the promotion?
Score each boundary as governed, partial, or ungoverned. The ungoverned boundaries are your risk surface.

Organizations that run this audit typically discover more boundaries than they expected. The agent count may be manageable. The boundary count is where the governance gap hides.

RPA’s Lesson

Unframe AI’s comparison to RPA includes an observation that applies directly: “Agents aren’t the unit of value. Outcomes are.” The organizations that survived the RPA consolidation crisis were the ones that shifted from managing individual bots to managing business outcomes that bots contributed to. They built centralized orchestration, unified governance, and shared monitoring. They treated the collection of bots as a system rather than a portfolio of independent tools.

The agent version of this lesson is the same. The organization that governs fifty agents as fifty individual tools will face the same consolidation crisis RPA created. The organization that governs fifty agents as a system with defined boundaries, scoped handoffs, and unified observation will not. The difference is not the number of agents. It is whether the governance model scales with the agent count or collapses under it.

Agentic Engineering Is a Practice. AgenticOps Is the Infrastructure. made this argument for individual developers: practice degrades under pressure, infrastructure holds. The argument is identical at organizational scale. An organization that relies on each team to govern their own agents will see governance degrade as deployment velocity increases. An organization that builds governance into the boundaries between agents will see governance hold regardless of how many agents individual teams deploy.

The agents are already here. The sprawl has already started. The RPA playbook says the consolidation crisis arrives in 18 to 24 months. The question is whether organizations build the boundaries now or pay for the cleanup later.

Let’s talk about it.

We Already Solved This Once

Leverage Isn’t Enough

What This Looks Like at My Desk

Receipts Can Be Forged

The Trust Ladder

Share this:

More Movement Is Not the Same as Better

Why “Loop Everything” Is the Wrong Goal

Place the Loop, Then Prove It

The Lane

Share this:

What Loop Engineering Gets Right

What the Discourse Keeps Skipping

The Loop Is the Easy Half

Evidence, or It Didn’t Happen

Where to Start, Honestly

Share this:

The Problem

Why It Breaks

This Looks Like RPA Orchestration. It Is Not.

The Fix

The Boundary Contract

The Boundary Middleware

The Boundary Log in PostgreSQL

The Boundary Dashboard in Vue.js

The Boundary Map

ML.NET at the Boundary

Stories from Production

Five Agents, Four Boundaries, Zero Rings (Framework Vision)

The Boundary That Caught a Model Drift (Framework Vision)

When the Boundary Itself Is Wrong

Share this:

What the Act Actually Requires

Why Most Organizations Will Miss It

The Fix: Map Rings to Requirements

What This Means for You

Share this:

The Problem

Why It Breaks

The Fix

Gate Thresholds

Stories from Production

The Sonar Survey Reality Check (Framework Applied)

The Math That Breaks (Framework Vision)

Verification Debt Gets Its Name (Framework Applied)

Share this:

The Comfortable Take Is Wrong

Six Failures That Compound

The Fix Is a Mapping Problem

The Diagnostic

Share this:

The Problem

Why It Breaks

The Fix

Zero-Trust Between Internal Agents

Circuit Breakers at Every Agent Boundary

Fan-Out Caps

Memory Isolation with Provenance

Mapping to the Four Rings

Stories from Production

The Lakera Progressive Breach Analysis (Framework Applied)

The Supply Chain Scenario (Framework Vision)

The OWASP Classification (Framework Applied)

Share this:

The Problem

Why It Breaks

The Fix

Per-Agent Identity

Task-Scoped, Just-in-Time Credentials

Runtime Authorization via Agent Gateway

Stories from Production

The Survey Wake-Up Call (Framework Applied)

The Privilege Escalation Path (Framework Vision)

The Agent Gateway in Practice (Framework Vision)

Share this:

History Repeats

Organizational Cognitive Debt

The Unit of Governance Is Not the Agent

The Inventory Problem

RPA’s Lesson