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

@jalcantara 

Context loss is the right second axis, and there is a sharper version of it hiding inside your own description.

You listed action, source, and intended outcome. Those three do not have the same trust properties. The action is observable, the system records it whether or not the agent cooperates. The reason is narrated by the agent, which means you are asking the thing whose judgment you are checking to also supply the justification for its own behaviour. A model that decided to send is a model that can write a persuasive account of why sending was correct. So the reason field fails in the one direction that matters, and it fails invisibly.

That is the line I would draw, captured provenance against narrated provenance. The message id, the row the query returned, the retrieval that actually happened, those are captured and they are checkable. A paragraph explaining the motivation is narrated. And narrated provenance is arguably worse than none, because a reviewer reading a plausible reason approves faster than one reading nothing. It manufactures confidence rather than supplying it.

Your closing line has a mechanism under it worth spelling out. Review time per item is roughly fixed, bounded by human attention. Production time has gone to nearly zero. So the ratio inverts and the bottleneck moves entirely into reconstruction. Once reconstructing why takes longer than producing the thing took, people stop reconstructing and start checking whether it looks right. Nobody decides to make that switch, it just happens. Surface plausibility is exactly the test a fluent narrated reason passes.

The return leg does something I had not given it credit for. If you declare an intended outcome at ask time and then cannot produce a matching observation afterwards, the outcome was decorative. So the evidence coming back grades your handoff format, not only the work. That is a free test of the thing that is hardest to evaluate directly.

Where ours falls short of your bar: our ask carries the action, the target, and free text. There is no structured field for a source, so provenance in our asks is whatever the agent chose to say about itself, which is precisely the narrated kind I just argued against. A field that resolves to an artifact instead of prose is the fix, and we do not have it.

So on yours: does source resolve to something a reviewer can open, or is it a sentence?

@blake_copeland 

Numbers first, since you asked for them.

The default ask window is 60 seconds for most tools and 45 for edits. Read only work is set to zero and never asks. Destructive actions are configured so that no timeout can auto anything, they hold the full window and then ask. The phone gets the first stretch of that window and the terminal gets the remainder.

The part that surprised me when we measured it is that N is not really ours to choose. The agent harness kills the hook on its own budget, and those budgets differ by agent. Claude Code allows about two minutes, Cursor allows one. We take that number, subtract a guard so we can return a decision rather than get killed mid wait, and that is the ceiling. Any policy timeout longer than the harness budget is fiction. So the honest answer to what is your N is that it is bounded by somebody else's timeout and the policy only picks a value inside it.

Now the part where you are right and I have to concede it.

We escalate across channels, not across people. A timeout on the phone falls back to the terminal, and the terminal is where the agent asks its own question. That works because there is usually a human sitting there. But that is the easy case, and it is not the case my post was about. For the person who never installed anything, falling back to the terminal is falling back to a room they are not in. We can name a specific decider and enforce that only they may answer. We cannot sequence two of them on a timer. The chain you are describing does not exist in our product, and calling it a routing problem rather than a policy problem is the correct diagnosis.

Keep waiting is a silent default toward denial is also right, and it is worse than it sounds, because that denial is unattributed. Nobody decided it, so nobody is accountable for it, and it does not appear in any record as a decision.

On your own answer, the slug rename is a stronger example than you gave it credit for. A send has reach you can count at the moment you send it. A slug rename does not. Its blast radius is inbound links and an index, it produces no error, and it lands over days. So there are two kinds of action here: ones whose reach is a number at the time of acting, and ones whose reach only becomes a number later. Everything on the audience or spend axis is the first kind. Almost everything in SEO is the second. Thresholds and budgets only work on the first kind, which is why your domain feels like it has no natural gate.

The line I would keep is yours. A is a claim about your current wiring, not about your agent. Wiring drifts and nothing fires when it stops being true, so A is accurate as of the last time you looked and there is no event that tells you it expired. Which is why I would take that bet.

@dalemooney 

