Human in the loop AI, enforced at the write path

The split runs through everything we build. An agent can query your accounting system, read a ticket history or search a document store as often as it needs to, because none of that changes anything. The moment it wants to apply a credit note, send an email, refund an order or update a record, it stops. That asymmetry is what lets the useful part run unattended without the dangerous part ever doing so.

A prompt that says the agent would like to update an invoice is not a control, because nobody can evaluate it. What our gates present is the concrete change: this field, from this value, to this value, on this record, because of this evidence. It reads like a pull request, and it is reviewable in seconds rather than requiring the reviewer to reconstruct the agent’s reasoning.

• The exact records and fields that will change
• The before and after values
• The evidence the agent used to decide
• What it considered and rejected, when that is relevant

Each agent holds a narrow set of capabilities, granted explicitly and scoped to the workflow it runs. There is no general purpose write access sitting behind a system prompt asking it politely not to use it. If a capability was not granted, the failure mode is that the agent cannot find a tool to call, which is a very different thing from an agent that decided not to.

Because every write passes through the same choke point, the record of what happened is a by-product of the architecture rather than something a developer remembered to log. Who approved what, when, on what basis, and what the system did next. This is usually the part that makes a compliance conversation short.

Plenty of teams relax a specific gate after watching a few hundred correct proposals, and that is reasonable. It happens per action type, it is a config change rather than a rebuild, and it is reversible in one deploy. What we will not do is ship with gates off and let you discover the consequences.