Discussion on "Making AI Agents Safe and Fast"

Daisuke Masuda · 2026-09-22T09:45:01.980Z

An agent investigating a production incident might read logs, search Jira, inspect GitHub, patch a service, and suggest a deployment. Each step needs different evidence and different authority. A usef

One edge case worth covering is a timeout after the database commits but before the executor records success. If the queue retries the migration blindly, you can end up applying a non-idempotent operation twice or marking a completed change as failed. I'd persist an execution ID and reconcile the actual resource state before retrying, so recovery doesn't depend on guessing whether the previous attempt made it through.

The small context packet idea is underrated. I’ve seen agents get worse just because we keep feeding them everything instead of what they actually need.

Sandbox first then model swap. Most agent bugs are path and permission issues not model IQ. I refuse to debug a runaway tool call outside a jail.

Agreed on the order: sandbox first, then evaluate whether a model swap actually helps. A better model won’t fix an overprivileged executor or a command running in the wrong directory.

That’s the distinction I wanted to make in the article: policy checks decide whether an action should run, while execution boundaries constrain what it can touch if something goes wrong. Explicit working directories, restricted filesystem and network access, and scoped credentials belong in that execution layer—not just in the prompt.

Debugging should let us reproduce a bad tool call without turning the investigation into another production incident. Thanks for making the priority explicit.

This is a genuinely well-built design, especially the point about production credentials staying unavailable to an unauthorized path even when a hook coordinates the decision - that's the part most agent-permission writeups skip entirely. One gap I don't see addressed: what happens when two independently valid ASK approvals target the same underlying resource within their expiry window - say two on-call engineers approve two different production migrations to the same billing table a few minutes apart, each action individually well-formed and each approval correctly bound to its own action hash. Binding approval to "the exact operation that was evaluated" stops a bait-and-switch on a single pending request, but it doesn't stop two correctly-approved operations from racing each other at execution time. Drawing on our own approval-gated deploy work, that usually ends up needing a resource-scoped lock the executor takes before running any approved action, on top of the action-identity check, so a second approved action against a still-locked resource gets requeued rather than executed. Is that layer intentionally out of scope here, or would you fold it into the execution layer's contract too?

Thanks for calling this out—and for the concrete migration example. I’d fold it into the execution layer’s contract. The article leaves that concurrency requirement underspecified.

You’re right that binding approval to an action hash prevents substitution, but doesn’t make two independently approved actions safe to execute concurrently. The executor should acquire a lock scoped to the affected resource before execution, with conflicting approved actions remaining queued.

I’d add one requirement after acquiring that lock: revalidate the action’s preconditions against the current resource state. If migration A changes the schema that migration B was evaluated against, B’s approval may still be unexpired and correctly bound to its action, while the assumptions behind that approval no longer hold. In that case, the executor should stop and return it for re-evaluation—and renewed approval if the approved assumptions or operation change.

So the contract I’d make explicit is: acquire the resource lock, recheck approval validity and resource preconditions, execute, and record the resulting state before releasing the lock. A queued action gets those checks when it actually reaches execution.

That belongs alongside the credential boundary you highlighted. Approval establishes authority for an operation; the executor also has to establish that the operation is valid against the state it is about to change.

Revalidating preconditions after the lock, not just before, is the piece I missed. I was thinking of the lock purely as a mutual-exclusion device for the execution itself, but you're right that an approval's validity and the resource's current state are two separate things that can each go stale independently, and the lock is really the only place left to catch the second one before it's too late to stop. Recording the resulting state before releasing the lock closes the loop nicely too — that's what lets the next queued action's precondition check actually mean something instead of racing against a write that hasn't landed yet.

Search Hashnode

Making AI Agents Safe and Fast

Responses7