Give the Agent a Computer: Cowork’s Path from Chat to Delegated Work

An animated emoji becomes a programming task

A designer needed an animated internal emoji. He drew an SVG, handed it to Claude Cowork, and asked for an animation. Felix Rieseberg, Cowork’s engineering lead, reports that it produced a looping result. The task looked like design work, but code supplied the means to finish it. Felix sees this pattern repeatedly: enthusiastic users discover applications the team did not anticipate.

In the Latent Space conversation with Felix, a host describes using Cowork to upload videos, generate titles, and help with editing. Felix explains Cowork as a user-friendly version of Claude Code: its agent harness—the software around the model that enables it to act—runs inside a virtual machine with additional guardrails and conveniences. During December, the team had observed people using Claude Code for expenses, receipts, and knowledge-base organization, including Obsidian workflows. Cowork brings that capability to people who do not want to work in a terminal.

Convenience can also attract experienced developers. A host finds Cowork’s browser integration particularly useful; Felix agrees and draws an analogy to Visual Studio Code. In his view, hackability and extensibility helped that editor overcome early skepticism. Cowork might benefit similarly: users can adapt a general tool to the work they actually have.

Ten days of assembly, much longer in preparation

The ten-day development story has a crucial qualification: Cowork assembled existing prototypes. Felix says Anthropic had explored moving users from question answering into task execution for roughly a year and a half. Its internal demo culture supplied pieces that could be combined quickly.

For Felix, cheaper implementation changes product discovery: teams can build several candidates and test them with users before committing. Alessio raises a complementary argument that reusable platforms could become more valuable as software becomes easier to produce. The response favors building on the existing coding agent. Cheaper execution makes useful combinations easier to try; shared foundations still save effort, and shared applications preserve interoperability.

One participant describes recreating an Electron application in Swift after development and build problems involving SQLite. His contribution was specifying behavior; he says he was not reviewing the generated code. The responding engineer still considers an architectural view necessary for complex or high-performance software, even if expressed in Markdown. The exchange shifts attention toward behavior and architecture while leaving implementation quality as a separate question.

A computer gives Claude room to act

A developer limited to exchanging code by email would lack the environment needed to work effectively. Giving Claude a computer addresses a similar constraint. Cowork’s lightweight Linux virtual machine (VM) provides a separate computer environment on the host. Inside it, the coding agent can install tools such as Python and Node.js, while the surrounding system controls incoming and outgoing network traffic.

Environment management becomes a product responsibility. A lawyer should not have to evaluate the implications of installing Homebrew before getting useful work done. Around the VM, system prompting supplies work context and steers behavior. A tightly integrated Chrome sub-agent offers another route to action when service connectors require numerous authorization flows or cannot perform the needed operation.

A crash-triage workflow shows how delegation can move beyond individual coding requests. Instead of manually choosing reports for Claude to fix, a Cowork developer describes this sequence: 1. Read the bug dashboard and inspect the latest reports. 2. Identify likely fixable application bugs, excluding issues such as operating-system crashes. 3. Write a Markdown prompt for each candidate, then start a separate Claude session for each prompt. The handoff uses Claude Code Remote, a workaround rather than native sub-agent functionality. Those remote tasks can continue while the developer goes to another meeting.

That handoff invites a cloud-first challenge. The case for local execution, however, concerns access to the user’s working environment as much as compute. Moving tools into the cloud means granting and maintaining permissions across services. Copying an entire computer also raises the separate question of whether users want their work transferred that way. The builder offers moving browser authentication as a hypothetical shortcut, then warns that websites, including banks, may lock accounts when the same authentication appears from different locations. Putting Claude where users already work avoids some of those integration problems.

Longer tasks make clarification essential

Cowork and Claude Code share substantial machinery but target different work. Claude Code is optimized and evaluated primarily for coding; Cowork emphasizes knowledge work such as finance and legal-office tasks. System prompts and tool selection steer those differences. The builder leaves open whether these optimizations will remain consequential across future model generations.

