Field notes
Your CRM already has AI. That’s not the same as needing it.
HubSpot has Breeze. Salesforce has Einstein and Agentforce. Both work. The harder question is which of your problems needs a model at all, and for most of them the answer is none.
Most AI questions in your CRM get framed as Breeze versus Einstein. The one that matters is whether a given problem needs a model at all. Usually it doesn’t; most are process and data problems, and a model only makes those more expensive.
On this page
Every CRM you might use already ships with AI. HubSpot has Breeze. Salesforce has Einstein and Agentforce. Both are real and getting better. They’re also being sold to you as the answer to a question you probably haven’t asked yet.
Which one is better matters less than which of your problems needs a model at all.
And most 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 started 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 holds the behavioural data.
Use it there. It’s already included, sitting in the interface your team has open, and it needs no maintenance from you, which matters more than you’d think.
Native AI runs out at the edges of its own database. It reasons well about what it can see. Past that it can’t enrich from a source the vendor doesn’t integrate, or run a model you chose against data you assembled, or reach a decision that depends on three systems at once. That’s the 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 and write results back through the API, calling whatever they need along the way. There’s no tier to upgrade and no vendor roadmap to wait on.
The pattern that matters is conditional. Rather than sending everything to a model, the workflow decides, per record, whether that one needs judgment at all.
Concretely: a lead lands. Step one is deterministic and free - is the domain a real company, does the email 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’re after.
Then comes the expensive question. If the cheap model isn’t confident, escalate to the better one. If that one isn’t confident either, escalate to a person. Everyone skips that last step, and it’s what makes the rest safe to run.
That’s the whole design. Cheap checks handle most of it, a model takes what’s left, and each stage only pays for the records the one before it couldn’t settle.
Automation and agents, in the same workflow
The industry keeps framing this as a choice between automation and agents. It isn’t one. The systems that hold up are mostly deterministic, with a model dropped into the two or three places a rule can’t reach.
A rule routes the lead. A model reads the message and works out what it’s about. A rule writes the field; a model drafts the reply; a rule decides whether that draft can send on its own. Every model call sits wrapped in deterministic logic on both sides, which is what makes the thing debuggable at two in the morning.
Give the agentic part a boundary and a log. It should be able to say what it did and why, and against what input, with something deterministic checking the answer before it reaches a customer. An agent that can act with no rule downstream of it is an unreviewed intern with API access, whatever the vendor calls it.
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 it can, that’s automation, cheaper and more reliable than a model, so 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 logic, 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 a stack like that. But it holds up on an ordinary Tuesday, and for revenue systems that’s the benchmark that counts.