Client Context Is the Only Asset in GTM Engineering

When GTM work goes well, people credit the deliverables: the account list that converted, the enrichment workflow that found the right buyers, the sequence that booked meetings. But those can be rebuilt. Give a capable team a week and they'll reproduce most of the mechanics.

What they can't reproduce in a week is the understanding behind them: everything the team learned about how this particular client sells, who they sell to, and what they will never accept.

That understanding is business context, and it's the only asset you can't rebuild in a week. Everything else is built on it.

We build Revcode, an IDE for go-to-market teams: you describe the work to Claude Code or Codex, and the agent builds and runs it - the tables, the column functions, the provider calls. Building it taught us that the hard part of AI-assisted GTM work isn't execution anymore. It's making sure the agent knows the client as well as the team does.

We'll say "client" throughout. If you're on an in-house team, the client is your own company - the context is the same, and so is the problem.

What business context actually is

Business context isn't one document. It's every decision and fact that changes what "good work" means for a particular client:

• Who to target. The ICP, but also its exceptions: the industry that technically fits and never closes, the company size that only works in one region.
• Who to avoid. Existing customers, open opportunities, competitors, partners, the accounts the CEO personally asked to leave alone.
• How to sound. Positioning, tone, words that are off-limits, claims legal won't approve.
• What already happened. Past campaigns, what worked, what didn't, and the reasons.
• How the team works. Preferred data providers, the format the client expects, the review step before anything goes out.

None of this is secret, but very little of it is written down in one place. Some lives in the client's documents. Some came up in a call. Some is in a teammate's head because they were on the call when the client changed their mind.

The last category matters more than it looks. In Revcode, the agent picks the providers, defines the columns, and shapes the output table, so "how the team works" isn't a style preference. It decides what actually runs.

The LLM is not a GTM engineer

When GTM work was done by hand, most of this context never had to be written down. You skipped the healthcare accounts because you knew the client had dropped that segment. You rewrote a line because you knew how the founder talks.

Now ask the agent in Revcode for 200 target accounts for that client. Within minutes it has created the table, written the columns, picked the providers, and filled the rows. Every row is accurate. Forty of them are healthcare companies, and the agent can explain convincingly why each one fits. Nothing is wrong with the data. The agent just didn't know the client dropped that segment - and it won't stop to ask.

Better models don't fix this. The model is the same for everyone. Your client context isn't.

And the context is slow to build. Discovery calls, the client's documents, their CRM, a dozen "why did you stop doing that?" questions. After a few weeks you can predict the client's reaction to a list before you send it. Then you open a session with an agent, and none of that comes with you.

You explain the client. The agent does good work. The session ends, and the explanation ends with it. Next week you explain again - shorter this time, because you skip what feels obvious. A month later a teammate takes over the account, and everything you learned has to fit into a handover call. Meanwhile the client narrows the ICP, adds a competitor to the exclusion list, drops another segment.

Each retelling is a little shorter and a little older than the one before. Nobody decides to lose the context. It just wears away, one session and one handover at a time.

How Revcode keeps business context

Prompts are temporary. Client context shouldn't be. Every Revcode project keeps the targeting, exclusions, providers, and format alongside the work. Write down the decisions, connect the client's sources, and the next request starts with that context already available. Your attention goes to what's new.

Context arrives from everywhere

No two clients hand over context the same way. One sends a Google Doc and calls it a brief. Another has a wiki full of campaign retrospectives. More advanced teams keep a repository just for context, versioned like code.

On calls, clients think out loud: they hesitate about a segment, mention a deal that went wrong, contradict their own brief. That nuance often separates a good list from a generic one. Most teams record these calls. Few can use them when the work is happening.

So Revcode doesn't ask you to move context into a new place. You connect the places where it already lives - documents, workspaces, repositories, meeting recordings - and choose what to track.

Raw sources, distilled notes

Memory in a Revcode project has two layers.

Sources are the raw record. Connected documents and meetings are imported into the project as plain Markdown files and kept current as the originals change. They're read-only, because the client's words should stay the client's words. If a provider is unavailable, the last imported copy is still readable, and a document deleted upstream doesn't silently disappear from what your agent knows.

Notes are the decisions. Targeting, exclusions, positioning, provider preferences, output format. Each is a short Markdown note covering one concept, so changing the territory doesn't mean rewriting the exclusions. You write notes yourself, or tell the agent to remember something you decided together: "from now on, never include agencies for this client." Instructions meant only for the current task stay with that task, so a one-off correction doesn't become a permanent rule.

Notes link back to the material they came from:

Target accounts are European B2B SaaS companies with 50-500 employees.
Exclude anything in healthcare - the client dropped that segment after
the Q2 pilot. See [[2026-09-14 Kickoff Call]] and [[Exclusions]].

The note gives the agent the decision in three lines. The link keeps the full conversation one step away, for when the agent - or a new teammate - needs to know why.

How the agent finds the context

Saving the decision is half the job. When you ask for the next account list, the agent needs to find the targeting criteria and exclusions before it starts building.

Notes and sources are plain files inside the project, synced to your machine ahead of time. Claude Code and Codex already know how to list, search, read, and follow links between files. Finding the client's ICP works like finding a function in a codebase: read the relevant note, then follow its links when more context is needed.

That makes structure matter. Each note is named for the decision it covers, like "Targeting Criteria" rather than "Notes from Tuesday", and uses the language the team actually uses.

Adding "Ideal Customer Profile" as an alias lets a search for "ideal customer" find the targeting note.

This is why we kept memory in the project instead of putting it behind a dedicated retrieval service with embeddings and a vector index. The same files are available to the agent doing the work and the teammate reviewing its decisions. Both can follow the reasoning back to the source.

The trade-off remains: the agent has to recognize when client context matters and go looking for it. Saving a note makes the decision available; clear organization makes it easier to find.

Keeping decisions current

Sources update themselves. Decisions don't, and we don't pretend otherwise: Revcode doesn't guess when a call has quietly overruled a note. What it does is make updating a decision part of the work instead of a separate chore.

When the client changes their mind, tell the agent in the session where you're already working. It updates the existing note with the new decision, the reason, and the date, so everyone can see what changed and why.

Everyone on the account learns different things, so every teammate can update memory, directly or through their agent. Changes merge like code on GitHub: edits to different notes, or different parts of one note, don't overwrite each other. The result reaches everyone working on the client.

Gather once, reuse everywhere

Every GTM team already does the hard part. They learn their clients deeply, through calls, documents, and months of trial and error. Most then lose that knowledge one session and one handover at a time - and with it, the thing that made their work hard to replace.

Kept context changes what a handover is. A new teammate doesn't need the call; they open the project and read the decisions, with the reasoning one link away. The next campaign starts where the last one ended.

If you want to see it on your own work, take one client: connect their brief and a couple of recorded calls to a Revcode project, write down the five decisions you'd hate to repeat, and ask the agent for the next list.