Claude Cowork Architecture Deep Dive: VM Isolation, MCP, and Agentic Loop

Have you ever wondered why, after all these years of chatting with AI, it can only “talk” but not “do”?

Just now, Anthropic released Claude Cowork, and this product really caught my attention. It’s not just another chatbot—it’s a digital coworker that can actually help you get things done.

Today we’re going to dissect the underlying architecture behind Cowork: how it transforms a “talking model” into a “doing system.”

If you’re more interested in “how to use, manage, and pilot” (task templates, guardrails, metrics), I’ve written a separate article on implementation: /en/blog/claude-cowork-landing-guide/.

TL;DR

• Paradigm Shift: AI evolves from “Oracle Mode” (passive Q&A) to “Agentic Mode” (active collaboration), bridging the gap between thinking and acting
• Virtualization Isolation: Cowork executes tasks in a local VM-isolated environment with strict control over file and network access; third-party analysis suggests the macOS version may use Apple Virtualization Framework (AVF)
• MCP Protocol: Model Context Protocol is the “USB-C port” of the AI era—through Resources/Tools/Prompts primitives, it enables Agents to connect to various data sources and tools in a standardized way
• Agentic Loop: The closed-loop design of Observe-Plan-Act-Reflect enables AI to autonomously complete complex tasks and learn from errors
• Shared Architecture: Cowork and Claude Code share the same agentic architecture and workflow patterns; the GUI serves as a “control plane/visual shell,” bringing these capabilities to a broader audience

1. Paradigm Shift: From Oracle Mode to Agentic Collaboration

In the long evolution of software engineering and human-computer interaction, we’re at a decisive turning point.

Over the past two decades, we’ve progressed from command-line interface (CLI) precision control to graphical user interface (GUI) intuitive operation, and more recently to early experiments with natural language interface (LUI). However, until LLMs acquired Tool Use and long-term planning capabilities, AI’s role in development and office scenarios remained largely in “Oracle Mode”:

Users ask questions, AI provides probabilistic text answers, but final decisions, validation, and execution still require human manual intervention.

This pattern has a fundamental flaw—the separation of thinking and acting.

The emergence of Claude Cowork, along with its underlying Claude Code architecture, marks our official crossing of this divide into the “Agentic Era”. In this new era, AI is no longer merely a text-generation engine but a digital entity endowed with hands (tools), eyes (visual perception), and environmental awareness. It can not only “speak” but also “do.”

1.1 Externalization of Cognition and Execution Closure

In traditional software development lifecycle (SDLC) or complex knowledge work, the biggest bottleneck often isn’t “knowing how to do it” but the tedious context switching and execution details.

For example, refactoring a legacy module requires a developer to: understand the code → find references → modify files → run tests → fix errors → commit code. This is a classic OODA Loop (Observe-Orient-Decide-Act).

The core value of Claude Cowork lies in taking over the intermediate steps of this loop. Through deep integration into the user’s desktop environment, it unifies externalization of cognition (Reasoning) with execution closure (Execution) in the same context.

This isn’t simple automation scripting, because scripts can’t handle non-deterministic errors. Cowork relies on LLM reasoning capabilities to self-reflect and self-correct when encountering errors (like compilation failures or files not found).

1.2 Democratization of “Computer Use”

While Claude Code provides developers with powerful terminal interaction capabilities, its CLI form naturally excludes non-technical users.

The architectural significance of Cowork is that it wraps this ability to operate computers through code and tools into a user-friendly GUI shell. This isn’t just an interface change—it’s a generalization of underlying capabilities.

From a technical perspective, Cowork achieves an ideal form of “human-machine collaboration”:

• Humans handle high-level intent definition and critical node approvals (Human-in-the-Loop)
• AI handles low-level task decomposition, tool invocation, and state management

This division of labor significantly frees human cognitive bandwidth, allowing us to focus on the most creative parts.

