If your team is asking whether to build its own AI sales agents, you’re probably not new to this. You’ve connected Claude to your CRM. You’ve written skills. Maybe an engineer built something custom with Claude Code, and it’s good.

That’s real work, and most teams haven’t done it. It’s also why, when you see a demo of an AI sales agent, the first thought is: we could build this. That’s the build vs. buy AI question most sales leaders are working through right now.

You probably could build something that looks like it. The demo is the easy part. The cost is in everything after the demo: making it work on every deal for every rep, and keeping it working. Here’s the honest version, from people who tried it first.

We built it ourselves first

Before Arrows looked the way it does now, we ran our own sales team in Claude. Our reps stopped opening HubSpot and worked every deal through it. The first two weeks were great. Then it started to break. (Here’s the full story.)

Since then, we’ve talked with a lot of teams partway through building their own version. What follows is what we’ve seen from both sides.

The demo is the easy part

With today’s AI, someone on your team can describe what they want for a few minutes and get a working version back. It connects to your tools, drafts a follow-up that sounds like your best rep, and in a 30-second demo it looks just as good as anything you could buy.

But that version is maybe 20% of the work. The other 80% is getting it to work on every deal, for every rep, every day, without someone babysitting it.

Where it starts to break

Anyone who has spent a few days in Claude Code has built something that works. The problems don’t show up in the demo. They show up a few weeks later, once the whole team is using it every day.

What reps run into

  • You have to ask it every time. After every call, a rep has to open Claude, find the deal, and ask for the follow-up email and the CRM update. On a day of back-to-back calls, that doesn’t happen. It gets done at the end of the day, or not at all.
  • Reps end up managing it. They spend time tweaking prompts, fixing skills, and figuring out why it pulled the wrong info, instead of selling.
  • Everyone ends up with their own version. When something stops working, one rep fixes it in their own setup. Nobody else gets that fix. Pretty soon every rep is using it a little differently.
  • The emails don’t sound like them. So they rewrite them, or go back to writing them from scratch.
  • They have to check everything. They can’t trust it to get the details right, so they read every email and every CRM update before it goes anywhere.

What leaders run into

  • You can’t make reps follow the process. You can build skills for how you want deals run, but reps can skip them or change them. Nothing makes sure the steps happen on every deal.
  • You can’t see who’s using it. You don’t know which reps use it, on which deals, or what it did. It’s all in their own chats.
  • Your best rep’s habits don’t rub off on the team. If your top rep has a way of following up that works, nobody else gets it unless someone copies it over by hand.
  • It’s hard to coach. If a rep’s follow-ups are bad, you can’t tell whether it’s them or their setup.
  • Deals get dropped and nobody notices. If a rep doesn’t ask Claude about a deal, nothing happens on it. Nothing tells you a buyer hasn’t heard from you in two weeks.
  • Someone on your team ends up running a software product. This is the biggest one, so it gets its own section below.

If a few of these sound familiar, building more probably won’t fix them.

What a team version has to handle

None of it is hard to understand. There’s just a lot of it, and each piece has to be built and then kept working. Here’s what we’ve had to figure out.

1. Connections that write back, not just read

Reading your CRM is simple. Writing back safely is harder. Every call and email has to be matched to the right deal, including when one company has two open deals or the buyer replies from a personal address. Then every update has to go into the right field.

2. Something that runs without being asked

If someone has to prompt the agent, the deals that need the most attention are the ones nobody prompts it about. A team version needs to run after every call, email, and CRM change, and decide what your playbook calls for.

3. One playbook, in one place

Give five reps the same skills and within a month you’ll have five versions of your sales process. A team version needs one playbook that every agent follows. When you change it, it changes for everyone.

4. A plan for every deal

Single tasks are easy. A team needs a plan for each deal: what happens after this call, what’s due next week, which deal has gone quiet. That plan has to carry from one call to the next.

5. A place for reps to review and approve

A chat window works for one person. For a team you need a queue of finished work (follow-ups, CRM updates, call prep) that a rep can approve in one click, and that everyone else can see.

6. Something for the buyer to see

Buyers want one place for the proposal, the next steps, and the materials they asked for. If you want that page to stay current as the deal moves, that’s another piece of software to build.

7. The edge cases

