Go-to-Market Context: One Architecture, Many Systems

The popular framing on Substack right now calls CLAUDE.md "a competitive moat in markdown form." It is closer to an on-ramp than a moat.

What sits above is what most teams are running. A dense, undifferentiated preamble loaded into the model's reasoning window before every prompt. ICP, positioning, personas, FAQ, boilerplate, all there, all the time. The signals you actually need for the task at hand are inside that block somewhere. The model's job is to find them.

It does not, reliably. Not because the model is broken. Because the architecture is.

The instinct, once a team feels the limits of a single file, splits two ways, and both are wrong. One camp builds bigger: consolidate everything into one giant store, the org's AI brain. The other camp builds narrower: let every tool and project keep its own copy of the context it needs. The first creates a monolith no team can maintain and agents retrieve worse from. The second fragments the org and pays context debt N times over. The right answer is neither. It is one architecture, many systems — a small number of domain-owned context systems that share a common structure. The rest of this piece is what that structure is and why it holds.

The problem: what happens when the context is wrong

Three failure modes show up in every team running AI in production. They all share the same underlying cause.

Failure 1: Generic outputs that do not ship. When the preamble is dense, the model defaults to category-level patterns. The output reads like a template anyone could have written. Asked to write a competitive email, the model carries the full ICP definition, the personas, the positioning doc, the boilerplate. Each is a real signal the model has to filter through to find what matters for this email. The math of attention does not weight signal over noise. It weights statistical frequency over rarity. Generic patterns dominate. Specific facts get under-weighted. The output that comes back is plausible, hedged, defensible, and not deployable. The CMO rewrites it. The AE rewrites it. The promised compression turns into another editorial step.

Failure 2: Inconsistency that compounds across the team. Two people ask the same question slightly differently. The model retrieves slightly different fragments. Two months later, the team is producing different positioning from one source of truth. The architecture promised consistency. What it delivered was a single file pretending to be a single source of truth, with the actual variance hidden in retrieval and customization.

Failure 3: Confident wrong answers. Stale context produces fluent, confident outputs grounded in deprecated facts. They ship before someone catches them. Trust erodes. A CLAUDE.md that has not been updated in six weeks produces outputs that cite positioning the team moved off, customer references the team no longer ships, product features that have been deprecated. The model produces these confidently, with the same fluency as the right answers. They ship. Someone catches the mistake in a customer call, in a deal review, in a board doc. "AI didn't work" gets said out loud, and the architecture investment gets shelved.

The technical name for what is happening underneath all three is attention dilution. Transformer attention is finite. When the model is reasoning over fifteen thousand tokens of mostly-irrelevant preamble plus a task, attention spreads thin. The specific facts you care about are technically in the haystack, but the model's attention defaults to the most statistically common patterns in the haystack rather than the rare specifics inside it. Curated context is not less context. It is more attention per relevant token.

The approach: one architecture, many systems

The shape that holds is three layers, each with its own owner, cadence, and access pattern. The model retrieves only what the task needs at the moment of reasoning.

Conceptual — Market context. Wiki shape, vault. What the market believes today: theses, frameworks, evolving hypotheses, thought-leader positions, competitive narratives. Squishy and relational, captured continuously as atomic notes. The model retrieves them on demand by inferring relevance. (This top layer was called "contextual" in earlier framings; "conceptual" is the current name, and it is more honest about what the layer actually holds.)

Canonical — Product-marketing context. Schema shape, Octave. The org's authoritative product-marketing primitives: ICP, segments, personas, positioning, value pillars, sales plays, proof points, competitive positioning. Schema-driven, owner-controlled, accessed through MCP. Resolves the same way across every team and every session. No drift.

Deterministic — Customer context. System-of-record. Live customer state and internal coverage: CRM records, call transcripts, account hierarchies, named teammates and ownership. There is a right answer and a wrong answer, and it is queried through MCP where the data lives.

The wiki for what your team thinks. The schema for what your team has decided. The system of record for what is true right now. Each accessed differently because each is a different kind of context. The model pulls what the task needs and leaves the rest where it lives.

