Imagine this happening inside a revenue system.
A visitor from a target account reaches your website. An intent platform identifies the company. An enrichment tool finds the likely contact. An AI agent reviews previous conversations, decides the account deserves attention, updates the CRM and drafts a personalised follow-up.All of this happens before anyone on the revenue team opens the account.
It sounds like efficient GTM execution. It may well be.
But it is also several automated decisions built on data from multiple systems - each with different owners, definitions and levels of reliability.
What happens if the visitor was identified incorrectly? What if the enrichment data conflicts with the CRM? What if the account is already in an active sales conversation? What if the AI changes something that triggers another workflow?
The biggest risk with GTM AI is no longer a poorly written email.
It is a plausible but incorrect decision spreading through your revenue systems.
Until recently, most Marketing Operations and Revenue Operations teams used AI for relatively contained tasks:
A person remained between the AI output and the operational action.
That boundary is now disappearing.
The HubSpot connector for Claude can create and update CRM records, log activities and create tasks. Clay's Account Research Agents can turn CRM, engagement, enrichment and intent data into structured account intelligence that triggers other plays. Gong's MCP capabilities can make conversation history, objections, buying signals and account context available to AI agents across the revenue stack.
The tools are becoming more capable. The governance around them is not necessarily improving at the same pace.
Most teams still focus on the prompt:
"Have we given the AI enough instructions?"
That matters, but it is not the most important question.
A detailed prompt cannot fix stale CRM data. It cannot resolve unclear system ownership. It cannot prevent a badly scoped permission from affecting hundreds of records. It cannot guarantee that an incorrect action can be reversed.
Before improving the prompt, RevOps needs to define the guardrails.
The current direction of GTM technology is clear: bring more customer context together and allow AI to reason across it.
In theory, this should produce better decisions.
In practice, the agent may be working with:
These sources do not automatically agree.
An enrichment provider may classify an organisation as an enterprise account while the CRM still categorises it as mid-market. A recent call may reveal that an opportunity is no longer active, but the opportunity stage has not been updated. An intent platform may identify an account without identifying the person researching the product.
Giving an AI agent access to every source does not resolve those conflicts. It simply gives the agent more information to interpret.
This is particularly important because the underlying data-readiness problem remains unresolved. Salesforce's State of Data and Analytics research found that only 43% of surveyed data and analytics leaders had established formal data-governance frameworks. Forty-two percent lacked full confidence in the accuracy and relevance of their AI outputs, while respondents estimated that 26% of organisational data was untrustworthy.
This is enterprise research rather than a GTM-specific benchmark, but the implication is difficult to ignore.
A GTM AI agent does not need a 40-page governance document before it can deliver value. It does, however, need clear boundaries.
A practical review should answer four questions.
Not every connected data point should have equal authority.
The team needs to decide which system governs important information and what happens when sources disagree. Human-entered CRM data, third-party enrichment and AI-generated conclusions should not silently overwrite one another.
An agent should also be allowed to say, "I do not have enough reliable information."
That is not a failed automation. It is a useful safeguard.
If an account cannot be identified confidently, the agent should pause. If its recommendation depends on outdated information, it should flag the issue. If two important sources conflict, it should surface the conflict rather than quietly choosing the most convenient value.
There is a significant difference between reading a record, recommending a change and executing that change.
An account-research agent may need to create a summary or propose a next step. That does not mean it needs permission to change opportunity stages, reassign ownership or enrol contacts in outbound campaigns.
This is where teams should apply the principle of least privilege: give the agent only the access required for the use case being tested.
HubSpot's Claude documentation provides a useful example. The connector can create and update records, but HubSpot notes that certain custom validation rules are not applied when records are changed through the connector. HubSpot therefore recommends testing with a single record, reviewing proposed changes and requiring approval for write actions.
The lesson applies beyond HubSpot. Never assume an AI action will pass through every safeguard used by a person working directly inside the CRM.
Test the actual route the agent will use.
Not every AI action needs the same amount of supervision.
Reading and summarising account information may be safe to automate. Drafting an email is more consequential but still reversible. Sending that email, changing ownership or updating an opportunity stage can affect customer experience, reporting and pipeline management.
Human involvement should increase with the consequence of the action.
A useful starting principle is:
The objective is not to place a person in front of every automation. That would remove much of the value.
The objective is to place human judgement where an incorrect action would create meaningful commercial or operational damage.
When an agent makes a change, the team should be able to answer:
HubSpot records actions taken through its Claude connector in the audit log against both the user and the connector. That provides useful attribution, but an audit entry alone is not a recovery plan.
RevOps still needs a practical way to isolate an automation run, inspect its changes and restore affected records when required.
If an automated decision cannot be explained or reversed, it probably should not be fully autonomous.
Consider a company that wants to use intent, enrichment and conversation data to identify accounts ready for personalised outreach.
The tempting approach is to connect the systems and allow the agent to execute the complete workflow.
A safer first version would ask the agent to produce a recommendation explaining:
The account owner can then accept, reject or edit the recommendation.
That feedback is valuable. It reveals where information is missing, which signals are unreliable and how frequently the agent's reasoning needs correction.
Once the team understands those failure patterns, the agent can be given limited authority - for example, creating a task or adding a clearly identifiable AI-generated summary.
More consequential actions can be introduced only after the evidence supports them.
This may appear slower than switching on full automation. In reality, it is usually faster than repairing CRM data, incorrect routing and poorly timed customer communication after an uncontrolled rollout.
The market is rapidly moving towards AI agents that can reason across the GTM technology stack.
The competitive advantage will not come from connecting the largest number of tools or writing the longest prompt. It will come from knowing which decisions should be automated, which data deserves authority and where human judgement still creates value.
This does not require turning Marketing Operations into an AI compliance department.
It requires treating AI actions with the same discipline already expected from lead routing, lifecycle management, CRM integrations and revenue reporting.
Before giving an agent access to your revenue systems, ask four questions:
The goal is not to slow AI adoption.
It is to build enough trust that the business can use AI beyond a small experiment - without giving an untested agent the keys to the entire revenue engine.
|
Build trust before adding autonomy Planning an AI workflow across your CRM and GTM systems? Structured GTM can help design the data, automation and governance foundations behind it. |