This is where most builds stall. Should the agent reply in the existing thread or start a new email? What if the meeting was rescheduled, and by whom? What if it gets a detail wrong but says it like it’s sure? AI won’t figure these out on its own. Someone has to decide how each one should work, and then build it.

8. Someone to own it

Every rep will have requests. Every time your process changes, it needs an update. And when one of your tools changes how it connects, something breaks.

The part nobody plans for: someone has to run it

The first version gets built once. After that, someone has to keep it running.

Every time something breaks, someone on your team has to fix it. Same when a rep asks for something new, when you change how you sell, or when Claude adds something your reps want to use. That person has to figure out what to change, build it, test it, get every rep onto the new version, and answer everyone’s questions. That’s product management, for a tool that touches every deal and every rep.

If you have an internal tools team whose job is exactly this, great. Most sales teams don’t. It usually lands on whoever built it, on top of their actual job.

A sales leader once told us his in-house AI person loved the system they built. Then we learned that person was getting Slack messages from 40 reps every week asking for fixes and changes. Another told us the tool their team built was code only one person understood. If that person left, nobody could run it.

At Arrows, we have a full-time team that does only this: fixing what breaks, keeping up with what’s new in AI, and building what sales teams ask for.

Your engineers have other work

The people who can build this are usually the same people building your product. We hear it on almost every call: the dev team is getting dozens of requests a week, or the engineers keep being pulled into sales automation when they should be shipping product.

So it’s worth asking: if they build this, what aren’t they building?

You’d start behind, and stay behind

AI for sales changes every month. A team that starts building today will spend six months to a year getting to a working version, and the tools keep moving the whole time.

For a sense of pace: in the last ten weeks, we shipped close to 1,000 updates to Arrows, about 14 a day. That’s a full-time team doing nothing but this.

There’s another difference. When one customer runs into a problem, we fix it for everyone, so the product keeps getting better while you sell. Something you build only gets better when someone on your team stops what they’re doing to work on it.

Ask why you’re building it

Be honest about why. “Because we can” isn’t a good reason, since anyone can build a first version now.

“Our sales process is unique” usually isn’t a good reason either. Every team’s details are different, but the shape is almost always the same: calls, a proposal, then legal, security review, maybe a pilot, and a close. A good playbook captures your details. You don’t need custom software for them.

Building really makes sense in only a few cases, and each one means you plan to own this for years, not a quarter:

  • You have an internal tools team for go-to-market. Engineers and a product owner whose full-time job is building and running sales tools, with the budget to keep doing it. Not product engineers on loan, and not one person who’s good with Claude Code.
  • You’ll roll it out to clients. If you’re an agency or consultancy that builds this once and delivers it to many customers, owning it is part of your business.
  • Owning it is the goal. For example, an investor who wants one system across every company it backs.

If none of these fit, building means signing someone on your team up to run a software product. Most sales teams don’t want that job.

And if you have one or two sellers, you may not need either yet. Claude and a few good skills cover a lot. Start with our free Claude sales skills, and take the two-minute check to see when you’ve outgrown it.

Six questions to answer before you build

  1. Who builds it, and what do they stop working on?
  2. When can they realistically start?
  3. Who fixes it when a rep says it’s broken?
  4. If that person leaves, who runs it?
  5. When your process changes, who updates it, and how fast?
  6. How will you know which deals it missed?

If you have clear answers to all six, building may be right for you. If you don’t, that’s useful to know before you start. We turned these into a one-page build vs. buy business case you can fill in with your own numbers.

What buying looks like with Arrows

Arrows is the version we wished we’d had when we tried this ourselves. (If you’re still sorting out which kind of AI agent you need at all, start with which AI sales agent fits which job.)

  • Every rep follows your process. Agents work every open deal using one playbook, built from how your best reps already sell.
  • Nobody has to ask it. After every call, the follow-up email, the CRM update, and the prep for the next call are ready.
  • Nobody on your team has to keep it running. Your Agent Architect builds the playbook with you and updates it when the way you sell changes.
  • Reps stay in control. Nothing goes to a buyer until a rep approves it.

See the side-by-side: Arrows vs. Claude for sales teams.

If you’re weighing it now, book an agent kickoff. We’ll show you what agents would do on your real deals, so you can compare it with what you’d build.