Source-linked AI summary
StagedWorkspace: A Versioned Workspace for Knowledge-Work Agents
Yining Hua, Hongbin Na, Yifan Zhou, Akshay Kalose, Cyrus Ayubcha, Levi Lian
TL;DR
Knowledge-work agents can search, edit, review, and submit different versions of the same artifact, while non-coding workspaces lack an explicit contract tying these views together. StagedWorkspace provides versioned dual artifact views and review diffs, and fixed-harness ablations found improved read-axis performance across OfficeQA Pro and APEX-Agents.
Problem
Non-coding knowledge-work interfaces do not consistently tie parsed search, native edits, review, and submitted deliverables to one workspace version.
Method
StagedWorkspace binds parsed records, native operations, staged changes, review state, and submitted artifacts to an evolving workspace state using file-version hashes.
Results
Fixed-harness ablations found dual views improved read-axis performance in OFFICEQA PRO and APEX-AGENTS; Gemini 3.1 Pro rose from 29.3% to 63.9% on OfficeQA.
Takeaways & Limitations
Workspace state is an experimental variable that can affect measured knowledge-work-agent performance and benchmark comparisons.
Takeaways & Limitations
Benchmarks score final answers or deliverables rather than intermediate retrieval, synchronization, or diff-visibility checkpoints.
Abstract
from arXiv · showhide
AI agents increasingly perform knowledge work (i.e., produce and modify persistent digital artifacts such as code repositories, documents, spreadsheets, slides, reports), yet the parsed views they search, the native files they edit, the changes they review, and the artifacts they submit can refer to different versions of the same work product. We formulate this as a workspace-state contract: every view should be explicitly tied to a version of the evolving workspace state. Coding agents partly address this need through repository contracts for search, diffs, and tests, whereas an analogous contract is less explicit for PDFs, spreadsheets, slides, notebooks, and mixed-format project folders. We propose StagedWorkspace, a versioned workspace for knowledge-work agents. The workspace binds parsed records and review diffs to content hashes of the native files as they change. In fixed-harness ablations on OfficeQA Pro and APEX-Agents, dual parsed/native access has the highest point estimate for every tested model; relative to the more limiting single view, it improves OfficeQA Pass@1 by 8.3-12.1 points and APEX mean rubric score by 4.7-9.2 points. SW-AGENT scores 63.9% with Gemini 3.1 Pro on OfficeQA and 42.1 with GPT-5.4 Nano on APEX, compared with published same-model scores of 29.3% and 25.5, respectively. A paired review-axis ablation on 57 file-editing tasks further finds higher observed scores when diffs are visible. These results identify workspace state as an experimental variable in knowledge-work agents and motivate benchmarks that score evidence, staged edits, and submitted artifacts as explicit state transitions.
1 Introduction
Knowledge-work agents increasingly manipulate persistent digital artifacts, but their search, editing, review, and submission interfaces can expose inconsistent workspace versions. StagedWorkspace addresses this with an explicit workspace-state contract linking complementary parsed and native views, staged changes, review state, and submitted artifacts to one evolving workspace state.
- Motivation: Knowledge-work agents increasingly produce or transform persistent digital artifacts across coding, document, office, web, computer-use, and workplace settings.These settings share a target: knowledge work.
- Workspace-state contract: A workspace-state contract is needed because an agent may search one workbook version, edit another, and submit an inconsistent deliverable.The contract requires parsed search, native operations, review, and submission to identify the workspace version they expose or modify.
- Interface trade-offs: Artifact-only interfaces preserve native completeness but hinder search, parsed-only interfaces ease search but lose layout, formulas, or visual evidence, and unversioned workspaces lack durable review diffs.These three interface trade-offs motivate a unified, version-aware workspace design.
- StagedWorkspace: StagedWorkspace instantiates the contract by providing complementary parsed and native artifact views tied to the same evolving workspace state.It also binds parsed records, staged changes, review state, and submitted artifacts to that state.
2 Related Work
Prior work covers knowledge-work evaluation, agent retrieval, software-engineering workflows, and document editing, but no single line explicitly specifies version relations across mutable knowledge-work artifacts. StagedWorkspace builds on repository-state conventions while addressing binary, notebook, and layout-heavy formats.
- Knowledge-Work Agents and Work-Product Evaluation: Knowledge-work benchmarks evaluate activities, tested settings, and scored work products across enterprise workflows, desktop control, office automation, and longer workflows.Examples include WorkArena, WorkArena++, TheAgentCompany, OSWorld, OfficeBench, and OdysseyBench.
- Agent Infrastructure and Retrieval: ReAct, retrieval-augmented generation, and dense passage retrieval govern how agents obtain context but do not specify version relations among mutable artifacts.These methods address actions, retrieved passages, and neural lookup rather than explicit artifact-version alignment.
- Patch-Based Software-Engineering Agents: SWE-bench and SWE-agent provide the closest shared workspace-state convention through repository snapshots, test feedback, and patch-oriented tools.This convention aligns agent, evaluator, and reviewer representations of current state, proposed changes, and partial verification.
- Patch-Based Software-Engineering Agents: Binary office files, notebooks, and layout-heavy PDFs violate software agents’ assumptions of line-addressable text and exact search.These formats cannot be diffed line by line, limiting direct transfer of repository-based designs.
- Document Editing and Versioned Artifacts: Document AI and versioned-authoring research addresses only parts of the contract, spanning layout-aware question answering, localized editing, layout-grounded commands, and document-level model editing.The cited document-AI work focuses on reading scanned documents and long research papers, while other work studies editing mechanisms.
3 Methods
StagedWorkspace synchronizes parsed records, native files, and review diffs through content-hash versioning, so agents search, edit, inspect, and submit against a shared workspace state. Its turn loop refreshes affected views after mutations and supports controlled read- and review-axis ablations.
- Agent-facing views: The native workspace preserves layout, formulas, executability, and editable artifacts, while parsed views support search and evidence localization over the same evolving file state.This dual access lets agents search parsed files and then open or execute corresponding native files without crossing artifact versions.
- Workspace state contract: Parsed records, native workspace W_t, and review diff Δ_t are tied to file paths and content hashes, with W_t authoritative for execution and submission.Records whose source hashes differ from W_t are marked stale until refreshed; parsed tools read C_t, native operations read or edit W_t, and review tools expose δ(W_0, W_t).
- Workspace state contract: After each mutation batch, hash scanning advances W_t→W_t+1, invalidates affected parsed records, and recomputes C_t+1 = sync(C_t, W_t+1) and Δ_t+1 = δ(W_0, W_t+1).Unchanged files reuse prior parsed records, while changed hashes queue only affected records for refresh.
- Review and submission: Before handoff, deliverables are produced from the staged workspace state, and visible diffs let agents inspect Δ_t; journals, diffs, and traces are retained for replay and trajectory analysis.Review diffs are format-specific: text uses line diffs, spreadsheets row- and cell-level changes, slides slide-level changes, and unsupported binaries before/after previews.
- Ablation design: The read-axis ablation compares synchronized dual views with artifact-only and parsed-only access, while the review-axis ablation changes only whether tracked diffs are visible before submission.The read-axis comparison holds the model, prompt, parser, retriever, grader, file tracker, and tool budget fixed.
4 Results
SW-AGENT’s strongest results come from synchronized access to parsed evidence and native files, with dual access outperforming restricted views across OfficeQA Pro and APEX-Agents. Visible review diffs further improve APEX file-editing scores, while trajectory evidence links gains to parsed retrieval and native execution rather than workspace synchronization alone.
- Benchmark results: 63.9 vs. 29.3 Pass@1 points is SW-AGENT’s Gemini 3.1 Pro improvement over the best published Full row on OfficeQA Pro.The corresponding gains are 8.3 Pass@1 points for GPT-5.4 (64.7 vs. 56.4) and 34.6 points for Gemini 3.1 Pro (63.9 vs. 29.3).
- Benchmark results: On APEX-Agents, GPT-5.4 Nano has the largest gains: +8.1 Pass@1 and +16.6 mean-score points.Gemini 3 Flash gains +6.9 Pass@1 and +8.3 mean-score points, while GPT-5.4 improves by +1.7 Pass@1 and +0.9 mean-score points.
- Mechanism ablations: 8.3 to 12.1 points is the dual-view improvement in OfficeQA Pass@1 over artifact-only, with paired bootstrap significance for all three models.Artifact-only permits PDF access but lacks indexed evidence localization, whereas parsed-only is closer to dual on this find-and-read task.
- Mechanism ablations: 4.7 to 9.2 points is the dual-view improvement in APEX mean rubric score over parsed-only for all three mechanism models.Parsed-only agents can find instructions but cannot reliably execute on native files; dual access synchronizes retrieval with file execution.
- Review-axis ablation: 2.5 to 8.5 points is the APEX file-editing-subset score increase from exposing workspace diffs before submission.Both review-axis arms make the same file changes; only the visible arm exposes workspace_diff and workspace_file_diff, and the subset is roughly 12% of APEX.
- Mechanism analysis: Parsed retrieval and native-file execution account for most coded mechanisms across dual-win model-task instances.Trajectory review shows parsed search locating instructions and native access executing on deliverables; remaining failures often require stronger reasoning, validation, or planning.
5 Discussion
The discussion argues that synchronized artifact access and review visibility address workspace-state failures but do not eliminate planning, domain-reasoning, or rubric-following errors. It also identifies evaluation gaps and calls for broader component tests and software-engineering-style acceptance criteria.
- Findings: Artifact-state synchronization matters because agents can reason over one file state and submit another, while removing a view changes performance according to task mechanisms.The paired ablations isolate artifact access and review visibility, but large all-arm-zero residuals show that synchronization does not remove every failure mode.
- Findings: Gemini 3.1 Pro rises from 29.3% to 63.9% on OfficeQA, while frontier models change little, suggesting artifact-state access interacts with model capability.The passage interprets synchronized workspaces as recovering some performance that larger models may otherwise gain through repeated search and re-reading, while noting a possible ceiling effect.
- Limitations: Benchmark graders score only final answers or materialized deliverables, not whether retrieval, workspace synchronization, or diff visibility succeeded at intermediate checkpoints.Current rubrics omit trajectory-level mini-successes such as opening the correct source, reading the correct table region, or making a valid tracked edit.
- Limitations: 188/452 evaluated APEX tasks are all-arm zeros for at least one model and do not move under read-axis toggles, marking where state-management gains end.The remaining failures begin with planning, domain reasoning, and rubric-following errors rather than synchronization.
- Future Directions: Future work should vary agent stacks, parsers, retrievers, prompts, and human-in-the-loop review policies, then develop patch-and-test contracts and verifiers for retrieval, read-region, and edit checks.The study fixes one agent stack, parser, retriever, and prompt; proposed acceptance criteria follow software-engineering-style contracts rather than relying on traces alone.
6 Conclusion
Long-horizon knowledge-work agents can lose reliability when retrieval, editing, and final artifacts refer to different file versions. StagedWorkspace addresses this through synchronized artifact views, hash-keyed index refresh, and edit-diff exposure, evaluated in fixed-harness ablations.
- 6 Conclusion: Reliability can break when parsed caches, semantic search, and final artifacts reference different versions of the same files.This mismatch is identified as a failure mode for long-horizon knowledge-work agents.
- 6 Conclusion: StagedWorkspace formalizes synchronized retrieval, editing, and review through dual artifact views, hash-keyed parsed-index refresh, and diff exposure on edits.These mechanisms connect workspace representations and review outputs to evolving file state.
- 6 Conclusion: Long-horizon knowledge-work agents must find sources, read layout-heavy evidence, edit deliverables, and produce reviewable outputs over many turns.The conclusion frames these activities as the operational demands motivating the workspace contract.
A Implementation Details
StagedWorkspace maintains accepted files, staged operations, and three agent-facing views—native files, parsed cache, and review diffs—while enforcing version-aware updates. Its implementation adds format-aware review, transactional branching and rollback, and synchronized native/parsed sandbox access.
- Commit and Promotion Semantics: The workspace retains an accepted file tree and ordered proposed operations while exposing native files W_t, parsed cache C_t, and review diff Δ_t.Each operation records its actor, target path, base hash, type, and payload.
- Commit and Promotion Semantics: Stale operations whose recorded base hash differs from the target’s accepted hash remain pending agent or reviewer reconciliation.The hash check ties proposed updates to the current accepted version of each path.
- Commit and Promotion Semantics: Format-aware diffs provide line views for text, previews for documents and binary artifacts, row- and cell-level views for spreadsheets, and slide-level presentation views.The review surface adapts to the artifact format rather than using one universal diff representation.
- Versioned Workspace and Branches: Each agent turn creates a turn-scoped patch, human edits use lazily created human patches, and transactional commits support rollback through inverse patches.Per-user, kind-scoped branches cover chat, review, and evaluation workflows.
- Parsing, Retrieval, and Sandbox Sync: Hydrated sandbox files provide native access, Reducto-derived records and search provide parsed access, and parser outputs are regenerated on commit rather than journaled.Spreadsheet, document, and slide skill packs run inside the sandbox instead of on the first-class tool surface.
B Experimental Protocols · B.1 Agent Execution Environment · B.2 Grading Protocols and Grader Prompts
The experimental protocol standardizes agent execution, artifact-view ablations, prompting, and grading across OfficeQA Pro and APEX-Agents. Graders use benchmark-specific evidence rules, with exact answer matching for OfficeQA Pro and criterion-level artifact or response verification for APEX-Agents.
- B.1 Agent Execution Environment: Each agent turn runs in an isolated Daytona Linux sandbox with 1 vCPU, 1 GiB RAM, 3 GiB disk, and 30-second default tool timeouts.The sandbox is created on first tool use, with a 600-second maximum timeout.
- B.1 Agent Execution Environment: Agents share sandbox, inspection, search, diff, editing, and whiteboard tools, while OfficeQA Pro’s internet subset additionally permits web_search and web_fetch.Artifact-only arms disable parsed search, whereas parsed-only arms remove originals from the sandbox.
- B.1 Agent Execution Environment: All read-axis arms use the same base system prompt, isolating score changes to artifact views despite differing available tools.The prompt specifies workspace paths, parsed companions, freshness labels, tool surfaces, and benchmark submission rules.
- B.1 Agent Execution Environment: On first tool use, the workspace hydrates native artifacts and optional per-page parsed companions, with Reducto markdown, tables, media paths, captions, and vector-search chunks.Parsed views expose source, parse time, source update time, and freshness metadata; stale sources should be preferred or re-indexed.
- B.1 Agent Execution Environment: The OfficeQA Pro parsed-only and dual arms use live Reducto parsing and hash-keyed re-indexing, while the Databricks .txt corpus serves as a leaderboard-aligned baseline.The baseline concatenates parsed elements in reading order and omits figures.
- B.2 Grading Protocols and Grader Prompts: After each attempt, a separate grader session receives the original task, final response, optional changed-artifact paths, and rubric under fixed per-run model, decoding, and prompt settings.Artifact-view ablations vary only the agent artifact-view arm.
- B.2 Grading Protocols and Grader Prompts: OfficeQA Pro uses one exact answer-match rubric item, no partial credit, and Pass@1 equal to the fraction of questions receiving grader score=1.The grader may call only submit_eval_grade, and numeric answers require exact equivalence with a 0.0% allowable absolute relative error.
- B.2 Grading Protocols and Grader Prompts: APEX-Agents grades multiple pass/fail criteria using the final response and, when required, files viewed at allowed paths; a task passes only when every criterion scores 1.The grader uses google/gemini-3-flash-preview with thinking level low and follows criterion-specific evidence rules for chat, files, and hybrid tasks.
B.3 Efficiency Protocols
The efficiency protocol defines how pass rates, cost, and latency are measured across workspace-view arms. Primary paired ablation estimates remain distinct from diagnostic efficiency surfaces and secondary discordance checks.
- Pass@k and Multi-Attempt Rates: Pass@1 uses the benchmark’s mean per-attempt rate over three reruns, while Pass×3 requires all attempts to pass and Pass@any requires at least one.The public APEX-AGENTS leaderboard instead reports Pass@1 over eight independent attempts per task.
- Cost and Latency: Cost per graded completion sums logged assistant and tool-call spend at public list rates, excluding background parsing and sandbox CPU usage.Dual and parsed-only arms also omit one-time search-ingest cost, so reported costs compare in-run model spend across artifact-view arms.
- Cost and Latency: Latency is mean agent time per graded completion, measured from agent start to finish minus recorded sandbox startup time.Startup remains an end-to-end constraint, so longer per-case setup can increase wall-clock time despite its exclusion from reported latency.
- Ablation Table Alignment: Tables 3a and 3b provide the primary paired read-axis estimates, whereas cost-score panels and efficiency tables are diagnostic rather than replacements for paired intervals.Table A.3 supplies McNemar/sign tests as secondary checks on per-task paired wins and losses.
C Benchmark Selection · C.1 Early Design Probes
The study selects OfficeQA Pro and APEX-Agents because together they satisfy the workspace-focused inclusion criteria across complementary knowledge-work regimes. Early probes then motivate separating parsed search from native reads and synchronizing parsed caches with edited source artifacts by hash.
- C Benchmark Selection: The benchmark survey evaluates alternatives against whether parsed search, native reads, and edit visibility remain tied to the same hash-versioned working tree.This frames benchmark selection around isolating workspace-state behavior rather than only task or parser performance.
- C Benchmark Selection: The benchmarks target professional knowledge-work products, expose mixed-format file complexity, and require long-horizon retrieve, read, execute, and submit loops.They also provide public task pools and graders and run under identical prompts, tool budgets, and three-way artifact-view ablations.
- C Benchmark Selection: GUI-control suites are excluded as primary benchmarks because they mix UI grounding, application state, and file-state errors while under-specifying parsed-cache and sandbox-original synchronization.OSWorld, The Agent Company, and OdysseyBench remain relevant complements but do not isolate the read-axis ablation.
- C Benchmark Selection: Parsing and layout-fidelity benchmarks cannot test multi-turn agents over versioned workspaces or whether hash-keyed re-parsing keeps search aligned after edits.Parser F1 is therefore treated as insufficient for evaluating end-to-end artifact-view ablations.
- C Benchmark Selection: OfficeBench is retained only as a complement because it has shorter task chains than APEX-Agents and lacks OfficeQA’s full-corpus retrieval stress over approximately 697 shared PDFs.The selected pair covers static-corpus retrieval and cross-format deliverable rubrics without adding a third leaderboard protocol.
- C Benchmark Selection: OfficeQA Pro and APEX-Agents are selected as the closest public pair satisfying all inclusion criteria while covering complementary knowledge-work regimes.OfficeQA targets read-heavy numerical QA over a fixed bulletin library, whereas APEX-Agents targets deliverable-heavy professional folders requiring indexed search and native-file execution.
- C.1 Early Design Probes: Parsed companions are restricted to search: vector_search and grep query parsed chunks, while view reads source artifacts and rejects *_parsed/ paths.Early trajectories showed agents answering from one indexed page as though they had seen an entire bulletin.
- C.1 Early Design Probes: Static OfficeQA exports are reported only as leaderboard-aligned comparisons because they lack live PDFs, post-edit re-indexing, native execution, and hash synchronization.Headline ablations instead use live parsing with a hash-keyed cache; grep also depends on the parsed cache because it cannot search PDF bytes directly.
D Extended Ablation Analysis … D.3 Residual Failure Slice
The appendix supplements the main ablations with efficiency and parser diagnostics, qualitative trajectory analyses, and residual-failure slices. It documents when dual access outperforms restricted views and defines how all-arm-zero failures are computed.
- D Extended Ablation Analysis: The appendix retains efficiency accounting, an OfficeQA parser-sensitivity check, qualitative coding, and residual slices as supporting diagnostics for the main ablation analysis.The full three-arm read-axis ablation and paired-discordance checks are reported in Section 4.2.
- D.1 Supplementary Efficiency and Parser Checks: OfficeQA adds the released Databricks .txt export as a parser-sensitivity check, whereas APEX reports latency, cost, and tool counts without repeating main-Results scores.The corresponding efficiency tables identify latency conventions and where rubric scores are reported.
- D.2 Qualitative Trajectory Review: Trajectory coding records opened files, read cells or sections, and final-answer or deliverable content using benchmark-specific label sets.OfficeQA follows a golden-source pipeline trace shape, while APEX-AGENTS uses workbook/memo deliverables.
- D.2 Qualitative Trajectory Review: 452 evaluated APEX-AGENTS tasks include 72 where task-level best dual exceeds at least one restricted-view arm, including 27 that strictly exceed both.The appendix codes dual-win model-task instances through chat-log mechanisms rather than reproducing every trajectory checkpoint.
- D.2 Qualitative Trajectory Review: 356 dual-win model-task instances span 253 unique tasks, compared with 147 strict instances beating both restricted-view arms across 130 unique tasks.The coded instances require dual to score at least as high as both restricted-view arms and strictly beat at least one.
- D.3 Residual Failure Slice: Table A.7 counts all-arm-zero APEX-AGENTS tasks by domain among 452 evaluated tasks.All-arm zero means dual, artifact-only, and parsed-only each score 0 on the same task for at least one completed model triplet.
- D.3 Residual Failure Slice: All-arm-zero counts are computed from completed three-arm triplets, not trajectory labels.Section 4.4 interprets these residual failures, while compact dual-win traces appear in Appendix D.2.
E Benchmark Evaluation Outlook
Section 5 argues that benchmarks for stateful knowledge-work agents should make workspace-state mechanisms explicit before scoring final success. It proposes inspectable criteria over files, evidence, staged edits, state transitions, task surfaces, and verification outcomes.
- Benchmark Contract: Benchmarks should pair natural-language tasks with inspectable acceptance criteria over files, evidence, and staged edits.The goal extends beyond a better final rubric to checkpointed state-transition properties.
- Benchmark Contract: A benchmark contract should specify accepted project files, parsed retrieval state, sandbox capabilities, proposed-change operations, verification checks, and final-state authorization.These specifications include content hashes, represented document elements, admissible mutations, conflict rules, source-version requirements, pre-commit checks, and who authorizes submission.
- Task Design: Task construction should control task-surface distributions across lookup, retrieval, file editing, visual reading, and mixed evidence-to-edit workflows.Held-out or private projects should be reserved when contamination and overfitting pose material risks.
- Evaluation Labels: Useful labels include source-version correctness, retrieval-region correctness, evidence-to-edit alignment, staged-operation validity, synchronization correctness, conflict detection, format fidelity, numerical consistency, and verification outcome.These labels can separate reasoning errors from state-management errors and clarify which state-transition properties benchmark reports measured or merely exercised.
F Reproducibility, Assets, and Responsible-Release Notes
The study documents reproducibility procedures, compute accounting, asset licensing, and a planned sanitized implementation release. StagedWorkspace improves inspectability but does not ensure factual correctness, so high-stakes use requires qualified human review.
- Reproducibility Status: Experiments use original benchmark task sets, graders, and metrics, with outputs materialized through the reducer before submission.Logs retain operation journals, retrieval traces, diffs, and evidence references for replay and error analysis.
- Compute and Cost Accounting: The framework trains no new models; hosted model APIs provide inference, while local computation handles parsing, retrieval, sandboxed execution, diffs, and grading.Appendix B.3 records per-completion agent-run token charges and wall-clock agent latency at worker concurrency 1, excluding background parsing and sandbox host CPU.
- Existing Assets: Evaluation uses public APEX-AGENTS and OFFICEQA PRO assets without repackaging their data, with a planned license and terms-of-use table for released components.The table is intended to cover each benchmark, parser, and baseline implementation.
- Released Code: The planned GitHub release is a sanitized research implementation documenting workspace materialization, parsed-cache access, tool routing, staging, prompts, and benchmark submission.It does not release a new dataset, model, or high-risk pretrained model and was not used for the reported production runs.
- Responsible Use: Source hashes, tracked operations, format-aware diffs, and verification traces make artifact-modifying agents more inspectable, but they do not guarantee factual correctness.High-stakes legal, financial, clinical, and regulatory uses still require qualified human review.
- Ethics, Human Subjects, and LLM Usage: The evaluation collects no personal data, conducts no user studies, and involves no human-subject interventions; LLMs provide policy and reasoning while StagedWorkspace supplies workspace tracking and diffs.Error-mode coding concerns model traces and benchmark artifacts rather than human-subject data.