The async agent pattern: what actually changed when Claude Cowork moved to the server

An async agent is one that keeps working when you close the laptop. On 7 July, Anthropic pushed Claude Cowork past that line: sessions now live on Anthropic's servers, scheduled tasks run without a device online, and you approve the risky steps from your phone. This piece is about that architecture, not the Microsoft 365 headlines, because the shift from "the session lives on your device" to "the session lives on a server and pings you when it needs you" is the interesting thing.

I want to walk through the pattern properly, because it is going to show up in every serious agent product over the next year, and most of the coverage skips the part that matters: how the agent knows when to stop and ask.

The three modes of agent execution

Before this update, most agent products ran in one of two modes. The new Cowork release is a clean example of the third.

Synchronous. You send a message, the model thinks, you wait, you get a reply. This is ChatGPT circa 2023. The session dies when the tab closes. Total time-to-answer is whatever the model takes, and you are staring at a spinner for all of it.

Session-persistent. You start a task, the agent works, you can leave the tab and come back, and the conversation is still there. The session lives on a server but only advances when you are looking at it. If you close everything and go to bed, nothing happens overnight. This is what most "agent" chat products actually were until recently.

Fully async. You queue a task ("every Monday at 8am, pull the weekend's support tickets, draft replies to the ones you're confident about, and flag the rest for me"). You close everything. Monday at 8am, a server-side loop wakes up, does the work, hits a decision boundary it is not allowed to cross alone, sends your phone a notification, waits for you to tap approve, and finishes. This is the mode Cowork just shipped.

The jump from mode two to mode three is not a UX polish. It is a genuinely different system. And the load-bearing piece of it is the thing sitting at the decision boundary: the approval gate.

The approval gate, mechanically

An approval gate is the point in an agent's execution where it stops itself, saves its state, and refuses to continue until a human signals yes. It is the structural mechanism that makes async execution safe enough to actually ship into someone's Outlook.

Here is what happens under the surface, step by step:

1. The scheduler fires the task at its scheduled time. A server-side worker process picks it up.
2. The agent loop starts running. It reads the task description, plans steps, and begins calling tools — read a SharePoint file, query a calendar, draft an email body.
3. At some point the plan reaches a step marked as requiring approval. Sending an email on your behalf is the canonical example. Writing to a shared document is another.
4. The agent does not send the email. Instead, it serialises its current state — the conversation history so far, the tools it has called, the results it got back, the draft email it has composed, its intended next action — and writes that state to durable storage. This is a checkpoint.
5. A notification is dispatched to your phone with a summary of what the agent wants to do and the specific action pending. "I've drafted a reply to Sarah's ticket. Send it?"
6. The worker process releases its resources. Nothing is running for your task now. The checkpoint sits in storage.
7. You tap approve (or edit, or reject) on your phone. That signal hits Anthropic's servers.
8. A worker picks the task back up, loads the checkpoint, and resumes execution from exactly where it paused. The email sends. The loop continues to the next step, or ends.

If you never approve, the task sits in the checkpoint indefinitely, or until it expires. Nothing happens without your tap.

If this reminds you of interrupt handling in an operating system — a running process hits a boundary, saves its registers, hands control to something else, and resumes later from the saved state — that is the right analogy. The pattern is old. What is new is applying it to LLM agent loops, where "state" is not a stack pointer but a conversation history plus a set of tool-call results plus a partial plan.

A worked example: the Monday morning support triage

Concretely, imagine you schedule this task on Sunday night: "Every weekday at 8am, check the support inbox, draft replies to anything routine, escalate anything that mentions billing, and hold everything for my approval before sending."

Monday 8am. The server-side loop wakes up. It authenticates to Outlook using your delegated OAuth token — the same token you granted when you connected the integration, which lets Anthropic's backend make Microsoft Graph API calls on your behalf. It pulls the inbox, reads twelve new tickets, drafts eight replies, flags three as billing-related, and marks one as unclear.

Then it stops. It writes a checkpoint containing all twelve tickets, the eight drafts, the three flags, and the one uncertainty. Your phone buzzes: Cowork has 8 replies ready to send and 4 items for your review.

You are on the train. You open the notification, skim the drafts on your phone, edit one, approve seven, mark the billing three for a human colleague, and ask Cowork to draft a clarifying question for the unclear one. You tap send. The worker resumes, executes the sends, drafts the clarifying question, checkpoints again, and pings you back for that one final approval.

Total wall-clock time of the agent doing work: maybe ninety seconds. Total time you spent: two minutes on a train. The gap between those two numbers is the entire point of async.

Trade-offs, and what you give up

Server-side state means Anthropic holds your work-in-progress. The checkpoint contains the drafted emails, the file contents the agent read, the calendar entries it pulled. That is different from a device-local session where the sensitive material never leaves your laptop. The release notes do not spell out retention, encryption at rest, or regional data residency for these checkpoints, and enterprise buyers will want that spelled out before rolling this out widely.

The approval gate depends on notification delivery. If your phone is offline, or your MDM strips the notification, or you are simply asleep, the task sits paused. This is fine for support triage. It is not fine for time-critical workflows, and it is the reason you should not schedule a Cowork task to, say, respond to trading alerts.

Write access to Microsoft 365 is a real blast radius. Cowork can now draft and send email, edit calendar entries, and create or update files in OneDrive and SharePoint. Each of those is an authenticated API call against Microsoft Graph, executed with your permissions. If the agent misinterprets a task and the approval gate is misconfigured or bypassed, the damage is not "a weird chat reply" — it is a sent email or a modified shared document. The gates matter because the actions are real.

The one thing worth remembering

Async agents are not defined by what they can do. They are defined by where they stop.

The interesting engineering question for any agent product from here on is not "how capable is the model" but "where are the approval gates, what state gets checkpointed, and how does the human get pulled back in at the right moment". Cowork's July release is a clean version of the answer. Others will follow, and now you know what to look at when they do.

Footnotes and links

Further reading

• Anthropic Claude release notes: https://support.claude.com/en/articles/12138966-release-notes
• Microsoft Graph API overview: https://learn.microsoft.com/en-us/graph/overview
• InfoWorld coverage of the Cowork web and mobile expansion: https://www.infoworld.com/article/4108092/6-ai-breakthroughs-that-will-define-2026.html

¶