The stack
- Tooling
- a Claude plan with Claude Code + the MCP connectors you need
- Per run
- cents of model usage; no per-task automation bill
- First migration
- an afternoon to move one automation and gate it
- The payoff
- one readable brief replaces a cluster of unmaintained zaps
The problem
Open your ops team's automation account and count the zaps. Half are named 'Copy of lead router (FINAL)(2)', a third are paused, and nobody left in the building remembers what two of them do. Every one of them was a reasonable idea on a Tuesday. Together they are a tax you pay forever, and the person who built them moved on in Q2. This is the glue tax, and it compounds.
The deeper problem is where the logic lives. In a Zapier zap or an n8n flow, your actual go-to-market policy, who gets routed where, what counts as material, when to alert a human, is smeared across triggers, filters, formatter steps, and paths. Changing one rule means spelunking a canvas of nodes and hoping you did not break the branch three steps down. The thing that should be a paragraph is a diagram.
A Claude agent collapses the pile. Give it MCP connectors to the tools it needs, HubSpot, Slack, Drive, and it does the reading, reasoning, deciding, and writing that used to be spread across ten glue steps. The logic lives in a brief written in plain language, the kind a new RevOps hire can read and change without a diagram. Fewer moving parts, one place to look when something is off.
This is a capability you hand out carefully, not a toy. The agent can write to your CRM and message your customers, so you start read-only, gate the irreversible actions behind a human, and log everything it does. Earn trust in that order, and one agent quietly replaces a wall of zaps nobody was maintaining anyway.
How it works
- 01 Fire the agent Webhook / Routineevent or cadence, the only glue
- 02 Read the context Claude + MCPCRM, Slack, Drive, over connectors
- 03 Apply the judgment Claude Codethe logic, as a readable brief
- 04 Gate the risky bits Humansends, deletes, customer writes
- 05 Act on the safe bits Claude + MCPscore, draft, write, alert
- 06 Log every run Slack / Sheetauditable, not archaeology
- Pick one automation to move first, ideally a read-heavy one with a low blast radius
- Connect the tools it needs over MCP: HubSpot, Slack, Google Drive, whatever the task touches
- Write the logic as a brief, not a flowchart: what to read, how to decide, what to do
- Gate the irreversible actions (sends, deletes, CRM writes) behind a human until you trust it
- Fire it from a webhook for events or a Claude Routine for a cadence, and log every run
- Watch it for a week read-only, then let it act, then move the next automation over
The playbook
Pick the first automation to move
Do not start with the scariest, most business-critical flow. Start with one that reads a lot and writes little, and whose worst-case failure is a shrug, not an incident: a daily 'new signups digest', a 'flag deals with no next step' check, a 'summarize this week's closed-lost reasons' job. You want a real win with a small blast radius while you learn how the agent behaves.
Write down, in plain sentences, what the automation actually does today. If you cannot describe it in a short paragraph, that is the tell for why the Zapier version is unmaintainable, and it is exactly the logic the brief will make legible.
Note every tool it touches. Those become the MCP connectors you attach in the next step, and the list is usually shorter than the zap made it look.
TipMove a read-heavy job first. An agent that summarizes and flags is safe to get wrong on day one; an agent that emails customers is not. Earn the write access.
Connect the tools over MCP
Attach the MCP connectors for the tools the task touches: HubSpot or Salesforce for the CRM, Slack for alerts, Google Drive or Notion for docs. MCP is the standard that lets Claude read and write in those tools directly, which is what replaces the pile of per-app Zapier connections. One agent, many connectors, no formatter steps in between.
Scope the access to what the task needs and no more. If the job only reads deals and posts to one Slack channel, it does not need write access to every object in the CRM. Least privilege here is the same discipline you would apply to any service account.
For anything MCP does not cover, the agent can still call an API directly, but reach for a connector first: it is the difference between the agent working your tools like a teammate and you hand-rolling integration code.
Write the brief, not the flowchart
This is the whole shift. Instead of wiring nodes, you write the agent a brief: what to read, how to judge it, what to do, and when to stop and ask a human. The logic that was smeared across a canvas becomes a paragraph a person can read and edit. Keep it specific and decisive, the same way you would brief a sharp new hire who has your tools but not your context.
Encode the judgment explicitly, because that is where the value is. 'A deal is at risk if the last activity is over 21 days old and the amount is above 50k' is a rule the agent applies consistently every run, and it lives in one readable line instead of a filter buried three steps deep.
Say what NOT to do as clearly as what to do. 'Never email a contact flagged do-not-contact. Never delete a record. If a deal has no owner, post to #revops-triage instead of guessing.' The guardrails are part of the brief, not an afterthought.
TipIf you cannot write the automation's logic as a short brief, you do not understand it well enough to automate it safely yet. That is a feature: the brief forces the clarity the zap let you skip.
Gate the irreversible actions
Split the task into what is safe to do automatically and what needs a human. Reading, summarizing, scoring, drafting: let the agent do those freely. Sending an email, writing to a customer-facing field, deleting anything: route those through an approval step until the agent has earned the trust, the same human-in-the-loop discipline that keeps the post-call and inbound plays safe.
Start the whole thing read-only for the first week. Have it produce what it WOULD do, post that to a Slack channel, and let a human eyeball it. When the 'would-do' has been right for a week, flip the safe actions to automatic and keep the gate on the irreversible ones.
Log every action the agent takes to a channel or a sheet. When something looks off, you want a plain record of what it read and what it did, not a Zapier task-history archaeology dig.
Trigger it, watch it, then move the next one
Fire the agent the way the task wants: a webhook for event-driven jobs (a form fill, a closed deal), or a Claude Routine for anything on a cadence (a Monday digest, a nightly hygiene pass). That trigger is the only glue left; everything downstream is the agent.
Watch it for a week, then trust it, then move the next automation over. Each one you migrate deletes a cluster of zaps and pulls more of your go-to-market logic into readable briefs instead of a canvas nobody owns.
Keep a running list of what you have moved and what each agent is allowed to do. That list is your new automation map, and unlike the Zapier account, a person can actually read it.
What you get
The same lead-router logic, before as an eleven-step zap and after as one readable agent brief.
BEFORE (Zapier, 11 steps):
Trigger: new form submission -> Formatter (split name) -> Filter (has email?) -> Clearbit lookup -> Paths (A/B/C by size) -> Formatter (build message) -> HubSpot create -> Delay -> HubSpot update owner -> Slack (channel) -> Filter (is customer?) ... (paused since March, owner left in Q2)
AFTER (one Claude agent brief):
"On a new inbound lead:
- Research the company from the email domain (size, industry, role).
- Check HubSpot for an existing account or open deal FIRST.
- If existing: route to the account owner, stop.
- Otherwise score hot/warm/nurture against our ICP (industry in {list}, size {range}, decision-maker title, work email, intent signal).
- Write the record + owner to HubSpot. Post the hot ones to the rep in Slack with context.
- If anything is missing or ambiguous, post to #revops-triage instead of guessing.
Never email the lead. Never delete a record."
One paragraph, one place to change it, one agent to run it.Pitfalls to avoid
Handing over write access on day oneAn agent with full CRM write and email access on its first run is how a small logic slip becomes a customer-facing incident. Start read-only, gate the irreversible actions, and expand access as it earns trust.
Recreating the flowchart in proseIf your brief is just the zap's ten steps written out as ten numbered commands, you kept the brittleness and lost the readability. Write the judgment and the goal; let the agent handle the sequencing.
Over-broad connector accessAttaching a connector with write access to everything, for a task that reads two objects, is a needless blast radius. Scope MCP access to what the task actually touches.
No loggingAn agent you cannot audit is an agent you cannot trust. Log what it read and what it did to a channel or sheet, so a surprising outcome is one scroll to explain, not a forensic project.
Migrating the scariest flow firstStart with a low-blast-radius, read-heavy job. Moving your revenue-critical routing on day one, before you know how the agent behaves, is a bet with no upside worth the downside.
Questions people ask
- Is this safe? I'm nervous about giving Claude write access to the CRM.
- You should be, and the answer is to earn it in stages. Start read-only: the agent produces what it WOULD do and posts it for a human to check. After a week of that being right, let it do the safe actions (scoring, drafting, internal notes) automatically, and keep a human gate on the irreversible ones (customer emails, deletes, key field writes). Scope MCP access to what the task needs, and log every action. That is how you get the speed without betting the CRM on day one.
- Does the Claude agent replace the trigger too, like the form webhook?
- No, and I would not claim it does. Something still catches the event, a form submission, a closed deal, a schedule, and hands it to the agent. That trigger is a thin webhook or a Claude Routine, and it is the one bit of glue you keep. What collapses is everything after it: the filters, formatter steps, and branch logic that used to be smeared across a zap now live in the agent's brief.
- When should this be Claude Code versus a Routine versus the API?
- Rough guide, and there is a fuller one at /claude/which-claude-should-i-use/: use a Claude Routine when the job runs on a cadence and you want it hosted with no infra; reach for Claude Code or the API when it is event-driven, needs your own trigger, or you want to run it on your own machine. The brief and the MCP connectors are the same either way; you are just picking where it runs.
- What about the automations that genuinely aren't Claude's job?
- Leave them. Some things are better as a plain webhook or a purpose-built tool, and pretending otherwise is how you end up with a worse version of Zapier. The win is moving the judgment-heavy automations, the ones where a rule needs to be read and reasoned about, onto an agent. The dumb pipe-A-to-B connections can stay dumb pipes.