Designing for Agents为 Agent 设计产品

UI isn't dying, but the 80/20 of human-software interaction has flipped: most interactions will now route through AI agents, forcing companies like Salesforce to expose their entire platforms as agent-operable tools.

Designing for agents requires three disciplines: teaching agents your product's rules upfront (specs, not guesswork), building feedback loops (rationale fields, dedicated feedback tools) to learn what agents are trying to do, and identifying which side of an agent-to-agent exchange holds which context.

The essay opens with an anecdote from the author's social feed — a chorus claiming 'UI is dead' — then grounds it in two data points: Ramp's own 10x growth in weekly MCP active users over three months, and Salesforce's announcement of 'Headless 360,' which exposes its entire platform as APIs, MCP tools, and CLI commands. This framing establishes the piece isn't speculative futurism but a description of an already-underway shift, using Salesforce as the highest-profile incumbent validating the trend.

The author's key reframe is that UI isn't dying — humans still want buttons and confirmations — but the 80/20 has inverted: 80% of human-software interaction will flow through agents. This is stated as an assertion, not derived from data, and it's the load-bearing claim the rest of the essay builds on. The interaction model evolves in three stages: user→UI→database, then user→agent→database (UI vanishes), then user→user's agent→software's own agent→database, where two LLMs collaborate rather than a human directly touching the backend.

The first design principle — teach agents how to succeed — is illustrated by contrasting Notion's MCP, which forces agents to fetch an 'enhanced markdown spec' resource before writing (preventing hallucinated syntax), against Slack's MCP, which lacks this guardrail and leaves users manually correcting agent-generated formatting. The lesson: product-specific assumptions that once lived in developer documentation must now be pushed proactively to the agent at the moment of need, not left for it to infer from generic training data.

The second principle — build feedback loops — describes three concrete mechanisms Ramp adopted after realizing tool-call volume alone was uninformative: a mandatory 'rationale' parameter on every call (reconstructing intent without chat access), a dedicated feedback tool for agents to report blockers, and context-seeding parameters on specific tools. The worked example — recurring rationale phrases like 'drafting an incident report' signaling demand for a new build-incident-report tool — shows how agent behavior becomes a structured, machine-readable product research channel, arguably more consistent than typical human user feedback despite agents' tendency to hallucinate.

The third principle — mind the context gap — uses the Diego expense-report scenario to show that user-side and system-side agents each hold asymmetric information (calendar/email/Slack context vs. transaction data/policy/GL accounts). The prescription: instead of a traditional API pushing a raw choice back to the user ('pick one of 150 GL codes'), a well-designed agent interaction asks for context ('was this a client dinner?') that the requesting agent can actually answer, letting the receiving system apply its own domain knowledge to fill the gap — neither side needs to fully understand the other's domain.

The closing argument warns against checkbox-style MCP launches: usage may grow for a few quarters then plateau, while customers migrate toward products that genuinely invest in agent UX and away from those that merely 'support agents' nominally. The provocative closer — 'the one signing the check might be it' — reframes agents not as a feature checkbox but as the primary customer product teams now design for, an assertion worth treating as rhetorical emphasis rather than literal prediction.