--- title: "Discussion on \"Making AI Agents Safe and Fast\" | Hashnode" description: "Discussion on \"Making AI Agents Safe and Fast\". Practical Governance with Jev, Obsidian, and a Meta-Harness" url: "https://hashnode.com/posts/article-2026-09-22-1843/6ab24e1dad174d23b1e2b209" --- [Feed](https://hashnode.com/feed) / Discussion # [Making AI Agents Safe and Fast](https://daisuke.masuda.tokyo/article-2026-09-22-1843?utm_source=hashnode&utm_medium=feed) Practical Governance with Jev, Obsidian, and a Meta-Harness Sep 22 · 17 min read · daisuke.masuda.tokyo Read the article - [#ai-agents](https://hashnode.com/tag/ai-agents) - [#software-architecture](https://hashnode.com/tag/software-architecture) - [#ai-safety](https://hashnode.com/tag/ai-safety) - [#automation](https://hashnode.com/tag/automation) - [#developer-tools](https://hashnode.com/tag/developer-tools) - [#jev](https://hashnode.com/tag/jev) - [#obsidian](https://hashnode.com/tag/obsidian) ## Written by [Daisuke Masuda](https://hashnode.com/@x5gtrn) @x5gtrn · Hyogo, Japan [View profile](https://hashnode.com/@x5gtrn) DJ Ekusi, SAEKIKAZUMI Daisuke Masuda (born January 1982), also known as x5gtrn, SAEKIKAZUMI, or DJ Ekusi, is a Japanese software developer who aspires to gain recognition as a DJ. I balance programming and DJing as my lifelong pursuits and am a devoted enthusiast of both music and literature. I am a passionate admirer of Richie Hawtin, Sven Väth, Ryuichi Sakamoto, Ryu Murakami, Kenji Eno, and THA BLUE HERB. I draw inspiration from their creativity and vision. ## Responses 7 Markdown supported · ⌘↵ to post [Sina Rezaei](https://hashnode.com/@sinarezaei) [Oct 23](https://hashnode.com/posts/article-2026-09-22-1843/6ab24e1dad174d23b1e2b209/comment/6adb7b0d1234cffd108b950b) 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. [Julian Neagu](https://hashnode.com/@julianneagulab) [Sep 25](https://hashnode.com/posts/article-2026-09-22-1843/6ab24e1dad174d23b1e2b209/comment/6ab64122a741334af78601c7) 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. [Brian · AI News](https://hashnode.com/@brianainews) [Sep 23](https://hashnode.com/posts/article-2026-09-22-1843/6ab24e1dad174d23b1e2b209/comment/6ab3e63405613eb605b75ee4) 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. [Daisuke Masuda](https://hashnode.com/@x5gtrn) [Sep 23](https://hashnode.com/posts/article-2026-09-22-1843/6ab24e1dad174d23b1e2b209/comment/6ab3e63405613eb605b75ee4#reply-6ab4161e3bb4a819888b307e) 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. [Mihai\_LeanZero](https://hashnode.com/@mihaileanzero) [Sep 22](https://hashnode.com/posts/article-2026-09-22-1843/6ab24e1dad174d23b1e2b209/comment/6ab258761da04364a31ee2cc) 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? [Daisuke Masuda](https://hashnode.com/@x5gtrn) [Sep 22](https://hashnode.com/posts/article-2026-09-22-1843/6ab24e1dad174d23b1e2b209/comment/6ab258761da04364a31ee2cc#reply-6ab25d6d6991703e7eb67c87) 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. [Mihai\_LeanZero](https://hashnode.com/@mihaileanzero) [Sep 29](https://hashnode.com/posts/article-2026-09-22-1843/6ab24e1dad174d23b1e2b209/comment/6ab258761da04364a31ee2cc#reply-6abbc2ebd3b414aa06673577) 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.