Can an Agent Use Your Product?
The usability question that's about to show up in your sales calls and your roadmap reviews.
For as long as I can remember, product teams have obsessed over one question: can a person use this? Can they find the button, understand the screen, finish the task without rage-quitting halfway through. And does that workflow create value for that person.
That question will always be there, but product teams now have to ask themselves a different question. It’s quieter, and it’s going to matter more than most teams expect.
Can an agent use your product?
First, let me define “agent,” because it’s a word that’s been stretched until it barely means anything. An AI agent is software that takes actions for you. Not a chatbot that answers a question, but something that handles “the task”:
books the meeting
pulls the report
files the ticket
Some of your customers are probably already pointing agents at your software. Right now most of those agents are fumbling, screen-scraping, clicking around an interface built for human eyes and human hands. It sort of works, but it’s probably brittle.
This shows up in deals, not just stand-ups
It’s tempting to file “agent access” under engineering, something for the backend team to get to eventually. That’s a mistake, because this lands squarely on the commercial side of the house.
Buyers are going to start asking about this (if they haven’t already) in the same RFP where they ask about your SSO, your uptime, and your data residency. Account executives will field that question on calls before their product teams have a plan for it. Product managers will hear it in a roadmap review from a sales leader who just watched a deal almost blow up because of it.
The framing that matters is this: agents are becoming a new class of user. That’s right ... a user. While building an MCP server to expose capabilities of your product can be considered a feature, it’s important to realize that the AI agent speaking to that server is not a feature, but actually a new type of user category in itself.
When a new kind of user shows up, the products that already speak their language tend to beat the ones that don’t.
So I built one (because building is fun)
The thing I built is a Product Feedback Synthesizer. In plain terms, it takes the messy pile every product person knows too well: app store reviews, support tickets, survey responses, sales notes, and then turns that raw data into something useful. The AI-native application generates an executive summary, ranked themes, the pain points that keep resurfacing, the feature requests worth taking seriously, and a few roadmap recommendations to consider.
I picked this workflow on purpose. Every PM and every AE recognizes the feedback pile. It’s universal, it’s tedious, and it’s exactly the kind of work you’d happily hand off, which makes it a good place to show what “two ways in” actually looks like.
Door #1: the way a person uses it
The first use case of the Product Feedback Synthesizer is the one you would expect:
A human navigates to the home page.
Tells the app simple info about the product.
Chooses how they want to provide raw product feedback data.
Uploads a .csv file or pastes in the raw data.
Clicks a synthesize button.
Watches it run.
A few seconds later a dashboard displays with a summary up top, themes ranked by weight, real customer quotes pulled in as evidence, and a breakdown of where it all came from. The user can then optionally use the chatbot to ask further questions about the results.
There’s nothing exotic here. It’s a clean, useful tool a founder or PM could open on a Monday morning and get value from. This is the front door, the one built for you and me.
Door #2: the way an agent uses it
Now the same job, with nobody touching the screen.
An agent can do every step I just described by calling the product directly.
Create a feedback set.
Add the raw feedback.
Run the synthesis.
Get the results.
Ask a follow-up question.
This allows an agent to ask something like “what should we prioritize next quarter?”, and get a grounded answer built from the very same analysis a human would.
This works through something called MCP (Model Context Protocol). If you read my previous article The Captain & the Protocol of the Seas, this is an example of the analogy I portrayed as “the protocol of the seas”. No worries if you didn’t read it, the whole idea is that MCP is a shared standard that lets an AI agent plug into software and operate it. You can think of it as a kind of universal adapter between agents and the tools they need
But here’s what I want to emphasize: The agent isn’t using a copy of my app. It isn’t running some stripped-down “AI version” that I built on the side. It’s using the exact same engine the web app uses with the same workflow, same logic, and same results. It’s one product with two doors.
Less exotic, and more important, than it sounds
To be clear, a lot of products already have this door. Teams have been quietly wiring their software up for agents for a while now, and the tooling to do it gets easier by the month. So the takeaway isn’t that this is possible, it’s that this is transitioning from a nice-to-have a few forward-leaning teams bothered with into something buyers will simply expect. Sooner or later, this will be “table stakes”.
The reassuring part, and honestly the whole point of building this, is how relatively little it took. I didn’t rebuild the product. I added an entrance to a building that was already standing. The web app and the agent walk into the same room.
That pattern travels. Picture it in the products you actually sell or manage:
A CRM that lets an agent research an account and draft the opportunity update.
A support platform that lets an agent triage a ticket and flag the customer who’s about to churn.
An analytics tool that lets an agent pull the metric and write the first draft of the readout.
None of those need a parallel product. They need a door.
The question worth asking Monday
The companies that answer “yes, an agent can use our product” mostly won’t be the ones who tore everything down and rebuilt for the AI era. They’ll be the ones who looked hard at what they already had and added a way in.
So the question I’d leave you with isn’t really about my little feedback tool. It’s about yours. Look at the workflow at the center of your product, the one your users login to utilize. Then ask two things: (1) Is this a job an AI agent might be called upon to complete? and (2) If one showed up tomorrow, could it complete it?
If the first answer is yes and the second is no, that gap is worth a conversation. It happens to be the kind of thing I build, and the kind of thing I help teams think through. But even if you never send me a note, ask the question anyway. Your customers are about to.
Feel free to make use of the Product Feedback Synthesizer tool I built.
Or if you want to see the full codebase, I’ve open sourced the GitHub repository.