2. Architecture Anatomy: The Deep Structure of Claude Cowork

To understand Cowork’s power and limitations, we must peel back its Electron application surface and dive into its operating system-level implementation.

Based on public information and technical analysis, Cowork isn’t a simple API wrapper but a complex distributed system microcosm running on the user’s local machine.

2.1 Virtualization and Security Boundaries: VM Isolation Implementation

The core risk of running an Agent in enterprise environments or on personal devices is “uncontrolled side effects.”

An AI with file read/write permissions and Shell execution capabilities, without strict constraints, could cause catastrophic consequences due to hallucination or Prompt Injection (like accidentally deleting critical files or leaking sensitive data).

According to Anthropic’s official documentation, Cowork executes tasks in a local VM-isolated environment with controlled file/network access. Based on third-party observation and reverse engineering (particularly Simon Willison’s deep dive), the macOS version appears to employ a hardcore isolation scheme: lightweight virtual machines based on Apple Virtualization Framework (AVF).

2.1.1 Architecture Topology

To visually demonstrate Cowork’s security isolation mechanism, we’ve constructed the following architecture topology:

┌─────────────────────────────────────────────────────────────┐
│  Host Machine (Host - macOS)                                 │
│                                                              │
│  ┌────────────────────────────────────────────────────────┐ │
│  │  User Interface (UserUI - Electron)                     │ │
│  └────────────────────────────────────────────────────────┘ │
│                          │                                   │
│                          │ IPC / Stdio Control              │
│                          ▼                                   │
│  ╔════════════════════════════════════════════════════════╗ │
│  ║  Security Boundary (VM Isolation)                       ║ │
│  ║  ┌──────────────────────────────────────────────────┐  ║ │
│  ║  │  Guest Kernel (suspected Linux)                   │  ║ │
│  ║  │  ┌─────────────────────────────────────────────┐ │  ║ │
│  ║  │  │  Guest User Space                           │ │  ║ │
│  ║  │  │  ┌─────────┐  ┌─────────┐  ┌─────────┐     │ │  ║ │
│  ║  │  │  │  Agent  │  │  Tools  │  │  Shell  │     │ │  ║ │
│  ║  │  │  └─────────┘  └─────────┘  └─────────┘     │ │  ║ │
│  ║  │  └─────────────────────────────────────────────┘ │  ║ │
│  ║  └──────────────────────────────────────────────────┘  ║ │
│  ║                          │                              ║ │
│  ║                          │ FS_Bridge (Controlled Share) ║ │
│  ╚══════════════════════════│═════════════════════════════╝ │
│                             │                                │
│                             │ On-Demand Mount (Read/Write)   │
│                             ▼                                │
│  ┌────────────────────────────────────────────────────────┐ │
│  │  Host File System (User Home - Authorized Dirs Only)    │ │
│  └────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘

2.1.2 Why AVF + Linux VM? (Third-Party Inference)

Traditional sandboxing technologies (like macOS App Sandbox or Docker containers) often struggle to balance isolation and performance. Docker on macOS depends on a Linux VM, with significant overhead and file system performance as a persistent bottleneck.

AVF is Apple Silicon’s native virtualization framework, capable of launching virtual machines with minimal overhead.

Based on third-party observation and reverse engineering (primarily from technical professionals like Simon Willison), Cowork on macOS appears to employ the following implementation:

Compute Isolation: The Agent’s execution environment appears to run inside an independent Linux VM (with a custom rootfs), not directly in the host user space. Even if malicious commands are issued (like attempting rm -rf /), the damage is confined to the temporary Guest environment and cannot touch the host system.

Environment Consistency: This solves the classic “works on my machine” problem. Regardless of what Python, Node.js, or system library versions are installed on the user’s host machine, the Agent runs in a standardized Linux environment pre-installed with necessary toolchains (git, grep, curl, etc.). This greatly improves task execution success rate and predictability.

