Stop Building Zaps. Start Composing Agents.

TL;DR

For a decade, GTM teams glued their stack together with Zaps. If this, then that. Step 1 fires, step 2 fires, step 7 silently breaks at 11pm. That era is over. The new substrate is MCP, and the new unit of automation isn't a workflow, it's an agent. The shift rests on three things: tools that compose through one protocol, intent that replaces instruction, and an agent that is the workflow instead of a step inside it. At Spear, a real chain we run in production replaces what used to be a fragile six-step Zap with a single prompt across Slack, Apollo, and our own MCP. The change isn't incremental. It's architectural.

‍

The Zap That Broke at 11pm

Every ops person reading this has a story. A new lead came in. Step 1 fired. Step 2 fired. Somewhere around step 5, a field mapping changed, a rate limit hit, an API returned an unexpected null, and the whole chain quietly failed. Nobody noticed for three days.

‍

Zapier was a brilliant answer to a real problem. Over 25 million Zaps have been created, and roughly 69% of Fortune 1000 companies use Zapier in their tech stacks. That's not an accident. When machines couldn't reason, somebody had to write down the exact path from A to B. Zapier let non-engineers do that without code. It powered a decade of GTM glue.

‍

But it was always brittle. Users have long complained that Zapier is too "if this, then that," and that it forces them to look for more customization options, meaning other tools are needed anyway to fill the gap. The model assumes you know the exact sequence in advance. Reality doesn't work that way. Real workflows branch. They depend on context the trigger doesn't carry. They need judgment in the middle, not just at the ends.

‍

So teams built more Zaps. Then Zaps that called Zaps. Then a Zap monitoring dashboard. Then a Slack channel for Zap failure alerts. Then a person whose job became Zap maintenance.

‍

That's not automation. That's a part-time job with extra steps.

What an Agent Does Differently

Here's a real chain we run at Spear, in production, today.

‍

A prospect lands on our site and goes through our Navattic interactive demo. Navattic posts an automatic message into a Slack channel: someone from Company X just completed the demo, here's their email.

‍

That's the trigger. Now watch what happens.

‍

A Claude agent connected to the Spear MCP, Apollo, and Slack picks it up. Apollo resolves the email to a LinkedIn URL and pulls the prospect's company and role. The agent decides this person fits our ICP and warrants a senior-leadership touch, not a sales rep, not a junior SDR, but a connection request from two of our executives, staggered one week apart so the impact compounds. The agent creates a dedicated Spear campaign with the right messaging context, assigns the prospect to two profiles in our org, and pushes the outreach live.

‍

First reply came in 24 hours. From a senior buyer who'd just spent ten minutes inside our product.

‍

Now picture the Zap version. Trigger: Slack message received. Step 1: parse email out of message text. Step 2: call Apollo. Step 3: filter by ICP rules hardcoded in a Zapier Path. Step 4: push to a Google Sheet because Spear isn't in Zapier's catalog the way you need it. Step 5: notify a human to manually create the campaign. Step 6: the human forgets for two days.

‍

You could build that. People have. It breaks the moment Navattic changes the format of the Slack message, or Apollo returns a slightly different field shape, or the ICP logic needs to consider something you didn't anticipate when you wrote the Path.

‍

The agent doesn't break the same way. When the input shape shifts, it adapts. When the ICP needs nuance, it brings nuance. When something genuinely unusual happens, it asks.

Why This Is Architectural, Not Cosmetic

The shift from Zaps to agents isn't "Zapier with AI bolted on." It's a different paradigm built on three things working together.

‍

One: composability through a single protocol. Every tool that speaks MCP exposes its capabilities in a uniform way. You don't need a custom integration for each pairing. You don't need Zapier to have built a connector for the specific tool you care about. If a tool ships an MCP server, any agent can use it. The integration explosion that took Zapier from 700 to 1,400 apps in eighteen months, and now over 7,000, is being replaced by a protocol where the count doesn't matter the same way. The agent doesn't need to know the connector exists in advance. It discovers it.

