Agentic GTM Is a Data Problem Before It Is an AI Problem

Over the past year, almost every tool in the go-to-market stack has learned to talk to AI agents. The CRM has an MCP server. So do the outreach tool, LinkedIn Campaign Manager, the dialer and the analytics platform. An MCP server is a small piece of software that lets an AI assistant work inside one tool. If the term is new to you, you are in good company. Most GTM leaders have not read the documentation either.

On paper this looks like the moment agentic GTM becomes real. Connect your assistant and agents start working in your pipeline. In practice, the promise holds for narrow tasks: pull a contact, log a note, draft a sequence. Those tasks are useful. They are also not where go-to-market decisions are made.

The short version

• Agents can now act in every GTM tool, but each tool only sees itself. Real GTM decisions need data from four or five systems joined on the same person and account.

• The models are ready for causal reasoning. The data is not. Without joined, clean data an agent is a fast worker with a narrow view.

• The next layer needs four things: one identity across systems, shared definitions, live access with clear limits, and leadership instincts written down as testable context.

The blind spot

GTM decisions cross systems. Should we run ads to the cold calling list before the calls start? Which trade fair leads deserve a senior follow-up? Did the webinar create pipeline, or did the pipeline only show up afterwards?

Each of these questions needs data from several systems, joined on the same person and account. Each MCP server sees exactly one system. The CRM sees deals. The ad platform sees campaigns. The dialer sees calls. No single tool sees the whole picture.

That is the blind spot. Agents got hands in every tool. Nobody gave them a shared picture of the business.

Three steps of GTM decision making

GTM decision making moves through three steps.

Step 1: Reporting asks what happened

Most teams live here. Dashboards, first-touch and last-touch attribution, calls made, meetings booked. Reporting shows correlation. It tells you two things happened close to each other. It cannot tell you whether one caused the other.

Step 2: Testing asks what we caused

Incrementality tests answer this. Run LinkedIn ads on half of your cold calling list, then compare connect rates and meetings with the half that saw no ads. It is a clean test, and it is hard to run. You need data from Campaign Manager, the dialer, the calendar and the CRM. In most companies the same person has a different identifier in each of those systems. So most teams never run the test cleanly.

This is where it gets interesting. Good GTM leaders already think in causes. They run these tests in their heads, as rules:

• Trade fair leads convert better when a senior person follows up. Testing that rule needs the event lead list, the CRM owner and the deal outcome.

• A demo-first motion brings higher contract values than a free trial. That needs product sign-ups, CRM records and billing data.

• Friday mornings connect better.

Some of these rules are right. Some are wrong. Most were never tested. Each of them is a causal model that lives in one person's head. When that person leaves, the model leaves too. An agent cannot read a gut feeling. The rule has to become testable context.

Step 3: Agentic asks what we should do next

In the third step, agents form hypotheses, design tests and act on the results. A human approves what matters. Today's models can already do this kind of reasoning. The blocker is the data underneath them.

The talent side makes this harder. In the US there are more open GTM engineer roles than people filling them, and the people who could build a joined data layer spend most of their time keeping existing systems running.

What we see from running GTM with agents

At inseeq we run go-to-market with agents every day, for ourselves and for clients. The pattern is consistent: the agents are rarely the bottleneck. Access and context are. Much of what looks like an automation problem turns out to be a data problem.

So what does the next layer have to solve? We see four requirements.

1. One identity. Agents need to know that the person in the CRM, the ad audience and the dialer is the same person. Joined identity is the foundation. Without it, every agentic task is a guess.

2. Shared definitions. Agents need the same meaning for words like "qualified" and "pipeline" as your leadership team. If every system has its own definition, the agent optimises for the wrong thing.

3. Live access with clear limits. Trust decides how much work you hand over. Start small and expand as results hold.

4. Leadership instincts as context. Today that knowledge sits unwritten in people's heads. The next layer turns instincts into hypotheses that can be tested on one joined data layer.

An example: do AI search leads close faster?

Here is a belief we hear from many GTM leaders: leads who found the company through ChatGPT or Perplexity are further along and close faster. Many leaders feel this is true. Almost nobody can prove it.

Testing it needs AI assistant traffic from analytics, form data, the self-reported source and CRM deal stages, all on one identity. Once that data is joined, an agent can test the belief every month. If the pattern holds, shift budget and sales attention towards it. If it does not, stop chasing it.

Where this leaves GTM teams

Agents got hands in every tool. Better decisions need causation, and causation needs joined data. The best hypothesis library a company owns sits unwritten in the heads of its GTM leaders. The next frontier sits underneath the agents: the data layer they stand on.

This is the layer we build into the inseeq platform. Ads, CRM, analytics, outbound and AI search tools are joined into one view, and no budget or bid changes without a human approval. The goal is simple to describe: a leader's instinct becomes a test on Monday and a decision by the end of the month. The agent runs the test, a human approves, and the knowledge stays in the company.

An earlier version of this essay appeared on Hans-Peter Frank's Substack.