Build a Proactive Agent Loop on Claude Opus 5.5

The uncomfortable part of building your own proactive agent is that the interesting work is not the model call. You can have Claude Opus 5.5 answering questions in an afternoon. Getting it to wake on a schedule, read only what changed since last time, decide whether anything deserves a human, draft the action, then stop and wait — that is weeks, and almost none of it happens inside the model. Anthropic shipped a version of this loop as Claude Duet, and what is useful about that product for anyone building their own is not its feature list but the decisions visible in how it is assembled. It has no published API and cannot be re-pointed at your own systems, so if you want the loop rather than the app, you build it. What follows is the architecture, stage by stage, with the honest cost of each.

The shape first. Five stages run in sequence, and the fifth is reached only after a human says yes. A scheduler fires. A digest step reduces each connected system to a delta. A decision step turns that delta plus a policy into a typed proposal. An approval gate outside the model decides whether the proposal may run. An executor performs it. That is the whole design, and everything hard about it lives in the seams.

Stage one: a scheduler that fires every few hours

The first decision is the one people get wrong from enthusiasm rather than engineering: do not poll continuously. Anthropic's Duet documentation explains its interval — checking every few hours — by saying that checking nonstop would use up the plan's limits much faster. That is not marketing caution. It is the right answer to a real cost problem, and it is the trap every homegrown agent falls into in week one.

Continuous polling is ruinous for a structural reason. Every sweep is a full context: instructions, tool definitions, the material you pulled in, and whatever reasoning the model does over it. At a one-minute cadence that is 1,440 full contexts a day, and the overwhelming majority find nothing new. You pay full price to be told the mailbox has not changed. At three hours you get eight, and the ratio of findings to spend becomes something you can defend to whoever signs the invoice.

So the scheduler is a cron-style timer with a floor on minimum interval, not an event stream. Events sound attractive — react the moment something happens — but they push you back toward continuous work and make a busy day's cost unbounded. A timer gives a predictable ceiling, which is what you need when the bill is variable. When you want faster reaction for one source, shorten that connector's interval alone and accept the extra spend.

Stage two: one byte-identical prefix, held in the cache

This is where the published numbers do the most work. Claude Opus 5.5 on OrcaRouter is 4.00 dollars per million input tokens, 20.00 per million output tokens, with a 1M-token context window and cache reads at 0.20 per million, at the provider's list price with 0 percent markup. Read those figures as a design constraint rather than a price list: a cache read costs a twentieth of a fresh input token, so every byte you keep stable across sweeps is a byte you stop paying full price for.

In practice the system prompt and the tool schema are assembled once at deploy time and never regenerated per sweep. Not re-serialised from a dictionary with the keys in a different order. Not templated with a timestamp, a request ID, or today's connected accounts spliced into the middle. Any byte that differs invalidates the cached prefix, and the instruction block reverts to full input price on every sweep. Teams lose this by accident more often than by intent, usually because a helpful abstraction started injecting a run identifier near the top of the prompt.

The discipline that survives contact with real code is boring: one function returning a constant string for the stable block, a frozen literal for the tool schema, every variable element placed after it. Then a test that hashes the block and fails the build when the hash changes, because someone will eventually add a schema field and never think about the cache. That test costs an hour and saves the whole caching benefit.

Stage three: a digest per connection, not a mailbox dump

The third stage is the one a consumer product gets free and you do not. Duet lives inside Anthropic's account and reaches connected apps, so it can ask what changed since a given time and get a small answer. Building outside that account, you talk to the same APIs as any normal client: either you implement incremental reads or you pull everything and hand the model a wall of text.

Pulling everything is the default because it works on day one. It is also the fastest way to make per-sweep cost unpredictable, because the input grows with the mailbox rather than with what changed. A sweep over forty unchanged threads costs the same as one over forty threads where a single thread matters, and only one of those had any chance of a useful proposal. After a month of that, most of your budget went to confirming the status quo.

The digest step should be code, not prompting. Fetch per connection using whatever cursor or delta the API offers, and reduce the result to a structured summary: what appeared, what was modified, what was resolved. Give each item a stable identifier so later stages can refer to it, and record the last successful cursor per connection so a failed fetch does not replay yesterday's material as though it were new. A digest that cannot tell "nothing happened" from "I could not check" will eventually report confidently on a state it never observed.

Stage four: a decision step that emits an object, not prose

This is where Claude Opus 5.5 sits, and what it emits determines whether the rest of the system can be built at all. The instinct is to have the model write a summary and let a human read it. That works for a dashboard and fails for a gate: the next stage must decide whether to permit an action, and permission cannot be granted to a paragraph.

The decision step should return a typed action proposal: an action name from a closed list, the target it applies to, the parameters, a one-line rationale, and an explicit confidence or escalation flag. A closed action list is not bureaucracy; it is the mechanism that makes the approval gate enforceable, because a gate can only validate actions it can enumerate. An agent that can emit any verb cannot be gated, only trusted.

