For the past two years, I’ve been working in the AI space with companies trying to understand a deceptively simple question:
What can we actually build with this?
Not the keynote version. Not the LinkedIn version. The operational version.
How do AI systems connect to real company data? How do they interact with CRMs, warehouses, enrichment tools, call intelligence platforms, Slack, and internal workflows? Where do they create leverage, and where do they just add another brittle layer to an already fragmented stack?
The AI shift is no longer only about model capability. It is about systems.
The models are improving quickly. The APIs are getting better. Tool calling, agents, MCP, workflow automation, and long-context reasoning are all moving from experimental to practical. But most company systems were not designed for agentic software.
That gap is where more of my attention is going now: agent-native GTM infrastructure, meaning the systems, data flows, workflows, and operating models that let AI agents safely interact with revenue systems.
I am less interested in broad predictions about how AI will change sales, and more interested in the implementation evidence companies leave behind. A product launch says one thing. A new API endpoint, a hiring plan, a permissions model, or a data sync pattern usually says more.
The research question for me is: which parts of the GTM stack are being rebuilt so agents can participate in real work, not just summarize it? That means watching how CRM platforms expose records, how enrichment tools structure context, how automation platforms package actions, and how teams describe the operator roles around those systems.
The future gets built through small, specific infrastructure decisions: a field mapping, a webhook, a permission surface, a schema design, a sync pattern, a review queue, or a workflow that makes a new action safe enough to use repeatedly.
Marketing pages tell you what a product wants to be. API docs tell you what it can actually do.
What I’m building now is a research system for tracking those changes as they happen. It watches job postings as market signals because a job posting reveals how a company is structuring work.
It studies product docs and API references because that is where the truth usually is. It looks at MCP, automation platforms, CRM data models, enrichment systems, reverse ETL, and analytics layers because agents need more than prompts.
The biggest pattern I keep coming back to is this: every company wants AI leverage, but most companies still do not have agent-ready data infrastructure.
They have CRMs. They have warehouses. They have enrichment tools. They have call intelligence. They have automation platforms. But they often do not have a clear ownership model across those systems.
That creates the same problems over and over. The account exists five times. The enrichment score is different in three places. The CRM says one lifecycle stage and the warehouse says another. The agent can query data, but cannot tell which record is canonical.
The practical frontier is whether the system can give the model the right context, through the right interface, with the right permissions.
I wrote a separate operating checklist for the more practical version of this question: what has to be true before agents should touch revenue data. That piece is the framework. This one is the reason I am mapping the category in the first place.
I think the next few years of AI implementation will reward people who understand both sides: the model layer and the operational layer. You need to know what agents can do, but you also need to know why CRMs become noisy, why GTM data breaks, why sync logic matters, and why approval gates are product design.
The goal is not to predict the future in broad strokes. The goal is to map the systems that are already changing.