Aylin

One framing that changes what you build: treat the agent as an untrusted client of your own API, not as part of your application.

You would not let an unknown caller hit a paid endpoint with no quota, no rate limit and no per-key accounting. Give the agent its own credential, its own quota and its own bill, exactly as you would an external integration.

That is what the newer tools in this space are essentially selling — a credential with an allowance attached rather than your production key. You can build the same thing in an afternoon with a proxy in front of your providers, and the proxy is worth having anyway because it is where the logging, the caching and the kill switch live.

The kill switch is the part people skip. One flag that makes every tool call fail immediately, reachable without a deploy.

There is a principle and it is not "how risky is this". It is reversibility.

Sort every action the agent can take into three buckets:

• Reversible and cheap. Reading, searching, writing to a scratch branch, producing a draft. No approval, ever. Interrupting here is pure cost.
• Reversible with effort. Committing to a branch, creating a resource, sending an internal message. No approval, but it must be logged and undoable, and somebody must be able to see what happened without asking the agent.
• Irreversible or externally visible. Sending mail to a customer, deleting data, deploying, paying, posting publicly. Always approval.

The reason this beats a risk score is that risk is a judgement and reversibility is a fact. You can answer it for each tool once, at design time, and the answer does not drift.

It also tells you what to build: the middle bucket needs an undo, and building the undo is usually cheaper than building the approval flow.

One thing to decide before adopting any of them: what the agent is allowed to do, as opposed to see.

Reading pages is a fairly contained risk. Filling forms, clicking through checkouts, sending messages and changing settings is a different category, and the failure is not "wrong answer" but "wrong action, already taken".

The products that impress me draw that line explicitly and make the write actions require confirmation. The ones that treat browsing and acting as the same capability are the ones I would keep away from anything logged in.

Worth flagging the approval-first framing in that batch of launches, because it is addressing a real problem rather than a workflow preference.

Several agents acting concurrently means several chances to do something irreversible, and it is much harder to keep track of what was done and by which one. A single agent you are watching is reviewable. Five agents working in parallel are not, in practice — people approve the fifth one the way they approve a cookie banner.

The setups I have seen work make the isolation real: each agent in its own working copy, changes surfaced as diffs, nothing touching a shared environment until a person merges. That way the concurrency is in the producing and the serialisation is in the accepting, which is the correct place for it.