A participant finds Cowork better suited to long tasks because it exposes an editable plan and progress against it. Claude Code also has planning capabilities, the response explains, but users tend to give Cowork larger assignments. Longer tasks amplify ambiguity, so Cowork is instructed to use planning and clarification questions heavily. These let the user check the intended direction before the agent spends hours executing the wrong interpretation.

Evaluations cover both generated files and chat output. The team takes a conversation and available tools, varies the setup, and assesses the results. Cowork sits mainly in the scaffolding around the model, though it also receives some training attention. The discussion supplies no scoring rubric or measured comparison.

The builder’s broader hypothesis is a capability overhang: models can accomplish more than users currently get from them, partly because applications have not supplied the necessary tools. That creates two investment choices: - Correct current weaknesses: add specialized guidance to help the model produce the desired result. - Expand what the model can do: provide broad capabilities with safeguards that reduce worst-case consequences, then benefit from future improvements. He currently favors the second approach and predicts that better generalization may erode some specialized applications’ advantages.

Skills turn a successful session into reusable work

Skills are reusable task instructions, often written in plain text or Markdown. They grew out of a desktop data-analysis prototype: to connect it to a data warehouse, the team supplied a Markdown file describing the endpoint and API instead of building a custom integration tool. The model worked out how to use them. The team generalized that pattern into a way to describe work while letting the agent assemble its execution.

The recording workflow develops incrementally. A participant first delegates YouTube uploads, then adds downloading from Zoom. Cowork examines video frames to help name recordings. Once the guided process works, he asks it to package the process into a skill, then splits it into three reusable skills with a parent orchestrator. Failed steps can be handled separately, and individual capabilities reused. Later, Cowork consults upload documentation, handles Google Cloud setup, and incorporates a programmatic upload script into the skill.

These tasks recur weekly, but the participant has not yet tried scheduled Cowork tasks. The experience illustrates expanding a guided workflow as trust grows. Another participant compares it to playing Factorio with one’s own life: begin with a small automation, then add adjacent work.

Personal instructions can be as useful as API knowledge. One daily calendar check prioritizes particular people’s meetings, avoids rescheduling Dario, and respects preferred working hours. Its author clarifies that it remains a custom prompt, not a packaged skill. Desktop cleanup supplies another modest entry point—and an immediate boundary: during a live demonstration, Cowork offers to delete obvious junk. One participant advises against selecting it; the other would accept only if deletion were reversible. Reversibility is not established.

Browser feedback helps; portable files still need coordination

A participant reports generating a conference website from a Figma design in one pass, choosing Cowork for its perceived browser advantage. He then learns that Claude Code in the desktop app also has a built-in browser. The useful mechanism is feedback from the thing being built: Claude can inspect the rendered page and debug its structure, reducing the manual checking handed back to the user. The website result is a personal report without explicit acceptance criteria.

The builder favors integrating with existing browsers and applications; requiring a browser switch would unnecessarily narrow the audience. Working across environments introduces a different problem, however. A participant has an office visitor-registration skill in another agent and wants to use it from Cowork too. Maintaining two copies means synchronizing every change.

The portability problem has three parts: - Reusable instructions: skills are files and folders packaged in plugins. Claude Code and Cowork share the plugin format, and Cowork can use a GitHub repository as a marketplace. - Personal context: a participant wants skills shared across agents without necessarily sharing memories. Work and personal versions of a task may also require different preferences. - Discovery and synchronization: portable files do not automatically make skills easy to find, install, share, or update, especially for people unfamiliar with GitHub.

Flight booking illustrates the unresolved split between reusable procedure and personal preference: lower prices may appeal broadly, but preferred times, seats, and airports differ. This is a format example, not an endorsement of flight booking as an AI showcase; the participants are skeptical of that demo. Substituting personal values into instructions is floated as a solution, but the builder considers it clunky and says it has not been built.

Current workarounds are simple: one participant built a terminal interface that copies instruction files into agent folders; another uses symlinks to share instructions. A proposed independent service could synchronize skills across products, though its business viability is uncertain. The underlying motivation is clear: one participant expects a personal collection of skills to become a source of productivity advantage, even when everyone can access the same agent products.

