Anthropic opened a research preview of Claude Duet on October 21, a proactive agent that watches connected apps and works through tasks you hand it. Gmail and Slack are in its list of examples, next to QuickBooks, Stripe and HubSpot. Meta’s Muse launched six weeks earlier, on September 8, with the same pitch. Meta’s own engineering post says it was the first time they had handed their inboxes and calendars to software and let it run unattended, and that it did not always work out as planned.

Both products answer the obvious worry the same way: they ask before anything important. That sentence is true, and it tells you almost nothing. A dozen approvals a day is “asking before anything important” too, and by the second week you are tapping yes without reading.

I read the safety documents from both companies to see how they decide what counts as important. Neither one leans on the click. Each moved most of the control somewhere else, and what is left for the human is a short list.

Four ways to handle an agent action, and only one of them is a prompt

Put the two designs side by side and the same four treatments show up.

First, block it even if the human says yes. Duet will not trade securities, move money between your accounts or access someone else’s account, with or without your approval. No prompt exists for these, so nobody can approve them by accident.

Second, bound it before the agent starts. For purchases, Duet pays with a one-time card from a wallet such as Link, limited to that merchant and that amount. You approve the purchase in your Link app. The damage a wrong approval can do is capped by the card itself. Muse does the same thing for access: where a service supports it, read and write are separate grants, and Meta says you can grant the Gmail read scope and still remove the Gmail settings access that normally comes bundled with it.

Third, ask, every time. Duet will not let a “don’t ask me again” rule cover paying or sending money, deleting an order or creating an account, however often you approved them before. The prompt stays expensive on purpose. And the card shows the action, the destination and the content, including every recipient, so the person can judge it in a few seconds.

Fourth, allow it and check later. Muse says read-only, previously allowed or demonstrably low-risk actions can proceed without interruption. Its post says it plainly: the point is not to ask the user about everything.

Anthropic puts the reason in writing, in the Duet safety document: “Approval fatigue is a serious issue, because too many requests teach people to tap through them.” Read that as a vendor admitting the prompt is the weakest of the four tools, and spending it carefully.

Muse asks about the process, not only the action

The most useful idea I found is in Meta’s design. Muse tracks what a tool process has touched. Each one starts clean and becomes tainted the moment it reads user data. A clean outbound request that fits a narrow allow policy goes through. A tainted or unverifiable process loses auto-allow and falls back to the approval flow. Meta calls this “tainted egress” and says it exists to balance the signal-to-noise ratio of approvals.

So the same network call gets a different answer depending on what the process knew when it made it. That is a better question than “is sending an email risky?” Sending an email that contains nothing from your inbox is cheap. Sending one from a process that just read the CFO’s thread is not.

Two more details matter if you build anything similar. In Muse, a separate agent called Sentinel is the sole permission authority and returns allow, deny or ask, and the approval dialog appears in the client interface, not in the chat. In Duet, the check that compares each action to your intent runs outside the model doing the work. In both cases, nothing the agent reads, such as a web page or an email body, can answer its own approval card.

What the vendors cannot decide for you

Both products ship with defaults written for a consumer. Duet is a waitlist preview, starting with US users and included in the Pro, Max and Ultra plans. Muse offers allow once, always allow or deny, and also one-time, session, task and time-bounded grants. Nobody has written the table for your company: which Slack channels an agent may post in, which calendar invites it may accept for an executive, which mailbox it may read and which it may only draft from.

I am not claiming your team has connected any of these to work accounts. If someone does, or when your own agents get the same access, the four-way split is the thing to fill in. I have written before about Uber measuring people approving 50+ actions in one session, which showed the problem. This is the other half, the design that avoids it.

The test I would use for any single action:

1. Can a mistake be capped before it happens, with a limit, a read-only scope or a one-time credential? Then cap it and skip the prompt.
2. Is it irreversible, does it leave the company, and can the approver judge it from what the card shows? Then ask, every time, with no remembered approval.
3. Is it something no one should ever authorize? Then block it.
4. Is it none of those? Allow it, log it, and review the log.

If the approver cannot judge the action, because the card shows “Send message to 14 recipients” and nothing else, the prompt is theater. Fix the card or move the action to another group.

What we do at IQ Source

In AI Maestro this table gets built in two passes: the discovery maps which actions each process touches, and when the agent is designed, in Stage 2, every row gets its treatment before the agent gets mail, Slack or calendar access. One row per action the agent can take through each connector, one of the four treatments in the next column, and a reason. The rows that end up as “ask” are the ones you count: how many a day, per person, and whether the person approving can tell good from bad from the card alone. If the count is large, the group assignment is wrong, and we move rows to “bound” or “block” until it is small enough to read.

This is also where the OAuth grants you already gave get reviewed, since a read scope that quietly includes settings access cannot be fixed with a prompt. It is the operating side of what I called governance as the moat.

I did not cover OpenAI’s dots here. I could not find a page from OpenAI describing its approval design, and I would rather leave it out than quote someone else’s summary.

If you want your agent’s action table drafted before the first connector goes live, book the AI Maestro discovery and start with the actions list