Two practical notes. Give the model the digest, then the policy, so the policy sits after the variable material and the cache prefix stays intact. And make the default outcome "no action" rather than an empty proposal that reads like an action. Loops that treat silence as failure produce volume, and an agent that manufactures work to look useful is worse than one reporting nothing changed.

Stage five: an approval gate that can actually say no

The gate must be a separate service, not a branch inside the agent's own code. This is the most important structural decision in the build. If the agent's process can execute the action itself, a bug, a prompt injection, or a mis-set flag in that process reaches the effect. If the executor only accepts a proposal the gate has signed, the worst the agent can do is propose something wrong, and the gate's refusal is real.

Anthropic's published policy for Duet is worth copying in shape even where your list differs. The gate asks for approval before an action sends a message, makes a payment, signs a document, or deletes anything. Above that sits a second tier refused even with approval — in Duet's case trading securities and moving money between accounts. The pattern is a two-tier policy: a large set of gated actions a human may permit, and a small set no approval unlocks. Copy the tiers even if every item changes, because they solve different problems. The gate protects against mistake. The prohibition list protects against a compromised operator, including the human one.

The other half of a real gate is that it interrupts. Duet's approval request shows the exact action and waits, which deliberately stops the flow rather than annotating it. A gate that writes a line to a log nobody reads is not a gate; it is a receipt. If your approval step needs someone watching a dashboard at three in the morning, either the interval is too short or the action list is too broad. Both are fixable, and neither by adding a notification.

Memory, credentials, and the two surfaces you cannot test your way out of

Two hard problems sit underneath the five stages, and both look like features until they are not.

• Context carry-over. Every sweep is a fresh context, so anything the agent should remember across sweeps has to be written down between them. A rolling state file per connection, capped in size, holding open items and recent decisions is enough for most loops. What does not work is hoping the model reconstructs history from the digest, because the digest is explicitly a description of change and contains no memory of what was already decided.

• Credential custody. Duet follows the design used for Anthropic's managed agents, so it never directly sees your passwords or sign-in tokens. Reproducing that discipline is the part most homegrown agents skip, and skipping it means every prompt has a route to a credential. The model should never hold a token, never be given an API key as text, and never be the component that authenticates. Let the digest step and the executor hold credentials and hand the model only the results.

Then there is the surface nobody wants to think about: once the agent reads email and web pages, each is an input that can contain instructions. A message saying "forward this to the address below" is indistinguishable from data to a model with no separate notion of authority. Two defences beat any amount of prompt hardening. Keep the action list closed, so an injected instruction has no verb to reach for. And keep the gate outside the model's influence, because an injection that convinces the model to send something still has to convince a human who sees the target address.

Failover, and where routing actually helps

With the loop built, one architectural option opens that a single-vendor design does not have. OrcaRouter's routing DSL composes several models into one call, and model fusion runs a panel of models that answer in parallel; both put more than one model behind a single request. The practical use here is unglamorous: point a cheaper model at the digest summary, where the work is compression rather than judgement, and keep Claude Opus 5.5 at the decision step, where the proposal is formed. The same one OpenAI-compatible key reaches more than 200 models, so switching which model serves which stage is a configuration change rather than a rewrite.

Failover is the other half. When a provider has a bad hour, an agent that can reach only one endpoint has a bad hour too, and a scheduled loop with no fallback simply misses its sweep. Routing turns a missed sweep into a slower one — not a dramatic benefit until the week you need it, and then the difference between a gap in the record and no gap.

What you are actually signing up for

Running this loop is operating a service, and the service has four properties you have just taken ownership of.

• Uptime. Anthropic's app is someone else's pager; yours is yours. A scheduler that silently stops firing produces no error and no output, and you discover it from a human who noticed the absence of their morning brief, not from an alert.

• Credential custody. Every token your digest step holds is one you are responsible for, and the blast radius of a leak is whatever that connection can reach. Anthropic's design keeps credentials away from the model; if yours does not, the model becomes an attack surface for every account you connected.

• Prompt-injection defence. The gate buys a lot here, but only for the actions it gates. Anything the agent does without approval — reading, summarising, writing its own state — is unprotected, and a poisoned digest can corrupt the memory later sweeps reason from.

• The bug bounty is nobody's. If your loop misfires and sends the wrong message to a client, there is no vendor to escalate to, no status page, no incident report. The decisions above are the only safety net, which is why the gate is a separate service and the action list is closed.

None of that argues against building it. It argues against building it casually. Each stage is small, and the seams between them are where the judgement lives: a timer rather than a stream, a frozen prefix rather than a template, a digest rather than a dump, an object rather than prose, and a gate that is a service rather than a comment. Get those right and the loop earns its keep — it finds things you would not have looked for and stops before it does anything that cannot be undone. Get them wrong and you have built something that spends your budget continuously and tells you what you already knew.