Let the Agent Search, Keep the Choice Open

Imagine asking an assistant to find a floor sander for a community hall repair. You need it Saturday, within a modest budget, with a pickup arrangement the volunteers can manage. It returns three rentals, compares prices, and recommends one.

That is useful work. Nobody volunteered to spend Friday learning the navigation habits of six rental websites.

Then someone asks about the independent shop across town. It rents the same equipment, but availability requires a phone call. Did the assistant check it? Exclude it? Never encounter it?

The recommendation may still be sound. But “best available” and “best among the services I could check” are different claims. A tidy answer can conceal that difference without containing a single incorrect price.

---

A new interface, the same limits

In his September 28 essay, “Apps, Agents, and Aggregation,” Ben Thompson argues that agents could become the interface through which people reach many other services. His concern is not simply that software will perform tasks. It is that the company controlling the agent could gain power over which suppliers people encounter—and what they choose to buy.

Thompson supplies a smaller, firsthand example of the attraction: he describes asking Muse to organize recipes saved in Instagram. When it first supplied a PDF, he asked for something more accessible and received a custom app. He also notes that extracting more of the recipe content remained unfinished, constrained by Instagram rate-limiting.

I take two things from that account. The convenience is concrete. So is the dependence on what the underlying service permits. A new interface does not make the old arrangements disappear.

Thompson's larger argument is a forecast about power, not evidence that every agent already controls a marketplace. But it gives builders a question worth answering before the interface becomes indispensable: can the person using it change the field of choices, or only select from the field it presents?

Approval alone does not settle that. You can approve a rental while never learning that a suitable supplier was missing.

---

Give the missing option somewhere to enter

Return to the hypothetical repair crew. Suppose the assistant's rental search covered two national chains and a marketplace. It could read their listings, but it could not confirm stock at the independent shop.

There is nothing inherently wrong with that coverage. A limited search can be exactly what the job needs. The distortion begins when the limit disappears from the answer.

A more useful response would say: “These are the three listings I could check online. Saturday availability still needs confirmation. I have not checked the independent shop; that needs a call.”

That sentence changes the crew's next move. Someone can call. Someone can say the shop is too far away. Someone who knows the owner can supply the missing information. The assistant has reduced the work without pretending it finished the world.

This is where coherenceism becomes a design requirement rather than a reassuring description. An orderly result is not enough. The arrangement must admit feedback from the people it affects, especially when their knowledge does not arrive in the format the tool already handles.

The volunteer without a truck may know why the cheapest pickup is impractical. The supplier without online booking may still have the right machine. Neither becomes irrelevant because the interface cannot easily read them.

The point is not to give every possible supplier equal space or turn every purchase into a public hearing. It is to leave a usable opening for information that could change the decision.

---

Ask for a shortlist you can correct

For your next ordinary comparison, try adding this to the request:

Give me a shortlist, not a booking. Include the source link for each option and the criteria you used to rank it. Name the services you actually checked and any relevant gaps you know about. Distinguish unavailable from not checked. If you know a commercial relationship affects inclusion or ranking, disclose it; if you cannot establish that, say so. Let me add an option and compare it by the same criteria.

This is a proposed working brief, not a tested guarantee about any particular assistant. A prompt cannot make hidden commercial rules visible, and a fluent explanation is not proof of how a ranking was produced. Check the cited listing for the terms that matter: rental duration, total cost, collection or delivery, and cancellation. Confirm availability with the supplier before booking. Treat unsupported explanations as unsupported.

The useful test comes when you introduce a correction.

Tell the assistant the crew has no vehicle suitable for collection. Does it reconsider the recommendation around delivery, or merely explain why its original choice was reasonable? Add the independent shop's confirmed quote. Does it compare that quote on the same basis, including delivery and timing, or keep steering back toward the services it already knows?

You are not testing whether it agrees with you. The new option might genuinely be worse. You are testing whether new evidence can change the outcome.

If you are building the interface, make that correction cheap: an “add another option” path, editable criteria, source links, and a visible distinction between missing information and a failed requirement. Those are more useful than a paragraph assuring the user that the assistant considered their needs.

And keep the comparison portable. A short saved note with the requirements, quotes, and unresolved questions lets someone else continue the work without reconstructing an entire conversation.

The crew can spend less time searching without losing the ability to change the answer. That is the capability worth building: not a machine that always knows best, but an arrangement in which better information can still win.