Say the payment run is tomorrow. During today's review, someone asks an inbox agent in business Gmail three questions: the latest invoice from a vendor, the current amount on an invoice that was corrected, and how many invoices are due next month. Each answer gets pasted into the review sheet.
Confirming that an amount appears somewhere in the inbox leaves other conditions unresolved. It does not establish the intended vendor, the message supporting the current amount, or whether an invoice count is complete. The examples below include failed answers and a passing answer whose source attribution remains uncertain.
This article sets out three checks a reviewer can run instead, each tied to a simulated case LayerLens has examined. The checks are a proposed review method. No new tests were run for this article.
Resolve the vendor
The problem. Supplier names overlap. A parent company and a division, or two unrelated firms with similar trading names, can both answer to the short name staff use day to day.
The effect. An answer that picks one of them without saying so can put one company's amount next to the other company's account in the review. Nothing in the answer signals that a choice was made.
What a simulated case showed. In a simulated accounts-payable Gmail inbox of 40 fictional invoice threads across 8 vendors, "Northgate Logistics" matched 2 distinct vendors. Northgate Logistics Group's latest invoice was $13,150; Northgate Logistics Laboratories' was $6,500. One failed answer read: "The most recent invoice from Northgate Logistics is for $13,150 USD." The figure existed in the fixture. The problem was the second vendor it left out. The task rubric gave full credit for naming both vendors with each latest amount labeled, or asking which vendor was meant, and in 8 of 20 reported answers across 5 agents, the agent gave $13,150 without doing either. That tally comes from the test's source sheet and has not been independently rebuilt.
The check. Keep a list of overlapping vendor names and test the agent against it. When a request leaves multiple vendors in scope, require an answer that names the matching vendors and labels each latest amount, or asks which vendor was meant. Merely selecting one vendor does not resolve the ambiguity.
Trace the current amount to its message
The problem. Invoices get corrected inside email threads. A supplier sends one total, follows up with a revised one, and someone on the buyer's side may repeat it in a confirmation.
The effect. Using a superseded amount could lead to an incorrect payment if other checks do not catch it. This is a possible consequence, not an observed payment outcome.
What a simulated case showed. A published LayerLens test case used a different fictional mailbox, with 8 threads and 22 messages. An invoice began at $10,475, the supplier corrected it to $10,625, and the buyer later repeated $10,625 in a confirmation. In one saved attempt, the agent answered with the corrected amount and passed a check that looked for the number. Because $10,625 appeared in both the correction and the confirmation, that pass could not establish which message the agent relied on. The example did not validate a live accounting record or execute a payment.
The check. Ask for the amount presented as payable and the message that supports it, then open that message. Keep earlier amounts mentioned for context separate from the one being paid. Grading the cited source as well as the number is a proposed follow-up; it has not been run on that example.
Reconcile the invoice count
The problem. A monthly count depends on what gets counted. One invoice can generate a reminder, a correction and several replies, and a message that mentions a month is not necessarily an invoice due in it.
The effect. Relying on an undercount without checking the underlying set could leave a due bill outside the review.
What a simulated case showed. In the 40-invoice inbox, a question asked how many invoices were due in May 2025, with the number only. The known answer was 6; the saved agent answer was 5. The result screen recorded 10 tool calls and a failed exact-value grade. A later review of that same saved trace identified INV-2025-0016, due 17 May 2025, as the only one of six May invoice threads returned by search that it did not open. Why the agent stopped remains unknown; this was not a new agent run.
The check. Before asking, write down the expected set: invoice numbers and due dates for every bill in the month. Compare the agent's total with that list, not with a sense of what seems plausible. When they differ, compare the list with what the agent searched for and which records it opened. Checking only the records an answer names cannot show that nothing is missing, and a count of matching messages is not a count of qualifying invoices.
Keep a review record
Each check produces something worth writing down, so the next reviewer can see what was settled and what was not. A record for the May case, incorporating the later review of the same saved trace, would look like this:
- Question: How many invoices are due in May 2025?
- Known answer: 6
- Agent answer: 5, after 10 tool calls, failed the exact-value check
- Still open: why the agent stopped after five of six returned invoice threads
- Later trace review: six May invoice threads appeared in search; five were opened; INV-2025-0016 was not. This located the omission, not the reason for stopping
- Proposed decision: do not rely on the agent's count until the discrepancy has been resolved
The same shape works for the other two checks, with the vendor named or the message cited recorded next to the answer.
Limits of the examples
The Northgate rule checked whether an answer made ambiguity visible, not whether it guessed an unstated intention. The May grade, by its own description, looked for 6 in the final-answer line; it establishes a wrong total, not a validated counting process. The corrected-invoice pass established the number, not the source.
All three are simulated cases with small samples. They are evidence about those tests, not a general failure rate, a model ranking, a test of Gemini in Gmail, or a substitute for a team's live accounting checks and payment authorization. What they do support is the order of operations: decide what the answer must settle, then check that it settled it.