Automating entry-level work changes the learning path

If general agents absorb specialized planning and tools, where does durable product value remain? One participant argues that enterprise search could become a small component of a completed task, reducing willingness to pay for it separately. Customer trust in a provider’s ability to deliver a particular result could remain valuable. This is a conditional argument about differentiation, not a reported market outcome.

The employment concern follows directly: an experienced employee’s tedious task can be someone else’s entry-level assignment. A speaker describes concern within Anthropic about automating that work while declining to predict which industry will be hardest hit. Another proposes simulated early-career projects that concentrate valuable learning moments. Rehearsing a distributed-systems problem in a week rather than encountering it over months is an aspiration, not an evaluated training method. Realistic feedback would be harder to reproduce in sales or marketing.

Workplace experience offers another model. An engineer recalls Waterloo graduates who seemed better prepared to ship products, collaborate, and handle disagreement. Participants also report that younger engineers can approach AI tools more inventively because they have fewer established workflow habits. But adaptability does not guarantee hiring demand: employers might still need fewer engineers. The discussion calls for deeper engagement from economists and governments. Frequent releases may help people adjust gradually, while a possible self-reinforcing acceleration raises doubts about how long that adjustment window will last.

The desktop-cleanup task then returns with a concrete mismatch. It has organized files by type, while the user wanted their contents read and grouped by topic; he subsequently notices some topical organization too. For the demonstrated Opus 4.6 session, the recommendation is to state the desired outcome before assuming a custom skill is necessary. The model may find an approach, though it may differ from the user’s preferred method. The revised result is not shown.

Industry adoption still requires engineering. Dedicated verticals and enterprise teams work on making Cowork effective, understandable, and easier to integrate into particular industries. Software engineers have an early advantage because they already assemble automation chains. Some useful applications are difficult to demonstrate publicly: participants cite business analysis and taxes they do not want to disclose. In the more shareable recording workflow, one participant considers screenshot interpretation sufficient for titles and show notes, using NanoBanana separately for image generation.

A second cursor does not create a second user

Participants describe computer use as substantially improved over roughly a year, based on their experience rather than benchmarks. One has stopped relying on installed macOS automation tools and prefers having Claude write and execute task-specific AppleScript. Greater capability raises a practical question: can the agent operate the computer without preventing its owner from working?

A Cowork developer considered giving Claude its own cursor, then found that the problem runs deeper than another pointer. Desktop interaction assumes a single active operator. Foreground applications, background applications, and focus complicate concurrent control. Making Claude work in the background within Chrome is a narrower problem than supporting independent control across the operating system.

Several arrangements remain open: - A dedicated agent computer: the person enters it when needed while continuing work elsewhere. - Time-sharing the user’s computer: the agent takes over when the person steps away. - A separate cloud computer: the user sets up the environment the agent needs. The choice also depends on comfort with sharing particular data. The builder questions whether users would want Claude to decide what is appropriate to share, even if it could make that judgment.

A machine-within-a-machine tangent recalls a Windows 95 project built in one night as a joke for Slack colleagues during arguments about JavaScript performance. Its builder credits V86, the underlying processor simulator, and its developer Fabian, known as Copy, for nearly all the underlying work. Booting Windows 95 and opening Excel felt faster to him than some tasks in online business applications—an anecdotal provocation about software overhead.

The sandbox makes delegation practical

Cowork’s VM has real costs. Its builder says an image displayed as 10 GB on macOS consumes less actual disk space because empty regions are collapsed when written. Startup still adds latency compared with running Claude Code directly on the host. A participant revises his estimate from thirty seconds to perhaps ten, while saying it feels like thirty: a useful report of perceived delay, not a timing measurement.

The Windows implementation uses Windows Host Compute System, the foundation also used by Windows Subsystem for Linux 2. On macOS, it uses Apple’s Virtualization framework. Starting a VM is only the beginning. Production work includes choosing its execution context, restricting which host applications can communicate with Claude inside it, and handling network edge cases. The builder reports that the team began a networking service or driver the previous week, including work for corporate networks that inspect packets.

