Valuestream Episode 3: The Agent Acts, You Answer. Governing the Agents You've Already Deployed

Episode 3 of Valuestream is live. This is the governance episode, the conversation most teams keep putting off. You've deployed the agents. They're writing code, working tickets, maybe reaching into billing. The question nobody wrote down is the one that matters now: what is each of those agents actually allowed to do, and whose name is on the outcome when it acts?

For a decade the governance question was is this model accurate. That question is fine, and it's no longer enough. An autonomous agent doesn't just predict. It acts, chains tool calls, and takes steps no human explicitly approved. This episode is about the control model that keeps that power accountable, walked through one concrete scenario, plus the single move you can run on one agent this week.

Listen on Spotify above, or on Apple Podcasts and the rest once distribution propagates. Companion essay below has the full framework.

The opening

Picture a payments service. Solid, boring, reliable. Buried inside it is an idempotency layer, the unglamorous code that stops a customer from getting charged twice when a request gets retried. And picture why it exists. Two years ago an earlier version of that service double-charged 4,200 customers in 90 minutes on a Black Friday, and someone rebuilt the layer in the aftermath of a very bad weekend. It isn't redundant. It's load-bearing.

Now point an AI agent at that codebase with a reasonable task: clean up the payments service. The agent reads the idempotency layer, sees verbose middleware, decides it's redundant, and refactors it away. Tidier code. Fewer lines. The pull request is green. Every test passes. The reviewer is junior, the diff looks reasonable, and it merges.

Production holds for nine days. Then the same failure mode comes back, quietly, at lower volume. Customers double-charged. Again.

Here's the part to sit with. Nobody on that team wrote the bad code. An agent did. And nobody, not the junior reviewer, not the tech lead, not the director, ever actually decided that this agent was allowed to touch the payments service on its own. It just could. So it did.

The agent acted. Who answered?

Intake: the governance gap

Last episode ended on a promise: that the next hard conversation was the governance one. Here it is. Once an agent is authoring a third of your changes and chaining decisions across your systems, is this model accurate stops being enough. The new question is what is this agent allowed to do, and who's accountable when it acts.

Start with the scale, because most leaders are underestimating it. Gartner projects that by the end of 2026, 40% of enterprise applications will ship with task-specific AI agents built in, up from under 5% at the start of 2025. And by 2028, it expects the average Fortune 500 company to be running more than 150,000 agents, up from a figure that two years ago was in the low double digits. You're about to operate a workforce of software that can read, write, execute, and act on your behalf, and it will outnumber your people by orders of magnitude.

It already does, in one sense. In 2026, non-human identities (service accounts, tokens, bots, and now agents) outnumber human users in the average enterprise by roughly 80 to 1, and that population is the fastest-growing, least-governed attack surface most companies have. Every one of those agents is an identity with access. Not a feature. Not a tool on a shelf. A thing that can log in, reach into your CRM or your repo or your ledger, and take an action no human explicitly approved. Most organizations are governing that population the way they governed a spreadsheet macro in 2015.

Part of the problem is that most teams don't even know what they've deployed. There's a phenomenon worth naming: agent washing. A huge share of the tools sold as agentic are rebranded chatbots and old automation bots wearing a new logo. By some estimates, only around 130 of the thousands of "agentic" vendors are the real thing. So teams write governance rules for what they think they bought, a glorified assistant, and then a genuinely autonomous system shows up that can chain tool calls across the stack, and the rules built for a chatbot don't hold.

This is also why the existing frameworks won't save you. NIST, ISO, the EU AI Act, all built for a world of predictive models and classification. They ask: is this model accurate, is it biased, is the training data clean. Good questions, none of them the question. Agentic governance has to ask a different set. What can this agent do. What happens when it's wrong. Who's accountable for an action no human approved. And how do you audit a chain of reasoning that comes out different on every run. That's a structural gap, not an oversight you patch with a policy addendum.

And the failure mode is not the one you fear. The fear is the spectacular one, the agent goes rogue, drains an account, makes the news. That's rare. The common case is quiet. Call it agentic drift: a slow, plausible erosion of intent, committed in small green pull requests, each of which looks reasonable on its own. The scenario up top was agentic drift. Nothing dramatic, just a clean-looking refactor that quietly re-introduced a bug the original design was built to prevent, because the agent had no memory of why the design existed. Drift compounds. One suboptimal decision Tuesday, another Thursday, an access grant that was fine in isolation and dangerous in combination. None of it trips an alarm. All of it accumulates while everyone assumes the governance checkbox was already ticked by somebody else. And the blast radius is the killer: when one agent touches your CRM, your billing system, your repo, and your comms tools in a single workflow, a failure doesn't stay in one box. It cascades.

Gartner's framing of where this ends up is blunt. It expects a wave of enterprises to pull autonomous agents back out of production, not because the technology failed, but because of governance gaps discovered only after a production incident. Not gaps found in review. Gaps found in an incident. The bill comes due after the damage.

