Your CRM already has AI. That’s not the same as needing it.

Every CRM you might use already ships with AI. HubSpot has Breeze. Salesforce has Einstein and Agentforce. Both are real, both are improving, and both are being sold to you as the answer to a question you probably haven’t asked yet.

The useful question isn’t which one is better. It’s which of your problems needs a model at all.

Because most of them don’t. Automation follows rules you can write down; AI makes the calls a rule can’t. That line decides your whole stack, and almost every wasted AI budget we’ve seen starts by ignoring it.

What the CRM gives you for free

The native AI is genuinely good at the things that live inside the CRM and never leave it. Drafting the follow-up. Summarising a long thread nobody wants to read. Answering “what changed on this account” without you building a report. Scoring, where the platform already has the behavioural data.

Use it there. It’s included, it’s in the interface your team already has open, and it needs no maintenance from you. That last part is worth more than it sounds.

Where native AI runs out is at the edges of its own database. It reasons well about what it can see. It cannot enrich from a source the vendor doesn’t integrate, run a model you chose against data you assembled, or make a decision that depends on three systems at once. That isn’t a criticism. It’s a boundary, and knowing where it sits is most of the architecture.

What you build outside it

This is where Make.com and n8n earn their place. They sit outside the CRM, call whatever they need, and write the result back through the API. No tier to upgrade, no vendor roadmap to wait for.

The pattern that matters is conditional. Not “send everything to a model.” A workflow that decides, per record, whether this one needs judgment at all.

Concretely: a lead lands. Step one is deterministic and free — is the domain a real company, is the email role-based, does it match a disqualifying pattern? Most records get answered right there, at no cost and in milliseconds. Only what survives goes to a model, and then only for the part a rule genuinely can’t do: reading the free-text field and working out what they actually want.

Then the expensive question. If the cheap model isn’t confident, escalate to the better one. If the better one isn’t confident either, escalate to a person — which is the step everyone skips and the only one that makes the rest safe to run.

That’s the whole design. Cheap first, model second, human last, and each step only pays for the records the previous one couldn’t settle.

Automation and agents, in the same workflow

The industry keeps presenting this as a choice. It isn’t. The interesting systems are mostly deterministic with a model dropped into the two or three places where a rule can’t reach.

A rule routes the lead. A model reads the message and decides what it’s about. A rule writes the field. A model drafts the reply. A rule decides whether the draft is allowed to send on its own. Every model call is wrapped in deterministic logic on both sides, which is what makes it debuggable at two in the morning.

Give the agentic part a boundary and a log. It should be able to say what it did, why, and against what input — and something deterministic should check the answer before it touches a customer. An agent that can act without a rule downstream of it isn’t autonomy. It’s an unreviewed intern with API access.

Choosing, without the vendor in the room

Start from the work, not the tool. Write down the decision you want made, then ask whether a rule could make it. If yes, it’s automation, and it’s cheaper, faster and more reliable than a model — use the native workflow engine and stop.

If a rule can’t, ask whether the data lives entirely inside the CRM. If it does, the native AI is probably enough, and probably included in what you already pay. If it doesn’t — if the answer needs enrichment, a model you picked, or three systems agreeing — that’s the external orchestration layer, and that’s where we build it into the revenue engine rather than bolting it on.

The stack falls out of that. It usually looks boring: a lot of deterministic plumbing, a small number of model calls placed exactly where judgment is needed, and a human at the one point where being wrong would cost something.

Nobody demos that. It just works on a Tuesday, which is the only benchmark that ever mattered.