An agent opens an account record in the CRM.
The warehouse has a different lifecycle stage. The enrichment tool has a newer employee count. Slack has the most recent human context. The call notes show the deal is slipping.
Now ask the practical question: what should the agent do?
Should it update the CRM? Open a task? Flag the conflict? Ask for approval? If the systems disagree, which one wins?
This is the GTM problem I keep coming back to.
A lot of AI conversation starts at the model layer: prompts, reasoning quality, tool calling, and agent frameworks. Those things matter. But near revenue work, the bigger constraint is usually lower in the stack.
Most teams still do not have the operating conditions that let software interact with GTM systems safely.
The old stack was built for humans. A rep can notice ambiguity and work around it. A RevOps lead can inspect a field, ask a teammate, and decide which system is right. A manager can tolerate a noisy sync because they know where the exceptions live.
Agents do not get that luxury.
They experience the GTM stack as schemas, permissions, sync conflicts, missing context, and action boundaries. If those are unclear, the agent is not autonomous. It is just fast in the wrong direction.
That is why I think the useful question is not: how will AI change GTM?
The better question is: what has to be true before an agent can safely help run GTM work?
My current answer is five conditions.
The five conditions
A practical checklist for deciding whether revenue data is ready for agentic work.
| Condition | Question | Failure Mode | What Good Looks Like |
|---|---|---|---|
| Access | Can the agent reach the systems it is expected to use? | Credentials exist, but the agent cannot inspect the right objects or actions. | CRM, warehouse, enrichment, workflow, and collaboration tools expose deliberate interfaces. |
| Truth | Which source wins when records or fields disagree? | The model summarizes conflicting data confidently without knowing what is canonical. | Field ownership, freshness, and canonical records are explicit enough to resolve conflicts. |
| Boundaries | What can the agent read, propose, change, or never touch? | Safe notes, sensitive writes, and destructive actions are treated the same. | Reads, safe writes, approval-required writes, and restricted actions are separated. |
| Judgment | When should the agent answer, suggest, escalate, or stop? | Every signal becomes an action, even when review or context is missing. | Thresholds, review paths, handoffs, and escalation rules connect data to behavior. |
| Review & Budget | Can a human see what happened, interrupt it, and manage spend? | The system appears useful but becomes hard to trust, audit, or govern. | Logs, source traces, approval stops, interruption points, and spend controls are present. |
Access
An agent needs more than raw credentials. It needs a deliberate interface into the tools it is expected to use.
The exact interface can vary. The important question is whether the system exposes the right objects and actions in a way software can use without guesswork.
Can the agent read the account record? Can it see the related opportunity? Can it inspect recent activity? Can it query the warehouse-backed fields that explain why the account matters? Can it understand what actions are available?
If the answer is no, the agent is not operating in the GTM system. It is operating near it.
Truth
If the CRM says one thing and the warehouse says another, the agent needs a rule for what is true.
Which system owns the field? Which record is canonical? How fresh is the data? What happens when two sources disagree?
Without those rules, you do not have agent context. You have competing guesses.
This is where a lot of GTM AI breaks down. The model can summarize the record. It can generate a recommendation. It can sound confident. But if the underlying system cannot tell it which field to trust, confidence is not the same as correctness.
Boundaries
Reading a record is not the same as changing a lifecycle stage.
Drafting a note is not the same as enrolling an account in a sequence.
Creating a follow-up task is not the same as merging or deleting a record.
The system has to decide which actions are safe to automate, which actions require review, and which actions should stay off-limits.
This is the missing governance layer in a lot of agent conversations. The question is not simply whether the agent can act. The question is which actions deserve autonomy, which deserve approval, and which should stay human-owned.
Judgment
Even when the data is clean and the tools are connected, the agent still needs a way to decide whether to answer, escalate, suggest, or act.
That means thresholds, review paths, and handoffs.
Not every signal deserves the same action. Not every action deserves the same level of autonomy. A missing activity log may deserve a note. A slipping enterprise deal may deserve escalation. A conflicting field may deserve review before anything changes.
Judgment is where the system connects data to operating behavior.
Review and budget
If an agent can touch revenue work, someone needs to know what it saw, what it did, what it cost, and where a human can interrupt it.
Otherwise the system becomes hard to trust even when it appears useful.
Logs matter. Review queues matter. Approval stops matter. Budget controls matter. So does the ability to trace an output back to the sources and rules that produced it.
The more an agent moves from answer generation toward action, the more important this layer becomes.
This is the layer I am spending more time on now
I am not treating GTM AI as a prompt problem.
I am treating it as a systems problem: interfaces, data ownership, approval gates, workflow design, and the operating rules that determine whether software can be useful without becoming reckless.
My own current build is narrower than a full customer GTM deployment, but it reinforces the same point.
In the research and drafting workflow I am building now, the useful work does not come from generated text alone. It comes from making the workflow explicit: what sources are allowed, what claims need evidence, what can draft automatically, what must stop for review, and where Tyler approval is required before anything external happens.
That is not proof that every GTM team should copy the same workflow.
It is a build-scoped example of the broader pattern: once software moves closer to action, operating structure matters more than demo quality.
That is also why I do not think the next useful wave of GTM AI will be defined by one model or one app.
It will be defined by whether the underlying system can give the model the right context, through the right interface, with the right permissions, and under the right human controls.
That is the work I am mapping now.