Synthetic computers teach agents to work a month at a time

The big problem with today's AI agents is that we test them on tasks, but the work they actually have to do happens in context.

AI gets a new proving ground: not a task, but someone else's entire computer

The big problem with today's AI agents is that we test them on tasks, but the work they actually have to do happens in context. Not in a vacuum, not in a tidy sandbox holding a couple of files, but in real digital mess: folders, stale versions of documents, spreadsheets, email, drafts, inconsistent file names, notes from colleagues, forgotten attachments and deadlines stacked on top of each other. That is where the magic of a polished demo falls apart.

The authors of Synthetic Computers at Scale for Long-Horizon Productivity Simulation propose an ambitious move: if real work computers are off limits because of privacy and the cost of collecting the data, then synthesize them. Not individual documents, but whole user environments — with a file system, professional artifacts, a history of past work and a month of tasks ahead. Then run long simulations inside them, where the agent has to do more than write something: it has to actually live on that computer — hunt down the right files, talk to colleagues, fix its own mistakes, assemble a package of materials and carry the job through to a result.

The idea sounds like the next logical step after toy benchmarks. More importantly, the authors show that experience mined from these simulations really does improve how agents behave.

What the researchers actually built

The paper's core idea is to build synthetic computers: plausible user environments assembled from a persona. A persona is a description of a person — profession, years of experience, working style, the documents they typically handle, their tools, their habits for organizing files. From that seed the model expands a detailed user profile, then builds the contents of that person's computer.

This is not random generation of a Documents folder. First the rules for the user are fixed: how they name files, where they keep working material, how tidy they are, whether they like versions such as _v2_ and _FINAL_, whether everything lands on the desktop or gets sorted by project. Then the file system is planned from that profile: which directories should exist, which files sit in them, which ones are related, and which document grew out of which.

An important detail: the files here are not independent. A forecast spreadsheet can be built from a downloaded report, a deck from that spreadsheet, a final PDF from a draft. The researchers are modeling not just a pile of files but a work history, in which artifacts depend on one another.

Then two agents take over. One sets the goals covering roughly a month of work for that particular user. The other plays the user and has to carry the tasks out inside the synthetic computer. This is no longer "summarize this report" but something closer to: rebuild the updated financial model, prepare a deck for the investment committee, work through colleagues' comments, produce the final PDF and clear the package with a stand-in compliance team.

What a synthetic computer looks like

The strongest part of the paper is its attention to mundane realism. The researchers do not stop at generalities about "professional files"; they assemble environments with real substance. In the financial adviser example, the disk holds forecasts by asset class, client files, drafts of investment memos, scenario-analysis spreadsheets, decks, PDF reports, data pulled from outside sources and even Excel macros.

The artifacts themselves do not look like placeholders either. The authors go out of their way to show that these are working documents and spreadsheets, not empty files with plausible names. For some of the public material the system tries to download the real documents from the web; when that fails, it synthesizes them. The rest are produced by an agent equipped with tools for generating office formats.

Why does this matter? Because an agent's productivity in real work is not limited by the quality of its prose alone. It has to hold a long chain of dependencies: where a number came from, which version of a document is current, who asked for a particular edit, where the source file sits, what has already been promised to the client, and what cannot be changed without sign-off. That kind of context is almost always stripped out of short tasks, and it is exactly what decides whether long work succeeds.

Long simulations instead of short tasks

Once the environment exists, the most interesting part begins: the agent gets not one task but a full slate of work commitments spanning 20 working days. And the goals are tied to that specific computer and that specific user. For a senior financial adviser, the work involves updating model portfolios, onboarding a new client, memos, compliance and internal committees. A different profession, a different script.

What makes it especially valuable is that the authors model collaboration. The simulation is populated with colleagues, managers, clients and outside counterparties. Each has a role, a communication style, its own knowledge and sometimes private material the agent can obtain only by interacting. That pulls the task much closer to real work: not everything is known up front, some information has to be requested, clarified, received late and folded into the process.

The average simulation really is long: 2,272 turns and 8.59 hours of agent time per run. That is nothing like the usual benchmarks with 10–30 steps. Over the course of a run the agent plans a week, then works through the tasks day by day, reads files, creates new ones, edits existing ones, writes to colleagues and reacts to their replies.

