Human-in-the-loop: shipping agents that don't scare people

Human-in-the-loop (HITL) means a person stays in the decision path: the agent does the work, but a human approves the moments that matter. In Velaris it isn’t a setting — it’s the architecture. Read runs automatically, writes get logged, and anything destructive waits for an explicit tap.

Here’s why we made that a hard rule, and what it cost us.

The trust problem is the product problem

Ask someone to connect an AI agent to their email, their CRM and their production database, and the objection is never “is it smart enough”. It’s “what happens when it’s confidently wrong at 3am”.

That’s a fair question, and most of the answers on offer are bad. “It’s very accurate” is not a security model. “You can review the logs” is an autopsy, not a safeguard. If the only thing between an agent and your data is the model’s judgment, you’ve built something nobody sensible will connect to anything important.

So we inverted it: assume the agent will occasionally be wrong, and design for the blast radius.

Three tiers, no exceptions

Every capability in the mesh carries a tier, assigned at the connector level rather than left to the model:

Tier	Examples	Behavior
Read	search inbox, list issues, query rows	Runs automatically. Cheap, reversible, no side effects.
Write	draft a reply, create a ticket, update a record	Runs, but logged verbosely and surfaced in the run timeline. Reversible with effort.
Destructive	send, delete, pay, deploy, share externally	Stops. Shows exactly what it’s about to do. Waits for a human tap.

The tier is a property of the tool, not a judgment the model makes in the moment — because “is this destructive?” is exactly the question you don’t want answered by the thing that might be hallucinating.

Credentials are scoped per run

Tiering the actions isn’t enough if the agent holds your OAuth token the whole time. So credentials are minted per run, scoped to what that run’s plan actually needs, and expire with it.

An agent triaging your inbox gets read access to mail for the duration of the triage. It does not get your Drive. It does not get send scope unless sending is in the plan and you approved it. If the run ends, the grant ends. The audit trail records which run used which scope on whose behalf — so “what did it touch?” has an answer that isn’t a guess.

This is the difference between your agent acting on your behalf and your agent being you. Only one of those is safe to leave running.

What we refuse to automate

There’s a category we won’t put behind an approval tap at all, because the tap becomes theater when it fires often enough:

• Anything irreversible with no preview. If we can’t show you exactly what will happen, we don’t offer to do it automatically.
• Money movement. Agents can prepare a payment. A human executes it. Always.
• Permission and access changes. An agent that can grant access can grant itself access.
• Bulk destructive operations without a staged plan. Deleting one thing is a decision; deleting 4,000 things is a decision you should see itemized first.

Saying no here cost us some impressive demos. It’s the reason people connect production systems.

The constraint made everything better

We expected approvals to feel like friction. Instead they became a design forcing function.

Once an agent must present its next destructive step for a two-second human decision, you have to be able to describe that step in one clear line. That requirement propagates backwards through the whole system: plans get more explicit, steps get smaller, previews get built, undo gets designed in. An agent that can explain itself in one sentence is simply a better agent — and we only learned that because the gate forced us to build it.

The two-second tap isn’t the tax on the product. It’s the product.

---

If you want the broader argument for why this needs an operating system rather than a chat window, that’s here. If you’d like to put it in front of your own tools, get early access — and tell us what you’d never let an agent touch. We’ll probably agree.