Your agent does something wrong. How far does it reach before anyone notices?

@hammad_shams_uddin we actually send the code diffs and flag the unsafe changes, you just need to click on show more, or see the flagged notifications we send you.

@riya_pariyar 

The distinction between what the agent was authorised to do and what it happened to have access to is the sharpest version of this I have seen, and most audit trails genuinely cannot answer it. They record the action and the outcome and never the basis.

Scoped identity is also the mechanism for something I argued further up. The agent should not be inferring its own blast radius, because it is the worst possible judge of it. It should be a property of where it is running and what it is holding. Scoping the credential is exactly that, and it puts the boundary somewhere the agent's blind spot cannot reach.

Where I would push: scope bounds the maximum blast radius, not this one. A credential correctly scoped to send customer email still lets the agent send to fifty thousand people, because that is inside the scope. Scope answers could it ever. A gate answers should it now. Neither replaces the other, which is probably why we are both building.

The place they meet is the record. Two people in this thread arrived independently at the record being the thing that survives, one from clinical paging and one from support. Your point adds that it has to carry the basis and not just the action, and I had not been thinking about it that way.

Happy to compare notes properly if useful: https://cal.com/aadilghani/coffee

@flavio_riper 

Action rather than session is right, and I think you can push it further than you have. Jernej worked through this further up today and landed somewhere sharper: approval belongs to the action plus a condition it depends on. Per action alone still goes stale the moment the person walks away, because the action did not change, the world did.

Which makes "ask again" the part I would push on. Re-asking on every change is expensive, and expensive gates die. People route around them or rubber stamp them. Re-checking is cheap. Declare what the approval depended on, have the runtime re-evaluate it at execute time, and only surface the difference when something actually moved. Yes, provided nothing changed, verified by the system rather than by the person.

Your four also line up oddly well with where this thread ended up. Riya arrived at permissions and identity, Jernej at evidence, Tyler at reach and recovery as separate layers. You have the union of it. Worth reading back up before you build, there is a lot in there nobody has written down anywhere else.

@tony_tan10086 

You just restated the load-bearing sentence from the last thread and made it bigger than I had it. My version was that you cannot build a tripwire out of the thing that is tripping, so the boundary has to sit outside the agent. You have extended it to the reviewer, and that is the harder half. The reviewer is inside the loop too. They cannot see what they cannot see, which is why "have a human look at it" quietly stops being a control the moment the wrongness lives in the grounding rather than the text.

Mismatch-only escalation is the third independent arrival at the same mechanic in this thread. Jernej got there from evidence, re-resolve at review time and show the difference rather than the record. Flavio from conditions. You from canonical definitions. Three domains, one shape: declare the invariant, let the machine compare, only interrupt on divergence. Everything else is what teaches reviewers to stop reading.

And your split is the cleanest statement of it I have seen. The vendor carries the mechanism, the org supplies the declaration. It has to be that way round, because a vendor-supplied canonical definition is just the agent's assumption with better branding.

What happens when the org has never written the canonical one down, which I would guess is most of them?

@raffay_sajjad 

B is the honest answer and the uncomfortable one, which is usually the tell. Most people here picked a letter about their agent. You picked one about the code the agent leaves behind, and those are not the same question.

Your asymmetry has a mechanism under it worth naming. The refund reverses the row. It does not reverse what the row emitted. The decline email, the internal flag, whatever downstream consumer read that state and acted on it, all of it fanned out through channels that have no inverse. So irreversibility is not really a property of the action. It is a property of the side effects escaping into places with no undo. Which is exactly why a webhook handler is the worst possible two line diff, because a handler is a fan-out point by definition. The line count measures the code. The danger lives in the fan-out.

That is also why your instinct is right and your conclusion is wrong, in a way that excuses B rather than condemning it. Most of what your agents touch is code and not money, correct. But the blast radius is not where the agent is, it is where the code it wrote runs. Editing that handler has reach equal to every event it will ever process, weeks later, with no agent present. The gate would have to fire at edit time on a consequence that lands much later. That is genuinely hard to specify, so B there is an accurate read of a hard case rather than a shortcut.

The crude thing that actually works, and it is crude: scope the rule to the path. Not what the tool is, not what the arguments are, just which files. Blast radius is rarely knowable, but it is often co-located, and for payment webhooks it almost always is. A proxy, and a good one exactly where you need it.

Which rests on something I would want to know before trusting it. How many paths in your repo would be on that list, and is the list stable? If it is a handful of directories you could name from memory right now, this works. If it is diffuse, it does not, and I would rather say that than sell you a rule that quietly stops matching.

@tony_tan10086 

The unmade decision line is the whole thing, and it changes what the escalation is.

If a definition was never written down because writing it down means somebody loses an argument, then the escalation is not a clarification. It is an adjudication. Those have different requirements. A clarification can go to whoever is nearest and competent, because the answer is merely unknown. An adjudication cannot, because the answer is contested, and capturing it from whoever happens to be online is picking a side by accident and then recording it as canonical. The politics do not dissolve. They relocate to whoever answered first, laundered by the fact that a machine wrote it down.

So capture at first use needs a field it would not otherwise need. Not just the answer, but whether the person who gave it was entitled to. Routed to a named human with enforcement on, rather than a link that anyone holding it can answer.

There is a matching flaw on our side that your comment made visible. Our answers are atomic, first one wins. That is exactly right for approve or deny, where one decisive answer is what you want and a second is a race condition. It is exactly wrong for define this term, where first is not most correct, it is fastest. Same mechanism, opposite correctness, and the discriminator is whether the question is unknown or contested. I had not separated those two.