Note: The above is technical inference based on public observations. Official public statements only confirm “execution in a local VM-isolated environment with controlled file/network access.” Specific implementation details may change with version updates.

2.1.3 File Sharing: Controlled Access Across Boundaries

Isolation alone isn’t enough—Cowork’s job is to process user files. This involves high-performance file sharing between the VM and host machine.

Based on official documentation and third-party observations, Cowork appears to employ the following file sharing mechanism:

On-Demand Mounting: Cowork doesn’t have full access to the host file system. At the UI level, users must explicitly select a folder (Project Folder) to authorize for Cowork. Under the hood, VM file sharing/mounting mechanisms (possibly including VirtioFS) map specific host directories to the execution environment.

Permission Projection: This architecture achieves physical-level permission control. The Agent cannot read directories that haven’t been authorized for mounting (like ~/.ssh or ~/Documents) because these paths simply don’t exist in its isolated environment. This is far more secure than any software-level permission checks (like system prompts saying “please don’t read sensitive files”).

Note: Specific file sharing implementation details (whether VirtioFS is used, mount point paths, etc.) haven’t been publicly disclosed. Third-party analyses have mentioned various clues including mount/bindfs, and specific mechanisms may vary by platform and version.

2.1.4 Supplement: Implementation Details Frequently Mentioned in Public Sources (For Reference Only)

The following points come from public discussions and secondary summaries, and may change with preview version iterations; we’re placing them in a “supplement” to avoid being misread as official commitments:

• Platform Requirements: Some analyses suggest macOS 13+ and Apple Silicon are key prerequisites.
• Image Delivery: Some analyses mention downloading signed Linux VM bundles (e.g., artifacts like rootfs.img).
• Resource Quotas: Some analyses mention relatively conservative VM resource configurations (CPU/memory quotas) to balance performance and host utilization.
• “Sandbox within VM”: Some analyses mention the VM interior may use mechanisms like bubblewrap/seccomp to further constrain execution process permissions and system call surfaces.
• Unified Network Egress: Some analyses mention the execution environment may not directly connect to the external network by default, with network requests routed through host-side proxy/forwarding components for policy enforcement and auditing.

2.2 Architectural Relationship Between Claude Code and Cowork

Many users and analysts initially assumed Cowork was an entirely new standalone product. According to Anthropic’s official documentation, Cowork “uses the same agentic architecture that powers Claude Code.” This means they share the same agentic architecture and workflow patterns; the GUI serves more as a control plane/visual shell, bringing these capabilities to a broader audience.

This isomorphism means that the powerful Agent capabilities Anthropic has accumulated with Claude Code—code understanding, file operations, test fixing, etc.—are seamlessly migrated to Cowork.

Conversely, Cowork’s explorations in virtualization security will very likely feed back to the CLI version of the tool in the future.

2.3 Core Loop: Observe-Plan-Act-Reflect

Whether CLI or GUI, what drives the Agent is a core control loop. According to third-party technical analysis (such as PromptLayer’s analysis of Claude Code), this loop is called the “Master Agent Loop” and runs as a single-threaded while-loop.

    graph TD
    Start([User Input/Goal]) --> Observe
    
    subgraph CoreLoop["Agentic Master Loop"]
        Observe[Observation<br/>Read environment state/files] --> Plan
        Plan[Planning<br/>Generate/update chain of thought] --> Decision{Action needed?}
        
        Decision -- Yes --> Act[Action<br/>Generate tool call commands]
        Decision -- No --> Response[Generate final response]
        
        Act --> Execute[Execution<br/>VM/MCP runtime]
        Execute --> Reflect[Reflection<br/>Analyze execution results]
        
        Reflect -- Success/Failure --> Observe
    end
    
    Response --> End([End])
  

This loop is the embodiment of Agent intelligence:

1. Observation: The Agent obtains the current environment state. In Cowork, this includes reading the file list of the currently mounted directory, Git status, and stdout/stderr output from the previous tool execution.