That is a real shift in how the problem is framed. What gets measured is not only whether the model can solve a problem, but how it operates across an extended process: whether it can hold state, correct course, use outside material and keep hold of a project's thread after hundreds of steps.

The scale of the experiment, and what came out of it

The authors built 1,000 synthetic computers with different personas. Before the simulation, one such computer held 111.6 files on average; after a month of work, 197.4. The agent was not just producing a final document, it was genuinely growing the working environment with new artifacts.

The file mix is telling too: formats such as DOCX, XLSX, PDF and PPTX accounted for 67.8% of everything on disk. That is a good sign — the environment really does resemble office productivity work rather than an abstract heap of text.

For quality the authors did not settle for subjective impressions. For 100 of the computers they wrote detailed rubrics and scored the results against many criteria: whether every required file exists, whether numbers agree across documents, the quality of the argument, whether colleagues' requirements were met, whether formatting is correct, and so on. Most results landed in the 60–80% range of the maximum. Which means the agent can already cover a good part of the distance, but it is a long way from a dependable office worker.

This is probably the most honest part of the work. The authors show not only the wins but the characteristic failures. The appendix walks through a real simulation where the agent broadly coped yet committed the classic disaster of long work: it lost consistency across documents. Numbers in the spreadsheet, the PDF and the deck began to drift apart. In places, colleagues' comments were never incorporated. In others, empty messages sat where replies should have been. A very recognizable pattern: not fatal stupidity, but an accumulation of small inconsistencies, which is what most real work errors are made of.

Can this experience make agents better

The most practical thing in the paper is not the simulation itself but the attempt to turn it into a self-improvement loop. After every long run the researchers do a retrospective: what the agent got right, where it went wrong, which repeated failures are characteristic of a given profession. Out of those signals they build "skills" — external instructions and rules of behavior for agents of a particular type.

For financial analysts, such a skill might include rules like: keep a single source of truth for numbers, never change methodology without propagating the edit to every dependent file, check that the deck, the memo and the model do not contradict each other, and track compliance requirements and document versions separately.

On a held-out set of 100 new synthetic computers, these skills made a visible difference. The average score rose from 61.6% to 68.6%, that is by 7 percentage points. In pairwise comparisons the improved agent beat the baseline in 83 cases out of 100.

More interesting still, the transfer worked outside the authors' own environment, on the external GDPVal benchmark with 220 tasks. Those tasks are much shorter and built differently, yet the skills extracted from long simulations improved results all the same. That is an important signal: the model is not just learning to play this one simulator, it is absorbing more general work patterns.

Why this work matters

There is a lot of noise around agent systems right now, and nearly all of it runs into the same wall: short scenarios look convincing, while long work breaks memory, structure and execution discipline. This paper aims straight at that sore spot.

Its main contribution is not one more benchmark. The authors propose infrastructure for the next stage of agent development: scalable generation of work worlds where long behavioral trajectories can be collected safely and in bulk, without touching private user data. If this really does scale to millions of personas and computers, a new source of training data appears — not answers to queries, but entire histories of professional work.

That matters for industry and for research alike. For industry, because real corporate scenarios are almost always bound up with a file system, document versions and dealing with people. For research, because here you can study not only the final answer but the process: planning, navigating the environment, using files, handling feedback, recovering from mistakes.

The approach has no shortage of limitations, of course. Synthetic computers are still far tidier than real ones. Colleagues in the simulation are reactive rather than autonomous. Document formatting can be monotonous. But that reads as a roadmap, not a verdict on the method.

The takeaway

Synthetic Computers at Scale is one of those papers that looks less impressive than the next loud model release but may end up meaning more. It argues for treating agent training not as a set of isolated tasks but as immersion in a realistic working environment, with all of its mess, history and dependencies.

The paper's main conclusion is a simple one: if we want agents that genuinely help with productive work, they need to train not on sterile prompts but in worlds that look like our own computers. And the longer, messier and more realistic that experience is, the better the odds the model learns not only to answer well but to carry hard work through to the end.