If you run a B2B company that handles regulated or sensitive data, the first serious question your security team asks about any AI rollout is where the work physically executes, and as of October 6, 2026 that answer changed for a tool many of your people already use. Anthropic retired the local-only execution model for Claude Cowork on Pro and Max plans, so every new Cowork task now runs in an isolated environment on Anthropic's servers rather than on the laptop that started it. Tasks launched before October 6 stayed local, which means your team is now split across two execution models depending on when a given session happened to begin. That single configuration change turns a quiet convenience feature into a governance question that lands on the desk of whoever owns your data policy.
What changed in Claude Cowork on October 6, 2026?
Claude Cowork is the agentic side of Claude that takes a described outcome, plans the steps, and returns finished work like spreadsheets, research synthesis, and formatted documents without a human steering each individual prompt. Until this week Pro and Max users could keep that execution on their own machine, and Anthropic's help center now describes those pre-October-6 sessions as the exception rather than the standing default. New sessions run remotely, where Claude analyzes the request, breaks it into subtasks, and runs code and shell commands inside an isolated environment on Anthropic's infrastructure before delivering outputs back to your account. Deleted tasks leave your history immediately and clear from Anthropic's backend storage within thirty days, which is a concrete retention number your compliance reviewer can actually write into a policy.
Why does "where the agent runs" matter for a B2B business?
The location of execution decides which contracts, data-processing addenda, and residency commitments apply, so moving work from a controlled laptop to a shared cloud sandbox is a change your legal team has to re-paper rather than wave through. A healthcare SaaS company bound by HIPAA, or a private-equity-backed portfolio business carrying its sponsor's security requirements, cannot treat "it runs in the cloud now" as a footnote when the underlying files include patient records or financial diligence. The practical risk is not that Anthropic's isolation is weak, because the session isolation and network-egress controls here are genuinely solid, but that your own people adopt the tool faster than your governance can describe where sensitive files are allowed to travel. That gap between adoption speed and policy speed is exactly the condition that keeps companies stuck in pilot purgatory, our term for the state where AI experiments multiply yet never earn a sanctioned path into production.
What do Cowork's permission modes change about governance?
Cowork ships with three permission modes that decide when Claude pauses to ask before acting, and the distinction matters because each one trades oversight for speed in a measurably different way. Manual mode asks for approval before connector actions, Auto mode lets Claude proceed on read-only actions while it self-reviews write and delete steps for safety, and Skip mode runs without asking and without any automatic check. Manual has one catch that matters for compliance: any connector tool someone has marked "Always allow" still runs without a prompt, so Manual only gates the tools left on "Needs approval." For regulated work, Manual mode becomes a real review gate only after an admin sets every write-capable connector to "Needs approval" and keeps it there, because Auto still lets the model decide on some write actions and Skip removes the brake from the process entirely. The reason we hard-wire human approval into every node we deploy is that a vendor's safety check, however carefully tested, is not a substitute for a named person owning the decision on work that moves money or sends messages as your company.
What should a mid-market B2B company do about agent data residency?
The wrong reaction is to ban the tool outright, because a blanket block simply pushes the same work into shadow accounts where you keep zero visibility and run no review gate at all. The right reaction treats execution location as a governed setting across your whole stack, which means you decide per workload whether cloud execution is acceptable, you record that decision somewhere durable, and you give your team a sanctioned path that is easier to follow than the workaround. This is where an agent swarm matters, our term for a set of interconnected AI agents that run across business functions like marketing, sales, finance, and customer success while sharing one context engine and one review gate. When you deploy a swarm instead of a scatter of individual chat tools, the question of where each agent executes becomes one policy you set once rather than a setting every employee quietly toggles on their own machine.
How we handle agent execution at Flywheel
We run our own business on the Flywheel Agent Console before we sell any pattern, so when Anthropic shifts an execution model we see the governance impact on our own marketing, sales, and operations nodes before any client feels it. Every agent in our swarm surfaces its work to a human review queue rather than acting unsupervised, which means a change in where a vendor runs code never silently rewrites what a client sees, because nothing customer-facing ships without a person approving it first. Our approach to agent swarm architecture treats execution location, connector permissions, and review gates as configuration we own on the client's behalf, so the client's team does not have to track every vendor policy update on its own. That ownership is the actual product in a managed AI service, and it is the same reason our breakdown of Claude managed agents for B2B SaaS argues that governance, not raw model capability, is what separates a deployed system from a stalled experiment.
The bottom line on Cowork and AI agent swarm deployment
Anthropic's October 6 move is a reminder that the execution layer under your AI tools will keep shifting, and a business that has not decided who owns those decisions will absorb each change as a fire drill instead of a config review. A serious AI agent swarm deployment pins down three things before the first agent ever runs in production: where each agent executes, who approves its actions, and how quickly a change to either one gets reviewed. We started Flywheel's own deployment from a clean CRM in Phase 0 precisely so those governance questions had a single source of truth to attach to, and that sequence is what lets a vendor change like this one land softly. If your team is adopting agentic tools faster than your policy can describe where the work actually runs, that is the signal to deploy governed agent infrastructure now, while the surface area is still small enough to fence.