The payoff is a useful execution environment on an ordinary, potentially locked-down computer. The builder argues that lacking Python and Node.js sharply limits Claude’s effectiveness. Separating Claude’s computer from the employee’s host lets corporate administrators focus controls on the VM’s network and filesystem while allowing useful scripts inside it. Those boundaries address concerns including data loss, hostile actors, and exfiltration.

The safety discussion distinguishes three approaches: - Approve every step: repeated prompts create approval fatigue and prevent the user from walking away. - State approval preferences: one participant asks Claude to check before irreversible actions, such as sending or permanently deleting email. This is a personal practice, without demonstrated enforcement. - Constrain execution with layered defenses: the builder advocates the Swiss cheese model—multiple safeguards that reduce consequences without assuming a perfect model.

Script approval cannot carry the whole safety burden. Users may lack the expertise to assess a Python script, or stop reading once approvals become routine. The intended direction is to let Claude do more on the computer, independently, for longer. Even impressive workflows still require users to request scripts and coordinate intermediate steps; removing that orchestration remains a product goal.

The builder expects rapid iteration, with small or large features arriving weekly, but prefers releasing work before discussing it publicly. An interviewer suggests an assistant that watches a working day and identifies tasks suitable for delegation; that is a proposed use case. The remote-control exchange likewise establishes no release commitment. The emphasis is on features whose value users can readily understand.

Electron buys control over the rendering stack

The closing technical discussion returns to reusable foundations through Electron, which makes Chromium easy to ship inside an application. Its breadth of uses reinforces the speaker’s preference for general-purpose building blocks: both adoption and the applications people built were difficult to predict. A participant favors Tauri unless an application needs Electron’s full capabilities, prompting a discussion of when bundling a rendering engine is worthwhile.

The response draws on Slack’s earlier use of operating-system webviews, which render web content within an application. The speaker considers those adequate for smaller apps, but argues that critical rendering bugs demand control over fixes and updates. For a product such as Slack, leaving customers dependent on operating-system upgrades is unacceptable—a concern he says remains relevant in 2026.

Bundling Chromium also buys accumulated compatibility work. Its GPU diagnostics list workarounds for hardware and driver problems so requested pixels render correctly. A remembered Slack bug involving an embedded YouTube video led into lower-level code containing poorly understood bit-flipping workarounds. The supposedly stable layer beneath an application contains its own hard-won exceptions, which help explain why the speaker considers Chromium’s size a worthwhile tradeoff.

That history sharpens the earlier Swift-rewrite anecdote. The speaker reports improving AI assistance inside Chromium’s unusually specialized repository, but proposes a harder milestone: replicating behavior in native code differs from producing a better native application. Better performance, lower memory use, and reliable optimization require more than translation. He says even the best models available to him cannot yet reliably complete that whole conversion without mistakes.

From one person’s agents to work between people

Multiple agents inside one person’s workflow still leave handoffs between people with different context unresolved. A builder weighs custom communication infrastructure against giving agents Gmail accounts or Slack handles so they can use familiar coordination tools. Google Docs comments offer a nearer example: Claude is described as participating directly through comments after earlier integration work.

Another participant describes a personal project that places a repository and coding agent on a rented server, accepts tasks through a public webhook, and provides a review dashboard. It prompts a picture of agents queuing decisions across sales, engineering, marketing, and product. The unresolved issue is delegated authority: which requests can an agent approve autonomously, and which should it bring to a person?

Skill sharing might become conversational: one Cowork instance could ask another whether it has instructions for the current task. That remains a possibility. A more speculative idea would use Bluetooth proximity to infer that nearby people are collaborating. Its proposer says colleagues’ reactions suggest it probably will not appear in Cowork. Available context is not necessarily welcome context.

The conversation closes by distinguishing the growing Claude Code group from Anthropic’s Labs team. Labs is described as pursuing unpublished, improbable experiments that may only partly work—the kind of ideas few other teams would have reason to attempt. A participant ends with a personal endorsement: Cowork is the closest he has felt to artificial general intelligence that year. It is an expression of the experience of delegation, rather than a measured capability threshold.