Interesting approach, the governance loop is a cool idea, forcing the agent to periodically stop and re-read and creates checkpoint.
One thing we kept seeing is agents are very good at convincing themselves they followed the protocol even when they didn’t. Self-checking helps, but we eventually started treating the agent’s reasoning as advisory rather than authoritative.
The pattern we’ve been exploring is separating what the agent believes it did from what the system actually allows to execute. The agent can generate tests, retry, and self-correct, but any action that mutates real state still passes through an external gate enforcing deterministic constraints.
Your layered architecture probably makes that easier since the execution boundary between the agent and the browser interface is already well defined.
How well does the “never makes that mistake again” mechanism hold up in longer sessions? In our experience agents sometimes rediscover the same failure modes once enough context drift accumulates.
Interesting data, especially the retry-escalation pattern. We’ve seen something very similar in internal testing the agent doesn’t interpret a failure as a boundary, it interprets it as a problem to route around.
Your “helpful lie” point is spot on. Once the agent gets into a failure state it will often try to resolve the narrative rather than the system state.
The mental model we’ve been experimenting with is similar to what you describe about infrastructure boundaries. Instead of trying to make the model behave better, we assume it will eventually do something unsafe and focus on what happens at the commit boundary.
In our case the agent can propose actions, but anything that mutates real state (DB writes, API calls, payments etc.) has to pass through a deterministic gate first. The gate doesn’t try to understand intent? it just enforces mechanical invariants like sequencing, replay protection, and bounded actions before a commit is allowed.
The interesting side effect is you get an append-only ledger of proposals, freezes, and commits, which ends up being incredibly useful for understanding how agents actually behave in the wild.
Your sandbox approach and this kind of execution gating feel pretty complementary. Sandbox prevents access to things the agent should never touch, and a commit boundary protects the actions it is allowed to attempt.
Do your logs show patterns where agents keep retrying the same action after a failure, even when the environment makes it impossible? That seems to show up a lot.
Interesting approach. We ended up framing the problem a bit differently, less as “policy checking” and more as commit control.
Instead of validating the model’s output directly, we assume the model can propose anything. The important part is that real-world state changes can’t execute unless they pass a deterministic boundary.
In our experiments the gate sits between the agent and any irreversible action (DB writes, payments, API mutations). The agent proposes an action, the gate checks invariants like replay, sequencing, ceilings, and context consistency, and only then allows the commit.
The nice side effect is that you get a clean append-only ledger of every proposal, rejection, and commit, which becomes extremely useful when agents misbehave.
Prompt guardrails try to make the model behave better. Execution gates assume it eventually won’t and make sure nothing dangerous happens.
Have you seen issues where the policy layer itself becomes complex to maintain as agents operate more varied workflows.
That’s exactly the mental split we’ve been leaning on.
The ledger part turned out to be more useful than we expected. Every freeze/reject event becomes a concrete example of where the agent tried to do something inadmissible, which is much more informative than hypothetical rule design.
On the governance layer: for us keeping the core extremely small and deterministic is proving interesting. The gate itself doesn’t try to understand intent or policy: it only enforces mechanical invariants like sequencing, replay resistance and bounded actions.
So when the agent evolves, we’re mostly not changing the kernel. What changes are the constraints around it (things like ceilings, roles, or context updates). That keeps the maintenance burden manageable because the core logic doesn’t grow with the agent’s complexity.
Early days though the real test will be how it behaves once the agents start doing more varied workflows.
I've been approaching this from a slightly different angle: treating the problem less as "agent alignment" and more as an execution boundary problem.
Instead of trying to force the model to behave via prompts or policies, we assume the model will eventually propose something unsafe. The trick is making sure it can't commit irreversible actions directly.
So the pattern we've been experimenting with is:
agent proposes an action
proposal goes through a deterministic gate
gate checks things like replay, state advancement, spend ceilings, etc.
only then does the real-world action execute
In practice this looks more like a transaction firewall than a prompt guardrail.
The LLM can reason however it wants, but anything that changes real state (payments, DB writes, API calls) has to pass through the gate.
It doesn't solve the reasoning problem, but it makes the commit boundary deterministic, which removes a lot of the scary failure modes like duplicate actions or retries gone wild.
Still early experiments, but the model behaving badly becomes much less dangerous if it literally can't execute without passing the boundary.
One thing we kept seeing is agents are very good at convincing themselves they followed the protocol even when they didn’t. Self-checking helps, but we eventually started treating the agent’s reasoning as advisory rather than authoritative.
The pattern we’ve been exploring is separating what the agent believes it did from what the system actually allows to execute. The agent can generate tests, retry, and self-correct, but any action that mutates real state still passes through an external gate enforcing deterministic constraints.
Your layered architecture probably makes that easier since the execution boundary between the agent and the browser interface is already well defined.
How well does the “never makes that mistake again” mechanism hold up in longer sessions? In our experience agents sometimes rediscover the same failure modes once enough context drift accumulates.