Article
v1.0
The GTM architecture a capable agent still needs
Shared State, organisational knowledge, and a learning loop let familiar capabilities work together, giving people a better starting point for decisions.
A capable AI agent can still operate inside a weak GTM system.
Meeting preparation makes the problem easy to see.
An agent can research an account, summarise the last call and generate questions in seconds.
But the rep may still have to work out:
→ What actually changed?
→ What matters most?
→ What is still unproven?
→ What threatens the deal?
→ What needs to happen next?
The agent improved the summary.
It didn’t necessarily improve the decision.
This is where I think the distinction between AI-assisted and AI-native starts to matter.
→ AI-assisted makes the existing task faster
→ AI-native changes the system producing the work
Instead of reconstructing the deal for every meeting, the system maintains what is true now and what changed. It knows how the company operates and what good looks like. Then it brings together the capabilities needed for the objective in front of it.
Meeting Preparation is one example.
The same model applies across GTM.
→ Propensity Assessment determines why an account deserves attention now.
→ Deal Risk identifies what threatens progression, the evidence behind it and the appropriate response.
→ Pipeline Review surfaces the deals that actually require management attention.
→ Forecasting explains the number, the evidence behind it and what could change it.
These are familiar pieces of GTM work.
The leverage comes from not treating each one as an isolated AI workflow.
They can operate on the same underlying State, organisational knowledge and system of learning.
Improve what the system understands about a deal and multiple sales capabilities can benefit.
Improve how the organisation qualifies opportunities and that knowledge can shape meeting preparation, deal assessment and pipeline review.
Connect decisions to outcomes and the lesson doesn’t have to stay with one rep or manager.
That’s a very different economic proposition from making individual tasks faster.
Less time reconstructing reality. Less effort reconciling interpretations. Better allocation of attention. Better starting points for the decisions people actually own.
For RevOps, I think this changes the design question.
Not just:
What can we automate?
But:
What system needs to exist for these capabilities to perform well, every time?
Agents are an important part of that system.
They are not the architecture.
This essay is versioned. Where our thinking develops materially, we will update the version and explain why - the revision history is preserved, not polished away.