The harder half is revision. Once a definition is held and reused, everything computed under it was correct relative to that version. Changing it later does not only change future numbers, it silently invalidates past answers that were right when they were given. So the captured definition needs a version and an effective date, and every answer needs to record which version it stood on. Without that, the first capture becomes permanent by accident, because revising it costs more than living with it.

One caveat on surfacing conflicts from observed questions, since you will hit it: it finds contested definitions, not wrong ones. A term everyone computes identically and identically wrong produces no disagreement to surface. Still the right first pass, because the sample is weighted toward what people actually argue about, but it is a governance instrument rather than a correctness one.

So the load bearing question in your setup: is the person who resolves the ambiguity the person who can make it stick, or just the person who was there?

@malik_dixon1 

Blast radius over reversibility is where this thread opened, so rather than re-derive it I will go to the line in yours that nobody has said yet, which is that the agent should not estimate its own blast radius. That one is worth taking apart, because it is easy to think you have satisfied it when you have not.

We never ask the agent to estimate anything, and we still fail your test. We estimate for it, from the string it produced. Capability is a regex pass over the command text, so a shell call becomes destructive or network by its shape. Target class is a regex over the path. There is even a feature that buckets the length of the command, which is a proxy for reach made out of characters. None of that consults the agent's opinion and none of it is independent of the agent's output. An authoritative source has to be a different source, not a second reader of the same sentence.

Then the hard part, which is that authoritative context is available in inverse proportion to how badly you need it. Where reach is measurable it is usually already a parameter of the call. A recipient count is sitting in the arguments; you are not consulting a system, you are reading the request back. Where reach is unbounded, a shell command, a script, anything that is a program rather than a request, no source can produce the number, because the reach is whatever the thing computes at runtime. The ladder is well fed at the bottom and starved at the top, and the highest tier is the one whose input is always missing.

Which argues for keying the tiers on whether reach is knowable rather than on how large it is. Measurable and small, measurable and large, and not measurable. The third cannot be auto approved at any size, and it is also the only tier where execute and audit is an honest description rather than a preference, because there the number genuinely arrives after the fact.

On the second half, three of your four already exist here. The deadline is a column of seconds, the predefined outcome is an enum, and the decision owner is a routing table matching a tool and a target and a repo to a set of people. The fourth is the interesting one. Our default timeout action is literally named escalate, and what it escalates is the surface rather than the authority: it hands the decision back to the terminal, which is the same person on a different screen, and on the unattended path it degrades to a deny. Meanwhile the routing table that knows who owns the decision is read when picking who to ask first and never when that first ask times out. So we have an owner and an escalation and they do not know about each other. Naming the field was not the hard part. Escalation is the only one of your four that requires a second person to exist, which is why it is the one that quietly did not get built.

The scope point I would take with one caveat. Invalidating an approval when the action changes needs a notion of the same action, and byte equality pre approves nothing while anything looser is a per tool judgement about what counts as sameness. That is the same naming problem the accumulation branch hit a few comments up, arriving from the other direction.

@omri_ben_shoham1 

You found the failure mode my whole framing missed, and it's worse than any of my five letters because it's invisible from inside the system. I was asking "how far does a wrong action reach." You're pointing at something quieter: does the gate ever re-derive its own premise, or does it just re-confirm a cached conclusion and mistake repetition for verification.

That's the part that should scare people, and I include myself. Your escalation felt more trustworthy every time it re-ran, because "reconfirmed 20 times" reads as robustness. But it wasn't 20 checks, it was one wrong check looped 20 times, and the loop manufactured false confidence instead of catching the error. Re-running a stale premise isn't verification, it's the same mistake wearing a uniform, and the more it repeats the more legitimate it looks. A gate that never questions its own input degrades into a rubber stamp that's proud of how consistent it is.

And the reach you named is the sneaky one. It wasn't customers, it was your own confidence, which is arguably the more dangerous blast radius, because a wrong action that reaches customers at least gets contradicted by reality eventually. A wrong belief that keeps reconfirming itself has no external correction, it just calcifies. The stale slug from an old memory note is the perfect detail: the premise was wrong upstream, and every downstream check inherited the error and then validated it, because none of them re-derived where the URL came from.

So the principle underneath your five-letters-plus-one: a gate has two ways to fail. It can wave through something it should have stopped (the reach problem), or it can keep stopping something on a premise that's no longer true (your loop). Everyone's been building for the first. The second is quieter, cheaper to ship, and rots in place, because a stale gate and a healthy gate look identical from the outside, both just keep returning the same answer.

Which lands me on a question I genuinely can't answer for our own system: how would a gate know its own premise went stale? The action didn't change, the check didn't change, only the world underneath the cached input changed, and nothing re-read it. Do you think the fix is expiry, every escalation's premise gets a TTL and must be re-derived from source, not cache, past it? Or is that just moving the staleness down a layer, because now you're trusting the re-derivation not to hit the same cached slug? Because I can't tell whether "re-check your premise on a timer" actually solves it or just makes the loop slower.

@edward_paul3 

Thanks Edward. What convinced me was noticing that the two can point in opposite directions. The action that sounds most dangerous is usually the one that reaches a single person, and the boring routine one is what goes out to everybody at once.

Which is what makes the letters harder to pick than they look. Where do you land on them? And do you run agents yourself, or ship them to other people?

@maklyen_may 

It loosens. I think that happens to every approval step ever built, not just this one. Code review, alerting, security prompts, they all start strict and end up as a reflex once people trust the thing underneath.

What does not seem to loosen is wanting to know. Teams stop blocking long before they stop caring who approved what and when. So the part that survives people getting comfortable is the record, not the gate.

The failure mode is that it loosens quietly. Nobody decides to lower the threshold, it just drifts, and then one day nobody on the team can tell you what is still gated and what is not.

Are you running into this inside TrackerJam, or with your users?