The two things you gate on are not the same kind of thing, and separating them changes what can fix each.

Blast radius is a predicate on the action. You can evaluate it before anything happens, which is what makes it gateable. Time to notice is an outcome. It is not knowable at the moment you would need it, only afterwards, and it is a property of your organisation rather than of the call. So it cannot be an input to an approval decision at all. It can only change how much you let run between checks. One axis is a gate, the other is a leash length, and treating the second like the first is how it stays underbuilt.

On the org boundary you have the cleaner version of something I have been circling in another branch here. Reversible means reversible by you, and your undo authority stops exactly where the last copy you control does. Voiding the invoice reverses your ledger. It does not reach the client's inbox, their forward to their accountant, or their opinion about your billing. So the question is not whether the action has an inverse, it is who else is holding a copy by the time you want one.

The three days is the part I would sit with, and it is a limit on what I sell. A gate would not have helped. Nothing asked. The agent was doing things that were individually permitted, correctly permitted, and wrong in aggregate, and an approval layer tuned perfectly still produces your Friday. Approval is a control on discrete acts. Drift is about aggregates, and there is no per call decision that catches it.

What catches it is a system whose silence is distinguishable from health, which is also what makes your deadline fix work. Say so loudly is the load bearing clause, not the fallback. A quiet safe default is a small version of Tuesday to Friday, a decision the clock made that nobody knows about.

Ours is honest about half of that. A timeout is a first class outcome in our records rather than a missing answer, so the clock's decision is written down as itself. But the record is pull, nothing pushes it. And the only periodic report is weekly and fires only for workspaces that had activity, so it cannot report silence and cannot resolve a Tuesday to Friday inside one window.

What I would want to know from your Friday: was there a signal present that nobody was watching, or was there no signal at all? Those are different builds.

@omri_ben_shoham1 

The counter you would reach for first has a failure worth naming before you build it, because it does not show up until it is running. A rolling count gates call N plus one, which means the first N already went out. Against an irreversible send a threshold gate never prevents a mass send, it caps one. That is a different product, and better decided on purpose than discovered later.

Gating an aggregate before it starts needs something to declare the intended total up front, and the only thing that knows the total is the agent. Which is exactly the assertion the environment declared fix was built to remove. So the two properties do not come out of one mechanism. Environment declared reach is trustworthy and visible only per call. A declared budget is gateable in advance and only as good as the model.

You can have both if the declaration is allowed to move in one direction only. Let a stated budget raise the gate and never lower it. An agent announcing four hundred sends gets stopped on call one. An agent that says nothing falls back to the counter and gets capped rather than stopped. Worth being honest that this is a design for the buggy loop and not the adversarial one, since silence is strictly the better strategy for anything trying to get through, and the counter is what you keep for that case. Most bad loops are not trying.

On scope, the unit you count over has to be at least as trustworthy as the thing you are counting. Session ids are asserted by the client, ours included, so a session scoped budget inherits whatever the reporter is worth, and a restart resets it. Time is the one scope nothing can assert. Its weakness is pacing, and a loop slow enough to stay under a rate window is not stopped, but it now runs for hours instead of seconds. That is what a rate limit actually buys. Not prevention, a slow failure in place of a fast one, and a slow one can still be noticed while it is happening.

Where that leaves us is worse than unsolved. A policy row carries a tool pattern, a timeout, a timeout action, a delivery mode and a repo scope. Every field describes a single call, so there is no way to write your rule down at all. Meanwhile the tool actions we receive land with a session id and a timestamp, indexed on site plus session and on site plus created at. The data is already shaped for both of the scopes you named, and nothing at decision time reads it.

@vitalii_timonin 

The part I would sit with is nobody told it, and why would they. That is not an oversight, it is the default condition for anything holding a read that nothing registered. Every other consumer of that state either polls or was designed into the change path. The agent was designed into neither, so nothing that mutated the world had any reason to know it had a subscriber.

