Designing for Agents

If you spend time in the same corner of X as I do, scrolling past the "How I built a second brain with Obsidian" and "Anthropic just KILLED [insert industry] FOREVER" posts, you've probably also seen the take that UI is dead. And unless a product can be used by agents via an MCP, API, CLI, or something in between, it won't survive. The trend is real at Ramp. Over the past three months, weekly active users on our MCP have grown 10x as more customers reach into the product through Claude, ChatGPT, and other agents. Last week, Salesforce became one of the first incumbents to lean into this thesis. From VentureBeat: Salesforce on Wednesday unveiled the most ambitious architectural transformation in its 27-year history, introducing "Headless 360" — a sweeping initiative that exposes every capability in its platform as an API, MCP tool, or CLI command so AI agents can operate the entire system without ever opening a browser. The announcement, made at the company's annual TDX developer conference in San Francisco, ships more than 100 new tools and skills immediately available to developers. It marks a decisive response to the existential question hanging over enterprise software: In a world where AI agents can reason, plan, and execute, does a company still need a CRM with a graphical interface? Salesforce's answer: No — and that's exactly the point. This is a smart move by Salesforce, and one that I can't imagine was easy to make. Ask most salespeople, and they'll tell you how much they dislike using Salesforce. But the product is pervasive because of the familiarity of its UX. Sales leaders aren't interested in ramping up their teams on new technology, and consistency frequently trumps functionality. Benioff and team are accepting that this moat is eroding and leaning into the reality that a majority of usage will be driven through agents like Claude, ChatGPT, and other background processes that users never see. I don't think UI is dying. Humans still want to point and click, see their configurations, and verify completed work. But the 80/20 has flipped: the new 80% of interaction with software will be through agents. That changes not only what you need to build, but how you build it. The new interaction pattern For the past twenty years, the primary way people have interacted with software has been: User → Interface → Database You open a product, click around, get things done. The interface is how you experience the software. For most people, the interface is the product. As agents take on more of the work, a new layer has emerged: User → User's Agent (e.g. Claude) → Database The agent acts on the user's behalf. It reads, writes, and navigates the product so they don't have to. And suddenly the interface is gone. The agent is talking directly to the system underneath. But even this is rapidly changing. Software companies are (and should be) designing their own agents and capabilities. So the new pattern looks more like this: User → User's Agent → Software's Agent → Database In this model, the software's agent handles complexity on behalf of the user's agent: applying business logic, enforcing rules, pulling in context the latter doesn't have. Two LLMs working together to drive toward an outcome. Teach agents how to succeed I do a majority of my brainstorming, writing, and ideating with LLMs. When a draft is ready to share, I push it to Notion through their MCP server. I was a Google Docs loyalist for years; Notion's MCP flipped me. One thing I appreciate as a Notion MCP user is how every time I ask an agent to write something, it nails it. Tables, bullets, italics, lists, you name it — the agent never fails. This is by design. The notion-create-pages tool's description opens with: "For the complete Markdown specification, always first fetch the MCP resource at notion://docs/enhanced-markdown-spec. Do NOT guess or hallucinate Markdown syntax." When I ask my agent to write to a page, that's the first thing it does. It fetches the spec, then writes. Every Notion-specific assumption gets explicitly called out against the general model's defaults. In an old world, that spec would've lived in API docs, and a developer integrating with Notion would read it, internalize it, and write a transformation layer. Now Notion hands the spec directly to the agent, at the moment it's needed. If you've ever used the Slack MCP, you've probably experienced the inverse of this. Your agent assumes standard markdown and doesn't adhere to Slack's specific formatting. You end up spending more time editing the formatting than you would have writing the message: Sure, the formatting guidelines are online and you could save them somewhere and teach your agent how to use them. But that's annoying, and it shouldn't be necessary. Think about what your agent's callers need to know to succeed, and give it to them proactively. Don't make them figure it out. Build feedback loops When we first launched our MCP at Ramp, observability was our larg