The seven questions every mid-market revenue team asks before deploying AI agents

Nearly every B2B company between $20M and $500M in revenue is running the same evaluation right now, and running it the same way. The CRO needs pipeline coverage without headcount. The CTO and the security lead need to know where the workload runs. The CFO needs to know which budget line it comes out of and what it does when volume moves.

The capability question was settled a while ago. Agents can research accounts, score intent, draft outreach, and maintain CRM records well enough that no serious buyer disputes it. What has not been settled is governance: what happens when an autonomous system touches a customer relationship, and who is accountable when it does.

Below are the seven questions as they actually get asked, with the answers we can substantiate. Two of them are not the answers a vendor would prefer to give. Those are the two worth reading.

1. Is our CRM data training somebody’s model?

The right first question, and the one where most vendor copy — including some of ours from last year — has been loose. The honest version has two halves.

The half we can state plainly is the architecture:

PrescientIQ is hosted and operated by MatrixLabX on Google Cloud, which maintains SOC 2, ISO 27001, and PCI DSS-attested infrastructure. Per-agent least-privilege identities, prompt-injection defense on every inbound surface, and an immutable audit ledger record every action, its rationale, and the approving human.

The half that matters to your reviewer is what that does not say. PrescientIQ is vendor-hosted and multi-tenant. It does not run in an environment you control, and we make no data-location guarantee. If you have seen material from us describing dedicated per-customer boundaries, it was wrong and it has been withdrawn. Where a single-tenant deployment is a hard requirement, we are not a fit today, and it is cheaper for both sides to learn that in week one.

Model-training exclusion is a contract term, not an architecture diagram. Require it in writing from any vendor you evaluate, ours included, and treat a web page as evidence of nothing.

SOC 2, ISO 27001, and PCI DSS attestations are held by Google Cloud, which operates the underlying infrastructure. They are not MatrixLabX certifications.

MatrixLabX application-layer SOC 2 is in progress.

2. What stops an agent sending something damaging to a customer?

Nothing stops a fully autonomous system from doing that, which is why this one is not fully autonomous. Agents do the labor — research, scoring, drafting, preparing CRM changes — and every externally visible action waits for a named person to approve it.

The engineering detail is the part that matters in a security review: the gate is enforced at the tool layer, not in the prompt. An agent that attempts to act without an approval fails closed. A system instruction asking a model to behave is not a control, because a model can route around text. A capability it does not hold is a control.

3. What does our compliance team see during an audit?

A record rather than a reconstruction. Every action, the reasoning behind it, and the human who approved it are written to an immutable ledger as they happen — which is the part of the platform statement above that compliance teams actually read.

What a reviewer can pull for any single action is bounded by what the statement above commits to, and it is worth being precise about the boundary rather than generous:

• the action itself, as executed;
• the rationale the agent recorded for taking it;
• the named human who approved it before it ran.

That is the commitment. Anything beyond it — cryptographic attestation of the record, forensic reconstruction of a model’s internal state — is something you should make a vendor demonstrate on a live system rather than accept from a diagram. Ours included.

Two clarifications that come up immediately, and that we would rather make before your auditor does. The SOC 2, ISO 27001, and PCI DSS attestations belong to Google Cloud as the infrastructure operator; they are not MatrixLabX credentials, and any vendor presenting inherited attestations as their own badge row is telling you something about how they will handle the rest of the review. Our own application-layer SOC 2 is in progress and is not finished.

4. We already have Salesforce and HubSpot workflows. Why another layer?

Because those workflows execute what somebody anticipated. They fire on static triggers and scheduled jobs, and they run the sequence that was configured last quarter regardless of what changed this week.

The practical test is one question: can your current automation notice that an account’s behavior changed, reason about why, and adjust the play — or can it only run the branch someone predicted? If the answer is the second, the gap is not a missing rule. It is that rules are the wrong instrument for the job.

A concrete version: an account goes quiet for three weeks, then two people from procurement visit pricing twice in a day. A workflow sees two page views and a stage that has not moved, so it does nothing, or it fires the same nurture email it would have sent anyone. Recognising that the visitor changed, that the pattern reads as an evaluation rather than research, and that the play should now route to the account owner with a different message is reasoning over context — and it is not a branch anyone writes in advance, because the interesting cases are the ones nobody predicted.

Agents sit on top of Salesforce and HubSpot rather than replacing them. The CRM stays the system of record, and the workflows you have already built keep running.

5. How much of our engineering team does this consume?

Less than a custom build, and the honest constraint is not the platform:

Read the qualifier rather than the number. CRM data quality is what actually moves that range. A CRM with inconsistent ownership, stale records, and three conventions for the same field will extend integration well past the platform work, and no vendor timeline survives contact with one. That is a reason to run the diagnostic before you commit engineering time, not after.

6. Which budget line does this come out of?

A direct annual agreement. Two contracted numbers, published:

$165,000 in year one, $150,000 recurring. One thing this is not, and you may have read otherwise: there is no Google Cloud Marketplace listing today, so there is no private-offer path that draws down against an existing cloud commitment. Material from us describing that route predates September 2026 and has been removed. It is a real procurement advantage when it exists, and we are not going to describe one that does not.

7. What happens to our bill when volume spikes?

The platform fee is inclusive, not a floor. There is no per-token meter and no per-action meter on the invoice, which is deliberate: a metered line invites you to model what the year will really cost, and that modeling exercise is the thing a published price is supposed to make unnecessary.

Scope beyond what a typical mid-market deployment runs — more agent bundles, sustained higher volume — is quoted during the audit, before anything is signed. The commitment is that it gets settled in advance rather than arriving as a surprise in month seven.

How the seven change by industry

The questions are constant; their order is not. Whichever one leads in your evaluation tells you which executive is actually blocking, which is usually more useful than the answer:

The pattern underneath all seven

Every one of these objections is a governance question wearing a technical costume. Security is asking who controls the data. Revenue is asking who controls the customer relationship. Finance is asking who controls the spend. None of the three is really asking what the model can do.

Autonomy without governance fails all three reviews. Governance without autonomy delivers a chatbot with a compliance page. What clears a mid-market procurement process is a control plane that is architectural rather than promised: an approval gate the model cannot route around, a ledger written as things happen, and a price that does not move after signature.

Agents execute. Humans approve. Everything is on the record.

Where to start

Not with a pilot. Start with the diagnostic, because it is the only step that produces information about your environment rather than about the product. The Autonomous Audit Report runs against a sample of your CRM and returns where coverage is leaking, what your current configuration is paying for, and what the governed alternative looks like on your data — before any commitment. If you are further along and evaluating specific vendors, the buyer-side governance checklist is the companion to this post: same control questions, pointed outward.