RunningTab: Direct Workspace Interaction with Environment-Side Tabs

What it claims

Agents that build deliverables straight from a file workspace mostly fail after they have already found the right files, not before. In a diagnostic run, DCI (plain direct corpus interaction) with GPT-5.4 nano on Workspace-Bench (100 tasks, three runs) lost 51.1% of its rubric points to extraction: the right files were opened, but the deliverable lacked or distorted their content. Another 17.6% went to discovery, where the right files were never opened, including files that were listed but not opened. Of the 891 distinct rubric-expected numeric values that appeared in the agent's observations, 19.8% never reached the deliverable. RunningTab addresses this with a record kept by the environment, not the model. The authors report that it beats plain DWI and model-kept-record baselines in every benchmark × LLM combination.

How it works

The tab lives in the loop that runs the model and its tool calls, outside the context window. The agent writes only one part of it.

• Requirements: the agent adds one per fact, figure or element the task asks for.
• Read log: the environment captures every file read automatically, as an excerpt plus its provenance anchor (e.g. L1 patents: 3 — annual.pdf).
• Candidates: the environment records every listed-but-unopened file and ranks it by relevance to the task.
• Review: shows each open requirement beside its best-matching read-log excerpt and its top unopened candidates.
• Resolve: closes a requirement in one of two ways. It is marked done only by citing a read-log entry whose content matches it, or set aside with a stated reason.
• Finish check: if the agent stops with requirements still open, the environment returns them once. In the paper's example, the missing fact was already in the read log, so the agent closed it without re-searching.

The difference from Magentic-One-style progress ledgers and self-written notes is ownership. In those systems a model writes the record and marks items complete. Here the environment writes the evidence, and completion must cite captured content.

flowchart TD
  A[Agent adds requirements] --> B[ls / read files]
  B -->|env auto-records| T[(Tab: read log + candidates)]
  T --> C[Review: req vs best excerpt + candidates]
  C --> D{Resolve}
  D -->|cite excerpt| E[done]
  D -->|reason| F[set aside]
  E --> S{Agent stops: items open?}
  F --> S
  S -->|yes, once| C
  S -->|no| G[Write deliverable]

Evidence

• Setting: three benchmarks and three LLMs. The visible text names only Workspace-Bench (Tang et al., 2026). The other two are cited as Xu et al. (2025a) and Opsahl-Ong et al. (2026). GPT-5.4 nano is the only model named in the visible text.
• Failure taxonomy: the LLM annotators agree with human labels at Cohen's κ = 0.83. Extraction (51.1%) splits into Shown but Missing (12.3%) and Dropped or Distorted (38.9%). The remaining lost points are Reasoning 10.3%, Formatting 4.8% and Other 16.1%.
• Ablations: most of the gain comes from what the environment captures on its own, not from the agent's requirement bookkeeping. The gain grows with how much the agent reads. Once seen, the values a deliverable needs are usually held in the tab.

Limits

• Truncated text: the fetched page ends partway through Section 3.2. Main-result numbers, ablation tables, the other two LLMs, cost and latency overhead, and any stated limitations are not visible here. Do not adopt on the "outperforms in every case" claim without those tables.
• What it doesn't fix: RunningTab leaves file reaching unchanged. The 38.9% "Dropped or Distorted" bucket includes misread or inexact content with no evidence in the observations, which a provenance log may not catch.
• Version and code: this is v1, dated 7 Oct 2026. The visible text gives no code or release link.