One expense file, five stops, four runs

A cleaned spreadsheet looks finished. That is the danger. If the agent quietly fixed an ambiguous date or merged two conflicting rows, the result looks more confident than the data allows. The better question to ask of a run is what it left unresolved, and why.

The recorded run

On October 13, 2026 we ran a bounded trial in local Codex (GPT 6.1 Sol, high setting). The input was a synthetic expense CSV with 14 data rows. It was not real data. The receiver had earlier done a different weekly task. It had seen no spreadsheet answer and no designed example for this one.

The instruction asked for three outputs:

• cleaned.csv
• exceptions.csv
• reconciliation.md

All original fields and the original row order were retained. The agent added normalized fields beside them. Leading-zero IDs were preserved in the CSV. We didn’t test importing the file into any app.

The seven exceptions

The agent flagged seven rows, by source row number: 6, 7, 8, 9, 10, 13 and 14.

Scroll sideways to compare columns.

Source row	Recorded issue	Treatment / unresolved decision
6	Exact duplicate of row 5	Retained; later occurrence excluded by the supplied rule. No new decision needed.
7 and 8	Same ID 001006, USD 120 vs USD 140	Both retained and excluded; confirm the valid amount or explain the records.
9	Date 03/04/2026	Confirm date locale; no normalized date inferred.
10	Amount 95, currency blank	Confirm currency; no currency inferred.
13	Amount TBC	Supply the invoice amount; no zero substituted.
14	Amount 1.234,50	Confirm locale and value; no numeric value inferred.

The exceptions include both rule-based treatment and unresolved values. They are not seven new human decisions. Notice what that means for the totals.

The sums, and how far to trust them

Seven rows were clear, and seven were excluded. The agent reported:

• USD 1,375.49 from rows 1, 2, 4, 5 and 11 (1250 + 85.50 + 19.99 + 65 − 45)
• EUR 420 from rows 3 and 12 (240 + 180)
• No combined currency total; the brief did not authorize currency conversion

These are scoped sums over the rows the agent could defend. They are not accounting truth. Row 5 is in the USD sum, and row 6, its exact duplicate, is held out. That treatment follows the supplied duplicate rule and requires no new decision for this cleanup. The scope statement does the honest work. It says what the number covers and what it doesn’t.

A separate parser check, outside the agent’s own report, compared the original cells and row order between input and output. That is the kind of check we’d suggest you add. An agent saying “originals retained” is a claim. A script comparing cells is evidence.

The public record includes the exact instruction, synthetic input and saved files. We did not test payment, live writes, sending, shared storage or other providers. We didn’t time the run or compare models.

A shorter counterexample, where it went wrong first

We also ran the weekly manager update pack. A fresh agent got only the instruction and a synthetic input. Our review of its output found an ambiguity. The input held due dates and completion dates, and the output blurred them. A reader could not tell what was planned from what was done.

We tightened the instruction and the same receiver reran it. That is a repair loop run by us, on our own pack. It is not an independent second review, and it isn’t an unbiased before-and-after study of models.

The final run kept the mid-period snapshot and the later events distinct. It also surfaced:

• a missing owner
• blocked access
• conflicting review dates (October 14 vs October 16)
• a report approval gap
• a privacy issue found only in the notes
• completion dates that were unknown

It saved a Markdown update and a source map. We did not test Word output, pagination, any one-page guarantee, other providers, sending or recurring runs. The weekly-update record has the details and saved output. The task pack contains the reusable instruction.

The review exposed an ambiguity, and the instruction was repaired. This trial does not establish whether the initial behavior was caused by the instruction, the model, or their interaction. Inspecting the output gave us a specific repair to try.

The instruction you can reuse

Paste this into your own environment, adapted to your file:

Work on a copy of the CSV. Keep every original column and the original row order. Add new columns for normalized values; never overwrite originals. Preserve IDs as text, including leading zeros. Do not guess dates, currencies or number formats when the locale is unknown. Instead, write the row to exceptions.csv with source row number, the problem, and what you would need to resolve it. Report subtotals only for rows you included, state which rows were included and excluded, and do not combine currencies without a supplied rate. Finish with a short reconciliation.md listing counts in and out.

A practical check

• Confirm that the row count of included plus excluded equals the original.
• Spot-check three IDs for leading zeros in the raw file, not in a spreadsheet app, which may strip them.
• Re-add one subtotal by hand from the listed rows.
• Open each exception and decide who owns the answer.

The CSV Inspector runs in your browser and finds structural problems, such as ragged rows and odd quoting. It does not judge business accuracy. It can’t tell you that 140 was the right amount.

Scope and sources

Limitations. One synthetic file, one environment, one day. Fourteen rows is small. We can say how the agent behaved here, not how it behaves on your data. Parser validation covers cells and order only.

Next task: Run the spreadsheet pack, then inspect an export in your browser. Continue to handing over recurring work when the task is ready to repeat.

Exact evidence. Read the input and duplicate rule, exception log, reconciliation and weekly output. All describe synthetic work recorded October 13, 2026.