Correction, October 11, 2026: Khemani’s travel test involved available but uninstalled plugins. Work failed to suggest a suitable installation, rather than failing to use an installed plugin.

OpenAI built ChatGPT Work for people who already juggle a dozen tools. Independent researcher and writer Shlok Khemani thinks that framing undersells what it actually is.

In Shlok Khemani’s detailed breakdown of the product, Khemani argues Work is not a side product for specialists. It is a preview of the default ChatGPT experience.

What Khemani is saying

Khemani’s central claim is direct:

“Work, then, is not just a niche product for power users, but a preview of how ChatGPT’s billion weekly users will soon use the app.”

Khemani predicts that planning tasks, calling plugins, and using outside tools will become ordinary ChatGPT behavior rather than a niche feature set.

But Khemani also tested the feature closely enough to find where it breaks. When he asked ChatGPT Work to search for flights and hotels, it failed to suggest available travel plugins he had not installed:

“When I asked it to search for flights and hotels, it ignored several available but uninstalled travel plugins in favour of web search, even though a plugin might have used fewer tokens, returned better results, and let me complete a booking directly.”

He pushed further, naming a specific travel plugin by name. It still did not offer it: “Even naming Expedia outright didn’t prompt it to offer the plugin.”

Who Khemani is and why the take carries weight

Khemani describes himself as an independent builder and writer based in Mumbai, previously writing and building products in the crypto space at Decentralised.co. His recent work focuses on AI memory systems and personal AI products, including public research talks on how AI labs build memory into their models.

His critique comes from testing the product himself: the specific tasks he ran, the specific plugins he expected to see, and the specific results he got back.

What the piece gets right, and where it is incomplete

Khemani’s strongest point is specific and testable: he names the exact failure mode (a suitable plugin available but uninstalled, not suggested), the exact workaround he tried (naming the tool directly), and the exact result (still ignored). That identifies a concrete discovery failure in his test.

The piece is less strong as a general theory. Khemani generalizes from his own testing session to a claim about how a billion people will use the app. That is Khemani’s forecast. His plugin test describes one session, so it cannot establish how the wider user base will adopt the product.

Why it’s notable

An agent may handle installed tools well and still fail to recommend a missing one. Khemani’s travel test exposes that distinction: the directory had suitable plugins, but Work did not suggest installing one, even when he named Expedia.

Better plugin discovery could make a task easier to complete inside the app. His test does not establish how often Work misses an appropriate installation across other tasks or users.

What it means for builders

If you are building on top of an agent platform, plugin or tool visibility is not a detail to leave until launch. An agent that silently uses a fallback can leave users unaware of a purpose-built tool that might complete the task more directly.

Test discovery separately from tool use. Give your agent a task with a suitable plugin available in its directory but not installed. Check whether it suggests that installation, including when you name the plugin. A silent fallback can hide a missing capability rather than help the user add it.

End of article