2. Planning/Reasoning: Based on current state and user goals, the model generates a chain of thought (CoT). According to official documentation, Cowork creates a plan at the start of a task, and users can view and steer the plan’s execution during the process. This “Human-in-the-Loop” design is a key mechanism for addressing AI hallucinations.

3. Action: The model outputs structured tool call commands (Tool Calls), such as edit_file or run_command.

4. Execution: The system executes the tools. In Cowork, this typically means running through the MCP protocol or directly executing Bash commands in the Linux VM.

5. Reflection: The Agent receives execution results. If successful, it proceeds to the next step; if failed (file not found, API error), the Agent enters a self-correction flow, analyzing the error cause and attempting alternative approaches.

3. Neural System: Model Context Protocol (MCP) Deep Dive

If the LLM is the brain and the virtualized environment is the body, then Model Context Protocol (MCP) is the neural system connecting the Agent to the external world.

As a universal standard solving the AI application interconnect “N×M” problem, MCP’s introduction has epoch-making architectural significance.

3.1 Solving the Fragmented Integration “N×M” Dilemma

Before MCP, AI developers faced enormous integration costs:

• Making Claude access Google Drive required developing a dedicated plugin
• Making ChatGPT access Postgres required developing yet another solution

As the number of models (N) and data sources (M) increases, integration complexity grows N × M exponentially.

MCP aims to become the USB-C port of the AI era. It defines a standardized JSON-RPC protocol, so data sources only need to implement one MCP Server to be connected by all AI applications supporting MCP Client (such as Claude Desktop, Cursor, IDEs).

3.2 Protocol Architecture: Host, Client, and Server

MCP employs classic client-server architecture but gives new role definitions in the AI context:

    sequenceDiagram
    participant U as User
    participant H as Host (Claude Desktop)
    participant C as MCP Client (Internal)
    participant S as MCP Server (e.g., Git/Postgres)
    participant R as Actual Resource (Repo/DB)

    Note over H, S: Initialization Phase
    H->>S: Initialize (Capabilities)
    S-->>H: Server Capabilities (Resources, Tools)
    
    Note over U, R: Runtime Loop
    U->>H: "Query the latest order from the database"
    H->>H: LLM thinks and decides to call tool
    H->>C: Call Tool: query_db
    C->>S: JSON-RPC Request: tools/call
    S->>R: SQL Query
    R-->>S: Query Result
    S-->>C: JSON-RPC Response
    C-->>H: Tool Output
    H->>H: LLM generates natural language response
    H-->>U: "The latest order is #12345..."
  

MCP Host: This is the terminal the user directly interacts with, such as the Claude Desktop application. It manages the entire session lifecycle, UI rendering, and core interaction with the LLM. The Host acts as an orchestrator, deciding when to connect to which Servers and how to expose Server capabilities to the LLM.

MCP Client: The protocol implementation layer embedded within the Host. It establishes 1:1 connections with MCP Servers, handles protocol handshakes, Capability Negotiation, and serializes LLM-generated tool call requests into JSON-RPC messages to send to Servers.

MCP Server: This is the component that actually does the work. It can be a local Python script or a remote web service. It exposes three core primitives through standardized interfaces: Resources, Tools, and Prompts.

3.3 The Trinity of Core Primitives: Resources, Tools, Prompts

Understanding MCP’s core lies in understanding its three defined primitives, which correspond to three modes of Agent information acquisition, operation execution, and knowledge reuse.

3.3.1 Resources: Passive Context

Definition: Resources are data sources, similar to REST API GET endpoints or file system files. They are read-only and passive.

Interaction Pattern: Application-Driven. The user or Host decides when to “Attach” a certain Resource to the conversation context.