‍

Two: intent over instruction. With Zaps, you write the steps. With an agent, you write the outcome. "When a prospect finishes our demo, get them in front of two of our execs over the next week" is a sentence. It used to be a six-step workflow. The agent figures out the path, and the path can change run to run without you rewriting anything.

‍

Three: the agent is the workflow. This is the deepest shift. In Zapier, the workflow is the structure and the steps are dumb. In the new model, the agent is the structure. It holds the goal, reads the context, picks the tools, and decides what to do next. It's not a step inside the automation. It's the thing doing the automating.

‍

Even Zapier sees it. In 2025, Zapier introduced Copilot, Canvas, and MCP support, enabling AI agents to discover and execute Zaps. The platform that defined the if-this-then-that era is trying to wrap itself in the language of the agent era. That's not a coincidence. That's a company reading the room.

What This Means for You

1. Stop building new Zaps for anything non-trivial. If a workflow has more than three steps, branches on context, or needs to make a judgment call, don't write it as a Zap. Compose an agent. The Zap will cost you less to build and more to maintain. The agent costs more to set up and less to keep alive.

‍

2. Audit what you already have. Most teams have a graveyard of Zaps nobody owns. Half of them are probably broken right now and you don't know. The other half are doing work that an agent could do better with context. Start with the ones that touch revenue.

‍

3. Pick tools that ship MCP servers. The protocol matters more than the feature list this year. A tool with a worse UI and an MCP server will beat a tool with a better UI and no MCP server, because the first one can be composed and the second one can't. This applies to your CRM, your enrichment tool, your outbound platform, your data warehouse, everything.

‍

4. Hire (or become) someone who can compose, not just configure. The ops skill that mattered for ten years was "knows how to build a Zap." The ops skill that matters for the next ten is "knows how to specify intent clearly enough for an agent to act on it, with the right tools wired in." That's a different muscle. It looks more like writing than clicking.

‍

5. Don't outsource judgment. The point of an agent isn't to remove humans. It's to remove the mechanical parts so humans can spend time on the judgment that actually matters. In our Navattic chain, the agent does the boring work: parse, enrich, match, draft, schedule. A human still reviews the messages before they go live. That's not a limitation. That's the point.

Frequently Asked Questions

Is MCP going to replace Zapier completely?

‍

For simple, two-step, well-defined integrations, Zapier still works fine and probably will for a long time. For anything with branching, context, or judgment, MCP-composed agents are already better and the gap is widening. Most teams will run both for a while before the balance tips.

‍

Do I need to be technical to compose agents?

‍

Less than you needed to be to build complex Zaps, actually. You're writing intent in natural language instead of clicking through a step builder. The skill is being precise about what you want, which is a writing skill, not an engineering one.

‍

What about reliability? Aren't agents non-deterministic?

‍

They are, and that's a real tradeoff. The way to manage it is to keep humans in the loop on anything irreversible. The agent does the work; the human approves the send. We do this at Spear by design: every outbound message is reviewed before it leaves a profile. The agent gives you speed; the human gives you trust.

‍

Does this only matter for outbound and GTM?

‍

No. Outbound is just where the brittleness hurt earliest because the inputs are the messiest. The same shift is happening in support, recruiting, finance ops, and engineering workflows. We're seeing it first in GTM because that's where the cost of broken automation is most visible.

‍

Where do I actually start?

‍

Pick one workflow that you currently maintain as a chain of three or more Zaps. Map what it's trying to accomplish in one sentence. Then wire up an agent (Claude, or whatever you prefer) with MCP access to the tools involved, and give it that sentence as its job. You'll learn more from running one real chain than from reading ten more posts like this one.

‍

At Spear, we built our MCP because outbound was where the if-this-then-that model was failing hardest. Buyers stopped responding to mechanical sequences. The teams that win now are the ones whose outreach reads like a person paid attention, because a person did, with an agent doing the work that wasn't worth a person's time. That's the shift. The Zap era built the plumbing. The agent era is what runs through it.

‍