Your CRM Now Ships Its Own Agents. What They Can and Cannot Approve.

The buying question changed sometime in the last eighteen months, and a lot of evaluation frameworks have not caught up. It used to be whether to add AI agents to the revenue stack at all. That question is closed: if you run Salesforce or HubSpot, you already own agents, because your system of record now ships them as part of the platform. The open question is narrower and considerably more useful — what are those agents scoped to do, and what happens to the work that falls outside the scope?

This post is not a verdict on either product. Product surfaces move faster than any article about them, and a capability claim written in September is often wrong by January. What does not move that fast is architecture. An agent that lives inside a system of record inherits that system's boundaries, and the four questions below are the ones that reveal where those boundaries sit in your particular motion. Every one of them is answerable in a live demo, by the vendor, in front of you.

What “CRM-Native” Actually Means

Strip away the branding and a CRM-native agent is a capability of the platform rather than a system in its own right. It authenticates through the platform, reads the data the platform holds, writes through the platform's permission model, and is governed by the platform's administrative controls. That is a genuine advantage, and it is worth saying plainly before the caveats: a native agent arrives already knowing your object model, already inside your permission scheme, and already covered by whatever data processing agreement you signed years ago. Nothing to integrate is a real feature, not a consolation prize.

The same property is also the limit. The agent's native reach is the platform's reach, so the interesting question is not what it can do inside that box but what your workflow requires outside it. This is the same distinction drawn in software utility versus digital labor: a utility holds state and waits to be operated, while labor performs the task end to end. A native agent can be either, depending entirely on whether the task ends where the platform does.

Question 1: What Is the Agent Permitted to Write To?

Ask for the write scope as a list, not a description. Which objects, which fields, which external surfaces — and critically, what the agent does when a workflow needs something outside that list. There are only three possible answers and each tells you something different: it stops, it asks a human to finish the job manually, or it calls out to another system through a connector whose permissions you now also have to understand.

Most mid-market revenue workflows cross at least two boundaries. A trial-conversion play reads product usage, checks the CRM, drafts a message, and writes an outcome. An expansion play reads support history, billing state, and usage before it touches anything a seller sees. The moment a workflow spans systems, someone has to be accountable for the whole of it, and “the CRM agent does its part” is not an accountability model — it is a description of a seam.

Question 2: Whose Identity Does It Act Under?

This is the question most likely to be answered vaguely, and it is the one with the longest tail. When an agent updates an opportunity, the audit log records an actor. Ask to see it. If the actor is the agent, with its own identity and only the permissions its job requires, the record can attribute the action and you can revoke that agent's access without touching anything else. If the actor is a shared integration user — one identity behind which several automations and occasionally a human all act — then the log shows that the record changed without showing what changed it.

Attribution is not an abstract virtue. It is the first thing anyone asks for after an incident and the first thing an assessor asks for during a review, which is why it appears in the governance questions to put to any AI agent vendor. It also gets more expensive to retrofit with every automation that inherits the shared account, so the cost of deferring this question compounds quietly for about a year and then arrives all at once.

Question 3: What Does an Approval Actually Record?

Every vendor in this category will tell you there is a human in the loop. The useful follow-up is: what does the human's decision write, where is it written, and who can change it afterwards? There is a meaningful difference between a notification that was clicked and a record of a decision — the first is an event in a queue, the second is an artifact you can produce eighteen months later when someone asks why a particular action was taken and who authorised it.

The sharper version of the question is what a rejection does. If declining an action blocks it, the approval sits on the execution path and is a control. If declining it files a note while the action proceeds — or proceeds after a timeout, which is the same thing with better manners — then the approval sits beside the execution path and is a notification. That distinction is the whole subject of approval gates that actually hold, and it does not resolve in a feature list. It resolves in a demo where you press decline and watch what happens.

Question 4: What Happens at the Boundary?

The first three questions are about the agent. This one is about your architecture, and it is the one that determines whether you need a second layer at all. Take the workflow you most want automated and trace it: where it starts, every system it touches, where it ends, and who is accountable if it half-completes. If that trace stays inside the system of record, a native agent is very likely the right purchase and adding an execution layer above it would be paying twice for one boundary.

If the trace leaves and comes back — and for trial conversion, expansion, and governed outbound it almost always does — then you are not choosing between products. You are deciding which layer owns execution across systems and what record that layer produces. Run a real workflow through the branches below rather than a hypothetical one.

Where CRM-Native Agents Are the Right Answer

It is worth being specific about this, because a post that finds against the native option in every scenario is selling rather than advising. Native agents are a strong fit wherever the work is CRM-resident and the judgment is low-stakes: field hygiene and deduplication, summarising a long activity history before a call, routing a record to the right owner, drafting an internal note, suggesting a next step for a human to accept or ignore. In all of these the data is already in the platform, the action stays in the platform, and nothing leaves the building.

They are also the right answer when the alternative is nothing. A team with no automation and no appetite for an integration project gets more value from switching on what the platform already offers than from a twelve-month evaluation of something better. The consolidation argument in the CMO's consolidation playbook cuts both ways: fewer moving parts is a real benefit, and a native agent is the fewest moving parts available.

Where an Execution Layer Sits Instead

The case for a layer above the systems of record is not that it has better agents. It is that cross-system work needs one accountable owner, one approval path, and one record — and none of those can live inside a system that only sees part of the workflow. Where the CRM agent's audit trail necessarily ends at the CRM's edge, a governed execution layer records the whole chain: which agent acted, under which identity, on what evidence, and which named human approved the step that left the building.

That is the arrangement PrescientIQ™ implements, and the architecture behind it is described in how governed digital labor is actually built — specialist agents with scoped identities, an orchestration layer that routes work between them, a human approval gate on consequential actions, and an append-only ledger that records every decision. The two models are not mutually exclusive. The native agent keeps the work that begins and ends in the system of record; the layer above carries what crosses. What is not workable is running both without deciding which one owns a given workflow, because two agents acting on the same object under different approval models is how most agent-related incidents start.

If the honest answer to Question 4 is that nobody currently owns the cross-system case, that is worth knowing before the next renewal rather than after it — and it is the same diagnosis behind why so many agent pilots hit their targets and were not renewed.