Your next customer might send an agent

I built an agent that tried other people's software for me. It would sign up for a product, test three of its main use cases, record those flows, and turn the whole thing into a narrated showcase.

Now put that agent on the buyer's side.

A founder could ask it to try a few tools, use the same inputs in each, and come back with what worked. The founder would still make the buying decision. But the software company might never get a chance to give its carefully rehearsed demo before that decision starts taking shape.

I think we're going to spend a lot more time selling to someone else's agent. Calling your product “agent-friendly” won't help much if the customer's agent gets stuck trying to use it.

Your demo won't always be yours to control

If you're going to call your product agent-friendly, show me an agent using it. That's what @frantzfries suggested on X: put an agent doing a common customer job right on the homepage.¹

Then I can judge what happened: Did it finish? Did someone have to step in? Does the result match what the page promised?

You can cherry-pick a recording. What I'd really want as a buyer is to hand over my own task and see what happens. That first useful interaction with your product could happen before anyone on your team even knows there's a prospect.

I'd give a prospective customer a test account with useful data and enough access to complete a small job without arranging a meeting first.

On the homepage, show a specific task someone can try, what a correct result looks like, and a way to check it. If that small job requires a sales call, explain what the call is needed to resolve.

Some of your marketing now lives in the product

A buyer's agent needs to understand enough to try your product without you directing it. That makes the instructions you give it part of the sale.

I'd involve whoever understands why customers buy in writing the tool's instructions. What problem does this tool solve, what does it need from the customer, and what will it return? Test whether an agent can use those instructions to finish the job. Confusing instructions can make a working product look broken.

Include the jobs the product can't do. I'd rather have an agent correctly rule us out than waste a buyer's time on a job we can't finish.

I'd try to break the sale before a customer does

Here's the test I'd run on my own product: give an agent a normal customer task, with the access that customer would actually have.² Don't give it the special instructions you keep in your head. Watch where it gets stuck, and keep the failed attempts.

I'd start with something small enough that I could check the result myself, then try a task the product should refuse. Run both without quietly fixing the setup or filling in missing instructions.

Try the same job in a competing product. Keep the inputs and the definition of success the same. Repeat it before drawing a conclusion; an agent making a mistake once doesn't tell you which product is better.

Some failures will belong to the agent. Others will expose a confusing setup step, an unexplained requirement, or an error message that leaves the customer stuck. Fix the setup, requirements and error messages the test exposed.

A small company that lets me verify a useful result might get onto my shortlist before a much larger company gets me onto a sales calendar.

Make it easy for a customer to send an agent, try the thing they came for, and bring back evidence that it worked. I want our product to survive a demo we didn't direct.