Worth separating from confidence, because the repair looks different. It was not overconfident about the facts it had. It was correctly confident about facts that had expired. Calibration is measured against what you know, and no amount of it helps with something that stopped being true after you read it, which is why making the model hedge more does nothing here and a freshness check on the inputs is the only thing that does.

On the number, agreeing, and naming why it cannot be picked well. One value is doing two jobs that move with different variables. The duration is a claim about the approver, how long until they are plausibly reachable. The fallback is a claim about the action, what is safe with no answer at all. Bundle them and a single guess has to be right about two unrelated things, and no value is.

Which is where your question resolves for me. Who it affects should not set the number. It should select who answers, and then the number becomes a property of a person, which is measurable rather than picked. Answer latency is an observable distribution per approver. If someone's ninetieth percentile is four minutes, a sixty second timeout expires on a live and willing human every single time, and every expiry after that is a fact about your threshold rather than about them.

The other half inverts the intuition. You would think affects more people means wait longer. But waiting stops being neutral the moment the affected party is not the operator. If the decision only touches the person running the agent, the delay costs them and they chose the loop, so a long window is free. If a customer is sitting on a pending reply, the wait is being spent out of someone who never agreed to it. Stakes belong in the fallback, not the clock.

We built half of this and never connected it. Who answers is its own table, a role or a named person, re-resolved at answer time so a rule pointing at somebody who left the workspace addresses nobody instead of continuing to address them. The number lives in a different table keyed identically, on tool pattern and repo, and the routing table carries no number of its own. So we choose the person and choose the number independently and let neither inform the other. Elsewhere we compute median answer latency per person and timeout rate per person and put both on a dashboard. Every input a person derived threshold would need already exists, one join away from the thing doing the guessing.

@omri_ben_shoham1 

Worth separating the two failures you have stacked there, because only one of them is about trust. Session ids being client asserted is real, and it is not what breaks this. Give me a perfectly attested session id, signed, unforgeable, surviving restarts, and two honest sessions still deliver eight hundred. The scope is not weak, it is the wrong noun. Fixing the assertion buys nothing here, which is the useful part, because it means this does not get solved on the way to solving that.

The one directional trick does not survive the move either, and I would rather say so than let it stand. It works because the declarer is the thing being gated. You raise your own ceiling, so lying is self defeating. Once the number bounds a shared resource it has to be drawn down by parties who never declared it and have no reason to be bound by someone else's declaration. That is a lease, not a declaration. Advisory and self binding becomes stateful and other binding, and it is the first thing in this thread that cannot live inside a session at all.

On the join, I think you are being generous calling it hard. A join is easy once a key exists and there is no key. The resource has to be named identically by two callers who never coordinated. A recipient list is not an object with an id, it is an argument. One session built it from a query, the other from a CSV, same four hundred humans, two different strings, and nothing joins them. So a resource scoped budget needs a resource identity function per tool, and that is N functions rather than one mechanism. That is the actual reason nobody ships it, not the counting.

The version I would try is to count the leaves instead of the batch. You do not need to know that list A and list B are the same list. You need to know that one address has been sent to twice in ten minutes. The element is usually already its own canonical name, an address, an account id, a row id. The batch has no identity, the leaves do. The cost is that the tool has to enumerate its effect set before acting, which is fine for send to a list and useless anywhere the effect set is not knowable in advance.

Ours is worse than you are assuming, and then better in one place. The tool action rows are receipts. They are written from a post tool event, the target is truncated for display, nothing indexes it, and the insert sits in a try catch that logs on failure. Even with your join that reports the eight hundred, it cannot prevent it. Same bug lives in our own domain, since our targets are files and commands, and two sessions editing one file is your problem with a smaller blast radius.

Then the one place we built exactly your shape. Daily spend is a counter in Redis keyed on the site and the day, with no session anywhere in the key, so every session and every restart draws down the same number and the trip fires once under concurrency. Resource scoped, actor blind, enforced server side. It still only caps, because it counts after the spend lands. Scope and timing turn out to be separate constraints, and you have fixed the one I did not.

