Sales teams can now connect an AI agent to HubSpot through its remote MCP server, a standard connection point for AI apps. It lets an agent read and update contacts, companies and deals, and it powers HubSpot's connectors for Claude, ChatGPT, Gemini and Copilot. HubSpot pitches it for plain-language summaries of where deals stand, and the simplest is a count of open deals.
Most agent tests check that answer and not how an agent reached it. ClawTrack, a July 2026 study of 21 models, found that most benchmarks judge only final outcomes and named result verification as the systematic bottleneck. An earlier audit found TAU-bench counted empty responses as successes.
A deal count shows how a right answer can hide a weak route. HubSpot's search returns a total of matching deals plus 1 page of the deals themselves, up to 200 at a time. An agent can answer from the total without reading a single deal. A grader that checks only the number cannot tell, and in production there is no answer key to check it against.
LayerLens tested this in a simulated HubSpot account with 10 deals, 8 of them open. 2 agents ran the same search and got back a count of 8. Agent A then pulled all 10 deals and confirmed the count before answering; agent B answered 8 without checking. Both were right, and both passed.
Setup
LayerLens Environments are simulated versions of the services an agent works in. This one is a sales team's HubSpot account with fictional companies and deals. Agents get 20 read-only tools modeled on HubSpot's API, the interface other software uses to reach HubSpot.
Both agents got the same generic instruction: use the tools, then end with 1 line stating the answer, in the form ANSWER: <answer>. The task:
How many deals in Northwind Systems's portal are open (not in a closed stage)?
A portal is HubSpot's word for a company's account. A deal is a potential sale, and each sits in a pipeline stage; won and lost stages count as closed. The known answer, 8, was recorded when the task was written. The task has run once on each of 7 foundation models, the AI models agents run on, and all 7 passed. Their traces, the saved record of every tool call and response, show how 2 of them reached 8.
Results
- Tool calls: agent A, 3; agent B, 5
- Deal records read: agent A, 1, then 10; agent B, 1
- Where its 8 came from: agent A, reported total, then 8 of 10 deals in open stages; agent B, reported total only
- Next page fetched: agent A, no; agent B, no
- Grade: agent A, pass; agent B, pass
Agent A read the pipeline, which has 7 stages with Closed Won and Closed Lost flagged closed. It then searched for deals not in those 2 stages, with a page size of 1, and got back 1 deal and total: 8. It checked that number with a second search that listed 10 deals and their stages: 8 open, 1 won, 1 lost.
There are 8 open deals out of 10 in total. [...] I searched for deals in any other stage and got 8. I then listed all 10 deals to check. Of those, one is Closed Won and one is Closed Lost, which leaves 8.
Agent B searched twice for a company named Northwind Systems and found none, read the same pipeline and listed the account's 2 owners. Its only deal search used the same filter and page size of 1, returned 1 deal and total: 8, and was its last call.
Based on the deal pipeline stages (Closed Won and Closed Lost are the only closed stages), searching all deals in the portal that are NOT in those stages returns a total of 8 open deals.
The grader compared each final line, ANSWER: 8, with the known answer and logged the same reason for both: looked for "8" in the agent's final-answer line. Nothing above that line, including the tool calls, entered the grade.
The other 5 runs were read from their final answers only: 1 lists all 8 open deals by name, 2 describe 10 deals with 2 closed, and 2 give the number with little or no account of how they counted.
Limits
Agent B's answer rests entirely on its search filter. Here the answer key confirmed the filter; in production nothing would. Agent A's second search would expose a bad filter, though only among deals with a name.
This is 1 run per model on 1 small account, with every deal on 1 page. It does not show how often either model takes either route, or how either behaves on real HubSpot data. Neither agent found a company record named Northwind Systems; agent B's only link to it was 2 owner emails at northwind-systems.example.
Next tests
Neither has been run.
- A larger account. Past HubSpot's 200-deal page limit, for example 300 deals with 250 open, a count built from records has to follow the next-page cursor. The trace shows whether it did.
- A grade on the route. LayerLens graders can evaluate saved traces against a rubric, a written set of pass conditions. A rubric that passes a count only when it matches deal records it read would separate agent A from agent B with no new runs.
Method
Both runs are saved product runs from the LayerLens development environment, read end to end from their traces: every tool call and response, the final answer and the grade record. No runs, regrades or task changes were made for this post. The simulation copies the format of HubSpot's search responses, nothing more. Both traces are published verbatim, with the grade records and a script that recounts the deal records each agent read, in a test pack on Hugging Face.
LayerLens Environments simulate HubSpot, Salesforce, Gmail and other services. Teams test agents there against known answers before go-live and after every change. See how Environments work.