Built an AI sales agent from 0 to 1

Prospector ran as a loop you set in motion. You gave it a market and a few filters for the kind of person you wanted to reach, and it found those people, wrote each of them a personalized email, and sent the emails for you on a schedule, under your own name.

Writing the email was the easy part. A language model can do that, and ours did it well enough to get real replies and move deals forward. The harder part is everything around the writing. The email goes out under a real person’s name, to a real prospect, and it carries that person’s reputation with it. So before Prospector could be useful, it had to be trusted, and earning that trust turned out to be the whole design problem.

The obvious way to earn it is to make the rep approve every email before it goes out. But approving every email is exactly the work they signed up to stop doing, and a system that asks permission for each thing it does is not really an agent anymore. So the actual job was narrower: take the rep out of the loop on each individual send, but keep them in the loop on the system doing the sending.

I was Prospector’s first and only designer, brought on about two months in. The engineers had a working version running, but none of it had been designed yet, and with a release date already set, I had about three months to take that prototype to something a stranger would trust with their own pipeline.

The codebase was new and our design system was mid-migration and not really ready to build against, so rather than wait for it I built the interface in Tailwind, matched to our existing tokens. It was the kind of bet you make when the schedule is the real constraint, and it held up. The migration stalled out a few weeks later, and we were glad not to have waited on it.

If the rep is not approving each email, control has to live somewhere, and the place that makes sense is a level up: on the system as a whole, rather than on each thing it does. So the interface had one real job, which was to make the agent legible. You should always be able to see what it is about to do, what it has already done, and why it picked the people it picked, and step in wherever you wanted, without ever being made to.

That started before the agent did anything. To give it a market you set up a territory, choosing the industries, company sizes, seniorities, and locations you cared about, and as you adjusted the filters the page previewed five matching leads and the total number available, so you got a feel for who the agent would reach and how many of them before you committed. Without a territory the agent had nothing to do, which made setting one up the part of onboarding that actually mattered, so I built a guided tour around it: walk the new user into their first territory, and let that live preview do the convincing. It took activation from 17% to 42%.

Once it was running, the home page opened on the agent’s queue, divided into Scheduled, Sent, and Later. Every email waiting to go out was right there to read: the lead, the company, the subject, the first couple of lines. A banner across the top said, in one line, when the next batch would send and let you change it: “Scheduled for tomorrow, 12:00 PM,” with a Change link beside it. The same line appeared on the territory page for the next search. It is a small thing, a status line, but it does a lot of quiet work. The agent tells you its next move before it makes it, and the way to change that move sits right there in the sentence.

Open any queued email and a panel slid out from the side with the person behind it: their role and company, the company’s size and industry, links to their profiles, and so on. This was the agent’s reasoning, made visible. You could judge whether it had picked the right person, not only whether the email read well. One user, an SDR named Mariah Moore, flagged the small version of it: “Love that when you generate an email, it links you to their LinkedIn profile. That’s super slick and such a time saver.”

And ten minutes after each day’s emails went out, a digest landed in the rep’s inbox with the leads queued for tomorrow and the ones just reached, plus a link back in. The quick check and then on with your day was a rhythm we heard again and again in interviews, and the digest met it: what the agent had just done, what it would do next, and time to step in before it did.

Visibility lets you watch the agent work. The other half of control is being able to stop it, and that was the harder design question, because the answer depends less on the mechanism than on where you put it. Where the stop lives changes what the product seems to be.

Early on someone floated a big stop button on the home page, half as a joke, and it stuck with me, partly because it would have worked and partly because it would also have been a quiet mistake. A stop button on the main screen is the first thing a new user sees, and it tells them something before they have formed any opinion of their own. It says: this thing might do something you’ll need to halt in a hurry. The whole product starts to feel like a hazard you are keeping an eye on.

A schedule banner does the same job and says nearly the opposite. It tells you what is coming and how to change it, and what it implies is that you are running a system you set up yourself. Same capability, very different relationship to it. One version casts you as a supervisor waiting for the agent to slip. The other casts you as the person who configured a tool and can reconfigure it whenever they like.

So I put the stop where you tune things rather than where you panic. In settings you could pause everything with a vacation toggle, switch the agent off entirely, or just drop a day from its schedule. For the one moment that genuinely is urgent, a prospect writing back, or you reaching out to them yourself, the control sat where the work already was: a small banner inside Gmail offering to stop the follow-ups on that thread, and a remove option on the lead. We had a rule for that banner, which was to offer the choice rather than make it for the user, since the agent could easily mistake an out-of-office bounce for a real reply.

It comes down to something fairly simple. A kill switch on the main canvas is a signal that you don’t quite trust your own product. Routed through settings, the same switch is just configuration, and the product reads as a system you have chosen to run rather than a hazard someone has told you to watch.

The design never assumed the rep would stay hands-off forever. The editing tools were built for the opposite case, the early days, when someone is still deciding whether to trust the thing at all. You could edit any email in place. If you wanted a different version you could ask for one in plain language, the way you would ask a colleague, and it rewrote on the spot, then carried what you had changed into the emails it wrote next, so the drafts moved toward your taste over time. You could also hand it a sample of your own writing and let it learn your voice, so they started out sounding more like you and less like a model.

You were never required to do any of it, and over time people did less of it. In a rep’s first month they sent about 80% of the drafts as written. By their third month it was past 95%, and by their sixth, 99.6%. The longer someone worked with the agent, the less they needed to step in. That tracked what people told us in interviews: they wanted a stretch of time to build confidence before handing over real autonomy. Heavy editing early, lighter editing later. The review tools were how people earned their way into trusting it.

That trust came through in how people talked about using it. A sales manager named Melissa Seeker put it this way: “I check it in the morning and usually in the evening and just let it do its thing. It’s hands-off, and that’s what I wanted.” She did not stop paying attention. She stopped doing the work by hand.

Others said the same in their own words. Suzanne Kirkland, who runs sales at a startup, told us “there’s no way that I could do all of this research and even type up all of these emails every single day.” Chris Chiasson, a business development lead, had been spending two hours a day on this and got it down to fifteen minutes. Fabrizio Colombi, a consultant who had tried Apollo and a few others, found them “very capable, but at the same time, very cumbersome,” and Prospector easier to use. Over its life it sent more than 350,000 emails on behalf of the people who turned it on. At that volume, reviewing each one by hand was never realistic. Control had to sit at the level of the system, not the individual email.