@rabnoor_s 

Accumulation is on the board, a couple of branches up, and the conclusions there are worth having rather than re-deriving. Short version of where that one landed. A running total gates call N plus one, so it caps rather than prevents, because it counts after the effect has already landed. And the hard part is not the counting, it is the naming: the running total has to be kept against a resource that two callers who never coordinated would name identically, and a recipient list is not an object with an id, it is an argument. Same four hundred humans assembled from a query and from a CSV are two different strings and nothing joins them. That is why the first of your two moves keeps getting proposed and never shipped.

Your second move is the better one and I do not think it got its due, including from you, because you listed it second. It is a different kind of fix. The running total is a control on the aggregate and it needs to name the world. An expiring approval is a control on the grant, and it needs nothing you do not already have, since the approval has an id and a timestamp for the simple reason that you issued it. You get most of the protection without ever counting anything outside your own system.

The mechanism is that re-asking is itself the throttle. Four hundred sends against a ten minute expiry is two questions, not four hundred, and you never had to know what a list is. The failure mode is precise, though, and it is worth building against from the start. It only holds if the person answering notices that this is a re-ask. If the second question looks identical to the first, the second answer is identical too, and you have converted an accumulation problem into a fatigue one. Somebody tapping yes for the fortieth time is not a control, they are a rubber stamp with latency. So the re-ask has to carry the count. Approve this again, thirty ninth time in twenty minutes, is a different question from the first one, and it is the only moment in the entire system where the aggregate can be put in front of somebody who is already looking. Which is the real answer to nothing tells you. The gate does not have to detect the accumulation. It has to display it.

Ours does the exact inverse and I would not have gone looking without this. Repeated approvals of one pattern get mined over a month, and past a small threshold with a high enough approval ratio the system offers to stop asking. Accept and it writes a rule with a zero timeout and an approve action. No count, no window, no expiry. So repetition is our evidence for trust and yours is evidence for alarm, and the only thing standing between the two readings is how wide the window is. Same statistic, opposite sign.

The inversion is cleaner than that even. Our pending question has an expiry column. The permission it produces does not. The request expires and the grant is forever, which is precisely backwards from what you are arguing.

One place we did build your shape. A scope contract ratified for the current run is the only thing in our gate allowed to override a standing auto approve, and it dies with the run. So the general form might be that a licence should be scoped to the smallest unit that has an end. A run ends. A window ends. A row does not.

@bhargav5394 

Yours is the only control described in this thread that actually saves tokens, and I do not think that is incidental.

Everything else here gates a call that already exists. Our hook receives the tool name and its arguments on stdin, so by the time anything has an opinion the call has been generated and paid for. A deny buys back the consequence and none of the cost, and it usually costs more than an allow, because the model then re-plans and tries again. Approval is a control on what happens. Yours is a control on what gets produced, and only the second one shows up on the bill.

The difference is where the constraint lives. A library that is already there sits in the context from the first turn, so the wrong call never forms. Our rules sit behind the wall. The agent finds out what is gated by trying it, one deny string per round trip, and hitting the first rule teaches it nothing about the second.

What makes that worse rather than merely true is that we already write a block into the agent's memory file, and the comment above that code says agents only reach for a tool when something always in their context tells them to. So we know the mechanism and we use it for the behaviour, ask before anything risky, and not for the rules, here is what is auto approved and what is not. Same file, half the payload.

Where your fix stops is the part worth marking. Pre-placing works when the right answer is knowable before the run starts. A component library qualifies. Which of four hundred sends is acceptable does not, because it depends on the state of the world at the moment of the call. Everything on that side has to be generated before it can be stopped, so the burn there is the floor rather than the failure.

@omri_ben_shoham1 

makes a lot of sense on this one, if there's something more I can help with, I'm a nudge away.

@omri_ben_shoham1 cheers mate