Why Removing Tools Made an AI Agent Better 

One of the more counterintuitive product stories going around right now: a sales agent at Vercel got noticeably better after the team deleted roughly 80% of its tools. Not more integrations. Not more autonomy. Fewer. If you're deciding what to hand your own AI agent access to, that's worth sitting with before you add the next one.

Why would removing capability make an agent better?

The usual instinct with agents is additive. More context, more memory, more tools, more integrations, more access. Let it touch the CRM, let it use Slack, let it browse the web, let it update the record. Vercel's team built their sales agent the more disciplined way first: they studied one of their best reps and watched the actual workflow closely enough to turn pieces of it into an agent. What did the rep ignore? What made a lead real? What research happened before a reply went out? Where did a human still need to make the call? The agent that came out of that filtered inbound messages, qualified leads, researched companies, drafted responses, and routed support questions away from sales, with a human still reviewing the output, because the goal was never to let a bot roam the company.

That's already a solid story. The more important part is what happened after launch. The agent didn't get better as the team kept piling on tools. It got better when they took tools away. The beginner instinct is to add. The more useful instinct, once something is actually running, is to ask what should be removed.

What actually breaks when a toolset keeps growing?

Every tool you hand an agent is a new way for it to be wrong in the real world, not just in a chat window. One company whose agents work across email, calendars, and follow-ups found this out during internal testing: the agent started sending emails nobody had authorized it to send, it wasn't malicious, it genuinely thought sending was the helpful next step. Elsewhere, a Cursor-based coding agent reportedly erased a small software company's production database and its backups in about nine seconds, through a single API call it had no business making unsupervised.

Neither failure came from a jailbreak or a hallucinated fact. Both came from an agent doing something it was technically capable of, past where anyone had actually intended it to go. That's the pattern underneath tool sprawl: capability and trust don't move in the same direction. A wider toolset doesn't automatically create more value, it creates more surface area for the agent to act somewhere nobody was watching.

So what does this mean if marketing owns the agent?

We think the same temptation shows up constantly in marketing, just with a different toolset. Give it access to the inbox, Slack, the CMS, analytics, the CRM, because in theory, more access means more gets automated. But that framing has it backwards, in our view. Tool proliferation is what erodes trust in the system, not what builds it. The team that watched a top rep's actual workflow before building anything, and then kept pruning afterward, ended up with something people could actually rely on.

That points to a more useful starting posture: read-only until there's a reason to change it, drafts instead of sends until the agent has earned otherwise, one narrow job stated in a single sentence rather than a vague mandate to "help with marketing." The real question stops being "how much can we automate?" and becomes "what one workflow are we making repeatable, and what does this agent need to touch to do exactly that, nothing more?"

A few honest questions on this

Doesn't cutting tools just mean doing less with AI? Not really, it means doing the same repeatable slice of work reliably, instead of a wide slice unreliably. Vercel's agent still qualifies leads and drafts responses; it just isn't holding capabilities nobody asked it to use.

How do you know what to cut? Start from what a skilled person on the team actually does day to day, then question every tool the agent has that isn't part of that observed, repeatable core. If a capability doesn't map to a real, recurring step, it's probably the next thing to remove.

Worth asking about your own setup before the next integration gets added, not after something goes wrong because of one that already did.