Claude Duet Runs on Fixed Intervals: Designing the Wake-Up Loop

A proactive agent is a scheduler with judgment. The published behaviour of Claude Duet, read as an architecture spec for the loop you have to build.

Most discussion of proactive agents is about what they can do. The harder engineering question is when they are allowed to look, how often they may speak, and what has to happen between noticing something and acting on it. Anthropic's Claude Duet happens to document its answers to those questions in unusual detail, which makes it usable as a design reference even if you never touch the product.

The short version

• The interesting surface is the loop, not the model: a fixed check interval, a message that goes quiet once read, one thread of execution, and an approval checkpoint before irreversible actions.
• Every one of those choices is disclosed as a product or cost decision, not as a technical limit. That distinction is the part worth copying, because your own constraints will differ.
• What no public document closes: the actual interval, the quota numbers behind it, latency, and whether anyone reads the approval cards at 7 a.m.

The claim ledger

Anthropic published a launch post, a safety and privacy write-up, a product page and a help centre. Not everything in them carries the same weight, so the first job is sorting claims by what kind of evidence stands behind them.

That table is the whole argument in miniature: the behaviours are described precisely enough to reimplement in outline, and the parameters that would let you size a system are absent.

The loop, reconstructed

Put the disclosed behaviours in order and a state machine falls out. Nothing here comes from source code; it is a reconstruction from what the documentation says the agent does, and it is useful precisely because each transition has a documented rule behind it.

stateDiagram-v2
    [*] --> Idle
    Idle --> Sweep: interval elapsed
    Sweep --> Idle: nothing new
    Sweep --> Draft: something needs attention
    Draft --> Waiting: action is send, pay, sign or delete
    Draft --> Acting: action is reversible and permitted
    Waiting --> Acting: human approves
    Waiting --> Idle: human declines
    Acting --> Recorded: executed
    Recorded --> Idle

Two details in that diagram matter more than the shape of it.

The first is that Sweep is on a timer, not on an event stream. A design that reacted to every incoming webhook would need per-source rate limits, backpressure and deduplication across sources. A design that sweeps every few hours reduces event-driven pressure, at the cost of latency; source rate limits, backpressure and deduplication still need explicit handling. Anthropic states the cost tradeoff explicitly — checking constantly would burn quota — which tells you the interval was chosen for the bill, not for freshness.

The second is that Waiting is a first-class state with a documented payload: the action, the target, the content and every recipient. That is not a UI flourish. It is the contract that makes an approval meaningful, and it is the state most homegrown agents skip by firing the action and logging it afterwards.

Four properties worth copying

Idempotent notifications. "Goes quiet once you have read a message" implies the agent tracks which findings have already been surfaced. Without that, a proactive agent becomes a machine for repeating itself, and repetition is how users learn to ignore it. The implementation detail that carries the design is a stable dedupe key per finding — source, object id, and a content hash — not a timestamp, because timestamps change every sweep.

Bounded reach. The agent drives a browser through a fixed command set (open, click, type) in a separate machine, and website code and cookies do not come back. Whatever the security rationale, the engineering consequence is that the action space is enumerable. An agent whose reach can be listed can be reviewed; one that executes arbitrary code cannot.

Serialized execution. One thread, one task. That removes a whole class of bug — two actions racing on the same account — and it caps throughput in a way you can reason about. If you want parallelism later, the safe increment is parallel reads with serialized writes, not parallel everything.

A checkpoint before anything irreversible. Sending, paying, signing, deleting and creating accounts all stop for a human. Note what is absent: no "don't ask me again" setting for payments, transfers, order deletion or account creation. The absence is the design. A blanket "stop asking" toggle converts a control into a formality.

A loop sketch

The following is a sketch of those properties in code, not a reimplementation of anything Anthropic ships. It is deliberately small enough to argue about.

INTERVAL_HOURS = 4  # illustrative; the official interval is not published

def sweep(state):
    """One pass of the wake-up loop."""
    for app in state.connected_apps:              # bounded reach
        for event in poll(app, since=state.cursor(app)):
            key = (app.name, event.object_id, event.content_hash)
            if key in state.seen:                 # idempotent notifications
                continue
            if not state.budget.consume(event.estimated_cost):
                return                            # interval chosen for the bill

            if event.action in IRREVERSIBLE:      # send, pay, sign, delete
                state.waiting.append(approval_card(event))
            else:
                execute(event)                    # serialized: one writer
                state.log.append(decision(event, "executed"))
            state.seen.add(key)  # only after queuing or successful execution

Three things in those twenty lines are usually missing from a first attempt: the dedupe key, the budget check before work starts rather than after, and the branch that produces an approval payload instead of an action.

The timer is a cost decision wearing engineering clothes

An interval is a product decision, and the help centre is unusually direct about the reason: continuous watching would use up the subscription quota faster. Duet shares one quota with ordinary Claude use, and background sweeps consume it, so every hour of freshness is paid for in the same currency as a chat session.

That has a practical consequence for anyone designing a similar system: the interval is not a constant to be tuned for latency, it is a lever that trades user patience against operating cost. Picking four hours instead of fifteen minutes is a statement about which findings are worth interrupting someone for. Duet's own behaviour — a morning briefing, quiet otherwise — is a bet that most findings are not urgent, which is also why something time-critical can land between two sweeps.

What this design cannot tell you

• Access is reserved for Pro and Max subscribers in the United States who receive a waitlist invitation, so interval length, per-check cost, notification latency and briefing quality are all unknown from outside.
• The interval is described qualitatively ("every few hours"). No number is published, and no quota figure accompanies it.
• Approval fatigue is acknowledged as the reason for calibration but is not measured in public. Whether the cards get read is the load-bearing assumption of the whole design, and it is untested outside Anthropic.
• Anthropic's test programme — three variants, shadow traffic, red teams, an external penetration test — is aimed at adversarial and accidental misuse of the model. It is not aimed at the everyday human failure this design depends on: an owner half-awake at breakfast, tapping approve because the card looked routine.
• The state machine above is a reconstruction. Real systems have retries, partial failures and stale cursors, none of which the documentation describes.

My take

The part of a proactive agent that will decide whether people keep it is the loop, and the loop is mostly boring engineering: a timer, a dedupe key, a budget check, a serialized writer and an approval payload. Models get better every quarter; those five things get built once and then quietly determine whether the agent is trusted.

So copy the shape, not the copy. Set your interval from the cost you are willing to pay per user per day, not from how fresh you wish you were. Make every notification idempotent on a content hash, because users forgive late far more readily than repeated. Serialize writes before you add parallelism, and keep one irreversible-action path that cannot be switched off in a settings page.

If you are building this on top of several model providers, the routing layer becomes part of the loop too: model choice, effort level and per-call cost all belong in the budget check rather than scattered through the code. That is the job a gateway is for — Crazyrouter documents its endpoints and pricing, and whether a gateway fits depends on your call volume and compliance rules.

Sources