Synthetic Computers at Scale for Long-Horizon Productivity Simulation

🎯 Pitch

Training agents to handle a month of real productivity work has been impossible because no one has realistic digital environments at scale—this paper invents synthetic computers with full filesystems and professional artifacts, runs 8-hour, 2,000-turn simulations that act as the user, and shows a +7 percentage point gain that only materializes when diverse professions are covered, completely rewriting what experiential learning data can be synthesized.

1. Executive Summary

This paper introduces Synthetic Computers at Scale, a methodology for creating diverse, artifact-rich, user-specific synthetic computer environments—complete with realistic directory hierarchies, content-heavy professional files (documents, spreadsheets, presentations), and cross-file dependency graphs—that serve as grounding environments for long-horizon productivity simulations spanning roughly a month of human work and over 2,000 agent turns on average. Using 1,000 such synthetic computers built from sampled personas, the authors run simulations in which one agent creates multi-deliverable productivity objectives (e.g., a financial advisor producing investment committee presentations, client onboarding packages, and rebalancing frameworks) while a second agent acts as the computer's user—navigating the filesystem, coordinating with simulated collaborators, and iteratively producing professional artifacts—to generate rich experiential learning signals from both process trajectories and final deliverables. These signals, when extracted as occupation-specific skills and applied to a new work agent, yield a +7.0 percentage point improvement in rubric-based deliverable scores on held-out synthetic computers (winning on 83 of 100 test computers), with the win rate scaling from 50% to 83% as training computers grow from 10 to 900, and also transfer to the out-of-domain GDPVal benchmark, establishing that simulation-derived experience improves agent performance on realistic long-horizon productivity work only when the training coverage is sufficiently broad to capture diverse professions and failure modes.

2. Context and Motivation

The Core Problem: We Can't Train Productivity Agents Without Realistic Digital Environments

The fundamental problem this paper tackles is a deceptively simple bottleneck: to train AI agents that can handle realistic, long-horizon productivity work, you need realistic, long-horizon productivity environments to train them in—and those environments don't exist at scale. This is not a model architecture problem or an algorithm design problem. It is a data infrastructure problem, and it sits at the intersection of three converging trends in AI agent development.

First, AI agents are rapidly expanding beyond bounded, single-task interactions. The paper traces a clear evolution (Section 1): from conversation-bounded assistants like ChatGPT, to repository-grounded coding agents like Cursor, and now toward agents grounded in entire user computers—exemplified by systems like Claude Cowork. At each step, the scope of context the agent must understand grows: a chatbot needs only the conversation history; a coding agent needs the codebase; a productivity agent needs the user's files, project history, prior decisions, collaborator relationships, and evolving work state. The paper argues this trajectory is not incidental but fundamental: "realistic long-horizon productivity work is strongly conditioned on user-specific computer environments, where much of the work context is stored and organized through directory structures and content-rich artifacts."

Second, there is growing recognition that long-horizon agent trajectories—the sequence of actions an agent takes over extended periods while operating in rich contexts—produce valuable experiential learning signals. When an agent navigates a filesystem, reads existing documents, creates new ones, coordinates with collaborators, incorporates feedback, and revises its work over weeks of simulated time, the resulting trajectory captures how the agent plans, searches, recovers from errors, and manages competing priorities. These process-level signals are complementary to outcome-level signals (did the final deliverable meet the requirements?), and together they provide the kind of rich feedback that could drive agent self-improvement and agentic reinforcement learning. The paper cites emerging work in this direction: Cheng et al. (2026) on long-horizon multi-source memory benchmarks, Li et al. (2026) on long-horizon personalization with evolving preferences, and Laban et al. (2026) on LLMs corrupting documents during delegation—all evidence that the field is actively grappling with how to evaluate and improve agents over extended, context-rich interactions.

Third, and critically, real trajectories are nearly impossible to collect at scale because they are grounded in private computer environments. Real users' computers contain personal artifacts, enterprise documents, project state, interaction histories, and sensitive information that cannot be freely shared for training data (Ozaki et al., 2025; Jian et al., 2026). This means the very data that would be most valuable for training productivity agents—authentic, messy, context-heavy trajectories through real work—is the data that is least available. The paper frames this starkly: "This makes synthetic data necessary, but difficult to create well."

And "difficult to create well" is the crux. The paper identifies three specific challenges that prior synthetic data approaches fail to address for productivity scenarios:

Realistic user environments are complex, heterogeneous, and artifact-rich. A real professional's computer is not a clean set of labeled files. It contains diverse directory structures shaped by personal organization habits, professional artifacts in multiple formats (documents, spreadsheets, presentations, PDFs, data exports, code), naming conventions that reflect individual preferences, version histories with inconsistent archiving, and accumulated work products that reference and build on each other across months or years. Synthetic environments that lack this complexity produce training signals that don't transfer to real-world deployment.
Productivity work is context-heavy by nature. The paper's first guiding principle is that realistic productivity work is "grounded in existing files, project history, prior decisions, collaborator feedback, and evolving work state." A task like "write an investment policy statement for a new client" is not a standalone prompt. It depends on the client's specific account structure, risk tolerance questionnaire, discovery call notes, the firm's template documents, the advisor's recent capital markets outlook, compliance requirements, and feedback from managers and compliance officers. Without this context, the task becomes a generic writing exercise that teaches agents nothing about how real productivity work unfolds.
The key challenge is using rich user context over long horizons, not solving isolated tasks. Success for a productivity agent depends on "using the user's files, history, and evolving work context effectively over long horizons." This requires capabilities that single-turn benchmarks don't test: knowing when to consult existing files versus create new ones, maintaining consistency across multiple related deliverables, tracking commitments made to collaborators, incorporating feedback that arrives days or weeks later, and recovering from failures discovered late in a project timeline.

The paper's third guiding principle crystallizes the gap: "Synthetic data must synthesize the context, not only the task." Without realistic user environments to condition on, synthetic data "degenerates into generic, toy workflows that remain far from real work scenarios." This is the core insight that motivates the entire methodology.

Why This Problem Matters: The Infrastructure Gap in Agent Training

The practical importance of this problem becomes clear when you consider the economics of agent development. Training a capable productivity agent currently faces a chicken-and-egg problem: you need diverse, realistic environments to train the agent, but you can't get those environments without either (a) access to thousands of real users' private computers, which is practically and legally infeasible, or (b) a method for creating them synthetically, which prior work has not solved.

This infrastructure gap matters for several reasons articulated or implied by the paper:

Productivity work has enormous economic value. The personas sampled in the paper's experiments (Figure 4) span management, engineering, finance, healthcare, legal, education, and creative professions—precisely the kinds of knowledge work where AI assistance could have the largest economic impact. The GDPVal benchmark (Patwardhan et al., 2025), which the paper uses for out-of-domain evaluation, is explicitly designed to measure "real-world economically valuable tasks." If AI agents can be trained to handle such work effectively—not just answer questions or generate text, but actually operate over files, coordinate with stakeholders, and produce professional deliverables over extended periods—the productivity implications are substantial.

The gap between current agent capabilities and realistic needs is large and qualitative, not just quantitative. Current agent benchmarks primarily evaluate single-turn or short-horizon tasks: answer this question, write this function, summarize this document. But as the paper emphasizes through its simulation design, real productivity work involves planning across weeks, maintaining coherence across multiple interrelated deliverables, tracking commitments made days earlier, and incorporating feedback that arrives asynchronously. These are not simply "harder versions" of single-turn tasks—they require different capabilities entirely. The paper's retrospective analysis (Appendix A) reveals failure modes like cross-document inconsistency (the same portfolio weight appearing as 14%, 20%, 27.4%, and 19% across four documents), failure to correct errors flagged by simulated collaborators days earlier, and sending blank messages when the agent's context window or planning capacity is exceeded. These are failures of state management over time, not failures of reasoning or knowledge, and they can only be surfaced and trained against in environments that simulate extended work horizons.

The methodology is designed to scale. The paper explicitly frames this in terms of a scaling argument: "Given that personas are abundant at billion scale, this methodology can in principle scale to millions or even billions of synthetic computers with sufficient compute, enabling broader coverage of diverse professions, roles, contexts, environments, and productivity needs." This is not just aspirational. It connects to the authors' prior work (Ge et al., 2024) which released 370 million elite personas, providing a concrete starting point for population-scale synthetic computer generation. The implication is that the infrastructure problem, once solved at the methodological level, can be scaled to cover essentially arbitrary professional diversity.

Where Prior Approaches Fall Short

The paper positions itself against several categories of prior work, each of which addresses part of the problem but leaves the core infrastructure gap unresolved.

Persona-driven synthetic data creation. The authors' own prior work (Ge et al., 2024) demonstrated that personas—structured descriptions of potential users with occupations, backgrounds, and preferences—could be used to drive diverse synthetic data generation at scale, with up to 1 billion personas generated. That work focused on generating conversation data, task prompts, and other text-based artifacts conditioned on personas. However, personas alone are "too underspecified to determine what should exist on that user's computer" (Section 2.1). A persona might tell you that a user is a senior financial advisor, but it doesn't tell you what files are on their computer, how those files are organized, what naming conventions they use, or how different artifacts depend on each other. This paper extends the persona-driven paradigm by showing how to elaborate personas into fully populated computer environments—a necessary step for productivity simulation that prior persona-based work did not address.

Existing benchmarks for productivity and computer-use agents. Several benchmarks evaluate agents on realistic tasks, but they operate at much shorter time horizons and with far less context than the paper's simulations. GDPVal (Patwardhan et al., 2025), which the paper uses for out-of-domain evaluation, contains 220 productivity tasks—but as Table 5 shows, these tasks average only 1.18 explicit reference files, 1.63 deliverables, 31 turns, and 17 minutes of wall-clock time. In contrast, the paper's simulations involve an average of 13.8 explicit reference files embedded within approximately 112 computer files, 4.09 deliverables, 2,272 turns, and 8.59 hours of wall-clock time. The difference is not just in scale but in kind: GDPVal tasks are essentially extended single-turn problems with a few provided reference documents, while the paper's simulations require agents to discover relevant context by navigating a filesystem, manage state across weeks of work, and coordinate with multiple simulated collaborators.

OSWorld (Xie et al., 2024) and similar benchmarks (Kim et al., 2023; Wang et al., 2025; Awadallah et al., 2025) evaluate computer-use agents on tasks like navigating GUIs, manipulating files, and using applications. These environments provide realistic computer states but are designed for evaluating short-horizon task execution (can the agent open the right application, find the right file, perform the right operation?), not for long-horizon productivity work where the agent must plan across weeks and maintain coherence across multiple deliverables.

Synthetic environment generation. Recent work has explored synthetic environment creation for agent training. Cai et al. (2025) introduced AutoForge for automated environment synthesis for agentic reinforcement learning, but focused on structured task environments rather than realistic user computer states with professional artifacts and work history. Copet et al. (2025) developed world models for code generation, but did not address the broader productivity scenario with diverse artifact types, collaborator interactions, and cross-file dependencies. Feng et al. (2025) explored web world models, addressing a different grounding domain. None of these approaches tackled the specific challenge the paper identifies: creating realistic, user-specific computer environments with the directory structures, artifact types, naming conventions, and cross-file relationships that characterize real professional work.

Long-horizon agent evaluation. Benchmarks like LifeBench (Cheng et al., 2026) and HorizonBench (Li et al., 2026) evaluate agents on long-horizon tasks involving memory and evolving preferences, respectively. These benchmarks recognize the importance of extended interactions but focus on evaluating agent capabilities rather than generating the rich training environments and experiential signals that could improve agents. The paper's contribution is complementary: it provides a methodology for generating the training data that could help agents perform better on such benchmarks.

Agent self-improvement and experiential learning. Work on self-evolving agents (Cai et al., 2026; Lu et al., 2026; Xia et al., 2026a;b) has explored how agents can learn from their own experience through in-context skill acquisition and reinforcement learning. These approaches assume the existence of environments in which agents can accumulate experience. The paper's synthetic computers provide a scalable substrate for generating such experience specifically for productivity scenarios, addressing the environment-availability bottleneck that limits these self-improvement approaches.

Long-horizon simulation. The paper's simulation methodology—weekly planning followed by daily execution, with simulated collaborators providing asynchronous feedback—draws on principles from multi-agent simulation and organizational modeling, but applies them specifically to the problem of generating agent training data. The key difference from general multi-agent simulation is the tight coupling with the synthetic computer environment: the simulation is not just about agent-agent interaction but about agent-environment interaction, where the environment (the synthetic computer) is itself procedurally generated from a persona and accumulates state as the simulation progresses.

How This Paper Positions Itself

The paper positions its contribution as a methodology and infrastructure contribution rather than a model or algorithm contribution. The abstract explicitly frames the work as "a scalable methodology for creating such environments" and argues that "scalable synthetic computer creation, together with at-scale simulations, is highly promising as a foundational substrate for agent self-improvement and agentic reinforcement learning in long-horizon productivity scenarios."

This substrate framing is important. The paper is not claiming to have solved the problem of building better productivity agents. It is claiming to have solved the problem of building the environments in which better productivity agents can be trained. The experiments validate that claim by showing that experience extracted from simulations on these synthetic computers does improve agent performance—both in-domain (on new synthetic computers from the same distribution) and out-of-domain (on GDPVal). But the improvement method (extracting occupation-specific skills from retrospective reports) is presented as a demonstration of the methodology's value, not as the primary contribution itself.

Several design choices in the paper reflect this positioning:

Persona-driven but computer-grounded. The methodology builds on persona-driven synthetic data (Ge et al., 2024) but goes substantially beyond it by elaborating personas into entire computer environments. This bridges the gap between "who the user is" (persona) and "what context the user works in" (computer), which the paper argues is essential for realistic productivity simulation.

Realistic collaboration, not just task execution. The collaboration setup (Section 3.1.2) is a deliberate departure from standalone task execution. Simulated collaborators have private reference materials that the work agent must discover through interaction, communication styles that affect how feedback is delivered, and specific expectations that the agent must satisfy. This models productivity work as a social and organizational process, not just an individual cognitive task—a distinction the paper argues is central to realism but absent from most prior synthetic data approaches.

Process signals, not just outcome signals. The retrospective analysis (Section 4.2.2 and Appendix A) evaluates not just whether final deliverables meet specifications, but how the agent worked: its planning quality, its communication patterns, its error recovery behavior, its cross-document consistency. The paper argues that these process-level signals are where the richest learning opportunities lie, because "many failures in long-horizon productivity work are not visible from the final files alone."

Scaling as a first-class design goal. The paper repeatedly emphasizes scaling possibilities: from 1,000 computers in the preliminary experiments to potentially "millions or even billions" with sufficient compute, enabled by the abundance of personas and the automated nature of the creation and simulation pipelines. This is not merely aspirational—it reflects a methodological bet that the key barrier to improving productivity agents is environment coverage and diversity, and that the paper's approach can achieve coverage and diversity at scales that would be impossible with human-created or human-curated environments.

Open release to enable community development. The release of 100 synthetic computers and 500 retrospective reports positions the work as enabling infrastructure for the research community. This is consistent with the substrate framing: the paper provides the foundation on which other researchers can study synthetic computer creation, experiential learning from long-horizon trajectories, and scalable productivity simulation.

In summary, the paper addresses a specific, well-motivated gap: the absence of scalable, realistic environments for training and improving long-horizon productivity agents. It positions synthetic computer creation as the missing infrastructure layer, and demonstrates through both in-domain and out-of-domain experiments that simulation-derived experience from these environments produces measurable improvements in agent performance. The contribution is not a better agent, but a better way to train better agents—a substrate that can grow richer as simulation scale and model capability increase.

3. Technical Approach

This is primarily a systems and methodology paper whose core idea is that realistic, long-horizon productivity agent training data can be generated at scale by first procedurally creating user-specific synthetic computer environments from personas, then running extended multi-agent simulations on those environments that produce rich experiential learning signals from both process trajectories and final deliverables.

3.1 Reader Orientation

The system being built is a data generation pipeline that takes a persona (a high-level description of a potential user) as input, progressively elaborates it into a fully populated synthetic computer environment with realistic files, directory structures, and cross-file dependencies, then runs a month-long productivity simulation on that computer where AI agents plan weekly, execute daily, coordinate with simulated collaborators, and produce professional deliverables—generating long-horizon trajectories that can be analyzed to extract lessons, failure modes, and work patterns that improve future agent behavior.

The problem it solves is the environment-availability bottleneck: real productivity trajectories are grounded in private user computers and cannot be collected at scale, yet training agents for realistic productivity work requires rich, context-heavy environments that support extended planning, filesystem navigation, multi-deliverable coherence, and collaborator coordination. The solution "shape" is a three-stage pipeline—(1) environment creation from personas, (2) long-horizon simulation on those environments, (3) trajectory analysis and experience extraction—that is fully automated, requires no real user data, and can scale to millions of synthetic computers given sufficient compute.

3.2 Big-Picture Architecture (Diagram in Words)

The system has five major components arranged as a sequential pipeline with a feedback loop:

