TL;DR
RunningTab (as in a bar tab, a running account) is a wrapper around an agent that works on a folder of files through a terminal. Next to the agent, the environment keeps a separate record of the task outside the context window. It holds three lists: requirements (what the task asks you to include), a read log (verbatim excerpts of files that were read, with a pointer to the source) and candidates (files that showed up in a listing but were never opened). The agent writes the requirements itself at the start. The environment collects everything else automatically, and before the agent hands in the work it gets back everything still left open.
The headline finding: the agent loses not only the files it never found. It loses what it already read. A number appeared in the terminal output at step 5, by step 40 fresh observations had pushed it out, and it never made it into the report. On a weak model, more than half of the lost points are extraction errors: the right files were opened, but their content is missing from the report or garbled. Roughly one in five numeric values that the agent saw and that the report needed never reached the final result. The model does not keep this ledger in its head, and the context does not keep it either.
The core of the method: the ledger is kept by the environment, not the model. The model only states the requirements and closes them with a pointer to a specific piece of what it read (or writes down why the data is not there). Any attempt to finish with open items hands the list right back.
Want this for your own case? Apply this study to your task: AI adapts its method to what you are working on and writes the prompt.
Method Blueprint
STEP A: At the start the agent adds requirements (add) → one item per fact/number/section
STEP B: The agent works as usual → the environment ITSELF writes the read log and the list of unread files
STEP C: After exploring, the agent calls list → sees every open requirement
next to matching read-log excerpts and unread files (BM25 ranking)
STEP D: The agent closes a requirement (resolve) → done (pointer to a read-log entry)
or unavailable (reason)
STEP E: The agent tries to finish → the environment returns all open items once (finish check)
The key point: the ledger lives outside the context and outside the working folder. To every terminal response the environment appends a status line: how many requirements are open and how many entries the log has.
Example in Practice
Task: The owner of a bakery chain in Portland asks an agent (Claude Code or Cursor) to put together a quarterly summary for a business partner. The folder holds 12 monthly exports from Toast POS, a pitch deck for the bank, notes from team meetings and lease agreements. The summary needs four things: quarterly revenue, average ticket, headcount, and the lease term for the location by the train station. These facts are scattered across different files. By step forty the agent will have forgotten half of them.
Prompt:
Task: build a summary for the partner in summary.docx from the files in /workspace.
Work with an external ledger in the file TAB.md. Rules:
1. FIRST, before reading any files, write a REQUIREMENTS section in TAB.md:
r1 — quarterly revenue
r2 — average ticket by month
r3 — headcount at the end of the quarter
r4 — lease term for the location by the train station
(add your own if the task implies other items)
2. Every time you read a file, immediately append an entry to the READ LOG section:
L<number> | file path | command | verbatim quote with the needed value.
Do not paraphrase, copy as is.
3. Every time a file shows up in a listing but you did not open it,
add it to the CANDIDATES section. Remove it from there once you open it.
4. After exploring and BEFORE writing the summary, open TAB.md and for every
open requirement choose: done (pointer to entry L<number>)
or unavailable (why no file provides it).
For open requirements, check CANDIDATES first.
5. Before you finish, reread TAB.md. If there are open items,
do not end the work: close them or explain why.
Result: The agent will first create TAB.md with four requirements and, as it works, keep adding quotes with file paths to the log. Before writing the summary it will walk through every item and tie it to a log entry. At the end it will check itself against the file. You get the docx plus a TAB.md that shows in a minute where every number came from and what the agent marked as "not found".
Why It Works
The weakness. In normal agent work everything lives in the stream of observations. What the task asks for, what has been read, what merely flashed by in a listing — all of it slides down the context and gets pushed out by new output. The link "requirement → file where it gets closed" exists nowhere. So the agent can open the right annual report, pull the number and hand in the work without it.
The strength. The model is good at breaking a task into items and good at matching an item to a quote, as long as the quote is right in front of it. The environment, on the other hand, sees every read and every file listing and forgets nothing.
How the method uses this. The model states the requirements, because only it knows them. Everything mechanical (what was read, what was not opened) is collected by the environment. As a result the agent always has a record to lean on, and an item can only be closed with a pointer to a real piece of text. The authors write that most of the gain comes from the environment recording what was read on its own, and the benefit grows with how much the agent reads.
Control levers: - Number and granularity of requirements: one item per fact, number or section. The finer, the fewer losses, but the costlier the bookkeeping. - Verbatim quotes instead of paraphrase: paraphrasing reintroduces distortions. - Closing rule: "only with a pointer to a log entry" rules out "closed it from memory". - Final check: "do not finish with open items" is the main safety lever. - Status line in every response: reminds the agent of the ledger's state. In the manual version this becomes the rule "reread TAB.md every N steps".
Prompt Template
The accessible part of the paper does not quote the system block itself: the authors only describe that it asks the agent to start with add. Below is a reconstruction of the structure from the description. It keeps every entity and operation of the method, but the ledger is kept by the model itself, not the environment (see "Limitations").
<Role>
You work with a folder of files and assemble the final document {document_type}.
You keep an external ledger of the task in the file {ledger_file_name}. This file is the single source of truth
about what is needed, what has been read and what has not been opened.
</Role>
<Tab>
<Requirements> # what the task requires to include: one item = one fact/number/section
<ReadLog> # what was read: L<number> | path | command | verbatim quote
<Candidates> # files seen in listings but not opened
</Tab>
<Operations>
add(requirements) # at the very start, before reading files
list() # show open requirements next to matching ReadLog entries and Candidates
show(L<number>) # reread a log entry without reopening the file
resolve(r<number>, done, L<number>) # close with a pointer to an entry
resolve(r<number>, unavailable, reason) # close with a reason
</Operations>
<Procedure>
1. add: break the task "{task}" into requirements: one item per fact, number, section.
2. Work as usual. After EVERY file read, append an entry to ReadLog (verbatim quote, not a paraphrase).
If you only saw a file in a listing, add it to Candidates; remove it once you open it.
3. After exploring and BEFORE writing the document, call list: for every open requirement
look at the matching ReadLog entries and unread Candidates.
4. resolve:
- done — only if a ReadLog entry contains content that answers the requirement
- unavailable — if no file provides it (for example, the value has to be computed or written); give the reason
5. FinishCheck: before you finish, call list. If anything is still open, do not finish:
close it or explain the reason.
</Procedure>
What to fill in:
- {document_type} — a summary, report, brief, sales proposal.
- {ledger_file_name} — for example, TAB.md.
- {task} — the original wording of the task with all the details.
🚀 Quick start — paste into the chat:
Here is the RunningTab template (an external ledger of requirements and reads). Adapt it to my task: [your task].
Ask me questions to fill in the fields.
[paste the template above]
The LLM will ask what document you need, which files it is assembled from and which facts it must contain. It needs this to break the task into concrete requirements, because the whole method starts from that list. It will take the structure from the template and tailor the contents to your task.
Limitations
⚠️ Needs environment scaffolding: The method works because the record is kept by the environment, not the model. That has to be programmed: intercept terminal output, separate "read" from "seen in a listing", append the status line. You cannot switch this on in a regular chat or in Claude Code out of the box.
⚠️ The manual version is weaker than the original: If you ask the model itself to keep TAB.md, it will skip entries and close items "from memory". That is exactly the variant the authors used as a weak baseline ("the model keeps the record"), and it lost. The difference is that a file outside the context does not get pushed out. But all the discipline rests on an instruction, not a mechanism.
⚠️ Only a specific class of tasks: The method is about assembling a document from many files over many steps. For a short question whose answer sits in one file it is overkill and adds cost.
⚠️ Does not fix comprehension errors: If the agent misread a table or mixed up units, the record will simply preserve the wrong quote. The method fights losing what was found, not misinterpreting it.
⚠️ Not all of the text was checked: The accessible part of the paper cuts off before the results. I have not given the size of the gain or the ablation details here; they are not visible.
How They Tested It
First the authors dug into where a regular agent loses points. They took a simple terminal agent on a small model (GPT-5.4 nano) and ran it on 100 work tasks from Workspace-Bench three times each. Errors were classified by LLM annotators that agree with humans at a Cohen's kappa of 0.83. It turned out that just over half of the lost points (51.1%) are extraction errors: the right files were opened, but the content is missing from the report or distorted. 12.3% are "shown to the agent but missing from the report". Another 17.6% are files that were not found or not opened. A check on the numbers showed that about 20% of the values the agent saw and that were needed never made it into the final result. This flips the usual explanation "the agent did not find the file" and makes the case for an external ledger. Next, RunningTab was tested on three benchmarks with three models. It improves results in every case compared with plain terminal work and with variants where the model keeps the ledger itself. Ablations showed that the main contribution comes from the environment automatically capturing what was read, and the benefit grows with the volume read. The practical takeaway: whatever the model can forget, you cannot trust that same model to remember.
Adaptations and Extrapolations
🔧 Technique: a manual final check → instead of keeping the ledger along the way
If the agent will not follow the rules throughout the whole job, add only the last step as a separate message after it says "done":
Before handing in: reread the original task and build a table "requirement → where it appears in the document → which file it came from (path and quote)". List every item without a source or without a place in the document separately, and close them.
Effect: you get the equivalent of a finish check without keeping a log. It will catch missed facts, but it will not bring back the ones the agent can no longer find.
🔧 Technique: verbatim quotes → instead of paraphrasing in notes
Ask the agent to copy values as is, together with the command that showed them. Effect: fewer distortions when moving them into the document. It is the same "store the excerpt, not a summary" logic as in the original.
Extrapolation: a task ledger as a CLAUDE.md-style file
For Claude Code you can put a rule in CLAUDE.md: "for tasks that assemble a document from ≥5 files, start with TAB.md in the format below; do not finish while it has open items". It will not replace the environment, but it moves the discipline into a standing instruction, so you do not have to repeat the prompt every time.
Resources
- Paper: RunningTab: Direct Workspace Interaction with Environment-Side Tabs
- Authors: Jinheon Baek, Soyeong Jeong, Yumin Choi, Dongsu Han, Sung Ju Hwang — KAIST, DeepAuto.ai
- Related work cited in the paper: direct corpus interaction (Li et al., 2026b); Workspace-Bench (Tang et al., 2026); GDPval / OfficeBench-style work benchmarks (Xu et al., 2025a; Patwardhan et al., 2025); Magentic-One (Fourney et al., 2024) as an example of a task ledger written by an orchestrator model.