Here is the part most teams miss. These are not three files, and they are not three layers of one system. They are the internal grammar of separate, domain-owned systems. The conceptual layer is the grammar of the market-intelligence system that brand and demand-gen own. The canonical layer is the grammar of the product-marketing system PMM owns. The deterministic layer is the grammar of the customer-data system RevOps owns. A real org runs more than three: leadership runs a run-the-business system of its own (the live OKRs, the bets in flight, the plays this quarter), and ad-hoc teams spin up short-lived project systems. Each is a smaller, domain-scoped store — which is exactly why agents retrieve from it better than from one monolith. The way you make context maintainable for people is the same way you make it efficient for agents.

A caution before the layers do too much work for you. The layer model is a clarifying lens, not a periodic table. Most context skews to one layer-kind, which is why the three-layer spectrum is a faithful on-ramp. But some context — the run-the-business layer, an ad-hoc project — will not bin cleanly into one of three, and that is expected. The job of the lens is to make you ask four questions of any piece of context: who owns it, how fast does it decay, is there a right answer, and what governance does it need. When something does not fit the three, that is the signal to ask the four questions, not to invent a fourth bin.

The next section shows what this looks like at one specific account. Same prompt, two different architectures.

Evidence: the same prompt, two architectures

Prompt (identical for both, same account research skill):

"Build a strategic account plan for Snowflake, a $3B+ ARR enterprise with a partner ecosystem spanning thousands of technology partners, GSIs, and cloud resellers. In early 2024 they installed a new CEO who has made partner-led distribution the explicit strategy for the AI Data Cloud pivot. They recently announced expanded co-sell incentives at Snowflake Summit 2024 and appointed a new SVP of Worldwide Channels and Alliances. We have identified them as a Tier 1 prospect for our co-sell automation platform."

Output A — CLAUDE.md only. Full Snowflake research depth, generic WorkSpan positioning. Generic personas without names. Generic value prop. No proof points paired to people. No named internal coverage. A smart researcher's brief.

Output B — Layered context. Opens with a Strategic Context block (conceptual layer) framing Snowflake as a manifestation of the Co-Sell Convergence thesis. Buying committee resolved against canonical personas with persona-tuned talk tracks and canonical proof-point pairings. Differentiation language from the canonical layer. Channel strategy from conceptual-layer signals. Named internal coverage from the deterministic layer — Anitha, Chase, Mitchell, Conrad, Kevin — with Asher Mathew warm path. A deployable team plan.

Both knew Snowflake. Only one knew what to do about it.

Three things give Output B its edge, and each came from a different system.

The macro frame came from the conceptual layer, the market-intelligence system that holds the team's view of the market: Co-Sell Convergence, Orchestration Over Programs, PRM Is Broken, McBain on the ecosystem economy. These are not background research. They are the lens that turns Snowflake from "an account with partner pain" into "a manifestation of the convergence thesis at the moment between program announcement and program execution." Without that lens, the plan is tactical. With it, the plan situates the deal inside a strategic narrative the team has been building for years.

The persona resolution and canonical positioning came from the canonical layer, the product-marketing system in Octave. Aisha is not invented as an archetype for this deal. She gets resolved against the Alliance Management Executive persona the team uses across every other co-sell deal. The talk track is canonical, not improvised. The proof points (Capgemini for Aisha, Project Ascend for Rajiv, Deloitte for Caroline) are paired by Octave to the persona profile, not picked at random. The competitive language vs. Crossbeam and Agentforce is the team's standing positioning, ready to deploy.

The internal coverage came from the deterministic layer, where the CRM exposes who at WorkSpan owns what. Anitha for Aisha. Conrad for Rajiv's technical conversation. Kevin for executive alignment with Caroline. The Asher Mathew relationship for the warm path. The plan extends from positioning to action because the model knows the internal state.

Strip those three systems and Output B collapses back toward Output A. Not because the model got dumber. Because it lost access to the architecture that made better positioning, better tie-in, and better strategy possible.

Sharper outputs