So the strategic intent for the episode is one sentence: stop deploying agents you can't scope, can't see, and can't answer for. Stripped of the framework decks, that's what governance is. Three questions. What is this agent allowed to do. Can I see what it did. And when it acts, whose name is on the outcome. If you can't answer those three for an agent in production right now, you don't have a governance problem you'll get to later. You have an open liability you haven't priced.

Flow: the five-move control model

Not a policy binder. A working model you could stand up on one program this quarter. Five moves. The first three are the practitioner patterns that hold up in the field. The fourth is the memory layer almost everybody skips. The fifth keeps the whole thing honest.

1. Scope the authority. Draw the capability envelope.

Every agent gets a documented envelope: what it can access, what actions it can take, what triggers a human review. The part that separates real governance from a wiki page is that the envelope is enforced at the infrastructure level, not described in a document. If the agent wasn't granted write access to production, it can't write to production. Not "shouldn't." Can't. The permission doesn't exist.

This is least privilege, the oldest idea in security, applied to a new kind of identity. Almost nobody does it for agents, because agents got deployed by product and data teams who never had to think about identity governance. The agent in the opening scenario had write access to a payments service it never needed and no one had consciously granted. It inherited it. That's the default state in most shops right now: agents running with the ambient permissions of whatever account spun them up. Draw the envelope first, before the agent ships, not after the incident.

2. Make it observable. Keep the trace.

You can't govern what you can't see. Log everything: every action, every tool call, every decision branch. Not for a compliance report nobody reads, but so that when something goes wrong, and it will, you have the trace. You can reconstruct what the agent did, in what order, on what information, and where it went off the rails. Episode 1 said visibility is the intervention, in the context of decisions aging in a matrixed org. For agents, the trace is the intervention. The team that can pull up exactly what the agent did in the 90 minutes before an incident fixes it in an afternoon. The team that can't spends two weeks guessing and never fully trusts that agent again.

3. Put the human in the loop at the right level. And don't govern every agent the same.

This is where most governance efforts overcorrect and die. Scared, they put a human approval gate on every single agent action, and now you've built a very expensive, very slow autocomplete that the team routes around within a month. The art is calibration. Low-stakes, reversible, single-system actions: let them run. High-stakes, irreversible, or cross-system actions: explicit checkpoint, a human decides.

And a fresh piece of guidance from 2026 that's exactly right: Gartner says plainly that applying uniform governance across all your agents will cause failure. One size does not fit all. A read-only agent summarizing support tickets and an agent with write access to billing should not live under the same rulebook. Govern them identically and you'll strangle the harmless one or under-govern the dangerous one, usually both. Tier your governance to the blast radius. The bigger the blast radius, the tighter the envelope and the more checkpoints.

4. Give the agent memory of why. The ADR discipline.

The agent in the cold open didn't fail because it was dumb. It failed because it had no memory of why the idempotency layer existed. That knowledge lived in someone's head, and maybe in a postmortem doc nobody linked to the code. The fix is a discipline most teams quietly abandoned a decade ago: the Architecture Decision Record. An ADR is a short, boring document that records a decision when it's made: the context, the decision, the consequences, and the alternatives you rejected and why. Cheap enough that a team will actually write them.

The mechanical insight that turns documentation into a governance tool: keep your ADRs in version control next to the code, and modern agentic tools will index them and retrieve the relevant ones at planning time. The agent stops being a stateless machine that turns intent into code and becomes a planner that respects prior commitments. The ADR that says this idempotency layer is load-bearing, here's the incident that caused it, do not simplify it becomes a constraint the agent reads before it ever touches the file. Then close the loop: the same pull request that introduces a new pattern includes the ADR that explains it, and the reviewer rejects the PR if the ADR is missing. No exceptions for small changes. Small changes are how drift accumulates.

Does it work? The directional data is stark. When ADR coverage on the critical path is low, under 40% (the danger zone), something like 62% of agent-authored pull requests get flagged for architectural drift. Raise coverage into the healthy range, 70 to 80% on the decisions that matter, and that drift rate drops to around 9%. Same agents, same model. The only thing that changed is the agent could finally read why. Watch agent retrieval rate, how often the agent actually pulls and cites an ADR while planning. Retrieving zero is the agent about to refactor your payments layer. Citing the relevant one in its PR description is the agent that's been brought into the team's memory.

The discipline tends to die three ways. Ratification theater, the ADR written after the change shipped, for compliance, recording what happened and not why; the fix is to require the ADR in the same PR as the change. Archive sprawl, hundreds of ADRs about trivial choices until the archive is too noisy to use; be ruthless, an ADR is for a decision that constrains future work, not a package version bump. Detachment from the agent loop, great ADRs kept in a tidy wiki the agent never sees; if you can't show the agent retrieved an ADR on a recent significant PR, move the archive into the repo and verify the tooling indexes it.

5. Red-team the governance itself.

Everything above can look great on paper and still be theater. Test it, the way security teams test defenses. Stand up a governance red team whose job is to probe for policy failures, not code vulnerabilities. What happens when the agent gets contradictory instructions? When it's handed two datasets that are fine alone and toxic combined? When it confidently hallucinates a decision and acts on it? If you haven't run those scenarios on purpose, in a safe place, your governance is a hypothesis. Red-teaming turns it into something you've watched hold.

