Before answering, the agent had to ask one better question.

“90%” was not enough to define the task.

The brief said card selection was at 90%, yet too few support issues were closing. It asked for an investigation, not a prototype. The records contained two cohorts, A and B, but did not say which cohort the business question concerned.

We wanted to see whether the agent would notice that gap. A model can easily calculate a rate from the rows in front of it, choose whichever cohort looks plausible and produce an answer. The harder behavior is to recognize that the intended population is a business decision the data cannot make for you.

This was a small, live-model test with ten synthetic records and an explicitly simulated PM. It also exercised a correction to the goal while the task was running. The system had to apply the current instruction and stay in research, without drifting into a PoC.

Ask about inclusion, not “more context.”

The agent read both the context file and all ten records. It found the definitions of selected cards and verified closure, but no intended cohort or time window. Rather than request an entire project brief, it asked a targeted question:

Which population should the investigation cover: A, B, both, or another inclusion rule? Should the denominator include every ticket in that population, or only tickets with a selected card?

The actual request also asked about exclusions and the observation window. That made the reply actionable: the configured PM could answer the missing decision instead of guessing what “additional information” meant.

The request was stored as a business blocker and sent through the configured local notification path. The simulated reply selected cohort A and all A tickets. A received reply was not treated as proof of the metric; the agent still had to check that the source records matched the stated rule.

Three correct numbers, three different meanings.

All five A records had selected cards. Only one had both a closed status and an explicit confirmation. The other four remained open. The agent counted those conditions together; selection alone did not qualify a record as closed.

The full-fixture 90% matched the percentage in the brief arithmetically. That did not prove it came from the same reporting period or population. The output kept that distinction instead of presenting the coincidence as a verified link to management’s report.

The agent could count the gap. It could not explain it yet.

There were no ticket ages, follow-up durations, interviews or workflow observations in the fixture. Four open records might reflect a broken process, or simply cases that had not had time to close. A snapshot cannot distinguish those explanations.

The investigation therefore kept causes, timing, later outcomes and wider representativeness unresolved. It did not turn a low closure rate into a claim about staff behavior. It did not propose a numerical improvement target. It did not build a prototype to solve a cause that had not been established.

The final note cited the context and source rows, attributed the inclusion rule to the PM reply, and separated that statement from the records used to calculate the rate. If the scope changed again, those counts would need to be evaluated under the new rule rather than reused silently.

Completion meant more than a file appearing.

The recorded probe checked seven things: completion, goal correction, research-only execution, local notification receipt, the synthetic reply, the research checkpoint and final review. All seven checks passed.

The separate reviewer inspected the inputs and ran a Python count. It confirmed five A records, one verified closure, four open records, 100% selection in A and 90% selection across the fixture. The completed run used 15 model calls. The project record also reports that reloading the completed investigation did not repeat the model work.

The note itself still included a pending-review sentence because it was written before the checkpoint. The later verification record establishes completion; the sentence in the artifact is not the final status. This is a small but important reason to read execution records alongside the report.

No real PM was contacted in this test. The local notification and the injected reply exercised the workflow; they do not demonstrate a deployed Slack or email integration. The result supports the tested behavior: stop for a missing business decision, apply the reply, verify the relevant records and stay within the current goal.

Now ask why those four records were still open.

Once the scope was settled, a useful follow-up became possible: trace those four records through time. Were customers waiting for a response, had they already confirmed a resolution, or had the same problem reopened? Each state calls for different evidence.

That follow-up would need timestamps and workflow history. Until then, the honest deliverable was a verified snapshot and a precise list of what remained unknown. In this case, asking one better question prevented the agent from confidently solving the wrong problem.