GTM Engineering Has A Context Problem

Published on
November 25, 2025

Everyone expects AI to automate marketing and sales. It seems like the perfect use case: the models are good at generating text and images, the modalities go-to-market (GTM) teams largely use. Yet, two years into the AI revolution, software engineering has transformed, and GTM hasn’t.

A developer using Claude Code or Cursor today is operating at a higher level of abstraction than they were in 2022. They are doing more than coding. Now, they are managing a system that writes code. By contrast, a marketer today is mostly doing what they did in 2022 with ChatGPT-3.5, just a bit better.

Why the difference? It isn’t that code is logical and marketing is creative. It’s that engineering has a repository, and marketing has amnesia.

When you join an engineering team, you clone the repo. You immediately possess the history of every decision the team has made. You can see the tests (constraints), the comments (logic), and the docs (intent). The context is explicit and executable.

When you join a GTM team, you schedule fifteen coffee chats to find out what the last person tried.

This is the structural problem. Marketing is stateless. Its context lives in people’s heads, scattered across Slack threads, and hidden in three different versions of a Google Sheet. Because there is no "master branch" for marketing strategy, AI has nothing to ground itself in. It hallucinates because it has no reference frame.

If you want AI to transform GTM, you don't need better models. You need a GTM repo.

The real questions are: what would a GTM repo even look like and how do you make one if most marketing knowledge is tribal?

The Context Problem

To understand what a GTM repo would look like, look at why AI works for code.

When an AI agent interacts with a codebase, it doesn’t simply respond to your request. It reads the files. It sees how errors are handled. It notices what you’re currently building. It can run your tests. What the AI agent is doing is gathering context to generate code tailored to your repo.

Marketing has the equivalent of all these things, but they aren't organized as code.

  • The Codebase are your campaigns.
  • The Docs are your positioning information, personas, and the like.
  • The Test Suite is your A/B test results and conversion data.
  • The Database is your CRM.

The problem is that while the "Codebase" (campaigns) exists, the "Docs" are usually missing. When there are “docs”, they’re often dated or incomplete.

In software, comments, commit messages, and docs explain intent. In marketing, the intent is locked up in tribal knowledge. Why did we choose this messaging for the Enterprise ICP (Ideal Customer Profile) but not the SMB one? Why did we stop bidding on that keyword? The data says what happened, but the senior marketer knows why.

That "why" is the directional context. Without it, an AI can look at a failed campaign and say "this failed," but it can't tell you if it failed because the strategy was wrong or because the execution was sloppy.

Why GTM Needs A Repo For Agentic AI

Having a GTM repo means marketing teams can automate what would have otherwise been a series of tedious, manual exercises.

For example, when a competitor launches a new feature and you need to update your positioning, here's what happens today. Your product marketer manually goes through a positioning exercise. They dig through old campaign data, try to remember what messaging worked before, check what sales is saying, look at win/loss interviews from six months ago, and piece together a response.

This looks creative and strategic, but in reality you’re following a repeatable process:

  • Analyze the signal against your current positioning
  • Review what's worked historically with similar signals
  • Draft messaging variations based on proven patterns
  • Test with your target segments
  • Iterate based on results

This is secretly algorithmic. Having a GTM repo means that AI agents can use context on your process, taste, and data – from ICP descriptions to real campaign signals – to turn a fuzzy process into something executable.

The real question isn’t whether or not GTM engineering teams need a repo to make marketing as agentic as coding. It’s how you create one in the first place.

Bootstrapping A GTM Repo With AI

The roadblock to creating a GTM repo is where GTM info lives: in people’s heads. If most of marketing knowledge is tribal knowledge, no one can expect their teams to sit down and document that knowledge just because agentic AI is on the scene.

Code faced the same problem, it’s just not as obvious a problem as it is for marketing.

Think about how you use an AI agent for coding. You ask it to write a function. It writes something mediocre. You say, "No, use this library, and handle the edge case like this." It tries again. You correct it again. Eventually, it produces the right code.

We all like to think of AI as a consumer of context. The real power of AI is that it also is an efficient extractor of context.

When using coding agents, you extract context around taste and process over time, by giving the AI agents feedback. That interaction loop of “generate, critique, refine” is how you extract tacit knowledge.

The secret to building a GTM repo is using AI agents to extract the exact context they need to later consume piece by piece. You start with a fuzzy concept in a senior marketer's head, like "our brand voice." You ask the AI to generate copy. The marketer hates it. "Too aggressive," they say. "We don't sound like that."

A true GTM AI agent can use that information to update its own docs. By providing feedback, you are committing "taste" and "process" to the repo.

If you do this enough times by generating outputs, critiquing them, and feeding the principles back into the system, you eventually end up with a set of executable guidelines that represent the "vibe" of the company. You turn intuition into infrastructure.

The Moat

There is an economic reason to solve this.

In the software world, we learned long ago that accumulated context is a force multiplier. This is why we have CI/CD, documentation, and design patterns. If these were simply for organization, no one would make them. Instead, they’re for speed. They allow a new developer to deploy value on Day 1 without breaking the build.

Marketing is about to undergo the same transition.

Right now, most marketing teams are restarting from zero with every campaign. They are manually re-assembling context. If you can build a system that remembers –  a system that knows your ICP, remembers which messages worked for that ICP last quarter, and understands the constraints of your brand – you move from linear execution to compounding execution.

This is the Toyota Production System applied to GTM. Toyota didn't win because they had better robots. They won because they embedded the organizational knowledge into the process itself.

The companies that win the next few years won't be the ones with the best AI models. Everyone will have the same models. The winners will be the ones who realized that the model is useless without the repo, and started the hard work of downloading their team's brain into code.

FAQ

Frequently Asked Questions

Still have questions? Get connected to our support team.