Five moves. Scope the authority, keep the trace, calibrate the checkpoints by blast radius, give the agent memory, red-team the whole thing. None of it requires a governance platform off a shelf. All of it requires leaders who decide to own it.

Outcome: what it looks like when a team does the work

Not a specific company with the names filed off. A model, built from how this tends to go when a team actually runs the five moves.

Picture a company that did what a lot of ambitious teams did in 2026. All-in on agents. Coding agents in the pipeline, agents in the support flow, an agent wired straight into billing. Autonomy widening every quarter because the dashboard looked great and nothing had blown up yet, merge autonomy expanding off a blended metric that averaged the safe agents and the dangerous ones together. (The same trap as the metrics episode, pointed at a different number.) Look closely and three things are true. No capability envelope for any agent, each running with whatever access its service account happened to have. Almost no trace, so "what did the billing agent do last Tuesday" takes an engineer two days to reconstruct. And ADR coverage on the critical path around 35%, danger zone, with a decent set of architecture docs living in a wiki the agents never read. Textbook detachment.

Nothing gets ripped out. You run the five moves on one program over a quarter. You write capability envelopes for the top agents and enforce them at the infrastructure layer, and the billing agent, the biggest blast radius, loses its standing write access to production. Now it proposes; a human commits. You turn on real tracing, so every agent action is logged and replayable. You move the architecture docs into the repo as proper ADRs on the critical-path services and make the ADR a required part of any agent-authored PR. And you tier the whole thing, so the support-summary agent keeps running wide open because its blast radius is basically zero.

Here's where the numbers land. ADR coverage on the critical path goes from 35% to 78% over the quarter. The share of agent PRs flagged for drift falls from around 60% into the low teens and keeps dropping. And the part that matters most: a few weeks in, the trace catches a near-miss. An agent tries to tighten a database constraint on a field that an old ADR explicitly says to keep loose, for a reason a human documented eighteen months earlier. The agent reads the ADR, flags the conflict, and stops. Before the code ships, not after the incident. That is the whole game.

Then the second-order effect, the one that matters most. The conversation changes. Before, every AI review was a bragging contest about how many agents got deployed and how much autonomy got granted. After, the question becomes which of these agents can we actually answer for. Governance stops being something you hope legal is handling and becomes a number delivery leaders own and report, right next to velocity. You stop governing on hope.

The mistake to avoid is doing all of this after the fact, after the near-misses, after the exposure has piled up. The capability envelope should be the first artifact, written before the agent gets access, not the cleanup crew you send in once you realize you've got 200 agents running with permissions nobody scoped. Governance-first, not governance-later. It costs you a week up front. Governance-later costs you an incident, and the incident sets the price.

The takeaway

One agent. Not the fleet. One.

Pick the agent with the biggest blast radius, the one that can write to something that would hurt if it were wrong: payments, customer data, production infrastructure, whatever yours is. Write its capability envelope on one page. What it can read, what it can write, what actions it can take, what triggers a human. Describe reality first, what it can actually do today.

Then find the one action on that page that's irreversible, the charge that can't be un-charged, the delete that can't be undone. And ask the simplest question there is: whose name is on it when the agent does that at 2 a.m. on a Sunday? If you can't name a person, that's your first finding. An agent with an irreversible action and no human who answers for it isn't a productivity win. It's a liability with a login.

One rule on the rollout, same as always: coach, don't command. The teams deploying these agents aren't reckless, they're moving fast in a year that rewards speed. Praise the first person who writes an envelope. Make the trace something engineers reach for because it saves them, not something they dread because it grades them. Governance sticks when it feels like a seatbelt, not a speed trap.

The boring news is the fundamentals didn't change: least privilege, auditability, accountability, human judgment on the calls that matter. The brave news is you now have to apply them to a workforce that isn't human, outnumbers you 80 to 1, and acts faster than any review cycle you've ever run. That's the work.

What's next

Next episode turns the coin over. This one was about boundaries, what the agent isn't allowed to do. The flip side is capability. Most agents don't fail by going rogue; they fail by being useless, showing up every morning with no memory, no voice, no priorities, and no idea what you're working on. Point a fresh agent at your week and it hands you beautiful, generic, useless output, the cadence of a consulting deck and the substance of a fortune cookie. So the next one is about giving the agent a brain: the context, the memory, and the priorities that turn a confidently-wrong assistant into something that actually knows your week. Boundaries and a brain. You need both.

Listen

• Spotify · episode link populates the moment publishing finishes · follow the show
• Apple Podcasts · Valuestream on Apple (episode appears once the feed refreshes)
• Amazon Music · Valuestream on Amazon
• Pocket Casts / Overcast / Castbox / Podcast Addict · auto-discovered from the RSS feed
• RSS · subscribe in any podcast app at the show's RSS feed

Get notified when episode 4 drops

Drop your email on the Valuestream show page and you'll get a single line in your inbox the morning episode 4 publishes. Same list as the blog notifications. No fluff in between.

This is Valuestream. I'm Rick Pollick. The agent acts, you answer.