LayerLens

Finance teams use business @gmail to receive vendor invoices, check billing updates, and answer payment questions. @Google’s October 9, 2026 announcement shows @GeminiApp working directly inside the inbox, inline in the email thread. As teams begin asking agents routine finance questions in email, the first checks are the same ones accounts payable staff run before a payment cycle: what is the latest invoice from a vendor, or how many bills are due this month. In a business inbox, the right answer depends on conditions inside the messages. If two separate vendors share the same business name, a question asking for a vendor's latest invoice is ambiguous unless the agent distinguishes both accounts or asks which one is meant. Acting on a single answer without resolving that ambiguity creates the risk of referencing the wrong bill. Before real use, LayerLens tests agents in a separate simulated environment to inspect how they handle these questions. Google’s Gmail announcement is topical context, while LayerLens runs its own independent simulation. This week, LayerLens is testing a simulated accounts-payable Gmail inbox containing 40 fictional invoices across 8 vendors, including how agents handle a duplicate vendor-name question for Northgate Logistics and how they count invoices due in a given month.

Accounts payable teams often need to know how many times a vendor has written in about invoices, for example before a supplier review or when a bill is disputed. In a business @gmail inbox, the vendor's emails and the buyer's replies sit in the same threads. An accurate count depends on checking who sent each message. In a simulated inbox in LayerLens Environments, an agent was asked that question and answered 8. The vendor had sent 5 of those messages; the other 3 it counted were replies from the buyer who owns the mailbox. The inbox is fictional, with 8 threads, 22 messages and 2 invoice threads with a vendor called Vantage Analytics. The exact question was "How many messages about invoices did Vantage Analytics send into this mailbox?" LayerLens saved the run's tool calls. This agent's first 2 searches tried to filter by sender: one found nothing and the other returned an error. A third search for the vendor's name and the word invoice returned 8 message IDs with no sender attached, and the agent answered without opening any of them. The exact-value check against the known answer of 5 marked it failed. A count of 8 tells whoever reads it that the vendor wrote in 8 times, when 3 of those messages came from the buyer's own side. If an agent will answer who-sent-what questions from your inbox, test it on threads where both sides wrote, and check the count against a known answer. layerlens.ai/?utm_source=x&u…

. @zachlloydtweets is right that a chain of prompts stops being enough once agents do real work. At that point you need a record of what the agent did, step by step. We ran into this at LayerLens while testing AI agents in a fake company inbox. We asked one agent how many invoices were due in May. Its search found all 6, but it opened only 5 and answered 5, with no sign it had skipped one. In a real company, that missing invoice is a bill left out of a payment run. The answer looked fine, and the saved record of every step is the only thing that showed the miss.

An agent that gets each step right 99% of the time sounds ready, yet across a 50-step task that works out to finishing only about 61% of the time. LayerLens co-founder @jrdothoughts writes about why useful AI now depends on matching the model, its inputs and its feedback to the job. His example shows how a fraction of a point per step decides whether long tasks finish, and what that means for how agents should be built. LayerLens Environments make that per-step picture visible: an agent works through a full task in simulated versions of the services it will use, with every tool call saved, letting teams see which step broke instead of only whether the task passed. The full essay applies that lens to three recent releases. Worth the read. 👇

Google describes coworker agents with their own Workspace account: email, calendar, Drive and a place in the company directory. A continuing business role comes with changing instructions and handoffs between people. Those belong in an agent’s evaluation alongside the final answer. Business @gmail is the focus of LayerLens’s current test series, using fictional records and known answers. These are separate simulations; Google’s native Workspace agent was not evaluated.

Making an agent fetch every record can be wasted work when the business question only asks for a count. LayerLens’s public @HubSpot case has two saved runs that correctly answer 8 open deals. One checks all 10 records. The other uses a correctly filtered total after receiving 1 record. Both meet the count task. Requiring individual deal records would add a condition the question never asked for. The calls and results are public: huggingface.co/datasets/Laye…

Before closing a monthly payment schedule, an accounts payable lead needs to know how many vendor invoices are due in that month. When an agent is asked to count due invoices inside a business inbox, the accuracy of the answer depends on including every matching invoice in the set. In daily work, there is no answer key, so a plausible undercount carries the risk of leaving a due bill off the monthly review. LayerLens tested this workflow in a separate simulated accounts-payable @gmail inbox containing 40 fictional invoices across 8 vendors. In a saved test question asking for the number of invoices due in May 2025, the test's known answer was 6. The agent answered 5. Because the simulated inbox uses a known set of fictional records, the wrong count of 5 instead of 6 is directly visible, while the exact omitted invoice or the underlying cause of the miss is not established by the saved result.

When you set up an agent to answer pipeline questions for your team, the first step is making sure you can trust the numbers it brings back. Looking only at the final answer is a weak test because an agent can repeat a search total without reading a single record behind it. The answer to a pipeline question depends on conditions inside the records, and a final-number grade cannot tell if the agent actually checked them. LayerLens tested this in a simulated @HubSpot account, an Environment that saves every tool call an agent makes. Across 7 runs that all passed a final-number grade, asking what the open deals were worth made the answer rest on the records: the agent listed all 8 open deals with their amounts to reach $1,268,400. The way you test should depend on what your team is doing. Teams asking for bare counts in chat need to grade the saved trace of tool calls or require a list of the counted records, and teams whose agent can write to the CRM should check that the trace shows only reads. You can read the full write-up on the blog. layerlens.ai/blog/test-case-…

We tested Ponytail, a skill for @AnthropicAI's Claude Code, on 3 of our own scripts. On fully specified tickets it passed 60 of 60 tests with 26% fewer lines. On loose, chat-style tickets it hit 17 of 22 expected features, against 21 for plain Claude Code.