The model that reasons over targeted context produces specific outputs. Real names. Real proof points. Real segment definitions. The model that reasons under a fifteen-thousand-token preamble produces category-level language. "Series B SaaS" instead of an actual customer. "Healthcare buyer" instead of the persona the team has refined over a quarter.

You can verify this for your own deployment with the practice that has been getting attention recently as canary prompts. A small stable set of prompts you know the right answer to, run periodically across your context configuration. Run the same account plan every two weeks. If the outputs are getting blander, your context is decaying and you cannot see it without the canary.

We took that discipline further and built the GTM Context Benchmark: the same synthesis task — an account plan, a battlecard, a call interpretation — run across five context architectures, from a no-context control through static markdown, a filesystem vault, a canonical schema, and the full layered system. For AI to work in go-to-market, treat context like a codebase. In coding, the codebase is the context. In go-to-market, the context is the codebase you have to write, which is why the architecture you pick to write it in is one of the most consequential decisions a revenue org makes this decade. The benchmark measures, at the prompt level, two things most "AI for GTM" claims never put a number on: whether a given context system actually improves the output a human would ship, and what that improvement costs in tokens. The argument in this piece is the thesis. The benchmark is the data, and we are publishing the prompts, traces, outputs, and rubric so the result can be checked rather than asserted.

The architecture survives the team

Every CLAUDE.md eventually faces the same question: who owns it? One person sets it up, fills it with their understanding of ICP and positioning, and ships. Six weeks later that person leaves, gets reassigned, or just gets busy. The file stops being maintained. Output quality silently degrades. The team blames the model.

The layered architecture survives a personnel change because each system maps to a domain that already exists. The conceptual layer belongs to whoever runs market intelligence and thought leadership. The canonical layer belongs to product marketing, who already own positioning. The deterministic layer belongs to RevOps, who already own the CRM. Each system has the right people doing the right work at the right cadence. The architecture matches the org. The org does not have to bend to the architecture. That is the quiet payoff of one architecture, many systems: no single person owns the whole brain, because there is no single brain to own.

Operators can use it without becoming builders

The popular CLAUDE.md tutorial is written for a single operator who is also the builder, the maintainer, and the user. Three roles in one head. Most marketing and revenue teams do not have that operator. They have a CMO with a number to hit, a couple of senior marketers, an ops layer if they are lucky, and zero people whose job is to write a SKILL.md or debug an MCP integration.

When the operator and the builder are the same person, the system runs. When they are different people (which they almost always are at any company past five), the system has to be deployable by someone who did not build it and maintainable by someone who did not design it. CLAUDE.md alone does not survive that handoff. The layered architecture does, because the layers map to roles that already exist. A small builder team configures the layers, the MCPs, the skills, the maintenance rituals. The operators consume what gets built. Both roles exist explicitly. The operator does not need to learn the harness to get the value.

Where to start

If you do not have a CLAUDE.md yet, build one. The on-ramp is real and the popular tutorial is a reasonable place to start.

If you have built one and you are operating it across a team, start asking which system your content actually belongs to, and let the layer-kind tell you. Anything that captures how the team understands the market is conceptual, retrieved on demand from a graph of atomic notes. Anything that needs to resolve the same way across every team and every session is canonical, behind a server that enforces consistency. Anything with a single right answer is deterministic, queried where it lives. The content that does not fit cleanly is your signal to ask the four questions, not to cram it into the nearest bin.

If you are operating multiple repos and noticing degraded output, the diagnosis is probably not your CLAUDE.md. It is that you have either stuffed three kinds of context into one file, or scattered one kind across N tools that each maintain a stale copy. Both are the same failure read from opposite ends: context that should live in a small number of owned systems is instead living in the wrong shape.

One architecture, many systems. The file pattern you started with is neither.

That handoff — from a single file pattern to a set of domain-owned systems under one architecture — is the next chapter for any team that wants AI to compound in GTM. The third piece in this series gets into who runs each system: the AI-native GTM team, how the work decomposes, and what changes about roles when the architecture lands.