The Future of AI GTM Systems: From Tools to Infrastructure
The GTM engineering stack is being built right now
Something is happening in GTM engineering that most people are missing.
The conversation has moved past "how do I use AI for sales" and into something much more structural: how do I build AI systems that operate my entire go-to-market motion?
Not prompts. Not chat. Not one-off automations. Actual infrastructure — with version control, composable logic, deployed outputs, and measurement loops.
Smart people in GTM engineering like Scott Martinis have been talking about this publicly. His framework for building "agentic GTM operating systems" lays out a vision that goes far beyond what most teams are doing today. And the practitioners building this way are getting results that make traditional GTM ops look like manual labor.
Here's what's emerging — and where we think it's going.
The architecture of an AI GTM system
When you talk to the people actually building these systems, a clear architecture emerges. It has six layers, each building on the one below it.
Let's break this down.
Layer 1: The data layer
Everything starts with getting your GTM data into a place where agents can access it. CRM exports, Gong transcripts, sales enablement content, contact data, enrichment, signals, deal snapshots, competitive intel.
As Martinis puts it: "Context is everything. Perfect file systems don't matter as much as just having it where Claude can find it."
Most teams think they need perfect data hygiene before they can build with AI. They don't. They need access. Get it all into a repo, a data lake, or a connected system. Structure comes later. Access comes first.
Layer 2: The knowledge graph
This is where things get interesting — and where most current tooling falls short.
Enrichment tools (Clay, Apollo, ZoomInfo) give you data on demand. A knowledge graph is different. It's a persistent, constructed model of your company's GTM reality. Your ICP definitions. Your buyer personas. Your sales process. Your competitive positioning. Your win/loss patterns.
It's not "look up this account's employee count." It's "given everything we know about how we sell, who we sell to, and what works — what should we do next?"
This graph gets built from the data layer — synthesized from CRM history, call transcripts, enablement content, and deal outcomes. And it compounds over time. Every deal you close, every call you record, every signal you track makes the graph smarter.
Layer 3: Composable skills
Once you have a knowledge graph, you need reusable intelligence that operates against it.
Think of skills as functions. An "ICP scoring" skill takes an account and scores it against your graph. A "personas" skill maps contacts to your buyer personas. A "messaging" skill generates positioning tailored to a specific segment and stage.
These aren't prompt templates. They're modular, composable modules that any workflow can call. You chain them together:
ICP Score → Persona Match → Messaging Framework → Output
The power is in composition. The same skills that power your ABM campaign also power your outbound sequences, your deal room generation, and your customer expansion plays. Build once, compose everywhere.
Layer 4: Agentic development
This is where and how your GTM OS gets built. And this is what's perhaps most different about how those at the forefront of GTM Engineering are building for scale.
Agentic development means treating AI-built GTM tools with the same rigor as software engineering:
- Spec it — Define what you're building, what systems are involved, what the desired outcome is
- Research it — Have the agent investigate the problem space
- Build it — Generate the solution
- Test it — Validate before deployment
This happens in code — via Claude Code, CLI tools, and version-controlled repos. Not in a chat window where outputs evaporate.
The reason this layer lives in code and not a GUI is scale. You're not building one thing. You're building systems that generate many things. A chat UI means a human in the loop for every iteration. Code means you define a pattern once and it runs.
Layer 5: Deployed outputs
Here's where the architecture diverges from everything that exists today.
Most AI GTM tools produce internal outputs — a spreadsheet row, a draft email, a report, a score. The human still has to take that output and do something with it.
An AI GTM system produces deployed, live outputs — personalized landing pages, ABM microsites, interactive sales tools, deal rooms, recap videos. Hosted. Shareable. Measurable. No human in between "generated" and "in front of the buyer."
This is the layer that turns internal intelligence into external revenue signal. And it's the layer most current tools completely lack.
Layer 6: Campaign attribution
If you're generating outputs at scale, you need to know what worked.
The "Campaign" object is the connective tissue: it associates generated outputs to a campaign, tracks which accounts engaged with them, and lets you say: "This ABM campaign used these 5 apps, served to these 20 accounts, and created $X in pipeline."
Without attribution, you're generating at scale with no way to measure at scale. The system works, but you can't prove it. And you can't optimize it.
Why this can't be built in a chat UI
There's a reason the practitioners building this way use Claude Code, not ChatGPT or Claude.ai.
A chat UI is great for one-off exploration. But building GTM infrastructure requires:
- Version control — Your GTM logic needs to be in a repo, not a conversation history
- Composability — Skills need to call other skills. Pipelines need to chain together
- Programmatic execution — "Generate 200 personalized landing pages" is a script, not a prompt
- Determinism — When you run a pipeline, you want the same behavior every time
- Integration — MCPs, APIs, CRM hooks, deployment pipelines
Martinis' framework starts with "repos for each client" and "set up clients in Claude Code" for a reason. This is engineering, not conversation.
Where Canvas fits today — and where it's going
We've been watching this architecture emerge for months. And Canvas is built to be the infrastructure layer that makes it real for GTM teams.
What Canvas does today
Data layer. Canvas connects to your CRM, Gong, sales enablement platforms, and other GTM data sources — pulling everything into a place where the system can reason against it. No manual exports. No copy-pasting context.
Knowledge graph. Canvas doesn't just access your data — it constructs and maintains a persistent model of your company's GTM motion. Your ICP, personas, sales process, and competitive positioning — synthesized from every connected source into a graph that compounds over time.
Composable skills. Reusable intelligence modules that operate against the knowledge graph. An ICP skill, a personas skill, a messaging skill — all composable into workflows. Build once, use across every campaign, sequence, and play.
Deployed outputs — instant and hosted. The apps, agents, and automations you build in Canvas produce live, shareable, customer-facing outputs. A personalized landing page is deployed the moment it's generated. Your rep gets a URL and sends it. No infrastructure ticket. No deploy step.
Canvas already covers the layers where most teams are completely stuck: turning internal GTM intelligence into deployed, customer-facing assets — with the knowledge graph and skills to make those outputs actually good.
What's coming
Programmatic access. The ability to build Canvas apps via Claude Code. Define a pipeline in code, point it at a list of accounts, and generate deployed apps at scale. The GUI for prototyping. The CLI for production.
Campaign attribution. A native Campaign object that ties every generated output back to pipeline and revenue. So when you run an ABM campaign that generates 50 personalized landing pages across 50 accounts, you can trace the line from "Canvas generated this" to "$X in pipeline."
This is happening now
The teams building this way today are small. They're technical. They're mostly running Claude Code with custom repos and duct-taping deployment themselves.
But the architecture is clear. The layers are defined. The demand is real.
The question isn't whether AI GTM systems will be built this way. It's who builds the infrastructure that makes it accessible to every GTM team — not just the ones with engineers on staff.
That's what we're building.