Most AI assistants wait for a question. Claude Duet moves first. It checks connected apps, sends a short brief when something needs attention, and keeps working in its own virtual machine while the user is away.

Anthropic opened a research preview of Claude Duet on October 21, 2026. It is available by waitlist to Pro and Max subscribers in the United States, through standalone iOS and Android apps and on claude.ai. The interesting question is not whether a chatbot can initiate a conversation. It is what happens when an agent gets standing authority to act on a user's behalf.

What is confirmed, and what is not

Anthropic describes both the product and its safety design. Those are vendor claims. This review did not find an independent measurement of task accuracy, false-alert rates, or approval quality.

Item Confirmed in the announcement What it means
Availability Research preview, US Pro and Max waitlist Not general availability
Model Built around Claude Opus 5.5 Model changes are not documented
Runtime A virtual machine with its own browser Work continues without the user's device
Check cadence Connected apps are checked every few hours It is not continuous monitoring
Integrations More than 6,000 connectors and plugins Per-app permissions still need review
Approval Before sending, paying, signing, or deleting The approval UX is not independently tested
Hard limits Trading securities and moving money between accounts are off-limits even with approval Policy may change
Credentials Designed so Duet never directly sees passwords or sign-in tokens Anthropic's design claim
Known gaps Cannot yet show its browser; personal errands are weaker Explicit preview limitations

The "every few hours" cadence is a deliberate trade-off. Anthropic says checking nonstop would consume plan limits much faster. Background checks count toward the same usage limits as the rest of Claude. A more proactive agent is not automatically a better one; check frequency, alert quality, and cost have to be designed together.

Five layers behind the chat window

Calling Claude Duet a proactive chatbot misses the architecture. At minimum, separate five layers.

Layer Role Failure mode
Context Carries over memory, skills, and connected apps Repeats stale preferences or wrong context
Observation Checks connected apps on a schedule Misses important events or floods the user with noise
Execution Acts through a VM and browser Makes unintended changes in external services
Approval Stops before sensitive side effects Approval fatigue, mistaken approval, approval phishing
Audit Records what was done, where, and with which credential Cannot reconstruct an incident

Anthropic points to its trustworthy-agent framework, the credential handling used for Claude Managed Agents, an auto mode classifier, and browser-use research on prompt injection. It also says red teams and an external firm penetration-tested the product, and that it is covered by a public bug bounty. Those statements describe design intent and testing scope. They do not prove that every connector, account, and document path is equally safe.

Split the approval boundary by action

"Important actions require approval" is too broad to implement. The useful unit is the action class: read, draft, send, pay, sign, delete.

Action Default policy What the approval should show Main risk
Read Automatic App and data scope Over-broad access
Draft Automatic Draft and sources Sensitive data in the draft
Send externally Per-message approval Recipient, body, attachments Blanket approval
Pay Per-payment approval Amount, merchant, funding source, refund terms Budget and limit bypass
Sign Per-document approval Document, parties, effective date Legal effect without review
Delete Per-action approval Object, backup status, recoverability Irreversible loss
Trade securities or move money between accounts Deny Nothing to approve Explicitly off-limits

This table is a policy example for an adopting organization, not a description of a Claude Duet settings file. The important distinction is between "the agent asked for approval" and "the person understood the action and approved it." A long approval screen trains people to click through. Approval fatigue turns a safety control into decoration.

A two-tier design is more realistic. Low-risk actions can be summarized in a batch, with the original items still inspectable. High-risk actions should be approved one at a time, with the recipient, amount, document, or deletion target visible in plain language. A short cancellation window after approval helps with mistakes that are noticed immediately.

The cost of proactivity is attention

A proactive agent cannot be measured only by task completion. It also spends the user's attention. A long morning brief and several daytime alerts can turn the agent into another notification feed.

Anthropic emphasizes a short morning brief and messages only when something needs attention. It also says it is still tuning the agent's judgment about when to message. That is the right admission. Before adopting a tool like this, measure not only whether it catches the important event, but whether it stays quiet when nothing important is happening.

A pilot scorecard

A pilot that ends with "it felt useful" will not survive contact with a team. Track a small set of measures for at least two weeks.

Metric How to measure Direction
Useful alert rate Alerts that led to a real action Higher is better, with small-sample caution
False alerts Items the user marked as not important Lower is better
Approval rejection rate Approval requests that were rejected or edited High can mean weak judgment
Time to approve Time from request to approval or rejection Fast is not always good
Unassisted completion Tasks finished without human intervention Read alongside task difficulty
Permission scope Apps, accounts, and data the agent can reach Smaller is safer
Recovery time Time to undo a wrong action Shorter is better

A high rejection rate can mean the agent has learned the wrong approval threshold, not that it cannot do the work. A very low rejection rate can mean users are rubber-stamping. Neither number is meaningful without looking at the approval UI and the sample of tasks.

Enforce the boundary outside the model

A prompt that says "ask before paying" is not an approval boundary. The model can forget it, a tool schema can change, or a malicious document can inject a conflicting instruction. Enforcement belongs in a tool gateway or policy layer outside the model.

The YAML below is an unexecuted illustration of the policy shape, not a Claude Duet configuration.

# Illustrative policy, not a Claude Duet settings file.
actions:
  read_connected_app:
    mode: auto
    constraints:
      least_privilege: true
      audit_log: true
  draft_message:
    mode: auto
    constraints:
      external_side_effect: false
  send_message:
    mode: require_approval
    preview: [recipient, body, attachments]
    allow_bulk_approval: false
  make_payment:
    mode: require_approval
    preview: [amount, merchant, funding_source]
    limits:
      per_transaction: 0
      daily: 0
  sign_document:
    mode: require_approval
    preview: [document, parties, effective_date]
  delete_data:
    mode: require_approval
    preview: [object, backup_status, recoverability]
  trade_securities:
    mode: deny
  move_money_between_accounts:
    mode: deny

The actual product also depends on its approval UI, permission model, audit export, and payment provider. A policy file alone does not make an agent safe. It does make the intended boundary explicit, so it can be reviewed when the model or a connector changes.

Questions to ask before a pilot

  1. Is the agent using a dedicated, least-privilege work account rather than a personal primary account?
  2. Have sending, paying, and deleting been tested against a real external service in a controlled environment?
  3. Does the approval screen show the recipient, amount, document, or deletion target in plain language?
  4. Can a connected app be revoked immediately? What happens to scheduled work and cached data after revocation?
  5. If an email or document contains a prompt injection, can it cause an external send?
  6. How much of the plan limit do background checks consume?
  7. Can audit events be exported to the existing SIEM or ticketing system?
  8. How do users report a missed alert or a false alert?

Anthropic explicitly says Duet may misread a thread or miscalibrate urgency. It is designed around work, not personal errands, and it cannot yet show its browser. A pilot should be scoped around those limits rather than pretending they do not exist.

Conclusion: a proactive agent is standing authority

The distinctive part of Claude Duet is not that it starts conversations. It is that work continues while the user is away, and that work can create real side effects in external services. At that point the agent is no longer a chat partner. It is a delegate with standing authority.

The adoption decision will be won or lost at the approval boundary. Decide which actions are automatic, which stop one at a time, whether the approval screen is actually readable, and whether a wrong action can be undone. Then expand connectors and check frequency. Doing it in the other order is how a helpful preview becomes an incident.

Further reading

References

Go deeper with a course

Separating what to automate from what a human should review is a policy-design problem before it is a prompting problem. If you want practice connecting recurring judgments to code and designing confidence, stopping conditions, and human review together, this course is a useful starting point.