When should AI live inside the CRM versus outside it?
The wrong side of this line costs you the audit trail
If the work is CRM work it belongs in the platform, under its own approvals and audit trail. Outside is for what the platform cannot reach.
This is the architecture decision that determines what an agent deployment costs to run for the next five years. It’s usually made by accident — by whichever demo was most convincing, or by whichever team happened to build first.
It deserves to be made deliberately, and it’s a two-week decision rather than a two-year one.
Start inside, and make outside earn it
If the work is CRM work — triage, routing, summarization, next-best-action, quote preparation, anything whose subject is a record in the platform — it belongs in the platform.
The reason isn’t preference. Agent lifecycle, policy enforcement, approvals, execution monitoring and the audit trail are all native there. Build the same thing outside and you’re re-implementing all five, badly, and then maintaining them. Inside, you get one place to look when something goes wrong, one permission model rather than two, and no second system to license.
The test: if you can describe the agent’s job without naming a system other than the CRM, it goes inside.
What outside is genuinely for
Some work needs a model, a data source, a document pipeline or an integration the platform can’t reach. Then you build it outside, on a proper orchestration runtime, and integrate it back over a documented interface — grounding it against your live records so its output still resolves to data you can open.
Typical cases: heavy document extraction, a specialist model your sector requires, an agent that has to work across three systems of which the CRM is one, or work whose volume would be uneconomic inside a metered platform.
The expensive version of this mistake
It isn’t choosing wrong once. It’s choosing both, for the same work, at different times — an agent configured in the platform for one team and a custom-built equivalent for another, because two projects made the call independently.
Now you maintain two implementations of the same logic, two audit trails a reviewer has to reconcile, and two places where a rule change has to land. A rule changes, one of the two gets updated, and for a while the same company gives the same customer different answers. This is the state most organizations we’re called into as a rescue are actually in, and unwinding it costs more than either option would have cost done once.
So the split has to be a written decision that applies across the program, not a per-project instinct.
Where it runs is not which model it calls
Worth separating, because buyers conflate them constantly and it produces a bad conversation with procurement.
Where the agent runs is the runtime — the platform’s own studio, or an external orchestration service. It’s where the approval gates, the grounding and the audit trail live, and it’s the decision this article is about.
Which model it calls is separate and should stay open. Frontier models from more than one vendor, or one you host yourself where residency or a fine-tune requires it. The workflow logic sits in the runtime rather than in the model, so swapping the model is a configuration change rather than a rebuild.
A firm that welds you to one vendor’s model has handed you their negotiating position along with the invoice (how we keep the model swappable). A firm that’s opinionated about the runtime is telling you where its support experience is. That’s a different and more useful kind of opinion.
One caveat about versions
Native agent management is recent. If you’re on an earlier platform version, “inside” may mean planning an upgrade first — a real cost, and one that belongs in the decision rather than being discovered afterwards.
How we actually make the call
Four questions, in order:
- Can the platform’s native agent tooling do this? If yes, stop. It goes inside.
- What specifically can’t it reach — a data source, a model, a document type, a system? Name it. “Flexibility” isn’t an answer.
- What’s the running cost of each option, including metered AI actions inside versus infrastructure and maintenance outside?
- Who maintains it in year three? An external agent needs an owner who understands both ends. If that person doesn’t exist, inside is the safer answer even where outside is technically better.
Answer those in Discovery, in writing, before anyone builds. Getting this split wrong is what turns an agent program into a maintenance problem. Two weeks up front is what it costs to settle it before the build instead of after.
We settle the split in Discovery, before anyone builds either side; it is the first line of an automation plan with us.
Want this applied to your business?
Thirty minutes with a principal turns the general case into your specific list: which workflows, what they’re worth, and in what order. The article can only tell you what we would look at; the call tells you what we found.