Persona-Driven User Profile Generator — takes a sampled persona (e.g., "a financial advisor focused on assessing how different asset classes are likely to perform over time") and expands it into a detailed user profile capturing occupation, organization, career stage, responsibilities, recent work history, current projects, collaborators, common work products, computer usage habits, document preferences, spreadsheet usage, naming conventions, and organization style. This provides the semantic foundation for everything that follows.
Computer Environment Planner — takes the user profile and produces a complete filesystem plan: a directory tree, a filesystem policy (drive layout, default paths, storage patterns, organization style), and an inventory of planned files with metadata (logical paths, artifact types, descriptions, timestamps, origins, content modes) plus a directed dependency graph capturing how files reference, derive from, or build on each other. No file contents are generated yet.
Artifact Creator — takes the filesystem plan and instantiates it into an actual on-disk synthetic computer. First materializes the directory structure, then populates files in dependency-aware order (using Kahn's topological sort so that predecessor files are created before downstream dependents). Public web-downloadable files are retrieved from the internet; other user-specific artifacts are created by an LLM agent equipped with document-creation tools (for Office formats) and other skills. The output is a populated synthetic computer with content-rich professional files.
Long-Horizon Simulation Engine — takes the synthetic computer and runs a multi-agent simulation spanning roughly one month of work. A setup agent creates productivity objectives and collaborator profiles conditioned on the computer's user and contents. A work agent then acts as the user, operating over the computer in weekly planning and daily execution cycles: creating weekly plans that break objectives into daily activities, then executing each day by navigating the filesystem, reading existing artifacts, creating or revising files, and communicating with simulated collaborators. The simulation produces both a trajectory (process signals) and final deliverables (outcome signals).
Experience Extraction and Skill Creation Pipeline — takes simulation trajectories and their retrospective analysis reports, extracts experience items (useful patterns, lessons, warnings, failure modes), groups them by occupation, merges similar items with frequency counts, and uses a skill creator to write occupation-specific skills that encode the most common and important lessons. These skills are the consumable output: they can be given to future work agents to improve performance on new simulations.

Information flows as follows: a persona enters the pipeline → the user profile generator elaborates it → the environment planner creates a filesystem plan with dependency graph → the artifact creator instantiates the plan as a populated computer → the setup agent creates objectives and collaborators → the work agent executes the simulation over daily cycles, modifying the computer as it works → the trajectory is analyzed to produce a retrospective report → the experience extractor identifies reusable lessons → the skill creator writes occupation-specific skills → skills are fed back to future work agents, closing the loop.

3.3 Roadmap for the Deep Dive

First, the user profile generation step (Section 2.1), because it is the semantic seed from which the entire synthetic computer grows. Understanding what information a user profile contains and why that information matters is essential for understanding downstream design choices in filesystem planning and simulation setup.
Second, the computer environment planning process (Section 2.2), covering filesystem policy generation, directory tree construction, file inventory creation, and dependency graph construction. This is the blueprint that determines what the synthetic computer will contain and how its contents relate to each other.
Third, the artifact creation pipeline (Section 2.3), which materializes the planned computer environment on disk. This covers directory materialization, dependency-aware file instantiation order (topological sort), the distinction between web-downloadable and synthesized files, and the tools used to create content-rich professional artifacts.
Fourth, the simulation setup process (Section 3.1), which creates the scenario that the work agent will execute. This covers productivity objective generation (how the setup agent infers realistic multi-deliverable work packages from the user profile and computer contents) and collaboration setup (how simulated collaborators with roles, backgrounds, communication styles, and private reference materials are created to model the social and organizational dimensions of productivity work).
Fifth, the planning and daily work simulation loop (Section 3.2), which is where the actual agent trajectory is generated. This covers the weekly planning process, the daily execution cycle, state management across sessions, collaborator interaction mechanics, and how the synthetic computer evolves as the agent works.

3.4 Detailed, Sentence-Based Technical Breakdown

Persona-Driven User Profiles

The synthetic computer creation pipeline begins with a persona—a high-level textual description of a potential user. The paper's example persona reads: "A financial advisor focused on assessing how different asset classes are likely to perform over time, and on applying that insight to make well-informed investment choices. They are probably acquainted with the Vanguard Capital Markets Model® (VCMM) and its forecasting capabilities, and want to use those projections to guide how they balance their portfolio between shares and bonds. They are also interested in Vanguard's recommended asset allocations and in evaluating how those allocations fit their particular investment goals and risk tolerance."

This persona is drawn from a curated pool of personas following the methodology of Ge et al. (2024), which demonstrated that personas can be generated and sampled at billion scale. The 1,000 personas used in the paper's experiments span a diverse occupation distribution (Figure 4): Management & Executive (17.7%), Tech & Computing (13.7%), Engineering (13.4%), Business & Finance (10.9%), Arts & Media (10.0%), Healthcare (6.6%), Education (6.1%), Legal (4.5%), Social Science & Policy (4.1%), Sales & Marketing (2.7%), Sciences (2.7%), Protective Services (2.5%), Healthcare Support (2.2%), Production & Trades (2.0%), Office & Admin (0.9%), and Other (0.1%).

A persona by itself is too underspecified to determine what should exist on a user's computer. It provides high-level professional orientation but lacks the concrete details needed to construct a realistic filesystem: what projects is this person working on right now? What files do those projects generate? How does this person organize their work? What naming conventions do they use? What tools and formats do they prefer? Without answers to these questions, any filesystem constructed from the persona alone would be generic and unrealistic.

The first stage of the pipeline therefore expands the persona into a detailed user profile using a large language model (the paper does not specify which model is used for this stage, but notes that Claude Opus 4.6 is used for simulation setup, while Claude Sonnet 4.6 powers the work agent). The user profile serves as the semantic foundation for everything that follows—it determines not only what files will appear on the computer, but also where they will be stored, how they will be named, and how they will relate to the user's ongoing work.

The user profile captures two categories of information, both of which the paper argues are necessary for realistic computer construction:

Professional context information includes:

Identity: name, username, location (e.g., "Margaret Elaine Forsythe (mforsythe), based in Denver, Colorado")
Occupation: job title and specialization (e.g., "Senior Financial Advisor")
Organization: employer name and type (e.g., "Meridian Wealth Partners")
Career stage: seniority level, years of experience, certifications (e.g., "Senior; 16+ years in portfolio management... CFA charterholder (2013); CFP certified (2010)")
Responsibilities: the specific work activities the person performs (e.g., "Constructing and monitoring client portfolios across equity and fixed income; interpreting VCMM 10-year return projections into allocation recommendations; conducting Investment Policy Statement reviews...")
Recent work history: a timeline of major projects and accomplishments over the past several years, providing temporal context for what artifacts are likely to exist on the computer and when they were created
Current projects: the active work that the user is engaged in at the time the synthetic computer is sampled (e.g., five concurrent projects in the example: a VCMM-driven model portfolio refresh, onboarding three new HNW clients, a systematic rebalancing trigger framework, alternatives integration research, and an ESG equity overlay evaluation)
Collaborators: named individuals with roles and relationships to the user (manager, direct reports, peers, compliance officers, external partners), which later enables the collaboration setup
Common work products: the types of professional deliverables the user routinely produces (e.g., "Investment Policy Statements; capital markets outlook memos; client portfolio review decks (PowerPoint); asset allocation analysis spreadsheets (Excel); Monte Carlo simulation summaries; quarterly performance reports...")

Computer-use behavior information includes traits that are "directly relevant to filesystem construction" (Section 2.1):

Technical level: the user's technical sophistication (e.g., "Intermediate")
Computer usage level: how heavily the user relies on their computer (e.g., "High")
Preferred tools: which applications and formats the user gravitates toward (e.g., "Excel for analytical modeling; Word for IPS drafts and research memos; PowerPoint for client decks; PDF for client distribution")
Document habits: how the user creates, revises, and shares documents (e.g., "Drafts analysis in Excel before summarizing in Word or PowerPoint. Reviews own Word documents multiple times before sharing; uses Track Changes for collaborative edits. Prints final client-facing documents to PDF before distribution. Tends to over-document.")
Spreadsheet usage: specific practices around spreadsheet creation and management (e.g., "Heavy. Builds scenario-analysis tabs and data tables; adds cell comments to document assumptions and data sources; saves date-stamped intermediate versions before major structural changes.")
Attachment-saving behavior: what kinds of external files the user downloads and retains (e.g., "Retains source PDFs (VCMM reports, Vanguard white papers, client account statements) and vendor data exports (Bloomberg CSVs, Morningstar reports) as inputs to her Excel models.")
Naming preferences: how the user names files (e.g., "Descriptive filenames; uses explicit version suffixes; rarely keeps default names.")
Organization style: how tidy or messy the user's filesystem is (e.g., "Tidy and systematic, but occasionally accumulates multiple versions of the same spreadsheet without consistent archiving discipline.")

The inclusion of computer-use behavior traits is a critical design choice. A real user's filesystem is not just a function of their professional role—it is shaped by their personal habits, preferences, and idiosyncrasies. Two financial advisors with identical job descriptions might have very different computer environments: one might be meticulously organized with clear folder hierarchies and consistent naming, while another might have a cluttered desktop, inconsistent version management, and files scattered across default download directories. By encoding these behavioral traits in the user profile, the pipeline can produce synthetic computers that vary not just in what files exist, but in how those files are organized—a dimension of realism that task-only synthetic data approaches miss entirely.

Computer Environment Planning

Given a detailed user profile, the next stage plans the filesystem that will become the synthetic computer environment. This planning happens before any file contents are generated—it produces a complete specification of what files should exist, where they should be located, what types they should be, how they should relate to each other, and when they should appear to have been created, but does not yet create any actual file content. The paper breaks this planning into two sub-stages: filesystem policy generation and filesystem planning proper.

Filesystem Policy Generation

The first planning step generates a user-specific filesystem policy that specifies the basic conventions under which the synthetic computer is organized. This policy is generated from the user profile and encodes decisions that affect every subsequent planning choice:

System start time. The policy specifies when the computer was "set up," establishing the temporal origin for all file timestamps. In the example, this is 2022-11-05 17:41. This matters because later file creation dates must be consistent with the computer's virtual timeline—files cannot be created before the computer exists, and work history references must fall within the computer's lifetime.

Drive layout. The policy specifies the disk and partition structure. In the Windows-style example: C: (system); D: (data). This reflects a common pattern in professional environments where the system drive is separated from the data drive, and it determines where different categories of files will be placed.

Default user paths. The policy specifies the standard user directory locations. In the example: Desktop, Documents, Downloads, Pictures, and AppData under C:/Users/mforsythe/. These paths anchor the familiar user-facing directory structure and determine where certain types of files (temporary downloads, screenshots, personal documents) are likely to accumulate based on the user's behavior traits.

Storage patterns. The policy specifies where different categories of work are stored, informed by the user's occupation and organization habits. In the example: "Office files and project work go to D:/ClientWork, D:/Research, and D:/ModelPortfolios. Downloads land in C:/Users/mforsythe/Downloads or D:/Research/ExternalData. Screenshots go to C:/Users/mforsythe/Pictures/Screenshots. Temporary files often end up in Downloads or on the Desktop." These patterns encode the user's practices, not just their preferences—they describe where files actually end up, including places where they accumulate incidentally (temporary files on the Desktop) rather than by deliberate choice.

Organization style. The policy encodes the user's tidiness and organizational discipline. In the example: "High tidiness; uses project folders; low desktop and download clutter; does not pile files into default folders." This determines the cleanliness of the directory structure and affects where the environment planner places files—a high-tidiness user will have files predictably organized in project folders, while a low-tidiness user would have files scattered across default locations.

Naming style. The policy encodes the user's file-naming conventions with representative examples. In the example: "Consistent and descriptive; uses version suffixes; rarely keeps default filenames. Representative examples: IPS Draft v1.docx, AllocationModel v2.xlsx, ClientReview Q1 2025.pptx, CapMarketsOutlook 2026 FINAL.pdf." These examples serve as conditioning for the environment planner when it generates names for planned files—they establish the pattern that file names follow, making the synthetic computer's naming conventions internally consistent.

Usage patterns. The policy encodes the user's computer usage intensity and patterns. In the example: "High computer usage; frequently downloads files, creates new documents, edits existing files, and switches between projects; rarely takes screenshots." This affects the volume and diversity of files in the plan, as well as the frequency of certain artifact types (e.g., a user who rarely takes screenshots will have few image files, while a heavy downloader will have more external-source PDFs and data exports).

Filesystem Planning

Given the user profile and filesystem policy, the second planning step produces the complete filesystem plan, which has three components: a directory tree, a file inventory with metadata, and a directed dependency graph.

Directory tree construction. The environment planner constructs a hierarchical directory structure that reflects the user's professional activities, storage patterns, and organization style. The example directory tree (shown partially in Section 2.2.2) spans the system drive (C:) and data drive (D:) with distinct organizational principles for each.

On the system drive, the structure follows standard user-directory conventions: C:/Users/mforsythe/ contains AppData/ (with application-specific subdirectories like Roaming/Microsoft/Excel/XLSTART/ for Excel startup macros), Desktop/, Documents/ (with subdirectories like Admin/, FirmPolicies/, PersonalFinance/, Templates/, and WhitePaper/), and Downloads/. These locations reflect both standard operating-system conventions and the user's personal organization choices—for instance, the Documents/WhitePaper/ subdirectory reflects the user's work products, while Documents/PersonalFinance/ reflects personal content that a real computer would contain alongside professional files.

On the data drive (D:), the structure is organized around the user's professional domains: ClientWork/ (with subdirectories for individual clients like Castellano_Robert/ and for firm-wide functions like ExistingClients/, FirmReference/, InvestmentCommittee/, InvestmentPolicies/, and RiskProfiles/), ModelPortfolios/ (with Archive/, Exemplars/, RebalancingFramework/, and a project-specific VCMM_2026/), and Research/ (with Alternatives/, ESG/, ExternalData/, and VCMM/). The data-drive organization encodes the user's professional domain structure—it reflects how a senior financial advisor would naturally partition their work across client management, portfolio modeling, and research activities.

The directory tree is not merely cosmetic. It determines where the work agent will look for files during simulation, establishes the navigational structure that the agent must learn to use effectively, and provides implicit context about the user's work—the existence of an InvestmentCommittee/ directory tells the agent that this user participates in committee work and may need to produce committee-facing deliverables, while the Archive/ subdirectory within ModelPortfolios/ signals that the user maintains historical versions of their work.

File inventory creation. For each directory in the tree, the environment planner determines what files should exist, producing an inventory entry with the following metadata for each planned file:

Logical path: the full path within the computer's filesystem (e.g., D:/Research/VCMM/VCMM AssetClassProjections 2025.xlsx)
Artifact type: the file format (e.g., .xlsx, .docx, .pdf, .pptx, .xlsm, .py, .json, .md)
Description: a textual description of the file's content and purpose (e.g., "Structured workbook compiling VCMM 10-year return projections, transcribed from the Vanguard PDF above. Foundation data for all VCMM-based allocation work.")
Timestamp: the virtual creation or modification date (e.g., 2025-01-15), which must be consistent with the computer's system start time and the user's work history timeline
Origin: how the file came to exist—(web download) for files retrieved from the internet, (created) for user-authored artifacts, or implied by the dependency graph for derived files
Content mode: whether the file should be retrieved from the web or synthesized by an LLM

The file inventory is extensive. In the example, the planned files include system files (PersonalMacros.xlsm with VBA macros that auto-load with Excel), personal documents (VCMM ClientAllocationFramework v1.docx, a 22-page white paper draft), external reference materials (VCMM ReturnProjections Summary 2025.pdf, downloaded from Vanguard's advisor portal), derived analytical workbooks (VCMM AssetClassProjections 2025.xlsx, transcribed from the Vanguard PDF), versioned model spreadsheets (AllocationModel Conservative v1.xlsx and AllocationModel Conservative v2.xlsx, with the latter derived from the former), scenario analysis workbooks (ScenarioAnalysis EquityBondSplits 2025.xlsx, derived from two predecessor files), and final deliverables (CapMarketsOutlook 2026 FINAL.pdf, exported after investment committee review and derived from the draft .docx version).

The inventory design reflects several deliberate choices about realism. First, files span a temporal range, with creation dates distributed across the computer's virtual history—from 2023 system files to 2025 current-project files. This creates the accumulated work context that real computers have. Second, files exist at multiple stages of completion—drafts, revisions, and finals coexist, reflecting the paper's observation that real users "occasionally accumulate multiple versions of the same spreadsheet without consistent archiving discipline." Third, files come from multiple sources—some are user-authored, some are downloaded from external sources, and some are derived from other files. This makes the computer a heterogeneous information environment rather than a collection of independently generated artifacts.

Dependency graph construction. Perhaps the most important innovation in the filesystem planning stage is the construction of a directed dependency graph over the planned files. The paper argues that this is essential because "real computer environments contain correlated artifacts: later files often reuse, summarize, revise, or cite earlier ones" and that "treating files as independent samples conditioned only on the user profile" would produce an unrealistic environment.

The dependency graph is a directed acyclic graph (DAG) where nodes are planned files and edges represent directional relationships:

Derived-from (→derived from): one file was created by processing, transcribing, or building on another file. Example: VCMM AssetClassProjections 2025.xlsx →derived from VCMM ReturnProjections Summary 2025.pdf, because the spreadsheet was created by transcribing data from the downloaded PDF.
Version-of: one file is a later version of another. Example: AllocationModel Conservative v2.xlsx →derived from AllocationModel Conservative v1.xlsx.
Builds-on: one file uses data or analysis from another as input. Example: ScenarioAnalysis EquityBondSplits 2025.xlsx →derived from VCMM AssetClassProjections 2025.xlsx and Bloomberg RateData Q3 2025.xlsx.

The dependency graph serves two critical functions. First, it provides the conditioning structure for artifact creation. When the artifact creator later instantiates a file that depends on predecessor files, it can condition on the actual contents of those predecessor files (which have already been created, thanks to topological ordering). This means that derived files genuinely reflect and reference their sources—the allocation model v2 spreadsheet will contain data from the v1 spreadsheet it builds on, the capital markets outlook document will incorporate figures from the scenario analysis workbook it cites, and the final PDF will be a properly formatted export of the draft document it derives from. Without the dependency graph, each file would be created independently, and the cross-file relationships that characterize real professional work would be absent.

Second, it enables coherent simulation. When the work agent later operates over the synthetic computer, it can discover and use these dependency relationships—for example, when asked to update the capital markets outlook, it can find that the outlook document was built from the scenario analysis spreadsheet, which in turn was built from the VCMM projections spreadsheet and the Bloomberg data export. This allows the agent to trace information provenance, identify which files need to be updated when source data changes, and maintain consistency across related artifacts—precisely the kind of grounded reasoning that real productivity work requires.

Artifact Creation

With the filesystem plan complete, the next stage instantiates the synthetic computer as an actual on-disk directory structure populated with content-rich files. This proceeds in two steps.

Directory Materialization

The first step is to materialize the planned directory tree. The filesystem plan specifies logical paths using operating-system conventions (Windows-style paths with drive letters and backslashes, or macOS-style paths with forward slashes and a different root structure). These logical paths are mapped into a portable on-disk representation that preserves the intended operating-system semantics.

For Windows-style paths, the mapping transforms logical paths into a physical directory hierarchy under a root directory. For example, the planned path D:/Research/VCMM/VCMM ReturnProjections Summary 2025.pdf is physically stored as drives/D/Research/VCMM/VCMM ReturnProjections Summary 2025.pdf relative to the synthetic computer's root. All parent directories required by the planned file inventory are created first—so drives/D/Research/VCMM/ must exist before the PDF file can be placed there.

This mapping approach has practical advantages. It makes the synthetic computers portable across operating systems (the physical storage is just a directory tree with conventional path separators), while preserving the semantics of the target operating system (drive letters, user home directories, application data paths) that affect how an agent should navigate and reason about the environment.

File Instantiation

The second step is to populate the planned files with actual content. This is where the paper makes a crucial distinction between two categories of files, handled by different creation mechanisms.

Public web-downloadable files are artifacts that correspond to publicly available documents on the internet—typically external reference materials that a real professional would download from vendor portals, regulatory websites, or research databases. Examples from the financial advisor computer include Vanguard's VCMM return projections summary PDF and Bloomberg terminal data exports. When a file is marked in the plan as web-downloadable, the pipeline first attempts to retrieve it from the web—presumably by searching for the described document and downloading it to the planned location. The paper notes a practical limitation: "A more robust planning stage would verify that a candidate public file is actually available and downloadable before marking it as web-downloadable. In the current pipeline, this check is performed after planning, so some planned web downloads fall back to synthesis." This means the pipeline is optimistic during planning (assuming files are downloadable) and only discovers unavailability at instantiation time, where it falls back to LLM synthesis.

User-specific artifacts are files that are unique to the synthetic user—their own documents, spreadsheets, presentations, and other work products that wouldn't exist on the public internet. These are created by an LLM agent equipped with artifact-creation tools or skills, conditioned on the file's metadata (path, description, artifact type, timestamp, origin, content mode) and, critically, on the contents of predecessor files in the dependency graph.

The artifact-creation agent uses specific tools for different file formats:

For Office-related artifacts (.docx, .xlsx, .pptx, .pdf), the paper uses "MiniMax's open-source skills: minimax-docx, minimax-xlsx, pptx-generator, and minimax-pdf." These skills give the agent the ability to programmatically create properly formatted professional documents with realistic structure, formatting, and content.
For non-Office artifact types, the paper uses "Anthropic's skills"—presumably general-purpose file creation and manipulation capabilities built into the Claude Code SDK.

The skills-based approach to artifact creation is a practical engineering choice that reflects the domain's requirements. Professional productivity files are complex structured objects: an Excel workbook can contain multiple sheets with formulas, formatting, charts, and cell comments; a PowerPoint presentation has slides with layouts, placeholders, notes, and embedded media; a Word document has sections, headers, footers, track changes, and style hierarchies. Generating these programmatically requires specialized knowledge that is best encapsulated in reusable skills rather than reconstructed from scratch by the agent each time.

Dependency-aware instantiation order. The artifact creation process does not create files in arbitrary order. Instead, it uses topological sorting (Kahn's algorithm, 1962, explicitly cited in the paper) over the dependency graph to determine an instantiation order that respects all cross-file dependencies. The algorithm works as follows:

Identify all files with no predecessors (no incoming edges in the dependency graph). These are "root" files—typically external downloads, initial drafts, or template documents that don't depend on any other files on the computer.
Instantiate these root files first. For web-downloadable roots, attempt retrieval; for synthesized roots, use the LLM agent conditioned on the file metadata and user profile.
Once a file is instantiated, remove it from the graph. Any files that now have no remaining uninstantiated predecessors become eligible for instantiation.
When multiple files become eligible simultaneously (ties), break ties by timestamp—earlier files are instantiated before later files, maintaining consistency with the computer's virtual history.
Repeat until all files are instantiated.

This ordering is essential for the dependency graph to serve its conditioning function. When AllocationModel Conservative v2.xlsx is being created, the algorithm ensures that AllocationModel Conservative v1.xlsx has already been instantiated, so the v2 creation can condition on the actual content of v1—copying its structure, updating its figures, and adding new analysis tabs while preserving continuity with the earlier version. Without this ordering, v2 would have to be generated independently and then retroactively made consistent with v1, which is both harder to automate and more likely to produce inconsistencies.

The paper provides screenshots of resulting artifacts (Figure 3) showing the output quality: a multi-sheet Excel workbook with structured data tables and a multi-page PDF with professional formatting, tables, and figures. Table 2 reports file size statistics that confirm the artifacts are content-rich rather than placeholder files. For example, the mean file size for .pptx files among all artifacts is 593.7 KB (median 546.5 KB, 95th percentile 1200.6 KB), and for .pdf files it is 383.1 KB (median 83.4 KB, 95th percentile 1116.8 KB). These sizes are consistent with real professional documents containing substantial content, formatting, and embedded elements.

Figure 5 reports the artifact type distribution across synthetic computers. Productivity formats dominate: .docx files account for 34.8% of all files, .xlsx for 15.8%, .pdf for 13.9%, and .pptx for 8.5%—together 73.0% of all files. The remaining files include .py (5.9%), .txt (3.3%), .png (2.9%), .json (2.4%), .md (2.3%), .toml (1.9%), .jsonl (1.7%), and others (6.6%). This distribution reflects the paper's definition of "artifacts" as "structured productivity files, such as documents, spreadsheets, presentations, and PDFs, rather than plain-text-only files"—the synthetic computers are designed to support professional knowledge work, and the file type distribution reflects that focus.

Table 1 reports structural statistics for the 1,000 synthetic computers before simulation. Each computer contains on average 111.6 files (median 89, range 72–595), 30.4 directories (median 25, range 16–181), an average directory depth of 3.39 (median 3.22, range 2.72–6.68), and a maximum directory depth of 5.5 (median 5, range 4–13). These numbers indicate that the synthetic computers are substantial but not unrealistically large—they represent the computer of a professional who has been working for several years (the system start time in the example is 2022-11-05, roughly 3–4 years of virtual history) and has accumulated a meaningful but not overwhelming collection of work products.

Productivity Objectives and Collaboration Setup

With the synthetic computer created, the pipeline moves to the simulation stage, which is divided into setup and execution. The setup stage has two components: generating productivity objectives and creating simulated collaborators.

Productivity Objective Generation

The setup agent (powered by Claude Opus 4.6, as specified in Section 4.1) is responsible for determining what productivity objectives the work agent should pursue over the simulated period. This is not a matter of sampling a generic task from a predefined list. The setup agent must reason about what objectives are "realistic and valuable for that user to pursue over about a month of work" given who the user is and what already exists on their computer.

The paper specifies that the setup agent is prompted to "reason from the perspective of someone who understands the user's professional responsibilities, such as a manager, client, or domain expert." This is a deliberate framing choice: it encourages the setup agent to generate objectives that are authentic to the user's professional context rather than generic productivity tasks that could apply to anyone.

The setup agent conditions its objective generation on two sources of information:

The user profile, which provides context about the user's occupation, responsibilities, current projects, collaborators, and common work products. This tells the setup agent what kind of work this person does and what types of deliverables they typically produce.
The current state of the synthetic computer, including the full file inventory and the contents of existing artifacts. This tells the setup agent what work has already been done, what projects are in progress, what reference materials are available, and what deliverables might naturally follow from the existing work context.

The resulting productivity objectives are expressed as a set of deliverable work packages, each specifying a concrete professional outcome, the expected progress over the simulated period, and the output artifacts to be created or revised. The objectives are designed to be "challenging enough to require sustained effort, but also reachable for that user given their background, role, existing files, and available collaborators."

The example in the paper shows objectives for a 20-working-day period (2026-01-05 to 2026-01-30) consisting of five deliverables:

Deliverable 1: 2026 VCMM Model Portfolio Refresh (target: 2026-01-28). This deliverable requires finalizing three model portfolios using updated VCMM projections, authoring a Capital Markets Outlook document, and presenting to the Investment Committee. It specifies four weekly milestones (obtain dataset → rebuild allocation models → complete outlook → present to IC) and lists eight expected output artifacts with specific filenames and paths (e.g., D:/ModelPortfolios/VCMM 2026/AllocationModel Conservative v3.xlsx, D:/ModelPortfolios/VCMM 2026/CapMarketsOutlook 2026 FINAL v3.pdf). The deliverable also includes specific constraints: "Justify any weight changes >100 bps versus 2025 allocations."

Deliverable 2: Robert Castellano HNW Onboarding Package (target: 2026-01-29). This deliverable involves onboarding a new high-net-worth client with specific characteristics ($7.2M investable, retired tech executive, conservative-to-moderate risk tolerance, 20-year retirement horizon). It explicitly depends on Deliverable 1 ("proposed allocation calibrated to the refreshed 2026 model") and requires compliance sign-off from a specific collaborator (James Whitfield). It specifies weekly milestones and eight expected artifacts.

Deliverables 3–5, summarized in the paper, cover a rebalancing trigger framework (requiring peer review sign-off from Sandra Okonkwo), an alternatives integration recommendation (for Investment Committee vote), and an ESG equity overlay recommendation (requiring compliance-approved firm-wide recommendation).

Several design choices in the objective generation are worth noting:

Inter-deliverable dependencies. Objectives are not independent tasks. Deliverable 2 depends on Deliverable 1 (the client's proposed allocation must use the refreshed 2026 model portfolios). Deliverable 4 (alternatives integration) is presented alongside Deliverable 1 at the Investment Committee meeting. These dependencies reflect how real productivity work "often unfolds through connected projects rather than independent one-off tasks" (Section 3.1.1). They also create coordination challenges for the work agent: the agent cannot complete Deliverable 2 until specific outputs from Deliverable 1 are ready, creating a temporal dependency that must be managed across the simulated weeks.

Output specification specificity. The objectives specify not just what deliverables should be produced, but where they should be placed in the filesystem (full paths like D:/ModelPortfolios/VCMM 2026/AllocationModel Conservative v3.xlsx). This grounds the objectives in the specific synthetic computer—the paths are valid locations within the computer's directory tree that the work agent can navigate to and create files in. It also allows evaluation of whether the agent placed deliverables in the correct locations.

Collaborator integration. Several deliverables explicitly require interactions with specific collaborators: Hartley (manager) must approve the IC presentation, Whitfield (compliance) must sign off on the Castellano package and ESG recommendation, Okonkwo (peer) must review the rebalancing tool. These requirements are not add-ons—they are baked into the deliverable specifications, ensuring that the work agent cannot complete objectives purely through solo work but must engage with the collaboration system.

Temporal structure. Each deliverable specifies milestones broken down by week (W1, W2, W3, W4), creating a natural planning rhythm for the simulation. The work agent's weekly planning (Section 3.2) is conditioned on these milestones, and the daily execution is structured to make progress toward them.

Collaboration Setup

After generating productivity objectives, the setup agent creates a small set of simulated collaborators who may participate in the work. This is, as the paper argues, "a key difference between our simulations and standalone productivity tasks: instead of assuming that all necessary information is given upfront and that the work agent can complete the task independently, we model productivity work as a process that may require coordination with other people."

The paper argues that this modeling choice is not cosmetic but fundamental to realism: "In realistic long-horizon productivity work, the user often needs to clarify requirements, request data or source materials, understand stakeholder preferences, and revise artifacts based on feedback." Without collaborators who have their own knowledge, preferences, communication styles, and private information, the simulation would reduce to an extended solo task—still useful, but missing the social and organizational dimensions that characterize real professional work.

Each simulated collaborator is defined with several attributes:

Role and relationship. The collaborator's professional role relative to the user (manager, peer, direct report, client, compliance officer, external partner) determines the nature of their interactions—a manager gives direction and feedback, a peer provides technical review, a client expresses preferences and constraints.

Background. Professional background, expertise, and personal characteristics that shape the collaborator's perspective. For example, David Hartley (manager) is "58 years old, MBA Wharton, CFA charterholder. Runs Meridian's Denver office (12 advisor teams, $2.1B firm-wide AUM) and chairs the Denver Investment Committee. Numbers-first, skeptical of narrative arguments, demands complete staff work and clear executive summaries." This background explains why Hartley gives the kind of feedback he gives—terse emails, preference for bullet points, emphasis on quantitative evidence.

Communication style. How the collaborator communicates, including preferred formats, response latency, and stylistic tendencies. Hartley's style is "Terse. Email subjects like 'VCMM refresh — 3 items.' Response latency 24–48 hours. Prefers bullet points; ignores long prose." This creates realistic communication constraints: the agent cannot expect immediate responses or verbose dialogue, and must adapt its communication style to the collaborator's preferences.

Reference files held privately. This is perhaps the most important attribute. Each collaborator possesses private reference materials that contain information the work agent does not initially have access to. These files are "held privately" by the collaborator and are only shared with the user "through later collaboration when needed." Examples include:

Hartley's DirectorExpectations 2026 Priorities.docx (containing KPIs the agent must meet, such as "any model change >150 bps requires sensitivity analysis") and IC ReviewChecklist ModelPortfolio Refresh.docx (an 8-item checklist the agent must satisfy)
Castellano's AccountStatements YE2025.xlsx (containing "a 1.7% allocation discrepancy between summary and position-level rows that the agent must detect"), RiskQuestionnaire Completed.pdf, and DiscoveryCall Followup Questions.docx
Okonkwo's PeerReview RebalancingTool v2.docx (with specific cell references and corrections the agent must address), HistoricalRebalancingCalls 2024-2025.xlsx, and CrisisRegime Correlations 2020Q1 2022.xlsx
Whitfield's compliance manual references and regulatory citations

The private reference files serve a dual purpose. For the simulation, they create information asymmetry—the work agent must discover what collaborators know through interaction, just as real professionals must elicit requirements, preferences, and constraints through meetings, emails, and document reviews. For evaluation, they create ground truth—the evaluator can check whether the agent's deliverables satisfy the hidden requirements that were communicated through collaborator interactions (e.g., whether the agent detected and documented the 1.7% allocation discrepancy, whether the rebalancing tool addressed Okonkwo's specific cell-level corrections).

The paper reports that each synthetic computer has an average of 5.5 simulated collaborators (Table 3), with a range of 5 to 8. These collaborators span different organizational roles: managers (who set direction and evaluate), peers (who provide technical review), clients (who have specific needs and preferences), compliance officers (who enforce regulatory requirements), external partners (who provide data or services), and direct reports (who execute delegated tasks, occasionally introducing errors that the agent must catch—Kevin Tran "eager but occasionally sloppy — intentionally introduces unit-mismatch errors (bps vs. %) and missing data-as-of dates that the agent must catch").

Planning and Daily Work Simulation

With the synthetic computer created, objectives defined, and collaborators configured, the simulation proper begins. The work agent (powered by Claude Sonnet 4.6, as specified in Section 4.1) "acts as the computer's user and carries out the productivity objectives over the simulated period." The agent is given the user profile, the productivity objectives, the simulated collaborator descriptions, and access to the synthetic computer—but it does not see collaborators' private reference materials unless they are later shared through collaboration.

The simulation proceeds through two nested cycles: a weekly planning cycle that sets direction at the start of each week, and a daily execution cycle that carries out planned activities one workday at a time.

Weekly Planning

At the beginning of each simulated week, the work agent creates a detailed plan for the coming workdays. The plan is conditioned on several sources of information:

The productivity objectives and their weekly milestones
Remaining deliverables and their deadlines
Prior progress (what was completed in previous weeks)
Current computer state (what files exist, what drafts are in progress)
Expected collaboration needs (who needs to be contacted and when)

The plan breaks the week into daily activities, each specifying:

Activity type: categorized as deep work (creating or revising substantive deliverables), review (reading and analyzing existing materials), admin (meetings, filing, coordination), or outreach (communicating with collaborators)
Time: the scheduled time of day (e.g., "10:30," "14:00"), creating a realistic workday rhythm
Description: what the agent will do during this activity
Files to create or modify: specific paths for output artifacts
Source artifacts to consult: specific paths for input files the agent should read before working
Collaborators to contact: which simulated collaborators the agent will reach out to

The example weekly plan (Week 1, 2026-01-05 to 2026-01-09) shows a realistic work week for a senior financial advisor. Monday includes outreach to Patricia Huang (requesting VCMM data), outreach to Robert Castellano (scheduling discovery call), and several other activities (morning market review, 1:1 with manager, outreach to peer, direct report, and compliance officer). Tuesday includes reviewing Castellano reference files and preparing for the discovery call, with specific output files and source dependencies documented. Wednesday includes an IC huddle meeting, the discovery call with Castellano (creating formal call notes), and reviewing Okonkwo's peer review documents (creating an issues catalogue). Thursday includes building the VCMM delta analysis spreadsheet and sending feedback to a direct report. Friday includes writing a preliminary findings memo for the manager and emailing it with specific formatting requirements.

Each activity entry specifies explicit file paths for created outputs and derived-from sources. For example, the Wednesday discovery call notes activity specifies: Creates: D:/ClientWork/Castellano Robert/DiscoveryCall Notes 2026-01-07.docx and Derived from: Castellano AccountStatements YE2025.xlsx, ... and 3 more. This explicit grounding ensures that the agent's plan is anchored in the actual synthetic computer filesystem rather than floating in abstract task descriptions.

The weekly plan also encodes collaboration dependencies. The plan schedules outreach to specific collaborators on specific days, anticipating that responses will arrive with latency (David Hartley's "response latency 24–48 hours" means Monday outreach might not receive a response until Wednesday or Thursday). This temporal structuring is essential for realism: in real professional work, you cannot instantaneously get answers from colleagues, and planning must account for communication delays.

Daily Execution

After the weekly plan is created, the work agent executes it one workday at a time. Each day is run as a separate agent session—a critical design choice that has implications for state management and agent capabilities.

At the start of each day, the agent restores the current work context by:

Reviewing the activity log from previous days (what was done, what was left incomplete)
Checking the current computer state (what files have been added or modified)
Reading any new collaborator replies or shared files that arrived since the previous session

This context restoration step is essential because the work agent does not maintain a persistent memory across daily sessions. Each session is stateless with respect to the agent's internal context—the only continuity comes from the synthetic computer's evolving state and the recorded activity log. The agent must therefore re-ground itself in the current state of the computer and the simulation at the start of each day, much as a real professional might review their calendar, email, and recent files at the start of a workday.

The agent then performs the day's planned activities by:

Reading relevant existing artifacts from the synthetic computer's filesystem before working on them
Creating or revising the required output files, placing them at the specified paths
Sending messages or shared files to collaborators when needed (the paper refers to these as "communications"—Table 3 reports an average of 31 communications per simulation)

At the end of each day, the simulation records:

The new files created during the day
Revised artifacts (files that were modified)
Collaborator interactions (messages sent, responses received, files shared)
Activity history (a log of what was done, written by the agent during execution)

This recorded state becomes the input for the next daily session, ensuring that the simulation maintains continuity even though each session is stateless from the agent's perspective.

The daily activity log example (2026-01-07, Wednesday) shows the level of detail the agent records. For the IC huddle meeting, the log records specific topics discussed, action items, and deadlines. For the Castellano discovery call, it records detailed outcomes: confirmed account structures, detected the 1.7% Schwab international allocation discrepancy, documented the Aspen liquidity constraint, noted the CSCO phased disposition plan, and captured the Roth conversion sequencing concern. For the peer review analysis, it records specific technical issues (tax-lot awareness, cash-drag treatment, crisis-regime correlations) with development plans. This detailed log serves both as continuity for subsequent sessions and as process-level signal for retrospective analysis.

State Management and Simulation Evolution

As the simulation proceeds across weeks and days, the synthetic computer is changed by the agent's work. This is not a static environment where the agent simply reads files and produces outputs elsewhere. The computer itself evolves:

New files are added at the planned paths
Existing artifacts are revised (drafts become finals, v1 becomes v2, spreadsheets are updated with new data)
Collaborator exchanges are recorded (email threads, shared files, feedback documents)
The dependency graph is updated to reflect new relationships (new outputs that build on prior materials)

Table 1 reports the structural impact of a month of simulated work. After simulation, each computer increases from an average of 111.6 files to 197.4 files (a 77% increase), and from 30.4 directories to 36.0 directories (an 18% increase). Directory depth remains largely stable (from 3.39 to 3.40 average, 5.5 to 5.6 maximum), suggesting that "the work agent extends the existing computer environment mainly by creating and revising artifacts within the established organization, rather than producing unrealistic directory structures." This stability is a validation signal: a realistic work agent should add files to existing project folders, not create entirely new directory structures that would disrupt the user's organizational scheme.

Table 1 also reports post-simulation file size statistics for final deliverables separately from collaborator-held reference files. Final deliverables show substantial content: .pptx files average 615.4 KB (median 576.6 KB), .pdf files average 141.8 KB (median 88.9 KB), .xlsx files average 28.1 KB (median 16.4 KB), and .docx files average 14.8 KB (median 12.0 KB). These sizes are consistent with professional-quality deliverables containing real content, formatting, and analysis.

Table 3 reports the computational cost of simulation. Each simulation requires on average:

2,272 total turns (median 2,234, range 1,551–3,248), where a "turn" is a single agent action (reading a file, creating a file, sending a message, etc.)
8.59 hours of wall-clock time (median 8.31, range 6.27–11.67)
Weekly planning accounts for 63 turns and 0.59 hours on average, while daily execution accounts for 2,209 turns and 8.00 hours—the vast majority of the cost is in execution, not planning

These figures establish that the simulations are genuinely long-horizon. A single simulation requires more than a full workday of agent runtime and generates thousands of steps of trajectory. When multiplied across 1,000 synthetic computers, the total computation is substantial (roughly 8,590 agent-hours, or about 358 agent-days of continuous runtime).

Collaboration Mechanics

The collaboration system operates through message passing. The work agent can "send messages or shared files to collaborators when needed." The simulated collaborators respond according to their defined communication styles (Hartley with "response latency 24–48 hours," Okonkwo who "responds within hours"). This creates asynchronous communication that the work agent must manage: an email sent on Monday may not receive a response until Wednesday, and the agent must plan around this latency, not assume instant feedback.

Collaborators' private reference materials serve as a mechanism for injecting hidden requirements and evaluation criteria into the simulation. For example, Hartley's private DirectorExpectations 2026 Priorities.docx specifies that "any model change >150 bps requires sensitivity analysis"—a requirement the work agent can only learn by receiving and reading this document, which requires initiating contact with Hartley. Castellano's private AccountStatements YE2025.xlsx contains a deliberate discrepancy that the agent must detect through careful analysis. Okonkwo's private peer review documents contain specific technical corrections the agent must implement.

The paper reports that on average, each simulation involves 31 communications (median 30, range 17–56) across 5.5 collaborators (median 5, range 5–8). This represents a non-trivial collaboration load: the work agent is not just producing deliverables in isolation but actively coordinating with multiple stakeholders throughout the simulation.

The retrospective analysis in Appendix A reveals specific collaboration failure modes. The work agent sent 10 blank messages to collaborators in the final week of the example simulation—messages where the agent intended to communicate but produced empty content, "suggesting the agent ran out of context or planning capacity." These blank messages had cascading consequences: Okonkwo's critical stress-test corrections (sent on Day 17) were never acknowledged, and the corrections were never applied. This failure mode—losing track of collaborator feedback under competing time pressure—is precisely the kind of realistic long-horizon coordination failure that the simulation is designed to surface as a learning signal.

The weekly planning and daily execution loop repeats until the simulated period is complete—four weeks of five working days each in the example, for 20 total working days. At the end, the simulation has produced both a complete trajectory (process signals capturing how the agent planned, grounded, collaborated, revised, and recovered) and final deliverables (outcome signals measuring whether the objectives were achieved). These artifacts become the input to the experience extraction pipeline that produces occupation-specific skills for improving future agents.

4. Key Insights and Innovations

Innovation 1: Synthesizing the Context, Not Just the Task — A Fundamental Reframing of What Synthetic Data Must Contain

The paper's most intellectually distinctive contribution is not any specific algorithm or architecture, but a reframing of what it means to create synthetic data for agent training. Prior work on synthetic data generation for agents—whether persona-driven conversation generation (Ge et al., 2024), task-benchmark construction (Patwardhan et al., 2025), or environment synthesis for RL (Cai et al., 2025)—operates under an implicit assumption: that the task is the primary object to be synthesized, and the context is either provided as a small set of explicit reference files or is simply the state of the conversation so far. The task is the variable; the environment is the constant.

This paper argues, through its methodology and demonstrated results, that this assumption is backward for productivity work. The paper's third guiding principle—"Synthetic data must synthesize the context, not only the task"—is not a minor clarification. It is a claim that the dominant paradigm in synthetic data generation fails to capture the essential structure of the domain it aims to serve. Real productivity work is not defined by a task prompt with attached reference files; it is defined by a user's accumulated digital environment—their files, their project history, their naming conventions, their organizational habits, their collaborator relationships—and the task is what emerges when you place objectives inside that environment. You cannot create realistic productivity training data by varying the task while holding the environment constant, because in the real world, the environment is the primary source of variation across users.

The paper makes this argument concrete through its dependency graph, which is the mechanism that operationalizes the reframing but whose conceptual significance transcends its implementation details. Prior work treats synthetic files as conditionally independent samples from a user profile distribution. This paper treats them as nodes in a directed graph, where edges encode derivation, versioning, and citation relationships. The insight is that the structure of cross-file relationships is itself a source of realism that matters for training—an agent that learns to navigate a filesystem where later documents genuinely build on earlier ones (incorporating their data, citing their conclusions, revising their drafts) is learning a qualitatively different skill than an agent that learns to process a collection of independent reference files. The retrospective analysis in Appendix A makes this point vividly: one of the primary failure modes is cross-document inconsistency, where the same portfolio weight appears as 14%, 20%, 27.4%, and 19% across four related deliverables. This failure mode can only exist—and can only be trained against—in an environment where documents genuinely depend on each other.

Significance beyond performance. This reframing matters not because it produces a +7.0 pp score improvement (though it does), but because it changes what the field should build. If the dependency graph insight is correct, then future work on synthetic environment generation should focus not on generating more independent files with higher fidelity, but on generating richer dependency structures—cross-file citations, version chains, data provenance trails, and contradiction patterns that create the kind of coherence-maintenance challenges that real productivity work demands. The paper's topological sort over the dependency graph during artifact creation (Section 2.3) is a first step, but the concept points toward more sophisticated environment-generation objectives: environments that contain deliberately planted inconsistencies for agents to detect, dependency chains that require tracing information provenance across multiple files, and version histories that force agents to reconcile conflicting updates from different collaborators.

Comparison to prior work. Persona-driven data generation (Ge et al., 2024) conditions outputs on a user description, but the conditioning is flat: each output independently references the persona. The synthetic computer methodology introduces hierarchical conditioning: the persona conditions the user profile, which conditions the filesystem plan, which conditions individual files, which condition downstream derived files through the dependency graph. This creates depth—files are not just "about" the user, they are about each other, reflecting the accumulated structure of real work. This is a different kind of scaling than the billion-persona approach: it scales depth of conditioning rather than breadth of personas.

Innovation 2: Difficulty as Coverage — Scaling Trends Reveal That Synthetic Environment Diversity, Not Just Volume, Drives Transfer

The paper's scaling analysis in Section 4.3 (Figure 7) is superficially about how performance improves as training computers increase from 10 to 900. But the intellectual contribution is more specific and more important: the paper provides evidence that the transfer of simulation-derived experience is gated by occupation coverage, not by raw data volume. This distinguishes synthetic environment creation from standard data scaling narratives.

The finding is clean and counterintuitive if you come from a pretraining-data-scaling mindset. With only 10 training computers, the skill-augmented agent does not improve over baseline (50% win rate)—in fact, "the agent may use a weakly related skill that does not fit the user's work context and can even hurt performance." With 100 computers, the win rate rises to 64%. With 500, 75%. With 900, 83%. The paper explicitly identifies two mechanisms driving this trend: "First, occupation coverage becomes broader, so test computers are more likely to have a relevant skill. Second, the frequency estimates become more reliable, allowing the skill creator to better identify the common lessons and failure modes that should receive higher priority."

This is a coverage scaling law, not a volume scaling law. More training computers help not because more data is inherently better, but because more computers cover more occupations, and occupation-specific skills only transfer to test computers in the same occupation. A financial-advisor skill cannot help a healthcare administrator agent; a legal-professional skill cannot help an engineer. The scaling curve in Figure 7 is therefore fundamentally a coverage curve: it tracks the probability that a randomly sampled test computer's occupation has been seen in the training set, multiplied by the reliability of the skill extracted for that occupation.

Significance beyond performance. This finding has substantial implications for how synthetic environment generation should be scaled. If the goal were purely volume-driven improvement, you would generate as many computers as possible from the most common occupations (Management & Executive, Tech & Computing) and aggregate experience across them. The paper's result suggests this would be suboptimal—you would quickly saturate coverage of common occupations while leaving rarer ones uncovered, and the skills extracted would be biased toward patterns that may not generalize across professional domains. Instead, the optimal allocation of environment-generation compute should be coverage-driven: ensure that every occupation in the target distribution is represented by enough computers to produce reliable skill extraction. This is a fundamentally different resource allocation problem than pretraining data scaling, where more tokens from any source generally help.

The out-of-domain transfer results on GDPVal (Figure 8) reinforce this interpretation. The skills transfer across model families (Sonnet → Haiku and Opus) and across task distributions (synthetic computers → a public benchmark with different structure), but with weaker gains for stronger and weaker models. The paper attributes this to the skill set being Sonnet-specific—it captures failure modes that Sonnet exhibits, which Opus may avoid (reducing benefit) and which Haiku may not have the instruction-following capacity to apply (reducing benefit). This is a capability-specific transfer pattern: the extracted experience is not a universal productivity skill but a model-specific set of behavioral corrections, and its transfer value depends on the target model's similarity to the source model in failure-mode space.

Innovation 3: Information Asymmetry as Realism — Simulated Collaborators With Private Knowledge Create Training Signals That Static Benchmarks Cannot

The collaboration setup in Section 3.1.2 appears at first glance to be an engineering detail—a way to make simulations more interactive. But it represents a deeper conceptual move: the paper argues, through its simulation design and evaluation methodology, that information asymmetry between agents and their environment is a necessary condition for realistic productivity simulation, and that creating this asymmetry synthetically—through collaborators with private reference files, hidden requirements, and asynchronous communication—produces qualitatively different training signals than environments where all information is available upfront.

To see why this is conceptually significant, compare the paper's simulations to GDPVal, the benchmark used for out-of-domain evaluation (Table 5). GDPVal tasks average 1.18 explicit reference files; the paper's simulations average 13.8 explicit reference files plus approximately 112 additional computer files that provide implicit work context, plus collaborator-held private files that the agent must discover through interaction. The difference is not just quantitative. In GDPVal, all information needed to complete the task is either in the prompt or in the provided reference files—the agent's challenge is to process what it's given. In the paper's simulations, critical information is absent from the environment and must be elicited through social interaction—the agent must decide who to contact, what to ask, when to follow up, and how to incorporate responses that arrive with realistic latency.

This transforms the nature of what is being trained. A static benchmark trains an agent to be a good information processor: given everything you need, produce the right output. The paper's simulations train an agent to be a good information gatherer: given partial information and a social environment, figure out what you don't know, who knows it, how to get it from them, and how to integrate it with what you already have. These are different capabilities, and the paper's retrospective analysis (Appendix A) reveals failure modes specific to the latter: blank messages sent when the agent runs out of context capacity (losing critical collaborator corrections), failure to track action items committed during meetings, and misrepresenting document status to collaborators.

The private reference file mechanism is the key enabler. By giving collaborators files that contain requirements, constraints, and evaluation criteria that are invisible to the work agent until discovered, the simulation creates a natural incentive for proactive information-seeking. The Castellano example illustrates this clearly: the client's private AccountStatements YE2025.xlsx contains a deliberate 1.7% allocation discrepancy that the agent must detect, and the retrospective report explicitly scores whether the agent caught it. This is not a gotcha—it is a realistic modeling of the fact that in professional work, clients' financial situations contain nuances that aren't volunteered upfront and must be discovered through careful review.

Significance beyond performance. This information-asymmetry framing points toward a general principle for synthetic environment design: environments should be structured so that optimal agent behavior requires active information acquisition. Environments where all information is given upfront train agents for a different deployment regime—one where tasks are self-contained and context is provided—than the regime these agents will actually face in productivity settings. The synthetic computer methodology implements this principle through the collaborator system, but the principle itself is broader and could be applied to other domains (code generation with hidden repository structure, research tasks with paywalled papers, legal work with privileged documents).

The collaboration setup also creates a natural difficulty gradient. An agent that never contacts collaborators will miss private requirements and score poorly. An agent that contacts collaborators but fails to ask the right questions or follow up on responses will miss some requirements. An agent that actively manages collaborator relationships—scheduling meetings, tracking action items, incorporating feedback, verifying document status—will capture more of the hidden information. This gradient provides a richer learning signal than a static task with a single difficulty level.

Innovation 4: The Age of the Trajectory — Long-Horizon Process Signals Are a Distinct Learning Modality From Outcome Signals

The paper's retrospective analysis methodology (Section 4.2.2 and Appendix A) is, at the surface level, a way to generate training data from simulations. But it embodies a more fundamental claim: that process-level signals from long-horizon trajectories constitute a distinct and valuable learning modality that is not recoverable from final deliverables alone, and that synthetic environments are uniquely positioned to generate this modality at scale.

To understand why this is a conceptual contribution rather than an engineering choice, consider what information is available at different levels of evaluation:

Outcome signals (final deliverables) tell you whether the agent succeeded or failed, but not why. A rubric score of 71.5% on the example computer (Appendix A) tells you the agent's work was acceptable but imperfect—it doesn't tell you that the primary failure mode was cross-document inconsistency, that 10 blank messages were sent in the final week, or that Sandra Okonkwo's critical Day 17 corrections were never applied. These are all process failures that happened before the final deliverables were produced, and they would be invisible to an outcome-only evaluation.

Trajectory signals (the full sequence of agent actions, decisions, communications, and revisions) reveal how the agent worked and where it broke down. The retrospective analysis identifies specific error patterns that are diagnostic of capability gaps: blank messages concentrated in the final week suggesting context-window or planning-capacity exhaustion; failure to update supporting workbooks when narrative documents are revised, creating broken evidence chains; reconstructing enumerated lists from memory rather than copying from collaborator messages; deferring simple corrections (changing three cell values) because they were deprioritized under competing time pressure.

The paper argues that these process-level signals are where "the richest learning opportunities lie, because many failures in long-horizon productivity work are not visible from the final files alone." This is a claim about the information content of trajectories: a trajectory of 2,272 turns contains an order of magnitude more diagnostic information than a single deliverable score, because it reveals not just what went wrong but when, how, and in what context—information that is essential for generating specific, actionable corrections.

Connection to the dependency graph. The process-signal insight connects back to Innovation 1. The dependency graph doesn't just make the synthetic environment more realistic; it also makes the trajectory more informative. Because files have known dependency relationships, the trajectory analysis can identify specific failure patterns: "The agent updated v2.docx figures but never propagated corrections to the underlying workbooks, creating an evidence chain where narrative claims diverge from supporting data." This kind of diagnosis requires knowing that the narrative document was supposed to be consistent with the supporting workbook—knowledge that the dependency graph provides. Without it, the inconsistency would be just another error rather than a specific, nameable failure mode (broken evidence chain) that can be translated into a concrete skill rule ("Update source data first, then update derived documents").

Significance beyond performance. If process signals are a distinct learning modality, then synthetic environment design should optimize for trajectory informativeness, not just deliverable quality. Environments that produce clean, straightforward trajectories (where the agent never makes mistakes) generate zero process-level learning signals. Environments that are challenging enough to produce failures—but structured enough that those failures are diagnosable—generate rich signals. The paper's difficulty gradient from Innovation 3 serves double duty here: it not only creates realism but also creates a spectrum of failure modes across different agents and different simulations, each of which contributes to the occupation-specific skill extraction pipeline.

The skill creation methodology (grouping experience items by occupation, merging similar items with frequency counts) operationalizes this insight. The frequency counts serve as a signal-reliability filter: a failure mode that appears across many simulations within the same occupation is likely a genuine capability gap worth encoding as a skill, while a one-off error may be noise. This is essentially a form of trajectory-level bootstrapping: weak signals from individual trajectories are aggregated across many simulations to produce strong signals (skills) that improve future agents. The scaling trend in Figure 7—where 900 computers produce more reliable frequency estimates and thus better skills than 100 computers—validates this bootstrapping logic.

5. Experimental Analysis

Evaluation Methodology

Dataset. All experiments use the 1,000 synthetic computers created by the pipeline described in Section 2, built from 1,000 sampled personas whose occupation distribution is shown in Figure 4 (spanning Management & Executive at 17.7%, Tech & Computing at 13.7%, Engineering at 13.4%, Business & Finance at 10.9%, and 12 additional occupation categories). For in-domain evaluation (Section 4.3), these 1,000 computers are split into 900 training computers (used only to extract experience and create skills, with no model weight updates) and 100 held-out test computers (used for evaluation). Each synthetic computer contains on average 111.6 files before simulation and 197.4 files after simulation (Table 1). For out-of-domain evaluation (Section 4.4), the paper uses the GDPVal gold set (Patwardhan et al., 2025), consisting of 220 realistic productivity tasks with an average of 1.18 explicit reference files and 1.63 deliverables per task (Table 5).

Base model(s). The work agent is powered by Claude Sonnet 4.6, run through the Claude Code SDK as the agent runtime, while the setup agent (for simulation setup in Section 3.1) uses Claude Opus 4.6 (Section 4.1). The artifact-creation agent is equipped with external skills: Anthropic's skills for non-Office artifact types, and MiniMax's open-source skills (minimax-docx, minimax-xlsx, pptx-generator, and minimax-pdf) for Office-related artifacts. The judge used for rubric-based evaluation is a Claude Code SDK agent powered by Claude Opus 4.6 (Section 4.2.1). For the out-of-domain GDPVal evaluation, the paper tests three model configurations as the work agent: Claude Sonnet 4.6 (the primary setting, matching the source of the extracted skills), Claude Haiku 4.5, and Claude Opus 4.6 (Figure 8), enabling evaluation of cross-model skill transfer.

Metrics. The primary metric for in-domain evaluation is rubric-based deliverable score (%), computed by having a Claude Opus 4.6 judge score the final deliverables against a rubric created specifically for each evaluated computer and its productivity objectives (Section 4.2.1). The rubric construction process is described in detail below. For per-computer comparisons between baseline and skill-augmented agents, the paper reports the number of test computers (out of 100) on which the skill-augmented agent outperforms the baseline, as determined by rubric score (Table 4). For out-of-domain evaluation on GDPVal, the paper uses the pairwise judging protocol from the original benchmark and GDPVal-AA, where a Claude Opus 4.6 judge compares the baseline and skill-augmented agent outputs side-by-side for each of the 220 tasks and selects the better output according to the official GDPVal rubric. Results are reported as win/tie/loss counts with one-sided and two-sided sign test p-values (Figure 8). Additional structural metrics reported include files per computer, directories per computer, directory depth (Table 1), file sizes by artifact format (Table 2), number of turns, wall-clock time, and number of communications (Table 3).

Rubric construction and evaluation protocol. The rubric-based evaluation is non-trivial and warrants detailed explanation. For each of the 100 evaluated synthetic computers, the paper runs the same simulation setting five times (Section 4.2.1). For each run, a judge inspects the final deliverables and writes a draft rubric based on what a good solution should satisfy, considering the productivity objectives, deliverable expectations, and simulated collaborator preferences. The five draft rubrics are then merged into a final rubric, with different runs serving as "complementary references for writing a more complete and more general rubric." The sample rubric shown in the paper for a rebalancing tool deliverable contains 55 items totaling 176 points, with items categorized by source: specification items (6), interaction items (24), expertise items (11), reference items (4), and quality items (10). This rubric generation process is resource-intensive—requiring five full simulations per computer plus a merging step—and the paper explicitly notes that it is "a simple rubric-based judge for this technical report" while acknowledging more advanced rubric generation methods (Liu et al., 2026; Shen et al., 2026) as orthogonal.

Baselines. The primary baseline for in-domain evaluation is the baseline work agent—the same Claude Sonnet 4.6 agent, operating on the same synthetic computer with the same setup, but without access to the occupation-specific skill extracted from training simulations (Section 4.3). This is a clean comparison: the only difference between baseline and skill-augmented is the presence or absence of the externally provided skill. For the scaling analysis in Figure 7, additional baseline comparisons are implicit in the "Baseline" bar (the 0-training-computers condition, where no occupation-specific skills are available). For out-of-domain evaluation on GDPVal, the baseline is the same agent without skills, compared pairwise against the skill-augmented version (Figure 8).

Generation budget / compute accounting. The paper measures compute in several dimensions, none of which are aggregated into a single budget metric for fair method comparison (unlike the FLOPs-matched comparisons typical in scaling-law papers). Instead, compute is reported descriptively across three axes: (1) simulation cost per computer, measured in agent turns (mean 2,272, median 2,234) and wall-clock time (mean 8.59 hours, median 8.31) per simulation (Table 3); (2) training data scale, measured in number of training computers used to extract experience (N = 10, 100, 500, 900 in Figure 7); and (3) evaluation cost, measured in the number of simulation runs per evaluated computer (5 runs for rubric construction) and the rubric-based judging process. There is no attempt to compare the compute cost of skill extraction and augmentation against alternative improvement methods (e.g., fine-tuning, RL, or simply scaling the base model). This is a methodological paper about data generation infrastructure, and the compute accounting reflects that framing: it reports what the pipeline costs to run rather than optimizing a FLOPs-to-performance frontier.

Cross-validation / statistical protocol. The 900/100 train/test split is a simple hold-out split without cross-validation. For the in-domain evaluation, the skill-augmented agent is tested on all 100 held-out computers, and the comparison is per-computer: a win is recorded if the skill-augmented agent outscores the baseline on that computer's rubric (Table 4). No confidence intervals, standard errors, or statistical significance tests are reported for the in-domain results. For the out-of-domain evaluation on GDPVal, the paper uses sign tests (one-sided and two-sided) to assess whether the win/loss distribution differs from chance, with significance levels marked at p < 0.05, p < 0.01, and p < 0.001 (Figure 8). This is a standard non-parametric test for paired comparisons, appropriate for the pairwise judging setup. The scaling analysis in Figure 7 does not report any statistical test for the trend—the win rates (50%, 64%, 75%, 83%) are presented as raw percentages across 100 paired comparisons at each training-set size, without error bars or tests for whether successive increases are significant.

Main Quantitative Results

Synthetic Computer Structural Properties

Before reporting agent performance, the paper characterizes the environments themselves to establish that the synthetic computers are substantive enough to support meaningful productivity simulation. Table 1 reports pre-simulation statistics across 1,000 computers: each contains an average of 111.6 files (median 89, range 72–595), 30.4 directories (median 25, range 16–181), an average directory depth of 3.39 (median 3.22, range 2.72–6.68), and a maximum directory depth of 5.5 (median 5, range 4–13). After a month of simulated work, the environment grows to an average of 197.4 files (a 77% increase), 36.0 directories (18% increase), while directory depth remains largely stable (average 3.40, maximum 5.6). The paper interprets the stable depth as evidence that "the work agent extends the existing computer environment mainly by creating and revising artifacts within the established organization, rather than producing unrealistic directory structures"—a behavioral validation that the agent respects the user's organizational scheme rather than creating sprawling new hierarchies.

Figure 5 reports the artifact type distribution pooled across all synthetic computers. Productivity formats dominate decisively: .docx files account for 34.8% of all files, .xlsx for 15.8%, .pdf for 13.9%, and .pptx for 8.5%—together representing 73.0% of all files. The remaining distribution includes .py (5.9%), .txt (3.3%), .png (2.9%), .json (2.4%), .md (2.3%), .toml (1.9%), .jsonl (1.7%), and others (6.6%). This distribution is consistent with the paper's scoping of "artifacts" as structured productivity files, and the presence of code, text, and data formats in smaller proportions reflects the supporting materials (scripts, logs, configuration files) that naturally co-occur with productivity documents on real professional computers.

Table 2 reports file sizes by common artifact format, distinguishing collaborator-held reference files from final deliverables and providing aggregate statistics across all files. Final deliverables are non-trivial in size: .pptx files average 615.4 KB (median 576.6 KB, p95 1229.1 KB), .pdf files average 141.8 KB (median 88.9 KB, p95 359.3 KB), .xlsx files average 28.1 KB (median 16.4 KB, p95 74.1 KB), and .docx files average 14.8 KB (median 12.0 KB, p95 37.5 KB). Collaborator-held reference files tend to be larger for some formats (.xlsx mean 51.0 KB vs. 28.1 KB for deliverables; .docx mean 26.6 KB vs. 14.8 KB), which is consistent with reference files being more comprehensive source documents while deliverables may be more focused outputs. The paper notes these figures "indicate that the simulations produce content-rich productivity artifacts rather than lightweight placeholder files." The wide spread between median and p95 values for .pptx and .pdf files (p95 roughly 2–2.5× the median) suggests substantial variation in deliverable complexity across simulations.

Simulation Scale and Cost

Table 3 reports the computational cost of running one long-horizon simulation, averaged across 1,000 synthetic computers. Each simulation requires a mean of 2,272 total turns (median 2,234, range 1,551–3,248), where weekly planning accounts for 63 turns (median 63) and daily execution accounts for 2,209 turns (median 2,166). In wall-clock time, each simulation averages 8.59 hours (median 8.31, range 6.27–11.67), with weekly planning contributing 0.59 hours and daily execution contributing 8.00 hours. The total compute across 1,000 computers is therefore approximately 8,590 agent-hours (about 358 agent-days of continuous runtime), though this is distributed across presumably parallel execution. Each simulation involves an average of 5.5 simulated collaborators (median 5, range 5–8) and 31 communications (median 30, range 17–56).

These figures establish the simulations as genuinely long-horizon by any reasonable standard. The contrast with GDPVal (Table 5) is dramatic: GDPVal tasks average 31 turns and 17 minutes of wall-clock time, compared to 2,272 turns and 8.59 hours for the paper's simulations—roughly 73× more turns and 30× more wall-clock time. The paper does not report the total wall-clock time for the full 1,000-simulation run, the degree of parallelism used, or the infrastructure cost, making it difficult to assess the practical scalability of the approach for researchers with more limited compute budgets.

In-Domain Evaluation: Skill-Augmented vs. Baseline

Table 4 reports the headline in-domain result. Across the 100 held-out test computers, the baseline work agent achieves a mean rubric score of 61.6%. The skill-augmented work agent (equipped with occupation-specific skills extracted from the 900 training simulations) achieves a mean score of 68.6%, an improvement of +7.0 percentage points. In per-computer paired comparison, the skill-augmented agent outperforms the baseline on 83 out of 100 test computers (83%), while the baseline outperforms on 17 computers (17%). The paper does not report the median score, score distribution, or per-occupation breakdown for this aggregate result, making it difficult to assess whether the improvement is concentrated in certain occupation categories or is uniform across the test set.

Scaling Analysis: Effect of Training Computer Count

Figure 7 reports how the per-computer win/loss share of the skill-augmented agent against the baseline changes as the number of training computers (N) used to extract skills grows. Each row in the figure aggregates 100 paired comparisons at that training-set size:

N = 10: The skill-augmented agent wins on 50% of test computers and loses on 50%. The paper explains: "likely because the training set covers too few occupations. For many test computers, no matching occupation skill is available, so the agent may use a weakly related skill that does not fit the user's work context and can even hurt performance."
N = 100: Win rate rises to 64% (loss rate 36%).
N = 500: Win rate rises to 75% (loss rate 25%).
N = 900: Win rate rises to 83% (loss rate 17%).

The paper attributes this scaling trend to two mechanisms: broader occupation coverage (test computers are more likely to have a relevant occupation-specific skill available) and more reliable frequency estimates (with more simulations per occupation, the skill creator can better identify which failure modes and lessons are common versus idiosyncratic). The transition from no improvement at N=10 (where skills may actually hurt) to strong improvement at N=900 (where 83% of test computers benefit) is consistent with the coverage-scaling interpretation—N must be large enough that the training set includes meaningful representation of the occupations appearing in the test set.

Out-of-Domain Evaluation: Transfer to GDPVal

Figure 8 reports results on the GDPVal gold set (220 tasks), testing whether skills extracted from Sonnet 4.6 simulations on synthetic computers transfer to a public benchmark with different task structure, reference file count, and time horizon.

Primary setting (Sonnet 4.6, the source model): The skill-augmented agent wins 105 tasks, ties on 48, and loses 67, compared to the baseline. The one-sided sign test gives p = 0.002 (significant at p < 0.01), and the two-sided test gives p = 0.005 (significant at p < 0.01). The net advantage is 38 more wins than losses (105 − 67), representing the agent winning on 47.7% of tasks outright versus 30.5% for the baseline, with 21.8% ties.

Cross-model transfer to Haiku 4.5: The skill-augmented agent wins 104 tasks, ties on 36, and loses 80. One-sided p = 0.045 (significant at p < 0.05), two-sided p = 0.090 (not significant at p < 0.05). The net advantage is 24 more wins than losses—a weaker effect than for Sonnet. The paper attributes this to Haiku having "weaker instruction-following ability" and being "more affected by the long-context pressure introduced by long-horizon tasks."

Cross-model transfer to Opus 4.6: The skill-augmented agent wins 99 tasks, ties on 50, and loses 71. One-sided p = 0.019 (significant at p < 0.05), two-sided p = 0.038 (significant at p < 0.05). The net advantage is 28 more wins than losses—also weaker than for Sonnet. The paper attributes this to Opus being "already strong and may avoid many of the Sonnet failure modes captured by the skills." This is a particularly interesting result: it suggests the extracted skills are partially model-specific (capturing failure modes that Sonnet exhibits but a stronger model may not), reducing their incremental value for more capable models.

The paper does not report GDPVal rubric scores (only win/tie/loss counts), so the magnitude of improvement on GDPVal cannot be directly compared to the +7.0 pp in-domain improvement. It also does not report per-task-category breakdowns on GDPVal or analyze which types of skills transfer best across the domain gap.

Final Deliverable Quality Distribution

Figure 6 shows the score distribution from the rubric-based evaluation across 100 synthetic computers, reported both per-computer (aggregate score across all deliverables for that computer) and per-deliverable (individual deliverable scores). The per-computer distribution (left panel) shows most scores falling between 60% and 80%, with a mode around 65–70%. This distribution shape is consistent with the mean baseline score of 61.6% reported in Table 4—the agent can complete many required deliverables but "still leaves substantial room for improvement," as the paper notes. The per-deliverable distribution (right panel) shows a similar concentration in the 60–80% range but with a slightly different shape, suggesting that across-deliverable variation within computers is comparable to across-computer variation. The paper does not report the variance, interquartile range, or any distributional statistics beyond the histograms, so the dispersion of scores cannot be quantified precisely.

Ablation Studies and Robustness Checks

The paper's experimental section is notably sparse on traditional ablations—there are no controlled experiments varying individual components of the pipeline (e.g., with vs. without dependency graphs, with vs. without collaborator private files, with vs. without weekly planning) and measuring the impact on downstream agent performance. This reflects the paper's nature as a systems-and-methodology contribution rather than an algorithm contribution: the paper demonstrates that the full pipeline produces useful experiential signals, but does not isolate which components of the pipeline are necessary versus incidental for those signals' utility. The following analyses are presented in lieu of standard ablations:

Training computer count scaling (Figure 7). This serves as an indirect ablation of training data volume and occupation coverage. At N = 10 training computers, the skill-augmented agent shows zero net benefit (50% win rate), demonstrating that the pipeline's output is not automatically useful at small scales—coverage and frequency reliability matter. The monotonic improvement from 10 to 900 training computers provides evidence that the extracted experience generalizes increasingly well as occupation coverage expands. However, this is not an ablation of the pipeline itself (all configurations use the same pipeline) but rather a characterization of the data scaling behavior of the experience extraction step.

Cross-model transfer (Figure 8). Testing skills extracted from Sonnet simulations on Haiku and Opus serves as an indirect test of whether the skills capture model-specific behavioral patterns or more general productivity principles. The weaker transfer to both Haiku and Opus (compared to Sonnet) suggests partial model-specificity: the skills capture Sonnet failure modes that Opus may not exhibit and that Haiku may not have the capacity to correct. This is a robustness finding with practical implications: skills extracted from one model's simulations may not transfer cleanly to another model, limiting the reusability of simulation-derived experience across model generations or families.

Occupation coverage as a scaling mechanism (explicit mechanism analysis). The paper provides a mechanistic explanation for the Figure 7 scaling trend by identifying two factors (occupation coverage breadth and frequency estimate reliability) rather than treating it as a black-box data scaling curve. This is a conceptual ablation: it distinguishes between "more data helps because more data always helps" (volume scaling) and "more data helps because more occupations are represented and patterns become statistically reliable" (coverage scaling). The distinction matters for resource allocation—if coverage is the mechanism, generating 1,000 computers from 10 occupations would be worse than generating 100 computers from 100 occupations—but the paper does not run the controlled experiment (varying occupation diversity while holding computer count constant) that would definitively test this mechanism.

Private reference file mechanism (implicit validation through evaluation). While not presented as a formal ablation, the retrospective analysis in Appendix A demonstrates that collaborator private files inject specific, verifiable requirements into the simulation. The rubric includes items tagged as [interaction] (24 out of 55 items in the sample rubric) that test whether the agent discovered and satisfied requirements communicated through collaborator interactions rather than stated upfront. For example: "Cash is modeled as its own dedicated sleeve with its own target, drift threshold, and drag attribution—not folded into a bond-equivalent calculation" (a requirement from Okonkwo's private peer review document) and "Crisis-regime correlation handling is implemented as a parallel, simultaneously-displayed sensitivity output" (a requirement from collaborator feedback). The high proportion of interaction-sourced rubric items (24/55 in the sample) suggests that collaborator private files contribute substantially to the evaluation's discriminating power, but without a no-collaborator ablation, the marginal contribution cannot be quantified.

Multiple simulation runs for rubric construction (Section 4.2.1). The decision to run five simulations per evaluated computer and merge draft rubrics is a robustness choice aimed at reducing single-run bias in the evaluation rubric. A rubric built from a single simulation might be overly narrow—rewarding specific choices made in that run rather than evaluating whether the objectives were met. The paper argues that "different runs serve as complementary references for writing a more complete and more general rubric for the same productivity objectives." This is a strength of the evaluation methodology, but it also means the evaluation cost per computer is 5× the simulation cost, and the paper does not report how much rubric variation exists across runs or whether 3 or 4 runs would suffice.

Critical Assessment

Does the paper demonstrate that synthetic computer simulations produce useful experiential learning signals?

What was tested: The paper demonstrates that occupation-specific skills extracted from 900 training simulations improve the work agent's rubric score from 61.6% to 68.6% on 100 held-out synthetic computers (Table 4), with the skill-augmented agent winning on 83 of 100 paired comparisons. It also demonstrates significant improvement on the out-of-domain GDPVal benchmark (Figure 8: 105 wins vs. 67 losses, p = 0.002 on Sonnet 4.6).

What was not tested: The paper does not compare the skill-extraction approach against alternative methods for utilizing the same simulation data. Would fine-tuning the base model on the simulation trajectories (rather than extracting external skills) produce larger improvements? Would simply concatenating selected trajectory excerpts as few-shot examples outperform the skill format? Would the same occupations-specific skills, if written by human domain experts rather than extracted from simulation trajectories, be stronger or weaker? The paper demonstrates that simulation-derived experience can improve agents, but does not establish that skill extraction is the most effective way to use that experience, nor that the experience is superior to what could be obtained through other means (human-written guidance, web-scraped professional documentation, etc.).

The coverage-scaling interpretation is plausible but incompletely validated. The Figure 7 scaling trend (50% → 64% → 75% → 83% as N grows from 10 to 900) is interpreted as driven by occupation coverage and frequency reliability. However, the test set is only 100 computers (presumably spanning multiple occupations, but the paper does not report the occupation distribution of the test set). At N = 10, if the 10 training computers happen to cover, say, 5 occupations, and the 100 test computers span 40 occupations, then 35 test-computer occupations would have no matching skill—explaining the 50% win rate as chance-level performance on those computers. At N = 900, coverage is presumably much broader, so more test computers have a relevant skill. This explanation is consistent with the data but not uniquely supported by it. A cleaner test would report per-occupation win rates as a function of how many training computers exist in that occupation, decoupling coverage from volume.

Does the paper demonstrate that the improvements scale with simulation coverage?

What was tested: Figure 7 shows a monotonic improvement in win rate as training computers increase from 10 to 900. The paper explicitly identifies two mechanisms: broader occupation coverage and more reliable frequency estimates.

What was not tested: The paper does not control for occupation diversity while varying computer count. All training sets are random samples from the 900-computer pool, so coverage and volume are confounded—as N increases, both the number of distinct occupations represented and the number of computers per occupation increase. To distinguish coverage scaling from volume scaling, one would need to compare, for example, 100 computers from 100 occupations against 100 computers from 10 occupations (10 per occupation). The trend in Figure 7 is equally consistent with "more data always helps, and we happened to need ~100 computers to get a reliable signal" as with "occupation coverage is the key driver, and we need enough occupations to match the test distribution." The paper's mechanistic interpretation is plausible and well-articulated, but it is a post-hoc explanation of an observational trend, not a causally tested hypothesis.

Does the paper demonstrate out-of-domain transfer to GDPVal?

What was tested: Skills extracted from Sonnet simulations on synthetic computers improve Sonnet's performance on GDPVal (105 wins vs. 67 losses, p = 0.002), with weaker but still positive transfer to Haiku (104 wins vs. 80 losses, p = 0.045 one-sided) and Opus (99 wins vs. 71 losses, p = 0.019 one-sided).

What was not tested: Several aspects of the transfer claim are unexamined:

Mechanism of transfer: Why do skills trained on synthetic computer simulations help on GDPVal? GDPVal tasks average 31 turns and 17 minutes (Table 5), with 1.18 reference files; the paper's simulations average 2,272 turns and 8.59 hours, with ~112 computer files plus collaborator-held private files. These are qualitatively different task distributions. The skills that transfer may be general productivity principles (e.g., "maintain cross-document consistency," "verify cited figures against source data") rather than synthetic-computer-specific behaviors. Or they may be Sonnet-specific behavioral corrections (e.g., "don't claim to have checked something without actually opening the file") that happen to apply to both domains. Without analyzing which skills drive the GDPVal improvement (by ablating skill categories or examining per-task transfer patterns), the paper cannot distinguish between these mechanisms. This matters for assessing whether synthetic computer simulations are necessary for the improvement or whether the same skills could have been extracted from a different, cheaper data source.
Magnitude of improvement: The paper reports win/tie/loss counts but not rubric scores on GDPVal. The improvement could be a narrow but consistent edge (winning by 1–2 rubric points on many tasks) or a large margin on a subset of tasks. The absolute performance level matters for assessing practical significance—if both baseline and skill-augmented agents score poorly on GDPVal (e.g., 30% vs. 35%), then a statistically significant win/loss advantage may not translate to deployment-ready capability.
Comparison to GDPVal-specific training: A natural baseline for the out-of-domain claim would be to compare skills extracted from synthetic computer simulations against skills extracted directly from GDPVal training tasks (if any exist) or against general productivity guidance written by humans. Without such a comparison, we cannot assess whether synthetic computer simulations provide better transfer than alternative sources of productivity experience, or merely some transfer.

Does the paper demonstrate that the synthetic computers are realistic?

What was tested: The paper reports structural statistics (file counts, directory depths, artifact type distributions, file sizes in Tables 1–2) and provides qualitative examples (user profiles, filesystem plans, weekly plans, daily logs, and the retrospective analysis report in Appendix A). The agent's behavior during simulation provides indirect validation: directory depth remains stable post-simulation (Table 1), suggesting the agent respects the user's organizational scheme; the agent detects deliberately planted inconsistencies (the 1.7% Castellano allocation discrepancy); and the retrospective analysis reveals realistic failure modes (cross-document inconsistency, blank messages under time pressure, failure to track collaborator commitments).

What was not tested: Realism is assessed qualitatively and structurally, not through human evaluation. The paper does not report whether human professionals (e.g., actual financial advisors) would judge the synthetic computers and simulation trajectories as realistic, or whether the artifacts would pass as authentic professional work products. The structural statistics (e.g., "34.8% of files are .docx") are consistent with professional knowledge work but do not establish that the content of those files is professionally authentic. The retrospective analysis in Appendix A reveals cross-document inconsistencies, missed collaborator feedback, and blank messages—behaviors that are realistic failures but could also reflect limitations of the agent rather than authenticity of the environment. An environment that produces realistic-looking failure modes is not necessarily itself realistic; it could be that both the environment and the agent are jointly unrealistic in ways that happen to produce intelligible trajectories.

Additionally, the paper notes a specific limitation in artifact realism: "Current artifacts are grounded in the user's role, projects, and files, but their visual style and formatting can still be too uniform across computers" (Section 6). This suggests that while the content is user-specific, the presentation may not capture the stylistic diversity of real professional documents—an aspect of realism that the paper identifies as future work.

Structural Limitations of the Experimental Design

No pipeline-component ablations. The paper treats the full pipeline—persona → user profile → filesystem plan → artifact creation → simulation setup → simulation execution → experience extraction → skill creation—as a monolithic system. There are no experiments showing, for example, whether the dependency graph contributes beyond independent file generation, whether collaborator private files contribute beyond providing all information upfront, or whether weekly planning contributes beyond daily execution alone. This is understandable for a systems paper demonstrating a new capability, but it means we cannot assess which design choices are load-bearing versus incidental.

Single model family for most results. The in-domain evaluation uses only Claude Sonnet 4.6 as the work agent (with Claude Opus 4.6 for setup and judging). The out-of-domain evaluation tests cross-model transfer but only to other Claude models (Haiku and Opus). There is no evaluation with models from other families (GPT, Gemini, Llama), which would be important for establishing that the synthetic computers and extracted skills are model-agnostic infrastructure rather than Claude-specific.

100-computer test set with no statistical detail. The 100 held-out computers presumably span multiple occupations, but the paper does not report the occupation distribution of the test set, per-occupation scores, or any confidence intervals around the 61.6% vs. 68.6% mean scores. The 83/17 win/loss split is striking, but without knowing whether improvements are concentrated in a few well-covered occupations or distributed broadly, the practical significance is unclear.

Rubric construction cost is unaccounted for in practical deployment. Running each evaluated computer's simulation five times to construct a rubric is extremely expensive (5 × 8.59 hours = ~43 agent-hours per evaluated computer, plus the merging step). The paper acknowledges this is a "simple rubric-based judge for this technical report" and that more advanced methods exist, but the current evaluation protocol is clearly research-grade rather than deployment-grade, and the paper does not estimate how much cheaper a deployment evaluation would be.

No comparison to alternative data sources. The paper demonstrates that simulation-derived experience improves agents, but does not compare against the improvement achievable from alternative data sources at similar cost. For example: would extracting skills from publicly available professional writing (industry white papers, regulatory guidance, professional standards documents) provide comparable or better guidance for the work agent? Would the same 8,590 agent-hours of compute, spent on a different data generation strategy (e.g., human-written productivity guides, web-scraped professional templates, few-shot examples from GDPVal tasks), produce larger improvements? Without such comparisons, the paper demonstrates feasibility but not relative efficiency.

Summary of Experimental Strengths

Despite these limitations, the experiments have notable strengths:

The scaling curve (Figure 7) is genuinely informative. The monotonic improvement from 10 to 900 training computers, with a clear mechanism interpretation (coverage + frequency reliability), provides actionable guidance for practitioners allocating resources to this methodology.
The out-of-domain transfer (Figure 8) is a strong existence proof. Showing that skills extracted from Sonnet simulations on synthetic computers improve Sonnet's GDPVal performance demonstrates that the extracted experience is not purely in-domain overfitting. The cross-model transfer results, while weaker, provide useful information about model-specificity.
The simulation cost reporting (Table 3) is honest and detailed. Reporting mean, median, min, and max for turns, wall-clock time, collaborators, and communications gives a clear picture of the computational requirements, enabling other researchers to assess feasibility.
The qualitative analysis (Appendix A) adds depth. The retrospective report provides concrete examples of failure modes that would be invisible in aggregate metrics, making the case for process-level signals more compelling than numbers alone could.
The evaluation is multi-faceted. Combining structural statistics (Tables 1–2), simulation-scale metrics (Table 3), in-domain rubric scores (Table 4, Figure 6–7), and out-of-domain pairwise judging (Figure 8) provides triangulation that any single evaluation modality would lack.

6. Limitations and Trade-offs

Limitation 1: Difficulty Estimation Requires Expensive Multi-Run Execution and Evaluation — The Headline $+7.0$ pp Improvement Excludes Substantial Unreported Overhead

The assumption or constraint. The paper's core evaluation (Section 4.2.1) measures agent performance using a rubric-based judge that requires, for each evaluated synthetic computer, running five complete simulations of that computer's productivity objectives (each averaging 8.59 hours of agent runtime per Table 3), having a judge inspect each set of final deliverables, writing five draft rubrics, and then merging them into a final rubric before scoring a sixth agent run. The paper is transparent about this: it describes the procedure explicitly and acknowledges it as "a simple rubric-based judge for this technical report," noting that "more advanced rubric generation and automatic evaluation methods... are orthogonal to the synthetic computer and simulation methodology studied here." However, the paper presents its headline results—61.6% baseline, 68.6% skill-augmented, 83/100 win rate (Table 4)—without amortizing the rubric construction cost into any reported efficiency metric.

The consequence. The cost of evaluating whether the methodology works at all far exceeds the cost of running the simulation being evaluated. A single simulation requires approximately 8.59 hours (Table 3). Constructing the rubric for that simulation requires 5 additional simulation runs (~43 hours) plus the judge's rubric-writing and merging time. Evaluating the 100 test computers in Table 4 therefore consumes roughly 500 simulation runs (approximately 4,295 agent-hours) just for rubric construction, before a single baseline or skill-augmented evaluation run is scored. The per-computer evaluation cost is thus 6× the per-computer simulation cost—or more, since the rubric construction cost is fixed per evaluated computer regardless of how many experimental conditions (baseline, skill-augmented, ablations) are compared.

This has several consequences for practitioners. First, the evaluation protocol is research-grade, not deployment-grade: it cannot be used as an online evaluation metric during iterative development because each evaluation cycle costs days of compute. Second, the $+7.0$ pp improvement represents a gain in agent capability after an evaluation infrastructure has been built that costs 6× more than the training infrastructure. In a production setting where evaluation cost must be amortized across agent development, the net efficiency of the methodology would need to account for whether rubric construction can be simplified or reused across multiple agent versions. Third, the evaluation cost creates a barrier to exact replication: reproducing the paper's full results would require running approximately 5,000+ simulations (900 training computers × 1 simulation each + 100 test computers × 6 simulations each for rubric construction + 100 test computers × 2 evaluation runs for baseline and skill-augmented comparison), totaling roughly 43,000+ agent-hours. The paper's release of only 100 synthetic computers and 500 retrospective reports—rather than the full 1,000 computers and all simulation runs—reflects this barrier.

What evidence exists in the paper. The multi-run rubric construction procedure is described in Section 4.2.1: "To make the rubric less tied to a single run, we run the same simulation setting five times. For each run, we ask a judge to inspect the final deliverables and write a draft rubric... We then merge the draft rubrics into a final rubric." Table 3 reports 8.59 hours per simulation. The paper does not report the total compute consumed by rubric construction, the judge's runtime cost, or any analysis of how rubric quality varies with the number of merged draft rubrics (e.g., 1 run vs. 3 runs vs. 5 runs).

Mitigation status. The paper partially acknowledges the issue by noting that more advanced rubric generation methods (Liu et al., 2026; Shen et al., 2026) are "orthogonal" and could replace the five-run protocol. However, no experiments test whether 3 or even 1 simulation run would produce similarly effective rubrics, and the paper does not provide a comparison between its multi-run rubrics and rubrics generated by alternative methods. The evaluation infrastructure cost is therefore an unresolved practical limitation for anyone seeking to deploy or iterate on this methodology at scale.

Limitation 2: No Pipeline-Component Ablations Exist — We Cannot Distinguish Which Parts of the Methodology Are Load-Bearing

The assumption or constraint. The paper treats the synthetic computer creation and simulation pipeline as a monolithic system and evaluates only the end-to-end output. The methodology contains at least six major design choices—(1) dependency graph construction during filesystem planning, (2) topological-sort artifact creation ensuring derived files condition on predecessors, (3) collaborator private reference files creating information asymmetry, (4) weekly planning followed by daily execution as separate agent sessions, (5) simulated collaborators with distinct communication styles and response latencies, and (6) the retrospective analysis and occupation-specific skill extraction pipeline—but none of these are ablated individually in the experimental section. The paper does not report results for any variant of the pipeline that removes or simplifies one component while holding others constant.

The consequence. Without component-level ablations, we cannot answer several questions that are essential for understanding the methodology and deciding what to adopt in practice:

Is the dependency graph necessary? Could independent file generation (each file conditioned only on the user profile, without cross-file dependencies) produce synthetic computers that are equally useful for agent training? If so, the topological-sort artifact creation—which adds implementation complexity—is unnecessary overhead. The retrospective analysis in Appendix A identifies cross-document inconsistency as the primary failure mode, accounting for "~80–100 points lost across all deliverables." This failure mode is only meaningful in an environment where documents are genuinely supposed to be consistent—a property the dependency graph creates. But without evaluating an ablated environment without dependencies, we cannot assess whether agents trained on dependency-free environments would simply not exhibit this failure mode, or would exhibit it less severely because the environment itself is less challenging.
Is the collaboration system with private files necessary? The collaboration setup adds substantial complexity (simulated collaborators, asynchronous communication, private reference materials injected through interaction). The paper shows that the rubric contains a high proportion of [interaction] items (24 out of 55 in the sample rubric), meaning the evaluation strongly depends on collaborator-discovered requirements. But if those same requirements were provided upfront as part of the task specification, would agent performance be higher or lower? Would the extracted skills still transfer to GDPVal? Without a no-collaborator or all-information-upfront ablation, we cannot assess whether the collaboration system is adding value or merely adding difficulty that makes the evaluation harder without improving training signal quality.
Is the skill extraction and frequency-counting approach better than alternative ways to use trajectories? The paper demonstrates that occupation-specific skills improve agent performance. But other approaches—fine-tuning on trajectory data, using trajectory excerpts as few-shot examples, training a critic model to flag common errors—might make better use of the same simulation data. Without comparisons, the skill extraction method's efficiency advantage (or disadvantage) is unknown.

What evidence exists in the paper. Section 4 contains no ablation experiments. The scaling analysis (Figure 7) varies the number of training computers but does not vary the pipeline itself. The cross-model transfer results (Figure 8) test skill transfer across model families but use the same pipeline output. The paper's Section 5.2 discusses future directions implicitly ("as agents improve, the simulated work should also become more realistic") but does not report experiments that would identify which components of the current pipeline drive the observed improvements.

Mitigation status. Not addressed. The paper positions itself as a methodology contribution demonstrating a new capability—synthetic computers at scale with long-horizon simulation—and the authors may have judged that component-level ablations are premature for a paper establishing feasibility. However, for a practitioner trying to decide which aspects of this methodology to adopt (e.g., "should I implement the full dependency graph, or can I start with independent file generation?"), the absence of ablations means the decision must be made on first-principles reasoning rather than empirical evidence.

Limitation 3: Single Model Family and Single Task Domain — Transfer Claims Are Clustered Around Claude Models on Structured Knowledge Work

The assumption or constraint. The paper's primary in-domain evaluation (Section 4.3) uses only Claude Sonnet 4.6 as the work agent, with Claude Opus 4.6 handling simulation setup and rubric judging. The out-of-domain evaluation (Section 4.4) tests skill transfer to other models, but only within the same Claude model family: Haiku 4.5 and Opus 4.6. All simulations are run on synthetic computers built around professional knowledge work—the occupation distribution in Figure 4 spans management, engineering, finance, healthcare, legal, and creative professions, but all share a common structure: computer-grounded work producing structured productivity artifacts (documents, spreadsheets, presentations). The out-of-domain benchmark (GDPVal) similarly focuses on "real-world economically valuable tasks" in productivity domains. The paper makes no claims about applicability to other agent domains (code generation, creative work, scientific research, operational control) or other model families (GPT, Gemini, Llama, open-weight models).

The consequence. The paper's central claim—that "scalable synthetic computer creation, together with at-scale simulations, is highly promising as a foundational substrate for agent self-improvement and agentic reinforcement learning in long-horizon productivity scenarios"—is supported by evidence from exactly one model family (Claude) on one class of tasks (structured knowledge work producing Office-format deliverables). Several failure modes for generalization are plausible but untested:

Model-family specificity of skills. The cross-model transfer results (Figure 8) already show that Sonnet-extracted skills transfer more weakly to Haiku and Opus than to Sonnet itself. If skills are partially model-specific—capturing behavioral patterns unique to Claude models' training, prompting conventions, or failure modes—then the entire simulation pipeline would need to be re-run for each new model family. The paper's self-improvement vision (Figure 9) assumes that skills extracted from one round of simulations improve the agent for the next round, but if those skills are model-specific, they may become obsolete when the underlying model is updated or replaced.
Domain-specificity of synthetic computers. The synthetic computer creation pipeline is tailored to professional knowledge work: the artifact types are overwhelmingly Office formats (73.0% of files are .docx, .xlsx, .pdf, or .pptx per Figure 5), the directory structures reflect organizational project hierarchies, and the productivity objectives involve multi-deliverable analysis and documentation tasks. It is unclear whether the methodology would transfer to other domains—for example, a software engineer's computer would be dominated by code repositories, configuration files, and development tools, with very different organizational principles and artifact relationships. The paper does not claim this transfer, but a practitioner considering the methodology for non-knowledge-work domains has no evidence to guide their decision.

What evidence exists in the paper. The paper reports all primary results using Claude Sonnet 4.6 as the work agent (Section 4.1). The out-of-domain evaluation (Figure 8) tests three Claude variants but no non-Claude models. The artifact type distribution (Figure 5) shows 73.0% Office-format files. The occupation distribution (Figure 4) spans knowledge-work professions but does not include trades, manual labor, or operational roles where productivity work would involve different tooling and artifact types. The paper's Section 5.3 mentions "senior advisors, expert analysts, researchers, lawyers, operators, designers, engineers, and other domain experts" as target domains, but the current experiments focus on the subset of these that produce structured documents in Office formats.

Mitigation status. The paper does not attempt to mitigate this limitation—it does not test non-Claude models or non-knowledge-work domains. The cross-model transfer experiment (Figure 8) partially addresses model-family specificity by showing that skills transfer across Claude variants, but the conclusion that transfer weakens for both stronger (Opus) and weaker (Haiku) models suggests the skills are not model-agnostic. The paper's vision of scaling "to millions or even billions of synthetic user worlds" (Abstract) implicitly assumes that the methodology generalizes across occupations and contexts, but no evidence for this assumption is provided beyond the 1,000-computer sample drawn from the occupation distribution in Figure 4.

Limitation 4: The Hardest-Scenario Floor — The Methodology Provides No Evidence of Improvement on Problems Beyond the Agent's Base Capability

The assumption or constraint. The paper's skill-augmentation approach relies on extracting experience from trajectories where the agent both succeeds and fails, identifying common failure modes, and encoding corrections as explicit skills. This implicitly assumes that the agent's failures are within the "zone of proximal development"—close enough to successful behavior that an explicit skill (a rule or pattern the agent can follow) can bridge the gap. The paper does not test this assumption directly, but the methodology's design and results suggest a capability bound: if the base agent simply cannot perform a class of tasks (e.g., it lacks the domain knowledge, reasoning capacity, or instruction-following ability to execute certain productivity workflows at any level of quality), no amount of trajectory analysis and skill extraction will help.

The consequence. This limitation creates a sharp boundary on the methodology's applicability. For professions or task types where Claude Sonnet 4.6 already has reasonable baseline performance (as reflected in the 61.6% mean baseline score—the agent is completing most deliverables at a moderate quality level), skill augmentation provides a meaningful boost. For tasks where the base agent's performance is near zero, the skill extraction pipeline has no successful trajectories to learn from and no near-miss failures to correct—the experience extraction would produce no useful signals. This means the methodology amplifies existing capability but does not create it, a boundary condition the paper does not explicitly characterize or measure.

The evidence for this limitation is indirect but suggestive:

The occupation distribution (Figure 4) is heavily weighted toward professions where LLMs have substantial training-data exposure: Management & Executive (17.7%), Tech & Computing (13.7%), Engineering (13.4%), Business & Finance (10.9%). These are domains well-represented in web text and professional documentation. Rarer or more specialized professions (only 0.1% for "Other," 0.9% for Office & Admin) may have insufficient base-model capability for the methodology to bootstrap improvement.
The cross-model transfer to Haiku (Figure 8) shows weaker improvement for the weaker model, with the paper attributing this to Haiku's "weaker instruction-following ability" and greater susceptibility to "long-context pressure." This suggests that below some capability threshold, the skill format becomes ineffective—the agent cannot reliably follow the skill instructions, so the extracted experience provides no benefit. The paper does not identify where this threshold lies or whether it applies to the base Sonnet agent for sufficiently difficult occupations.
The retrospective analysis (Appendix A) for the financial advisor computer shows the agent scoring 71.5% overall, with substantial room for improvement driven by identifiable failure modes (cross-document inconsistency, missed collaborator corrections, blank messages). This is a success case for the methodology. But the paper does not show an analogous analysis for a lower-performing computer (e.g., one where the agent scored 30% because it fundamentally misunderstood the domain), which would reveal whether the methodology fails gracefully or produces actively harmful skills.

What evidence exists in the paper. The paper reports mean baseline performance of 61.6% (Table 4) and shows a score distribution (Figure 6) where most per-computer scores fall between 60% and 80%. This tells us the agent is operating in a regime where substantial improvement is possible. The paper does not report the minimum per-computer score, the score distribution for the lowest-performing computers, or any analysis of whether skill augmentation helps or hurts on computers where baseline performance is poor. The scaling analysis (Figure 7) shows that with only 10 training computers, the skill-augmented agent performs at chance level (50% win rate), but this is attributed to occupation coverage rather than base capability limits.

Mitigation status. The paper does not explicitly address this limitation. The self-improvement loop envisioned in Figure 9 assumes that each round of simulation produces better skills, which produce better agent behavior, enabling better subsequent simulations. But if the agent's base capability on some class of tasks is too low, the loop cannot start—the initial simulations would produce such poor trajectories that no useful skills could be extracted, creating a chicken-and-egg problem the paper does not discuss. The paper's approach to harder scenarios in the current distribution (the 60–80% score range) works because the agent has non-trivial baseline capability; extending to genuinely novel or specialized professions may require a different bootstrapping strategy.

Limitation 5: Latency and Serial Dependencies Are Not Accounted For — Wall-Clock Time Implications of Sequential Daily Execution May Limit Practical Deployment

The assumption or constraint. The work agent executes the simulation in daily sessions (Section 3.2), where each day is "run as a separate agent session" that restores context from the previous day's activity log and computer state. The weekly planning step precedes daily execution, and collaborator communication involves simulated latency (e.g., David Hartley's "response latency 24–48 hours"). This architecture creates a fundamentally serial execution timeline: Day N cannot begin until Day N-1 is complete, because Day N's context depends on the computer state, collaborator responses, and activity log produced during Day N-1.

The paper measures compute in agent turns (mean 2,272 per simulation) and wall-clock time (mean 8.59 hours), but these measurements reflect the total serial execution time—the agent runs continuously through the simulation without exploring whether parallelization is possible. The paper does not discuss whether multiple days could be planned and executed concurrently, whether collaborator responses could be sampled in advance rather than simulated with realistic latency, or whether the daily session structure could be compressed without sacrificing trajectory quality.

The consequence. The 8.59-hour wall-clock time per simulation is not just a compute cost—it is a latency constraint that affects how the methodology can be used in practice:

Agent development cycles. If a researcher wants to iterate on the simulation design (e.g., adjusting collaborator behavior, modifying productivity objectives, testing a new skill format), each iteration cycle for a single computer takes at minimum 8.59 hours from start to complete trajectory. Running multiple iterations in parallel across computers helps throughput but not latency for any single computer. This makes rapid prototyping and debugging of the simulation setup infeasibly slow.
Online deployment. The paper's self-improvement vision (Figure 9) envisions repeated cycles of simulation → skill extraction → agent improvement → simulation. If each cycle requires running simulations that take 8.59 hours each, the improvement loop's iteration time is at minimum several days (simulation time + skill extraction time + model update time), even before scaling to many computers. For production deployments where agents need to improve continuously from experience, this latency may be unacceptable unless simulations can be made substantially faster.
Interactive or human-in-the-loop scenarios. The daily session structure is designed to simulate a human's work cadence over a month. But if the goal is to generate training data quickly, simulating 20 daily sessions sequentially (with context restoration between each) is an inefficient use of agent runtime. The paper does not explore whether a more compressed simulation format—e.g., executing the entire month in a single long session, or parallelizing independent workstreams—would produce trajectories of comparable quality at lower wall-clock time.

What evidence exists in the paper. Table 3 reports that daily execution accounts for 8.00 of the 8.59 total hours (93% of wall-clock time), with weekly planning contributing only 0.59 hours. The simulation description (Section 3.2) confirms the sequential daily execution structure: "After the weekly plan is created, the work agent executes it one workday at a time. Each day is run as a separate agent session. At the start of each day, the agent restores the current work context..." The paper does not report any experiments with alternative execution schedules (compressed, parallelized, or batched) or analyze whether the daily session boundaries are necessary for trajectory quality or merely a design choice for simulation realism.

Mitigation status. Not addressed. The paper treats the 8.59-hour wall-clock time as a descriptive fact about the simulations rather than a limitation to be optimized. Section 5.2 discusses how "stronger agents can create better artifacts and workflows" but does not consider whether stronger agents could also execute simulations faster. Section 5.3 mentions "computer-use agents" requiring "realistic computer states, files, applications, and histories" but does not discuss whether those agents' training could be accelerated by relaxing the daily-session constraint. The latency issue is orthogonal to the paper's primary contribution (scalable environment creation) but is practically significant for anyone seeking to use the methodology in an iterative development or online improvement setting.

Limitation 6: The 83/100 Win Rate Is a Coarse Binary Metric — Per-Computer Magnitude of Improvement and Failure Case Analysis Are Missing

The assumption or constraint. The paper's primary in-domain evaluation metric is per-computer binary win/loss: the skill-augmented agent either outscores the baseline on that computer's rubric (a win) or does not (a loss). The headline result is that the skill-augmented agent wins on 83 of 100 test computers (Table 4). However, the paper does not report how much the skill-augmented agent wins by on those 83 computers, how much it loses by on the 17 computers where the baseline is better, the per-computer score distribution for either condition, or any analysis of which computers benefit most versus which are harmed by skill augmentation.

The consequence. The 83/17 win/loss split, while striking, masks potential heterogeneity that matters for deployment decisions:

Magnitude of improvement. A scenario where the skill-augmented agent wins by an average of +15 pp on 83 computers and loses by an average of −2 pp on 17 computers is very different from a scenario where it wins by +3 pp on 83 computers and loses by −15 pp on 17 computers. The mean score improvement (+7.0 pp) partially addresses this, but the mean aggregates across the divergent cases. Without the per-computer score deltas, a practitioner cannot assess whether the improvement is consistently moderate across most computers, or driven by large gains on a subset while others see negligible change or harm.
Failure cases. The 17 computers where the baseline outperforms the skill-augmented agent are critical for understanding the methodology's risk profile. Are these computers from specific occupations where the extracted skills are actively harmful (e.g., skills for a related but different occupation that give conflicting guidance)? Are they computers where the base agent already performs well and the skill adds noise? Are they computers where the simulation was unusually noisy and the skill was extracted from low-quality trajectories? Without analysis of the 17 loss cases, the paper cannot characterize when skill augmentation should be expected to help versus hurt.
Per-occupation analysis. The scaling analysis (Figure 7) strongly suggests that occupation coverage drives improvement—skills help only when a matching occupation skill is available. But the 83/17 split is aggregated across all 100 test computers regardless of occupation. If 17 computers correspond to occupations poorly represented in the 900 training computers, the loss rate in those occupations might be much higher than 17%, while the win rate in well-represented occupations might be near 100%. A per-occupation breakdown would reveal this pattern and provide actionable guidance: "for occupation X with N training computers, expected win probability is Y%." Without it, the 83% figure is an average that may not apply to any specific occupation a practitioner cares about.

What evidence exists in the paper. Table 4 reports the 83/17 split and the mean score improvement (+7.0 pp). Figure 6 shows aggregate score distributions (per-computer and per-deliverable) but does not separate baseline from skill-augmented distributions or show the distribution of score deltas. Figure 7 reports win rates at different training set sizes but does not break down by occupation or report score magnitudes. The paper does not analyze the 17 loss cases, identify which occupations they belong to, or examine whether the skills applied to those computers were occupation-matched or cross-occupation.

Mitigation status. The paper partially addresses the magnitude question by reporting mean scores (61.6% vs. 68.6%), which provides an aggregate effect size. But the mean alone does not characterize the distribution—a mean improvement of +7.0 pp with a standard deviation of ±12 pp (where some computers improve by +25 pp and others decline by −10 pp) has very different deployment implications than a mean of +7.0 pp with a standard deviation of ±3 pp (consistent moderate improvement). The absence of per-occupation analysis is unaddressed, despite the occupation-coverage mechanism being central to the paper's interpretation of the scaling trend. This is a missed opportunity: a per-occupation win-rate analysis would simultaneously validate the coverage-scaling hypothesis and provide the occupation-level guidance that practitioners need to decide whether to deploy this methodology for their specific use case.

7. Implications and Future Directions

How This Work Changes the Landscape

This paper introduces a new category of data infrastructure for agent training that does not previously exist in a scalable form. The shift is not algorithmic—the paper proposes no new model architecture, training objective, or inference strategy—but methodological: it establishes that realistic, long-horizon productivity environments can be procedurally generated at scale from personas, and that the resulting simulation trajectories contain experiential signals that measurably improve agent performance. This is best understood as an infrastructure-layer contribution that enables a class of research previously bottlenecked by environment availability.

The magnitude of the shift is foundational rather than incremental for the specific subfield of long-horizon productivity agent training, but narrow rather than broad in its current scope. For researchers working on agents that operate over user computers, produce professional deliverables, and coordinate with collaborators over extended periods, this paper provides the first demonstrated methodology for generating training environments that capture the structural complexity of real computer-grounded work—directory hierarchies, cross-file dependencies, version chains, collaborator information asymmetry, and accumulated work history. Before this work, training such agents required either access to private user data (infeasible at scale) or hand-crafted environments that lacked the diversity and realism needed for generalization. The paper removes this bottleneck.

However, the shift is not a paradigm change for agent training writ large. The current evidence is confined to one model family (Claude), one task domain (structured knowledge work producing Office-format deliverables), and one improvement mechanism (explicit occupation-specific skills extracted from retrospective reports). The paper does not demonstrate that synthetic computer simulations are superior to alternative data sources (human-written professional guidance, web-scraped templates, fine-tuning on shorter-horizon task data), nor that the skill format is the optimal way to use simulation-derived experience. The contribution is therefore best characterized as establishing feasibility and providing a scaling methodology for a previously unscalable data source, with the expectation that follow-up work will refine, extend, and stress-test the approach.

The paper reconciles a tension in the synthetic data literature between breadth and depth of conditioning. Prior persona-driven work (Ge et al., 2024) demonstrated that personas can generate diverse synthetic data at billion scale, but each output is independently conditioned on the persona—the depth of conditioning is shallow. This paper shows how to extend persona-driven generation into hierarchical conditioning: persona → user profile → filesystem plan → individual files → derived files through dependency graphs → simulation trajectories that modify the environment. Each level conditions on the output of the previous level, creating depth that is essential for realism in productivity scenarios. This reconciles the apparent tradeoff: you can have both scale (through many personas, as the paper argues in Section 5.3) and depth (through hierarchical elaboration and dependency-aware generation), provided you are willing to invest the compute to elaborate each persona into a full environment.

The paper also reorients the research agenda around environment generation as a first-class problem. Prior work on agent improvement has focused heavily on algorithms—better reinforcement learning, better prompting, better fine-tuning—while treating environments as a fixed input (existing benchmarks, deployed applications, static datasets). This paper argues, implicitly through its methodology and explicitly through its scaling analysis (Figure 7), that environment coverage and diversity may be the binding constraint on agent improvement for certain classes of tasks: when skills extracted from 10 training computers provide zero benefit (win rate at chance) but skills from 900 training computers provide strong benefit (83% win rate), the binding constraint was not algorithmic sophistication but the breadth of experience the agent was exposed to. This reframing suggests that research investment in environment generation may yield higher returns than marginal algorithmic improvements for long-horizon productivity scenarios—a claim the paper does not prove but provides substantial circumstantial evidence for.

Research directions that become more attractive as a result of this work:

Environment generation for agent training: scaling synthetic environments across occupations, domains, and task structures becomes a research area with demonstrated value, not just a speculative bet.
Process-level learning from trajectories: the retrospective analysis methodology (Appendix A) shows that process signals (how the agent planned, communicated, revised, and recovered) contain diagnostic information not available from final deliverables alone, opening a research direction on trajectory analysis for agent improvement.
Skill-based improvement as an intermediate learning format: the occupation-specific skill approach demonstrates that explicit skills provide a fast, interpretable improvement loop without model weight updates, enabling rapid iteration before committing to more expensive distillation or fine-tuning steps.

Research directions that become relatively less urgent as a result of this work:

Hand-crafted environment design for productivity agent evaluation: if synthetic computers can be generated at scale with sufficient realism, the labor-intensive process of designing individual evaluation environments by domain experts becomes a bottleneck worth bypassing.
Single-turn or short-horizon productivity benchmarks as the primary evaluation modality: the paper's contrast with GDPVal (2,272 turns vs. 31 turns, Table 5) demonstrates that long-horizon simulations surface failure modes (cross-document inconsistency, collaborator commitment tracking, context exhaustion) that short-horizon benchmarks do not capture, reducing the informativeness of short-horizon evaluation for long-horizon deployment.

Follow-Up Research This Work Enables

Ablation of the dependency graph: do cross-file dependencies actually improve training signal quality? The paper's dependency graph construction (Section 2.2.2) and topological-sort artifact creation (Section 2.3) are presented as essential for realism, but no experiment tests whether environments without cross-file dependencies produce equally useful training signals. A controlled experiment would generate two sets of synthetic computers from the same personas: one with the full dependency graph (derived files condition on predecessor contents), and one with independent file generation (each file conditioned only on the user profile, with no cross-file conditioning). The same simulation setup and skill extraction pipeline would be applied to both sets, and the resulting skills would be evaluated on a shared set of test computers. If dependency-graph environments produce skills that yield significantly larger in-domain improvements, the case for the additional implementation complexity is strengthened. More importantly, analyzing which skill categories differ between conditions (e.g., cross-document consistency rules, information-provenance tracking, version management patterns) would reveal what the dependency graph contributes beyond independent file generation.

Testing the coverage-scaling hypothesis directly: varying occupation diversity while holding computer count constant. The paper's Figure 7 shows a monotonic trend from 10 to 900 training computers and attributes it to occupation coverage, but coverage and volume are confounded. A clean test would hold the number of training computers constant (e.g., N = 200) while varying the number of distinct occupations they represent (e.g., 200 computers from 10 occupations with 20 computers each vs. 200 computers from 100 occupations with 2 computers each vs. 200 computers from 200 occupations with 1 computer each). Evaluating the resulting occupation-specific skills on the same 100-computer test set would isolate the coverage effect: if the "200 computers from 200 occupations" condition substantially outperforms the "200 computers from 10 occupations" condition, the coverage-scaling mechanism is confirmed and the optimal allocation of environment-generation compute is unambiguously toward breadth. If the conditions perform similarly, the scaling trend in Figure 7 was driven primarily by total data volume, and practitioners should maximize computer count regardless of occupation distribution.

Cross-model-family transfer of synthetic-computer-derived skills. The paper's cross-model transfer experiment (Figure 8) tests only Claude variants. A natural extension would extract skills from Sonnet simulations on synthetic computers and evaluate them on non-Claude models (GPT-4, Gemini, Llama-3) on GDPVal. This would test whether the extracted skills capture Claude-specific failure modes or more general productivity principles. A finding that skills transfer robustly to GPT-4 and Gemini but weakly to Llama-3 would suggest a capability-threshold effect (only sufficiently capable models benefit) rather than a model-family effect. A finding that skills transfer to no non-Claude model would substantially limit the methodology's generality and suggest that the simulation pipeline must be re-run for each model family. A negative result—zero transfer to any non-Claude model—would be as informative as a positive one, because it would reframe synthetic computer simulations as a model-specific improvement mechanism rather than a general agent-training substrate.

Combining simulation-derived skills with model weight updates: does internalization outperform external skills? The paper's self-improvement vision (Figure 9) proposes a cycle: simulation → skill extraction → agent improvement via skills → distillation into model weights → reset skills → next round. No experiment tests whether the "distillation into model weights" step actually improves over keeping the skills external. A direct comparison would train two agents on the same 900 training computers: one equipped with occupation-specific skills (the current paper's approach), and one fine-tuned on trajectory data from the same simulations (using behavioral cloning on successful trajectory segments, or preference optimization on retrospective report rankings). Evaluating both on the 100 held-out test computers would reveal whether internalization provides advantages beyond external skills—e.g., reducing context-window pressure, enabling more consistent application of learned patterns, or avoiding the skill-selection problem (applying the wrong occupation's skill to a test computer). The paper's note that "an ever-growing skill set can eventually become too large to carry as external instructions, reducing its usefulness and increasing the burden on the agent" (Section 5.1) identifies this as a future problem, but no evidence establishes when or whether internalization solves it.

Hard-floor analysis: at what baseline capability level does skill augmentation stop helping? The paper's methodology assumes the work agent has sufficient baseline capability that its failures are within the "zone of proximal development"—close enough to successful behavior that an explicit skill can bridge the gap. Testing this assumption requires identifying a class of tasks or occupations where Claude Sonnet 4.6's baseline performance is very low (e.g., < 30% rubric score) and evaluating whether skill extraction from simulations in those domains produces any improvement. The occupation distribution in Figure 4 shows strong representation of management, tech, engineering, and finance professions, but minimal representation of specialized domains (Office & Admin at 0.9%, Other at 0.1%). Constructing synthetic computers for a deliberately under-represented, highly specialized profession (e.g., a veterinary radiologist, a patent attorney specializing in biotechnology, a structural engineer for offshore platforms) and running the full pipeline would test whether the methodology bootstraps from low base capability or requires a minimum capability threshold. A finding that skill augmentation provides zero benefit below some baseline score (e.g., 40%) would establish a clear boundary condition for the methodology's applicability.

Latency-compressed simulation formats: can we get 90% of the trajectory quality at 10% of the wall-clock time? The 8.59-hour serial execution time per simulation (Table 3) is a practical barrier to iterative development and online deployment. A systematic comparison of simulation formats would evaluate: (1) single-session execution (the entire month executed in one long agent session without daily context restoration), (2) parallelized independent workstreams (deliverables simulated concurrently rather than interleaved across weeks), (3) compressed collaborator latency (responses arrive immediately rather than with realistic 24–48 hour delays), and (4) shortened timescale (one week of simulated work rather than one month). For each format, the key metric is whether the resulting trajectories produce skills of comparable quality to the full 20-day sequential simulation—measured by downstream agent improvement on the same test computers. If single-session execution produces trajectories where the agent exhibits similar failure modes (cross-document inconsistency, missed collaborator feedback, context exhaustion), then the wall-clock time can be reduced substantially without sacrificing training signal quality. The 8.59-hour figure is a property of the current simulation design, not necessarily a requirement for useful trajectory generation, and quantifying the compressibility of the simulation format is essential for practical adoption.

Practical Applications and Downstream Use Cases

Pre-deployment testing and hardening of productivity agents before customer access. An organization developing a productivity agent (e.g., a "Claude Cowork" successor that operates over user filesystems for extended periods) faces a chicken-and-egg problem: they cannot test the agent on real user computers without risking data exposure or poor user experience, but they cannot harden the agent without realistic testing environments. Synthetic computers provide a deployment-safe testing substrate. Before releasing an agent update, the organization can generate 1,000 synthetic computers covering the occupation distribution of their target user base (using the persona-driven methodology from Ge et al., 2024, which the paper's authors have demonstrated at billion scale), run long-horizon simulations on those computers, and extract retrospective reports identifying the update's failure modes. The paper's finding that 900 training computers produce skills that improve agent performance on 83% of held-out computers (Figure 7) suggests that a similar-scale pre-release testing protocol would catch the majority of systematic failure modes before they reach real users. The cost—roughly 8.59 agent-hours per test computer (Table 3)—is substantial but far lower than the reputational and support cost of deploying an unreliable agent to paying customers.

Data generation for fine-tuning productivity agents on occupation-specific behavior. The paper demonstrates skill-based improvement (explicit external instructions), but the same simulation trajectories could be used for supervised fine-tuning. An organization seeking to improve their agent's performance on specific high-value occupations (e.g., financial advisors, legal professionals, management consultants) can generate synthetic computers for those target occupations, run simulations, and use the resulting trajectories—filtered for quality using the retrospective analysis reports—as fine-tuning data. The paper's finding that occupation-specific skills extracted from 900 training computers improve performance on matching test computers (Table 4) indicates that occupation-specific trajectory data contains transferable behavioral patterns. Unlike skill-based improvement, fine-tuning internalizes these patterns into model weights, potentially reducing context-window pressure and enabling more consistent application. The occupation distribution in Figure 4 provides a starting point for prioritizing which professions to target: Management & Executive (17.7%), Tech & Computing (13.7%), Engineering (13.4%), and Business & Finance (10.9%) together cover 55.7% of the persona pool and represent high-economic-value productivity domains.

Bootstrapping agent evaluations for new professional domains without human expert rubric writers. The rubric-based evaluation methodology (Section 4.2.1) requires running five simulations per evaluated computer, having a judge write draft rubrics, and merging them. This is expensive but produces evaluation criteria that are grounded in the specific computer's objectives and collaborator requirements, without requiring human domain experts to anticipate what a good solution should look like. For an organization expanding their agent's capabilities into a new professional domain (e.g., adding support for architectural design workflows or clinical trial documentation), synthetic computers for that domain can be generated, simulations run, and rubrics constructed semi-automatically using the paper's multi-run merging protocol. The resulting rubrics serve as domain-specific evaluation benchmarks that would otherwise require hiring domain experts to design. The paper's note that more advanced rubric generation methods (Liu et al., 2026; Shen et al., 2026) are orthogonal to the synthetic computer methodology suggests that this evaluation bootstrapping can become more cost-effective as rubric generation itself improves, without requiring changes to the environment creation pipeline.

When to Prefer This Method

The paper does not articulate an explicit tradeoff against named alternative methods for improving productivity agents (e.g., fine-tuning on human demonstrations, reinforcement learning from human feedback on productivity tasks, scaling model size with existing benchmark evaluations). It positions synthetic computer simulation as a substrate—a way to generate training data that was previously unavailable—rather than as a replacement for existing training paradigms. The decision rule is therefore not "prefer synthetic computer simulations over alternative X" but rather "use synthetic computer simulations when you need realistic, scalable, long-horizon productivity training environments that cannot be obtained through other means." This is a domain-scoping decision, not a method-comparison decision.

The conditions under which synthetic computer simulation is most applicable, inferred from the paper's results and limitations:

When the target task requires agents to operate over extended time horizons with state management across sessions. Short-horizon benchmarks (GDPVal at 31 turns) do not generate the failure modes (cross-document inconsistency after multiple revisions, losing track of collaborator commitments made days earlier, context exhaustion in the final week) that synthetic computer simulations surface. If your deployment involves agents working over days or weeks with evolving computer state, synthetic computer simulation provides training signals that short-horizon data cannot.
When private user data is unavailable but occupation-specific environment realism matters. Real user computers contain the files, project histories, and collaborator interactions that make productivity training data valuable, but they cannot be accessed at scale. Synthetic computers provide an approximation whose quality is sufficient to produce transferable skills (demonstrated by the GDPVal out-of-domain transfer in Figure 8).
When you have the compute budget to run thousands of agent-hours of simulation. The 8.59-hour per-simulation cost (Table 3) and the evidence that benefits scale with training computer count (Figure 7, requiring ~100 computers before meaningful improvement emerges) mean this methodology is compute-intensive. It is appropriate for organizations that can amortize the simulation cost across many deployed agents or that are developing foundation-model-level productivity capabilities where the upfront investment is justified by downstream impact.
When occupation coverage of your target user distribution is achievable within your simulation budget. If your target users span 3–5 well-represented occupations, 100–200 training computers may suffice. If they span 50+ diverse professions, the scaling trend in Figure 7 suggests you may need 500–900+ training computers to achieve reliable skill extraction across all occupations. The methodology's value proposition depends on whether your target distribution can be covered at acceptable cost.
Not when the target domain falls entirely outside the base agent's capability. The paper's methodology amplifies existing capability rather than creating it. If the base agent's performance on a class of tasks is near zero (e.g., highly specialized professions with minimal training-data exposure, or tasks requiring capabilities the base model lacks), simulation-derived skills are unlikely to help (as suggested by the chance-level performance at 10 training computers and the weaker Haiku transfer in Figure 8). For such domains, investments in pretraining, fine-tuning on domain-specific corpora, or human demonstration collection are more appropriate initial steps before synthetic computer simulation becomes useful.