Which Tom · Designshippers

4 min read Original article ↗

View the coded design ↓

“Find the emails from Tom where he added a pdf and save those pdfs to our database.” Every noun in that sentence is a question. Which inbox? Which of the three Toms you have in your address book? What counts as an attachment? Which database, and does it write to production?

A general chat assistant can afford to be vague about all of it, because the worst case is a bad paragraph. An agent that acts cannot. 

Both of the current options are bad

Guess in silence and act on the wrong thing, or interrogate the user across turns. Both failure modes have now been measured.

DiscoBench, from Tencent Hunyuan and Tsinghua, found that the real failure of search agents is not searching badly. It is not asking when the request is ambiguous. Pick the wrong entity at an early node and the agent carries on with perfectly clean syntax while missing the target completely, and every unresolved ambiguity compounds down the chain. Tested without hints, the strongest model in their set finished 43.1% of tasks end to end. Searching harder instead of asking often did worse than guessing outright.

The same holds in code. Ambig-SWE, an underspecified variant of SWE-bench, found that models struggle to tell a well specified instruction from an underspecified one in the first place, and that the assumptions which follow produce tool misuse, wrong edits and wasted compute.

Asking has its own price. Laban et al. took fully specified instructions, split them into pieces and revealed one per turn across 200,000 simulated conversations. Performance fell by an average of 39%. Models commit to an early assumption and never recover from it. This problem is more expensive than we initially realised.

Splitting one instruction across two messages is not a smaller ask. It is a different and harder problem.

What we built

We came up with the idea to solve the problem at the point of typing, borrowed from @-mentions. Which solved a very similar problem years ago. The moment you pick from the menu, a name stops being a string and becomes a hard reference. Decided by the person who knows, while they are already thinking about it, for zero extra turns.

Press an example, or type your own: send the emails from tom to the team. References resolve as you pass them.

Load the first example and look at the amber chip. Run is disabled, and stays disabled until you say which Tom.

It refuses to guess

Tom stays amber and Run stays disabled, because two candidates are genuinely close and the cost of being wrong is a wrong write. Everything else takes a confident default you can change with one tap.

Scope, before you commit

The pill under the field reads 14 emails · 9 PDFs → production. That is not a status. It is the size of the thing you are about to do, computed from the references you picked. Switch Tom Johnson to Tom McNeill and it drops to 3 and 2.

Resolution is scoped

Who Tom is depends on the workspace. In one, three colleagues. In another, your brother and your accountant. So the candidate list is a property of the workspace rather than a global address book, and changing workspace reopens the reference instead of quietly pointing it at a stranger with a similar name.

Why this is an input problem

Resolving in the input costs nothing, because the person is already there, already typing, and already knows the answer. Resolve it later and the quality of the output goes down and you add tokens, cost and time to reach the desired end goal.


If you are building something agentic and need help increasing trust, clarity and reduce costly mistakes. Let us know. We'd love to help you find solutions.