u/SYaroshuk

Most "human-in-the-loop" is just a pause in the prompt: you click yes, then the model goes and calls the tool. If the prompt is confused or jailbroken, it can still act. The approval is a feeling, not a guarantee.

I went the other way — the model never holds the trigger:

- An effect tool (saveDraft, sendEmail, applyLabel…) is bound to a server-side function the model never sees. It can only propose the call and open a gate.

- On approval the server runs the real function, once, through an action ledger keyed workItemId + gateId (idempotent — replay/retry can't double-fire).

- So a jailbroken prompt has nothing to fire. There's no code path from the model to the action.

State is server-authoritative (Postgres), every step is in an audit/trace log, and you can Stop one agent / one workflow / everything mid-run. The runtime is swappable.

Three places I think it's honestly weakest — come attack them:

1. The gate fixes execution safety, not decision safety. "Approve this" is still a general mandate — a reviewer without a lens misses the same failure classes the model missed. My direction: learn recurring failure patterns and hand review a class + angle, not just "check here." The hard part I haven't cracked — defining what counts as the same failure class, since lookalikes need different lenses.
2. The read side is open. The model still reads your data; a prompt-injection in an inbound email can shape what it proposes. The execution gate doesn't stop read-side exfiltration.
3. Exactly-once is workItemId+gateId in the ledger — but the effect itself must stay idempotent across a process restart between "approved" and "executed".

I'm here for the holes — tell me where "the server executes, not the model" falls apart.

Most "human in the loop" is just a pause in the prompt. You click yes, and then the model goes and calls the tool itself. So if the prompt gets confused or jailbroken, it can still act. That's not really control, it just feels like it.

I got annoyed enough to build a framework around the opposite idea: the model never holds the trigger. How it works:

• The model can only propose an action and open a gate. It never even sees the function that actually does the thing.
• When you approve, the server runs it, once, through a ledger. Not the model.
• So a jailbroken prompt has nothing to fire. There's just no path from the model to the action.

Two other things, briefly: you write real TypeScript while whoever runs it just gets a board of approve/reject buttons (no node editor, those please nobody), and you don't even write the pipeline yourself, your coding agent does it from skills that ship inside the packages.

It's beta and I'm building in the open. Honestly I'm here for the holes, so tell me where "the server executes, not the model" falls apart.