Building Whet: lessons from an agent-native product
Three decisions that mattered when shipping a product where the CLI and the MCP server are first-class citizens, not afterthoughts.
Most products bolt agents on at the end. Whet was built the other way around: the CLI came before the workbench, the MCP server came before the React app. Three decisions did most of the work.
Same contract, three surfaces
The biggest one was committing to a single OpenAPI spec that the workbench, the CLI, and the MCP server all consume. It cost roughly a week of extra schema work up front. It started paying back the first time we needed to add an endpoint everywhere — one PR, one schema, three surfaces updated. The lock-in eventually goes the other way: shipping a feature to only one surface now feels wrong, and that’s the right default.
Auth has to be invisible
Agents fail loudly when auth is hard. They don’t have hands for a device-code flow and can’t scan a QR. The MCP server uses the same bearer token as the workbench — one OAuth, one token, no separate agent flow. The rule we landed on: if a human can sign in once and forget, an agent should get the same access on the same credentials. Anything that requires a second auth step is anti-agent by construction.
The CLI is the documentation
whet --help is the most-read doc in the project — by humans and by
agents. Every command has a one-line description, a verbose help block,
and at least one runnable example. The example matters more than the
prose. Agents use it as a few-shot prompt when they decide which command
to run, and commands without examples get used wrong roughly half the
time.