|
|
Every B2B software company should be building an agentic version of their product. |
HubSpot was the first leading CRM to ship MCP (Model Context Protocol) support. But here's what I've learned over the past few months: becoming a truly agentic company requires more than that. |
The companies and builders that succeed in the upcoming agentic era will be those that take a thoughtful approach to designing an Agentic User Experience -- AUX for short. |
So today, I want to break down: |
Why wrapping your existing API into an MCP server is wrong What a thoughtful Agentic User Experience (AUX) looks like How you can be an early adopter of AUX (starting today)
|
—@dharmesh |
|
|
What Is AUX? |
Two and a half years ago, I wrote about how humans would interact with agents in ways beyond chat through async work, agents pinging you when something mattered. |
I was half right. |
The half I missed: agents need an optimized experience too. In the agentic era, the agent is the user. |
The way I think about it now is that AUX is to agents what UX is to humans. |
Yes, building for agents will involve APIs, MCPs, and CLIs. But the difference will be in the ergonomics of the interface. We need to figure out how agents actually want to use our products -- because if all they wanted to do was use them like humans do, we already have "computer use" type systems for that. |
It's all about fit. How well does your AUX match the way agents actually work? |
Your agentic users will interact with your product differently from your human users, and the interface needs to reflect that. |
So the big question… how do we design for that? (more thoughts below) |
|
|
Why Agents Need Their Own Interface |
First, let’s run through a super-simple (but very common) example. |
Let’s say you have a relatively robust, web-based product. It’s got a well conceived, well designed navigation system so that users can find the features or configurations they’re looking for. This works great for human users (especially those that are new to the product), but an agent? It doesn’t need that hand-holding. You can just give the agent an “index” of the 273 features of your app and how to go directly to the page/URL for that app. No clicking around. No muss, no fuss. |
Here’s a slightly more involved example. Say your product is a support platform, and a customer's agent has been assigned to work through this morning's queue. |
Here's what happens if you just wrapped your API in MCP: |
First, you exposed every endpoint as a tool. get_ticket, get_customer_history, search_knowledgebase, create_response, update_ticket, escalate_ticket. The agent then has to chain them together itself after reasoning through things. This means reading the ticket, pulling customer history, searching the knowledge base, drafting the response, and deciding whether to escalate or close. On top of that, if something fails, the agent retries. If the data is stale, it fetches it again.
|
That’s five API calls plus all the error handling -- per ticket! Your API was written for developers to compose one call at a time, one decision at a time. What’s more, this is inefficient because although an agent can use a frontier LLM to reason through what should be done, it’s not going to reliably do it the same way every time. And it’s going to burn through some tokens as it thinks it through. And it’s going to do that every time for every ticket. |
You can do it that way, but that’s not a friendly AUX. |
Now imagine the same product with a thoughtful layer of AUX: |
You expose one tool: processTicketQueue. The agent calls it with the queue ID and gets back a structured response. Your backend understands the workflow. It already knows how to resolve tickets, when to escalate, when to retry, when to stop. (Maybe it’s even using an LLM behind the scenes to make some of those decisions). The agent gets back a clean report: what's resolved, what's escalated, what's waiting on the customer.
|
Here’s another way to think about it: |
Imagine the difference between telling your assistant "handle the client complaints that came in this morning" versus "read email #1, find that client's file, check their purchase history, draft a response based on our template, decide if it needs my approval, send it if not, repeat for emails #2-50." |
That's the difference between good AUX and just wrapping your existing API. In a way, an AUX just allows the agent to work at a higher level of abstraction and a more appropriate level of “non-determinism” (that’s when the software doesn’t deterministically do the same thing every time -- which is how LLMs work). |
Being agentic is not just about agents running on your platform -- it's about agents running your platform. |
|
|
How to Be Early |
If you’re reading this, you’re an early adopter. The playbook for AUX is still being written, but these things feel directionally correct: |
1. Don't treat MCP as the finish line. MCP makes your product reachable by agents. AUX is what makes it usable by them. |
2. Treat agents as first-class users. The software industry has spent decades designing interfaces for humans. Even when we built APIs, they were built for human developers. Now, we need to look at it from the perspective of the agent as the primary user? |
3. Pick one workflow and make it actually great for agents. Don’t try to overhaul the agent experience all at once. One workflow. Make "onboard a new customer" feel magical end-to-end for an agent, then expand. (Yes, yes, I know, agents don’t feel “magic” in the way humans might). |
The software companies and builders that win the next five years will be the ones investing in AUX: building for agents, not just for the human developers their API was originally designed for. |
One day, your product may have more agent users than human users. The builders who start designing for agents today -- thinking about ergonomics, workflows, and outcomes instead of just wrapping endpoints -- will be the ones ready when that day comes.
Oh, and by the way, that day may be closer than you think. |
—Dharmesh (@dharmesh)
p.s. If you want to get a free/cheap ride to see how this agentic world develops, I’d suggest signing up for the free ($0, no credit card) or Starter edition ($15/month) of HubSpot. Even if you’re not in the market for a CRM right now, it’ll give you a sense for how things are evolving -- and the kind of thing you should expect from your CRM. Check out my GoHubSpot.ai site to sign-up. Apologies for the shameless plug. I’m driving some Founder Led Growth -- and learning a lot. |
|
|
|
|
What'd you think of today's email?Click below to let me know. |
|
|