Architectural Significance: Resources’ design reflects fine-grained management of the LLM context window. Instead of stuffing all data into the model at once, resources are referenced via URI (like postgres://db/table/schema). The model can “see” the resource exists but only reads its content when needed.

Typical Examples: Database schemas, API documentation, log file tails, real-time system monitoring metrics.

3.3.2 Tools: Active Capabilities

Definition: Tools are executable functions that can produce side effects or perform computations.

Interaction Pattern: Model-Controlled. The LLM autonomously decides whether to call a tool based on user intent and current context, and what parameters to use.

Architectural Significance: Tools are the Agent’s means of changing the world. The MCP protocol mandates that Servers define clear JSON Schemas to describe tool parameter structures, enabling LLMs to accurately generate call commands.

Typical Examples: execute_sql_query (execute SQL), send_slack_message (send message), git_commit (commit code), resize_image (process image).

3.3.3 Prompts: Preset Workflows

Definition: Prompts are predefined templates containing specific System Prompts and user input placeholders.

Interaction Pattern: User-Initiated. Users select a Prompt in the interface to initiate a specific task flow.

Architectural Significance: Prompts enable the reuse of Best Practices. A senior operations engineer can write a Prompt called “Incident Analysis” that codifies standard troubleshooting steps, distributing it to junior team members or directly for Agent use.

3.4 Transport Layer Deep Comparison: Stdio vs Streamable HTTP

The MCP protocol provides two standard implementations at the transport layer, corresponding to two distinctly different local and remote application scenarios.

Important Note: The MCP specification has updated the transport layer to two standard transports: stdio and Streamable HTTP. Streamable HTTP can optionally use SSE (Server-Sent Events) for streaming capabilities and notification mechanisms. The old “HTTP+SSE transport” has been superseded but maintains backward compatibility.

Architectural Decision Analysis:

In common desktop deployment scenarios, Stdio mode is often the more natural choice: local processes, low latency, data stays on-machine, smaller attack surface.

For example, if launching a Git-type MCP Server subprocess within an isolated environment (VM/container), this design ensures operation atomicity and speed (operating on files directly within the isolated environment) while leveraging the boundary for security. Conversely, using Streamable HTTP network transport would introduce additional network and authentication complexity, expanding the attack surface.

However, as enterprise application demands increase, the importance of Streamable HTTP mode will grow. Imagine a scenario: an enterprise deploys a centralized “Oracle ERP MCP Server,” and analysts across the company connect to this Server through their respective Claude Desktop instances to query financial data. In this case, Streamable HTTP’s multi-tenant support and remote access capabilities become indispensable.

3.5 Protocol Lifecycle and Capability Negotiation

The MCP protocol is a stateful protocol, fundamentally different from stateless REST APIs. A typical MCP session includes the following phases:

1. Initialization: The Client sends an initialize request with protocol version and its own Capabilities.

2. Capability Negotiation: The Server responds with its supported protocol versions and capabilities (such as whether it supports resource subscriptions or dynamic tool list refresh). This step ensures Client and Server can collaborate on a minimum common feature set.

3. Listing Discovery: The Client requests available Tools, Resources, and Prompts lists.

4. Runtime Loop:

   • Client sends tools/call requests
   • Server executes logic and returns results
   • Server can proactively send notifications/resources/updated notifications, informing the Client that a resource has changed (like a log file having new content), and the Client may re-read the resource accordingly

5. Sampling: This is an advanced feature allowing Servers to request the Client (i.e., Host) to invoke the LLM for reasoning on its behalf. This allows Servers themselves to have certain intelligence, enabling more complex logic.

4. Intelligent Core: Claude’s “Computer Use” Capability

The brain powering Cowork is the Claude model series. Public materials often use models like Sonnet as examples to illustrate “Computer Use” capabilities, but specific model versions and capability toggles may vary with product stages and platforms.

4.1 Visual Perception and Pixel-Level Positioning

Traditional Agents primarily relied on text interfaces (like HTML DOM trees or Accessibility APIs) to understand screen content. However, many modern applications (like games, remote desktops, complex Canvas drawing apps) don’t provide structured DOMs.

Claude model series (e.g., Sonnet) introduced stronger visual perception capabilities. It can directly analyze screenshots:

• Semantic Understanding: It can identify a “Submit” button on screen even if it’s just an unlabeled blue rectangular icon
• Pixel-Level Coordinate Calculation: The model can output precise (x, y) coordinates to guide mouse movement and clicks. This requires the model to have extremely strong spatial reasoning capabilities, positioning elements by calculating pixel distances
• Multimodal Fusion: It can combine OCR (Optical Character Recognition) results with visual layout information to understand complex UI structures like tables, cascading menus, and popups

4.2 Dynamic Planning and Error Recovery

In Cowork workflows, the Agent frequently encounters unexpected obstacles: slow webpage loading, popup ads, locked files, etc.

Claude model series (e.g., Sonnet) typically demonstrates stronger dynamic planning capabilities:

• Observe-Judge: When clicking a button produces no expected response, the model compares before and after screenshots to determine if the operation failed
• Strategy Adjustment: If CSS Selector fails at that moment, the model might automatically switch to visual coordinate-based clicking or attempt keyboard shortcuts (Tab to switch focus)
• Self-Correction: In coding tasks, if generated code throws errors, the model can read the error stack, locate specific line numbers, and propose fixes. This Evaluator-Optimizer loop is key to Agents independently completing long-horizon tasks

4.3 Strategic Significance of Long Context Capability

Claude Cowork leverages the Claude model series’ long context capability (e.g., 200k Token standard context; some models/plans can reach 1M Tokens under specific conditions, depending on the model and subscription tier). This has tremendous architectural value in Agentic Workflows:

• Full Context: The Agent can read entire project directory structures, core code files, even related API documentation into context at once. This avoids the common retrieval loss issues in RAG (Retrieval-Augmented Generation) systems
• Long-Term Memory: During hours-long collaboration sessions, the Agent can “remember” constraints set by the user at the start (like “don’t use jQuery”) and maintain them throughout. While ultra-long contexts exhibit “Lost in the Middle” phenomena, Anthropic has significantly mitigated this through optimized attention mechanisms

5. From Architecture to Implementation: Three Things You Need to Care About

This article focuses on “how it’s built underneath.” But if you’re actually going to integrate it into team/enterprise workflows, the following three things matter more than “smarter models” for determining success:

1. Keep Permission Boundaries Small: Use “authorized folders/projects” as the minimum context radius, default to read-only, and require explicit enablement for writes.
2. Make Critical Actions Blockable: Irreversible actions like delete/overwrite/send/pay must have clear confirmation points (Human-in-the-Loop).
3. Make Results Traceable and Rollbackable: Change summaries, source lists, execution logs, rollback strategies—all are essential.

For a more complete implementation checklist and governance framework, see this companion article (complementary, no overlap): /en/blog/claude-cowork-landing-guide/.

If you’re more focused on “how to productize security” (threat models, defense in depth, least privilege, human-in-the-loop), consider reading: /en/blog/claude-cowork-security-architecture/.

Conclusion

Claude Cowork isn’t just a new feature release—it represents a profound transformation in software architecture design.

By establishing security boundaries through AVF virtualization, standardizing “tools/data source” access via the MCP protocol, and making “plan-act-feedback-correct” into a runnable system through the Master Agent Loop, Anthropic has shown us an engineering blueprint toward the “digital coworker” era.

For technology leaders, the task now is not to wait and see, but to act. We need to start thinking:

• How can existing business systems be exposed to Agents through MCP?
• Are our data pipelines prepared for Agents?
• Does our team’s skill stack include Agent engineering?

In this new era, Code still matters, but Cowork is the core.

What we’re writing is no longer instructions for machines to execute, but scripts for digital coworkers to read.

References

• Claude Code overview (official)
• Claude Code: Best practices for agentic coding (official)
• Building Effective AI Agents (official)