👋 Hi, it’s Kyle and welcome to Growth Unhinged, my weekly newsletter exploring the hidden playbooks behind the fastest-growing startups.

I recently surveyed readers about how they use Claude Code (and Cowork) for GTM. You all said the single most critical part of your Claude setup was the context layer — everything else runs downstream of this. Skill files, like the ones I shared last week, are only truly useful if they fit into GTM system that understands your exact business.

Matteo Tittarelli, founder of Genesys and co-founder of GTM Engineer School, helps Series A-C GTM teams transform their marketing and sales processes with Claude Code agents and skills. Today Matteo unpacks how to build your AI GTM system with context.

I run a solo consultancy at the speed of a 5-person team.

I work across the full B2B SaaS and AI spectrum — from seed-stage founders to PE-backed teams — embedded as the PMM and content functions for companies like Archive.com (Series A), Common Room (Series B), Crescendo (Series C), Pivot (Series B), AdvisoryAI (seed), Octave (Seed), Seapoint (seed), Enhesa (PE-backed), and many more.

I'm usually an early adopter of AI tools. But real productivity gains didn’t show up for me until January 2026. That’s when Claude Code, skills, and MCPs matured enough that I could stop stitching tools together and start building a compounding GTM system. Before that, every "AI productivity" win was local. One good prompt, one good output, then back to manual.

The first version ran inside a Claude project for Archive.com, the Series A creator marketing platform. I fed it everything by hand: 100+ customer interviews, sales call notes, competitor URLs, my PMM templates. It produced genuinely good positioning and messaging assets.

The problem was that nothing persisted between sessions except the prompt itself and the artifacts created. So all my effort went into the prompt: long instructions, context badly managed, me scrolling through a wall of my own text to find where I'd contradicted myself. There was no structured context for the model to pull from — other than project instructions and attachments — just giant prompts I kept rewriting and copy-pasting.

That's the ceiling of Claude.ai and ChatGPT, and the exact reason I moved to Claude Code. Since I moved to Claude Code, I stopped chasing better prompts and started building systems of context, action, orchestration, and integrations — a folder architecture, a naming convention, and a refresh discipline that every skill, agent, and human on the team reads from and writes to.

Here's what that looks like in practice.

Every GTM team I talk to is feeling the same thing: output isn’t compounding no matter how much they use AI.

Every new piece of content, research doc, and sales asset starts from scratch, but none of it makes the next piece sharper. Ask the team to point at one artifact that's making every other artifact better, and the room goes quiet. Meanwhile, GTM debt keeps piling up:

AI-native GTM has moved past "find the right prompt." The new standard is humans and agents orchestrating context, skills and MCPs. The most AI-mature operators I work with are running agents on tens of skills and connecting multiple MCPs (Apollo, Clay, Granola, Slack, Gmail, Drive, Linear, and counting).

As Zach Vidibor, CEO of Octave, said in a recent podcast episode with me, “The resting heart rate of the market went from 60 to 120." Research is faster, strategy is faster, the content and launch cadence is unrecognizable from twelve months ago. But because of this, there’s more noise, as out of a hundred LinkedIn posts from agents, none of them sound like the founder. Stale messaging compounds across more channels because the same drift propagates everywhere the agents reach, at a faster pace.

The gap is whether the work you produce has somewhere to live that makes the next piece of work sharper. What I’ve landed on is an AI GTM system with four layers (you can screenshot this image and tell Claude: “Set up my workspace with these four layers.”)

This is the starting point, the foundation that makes the whole machine spin. With specific skills, you can generate always-loaded foundational .md files so Claude knows your role, industry, company, and work. It should include:

Once you have your folder structure set up, you feed specific research skills your company URL and sales calls transcripts to generate these research docs, which will be used by other skills as foundational context. That’s how Claude never forgets about you, your ICP, and industry.

Skills for every GTM lane turn context into GTM research, strategy, or execution. You can build skills for each function. Yours might include LinkedIn content, ad copy, or outbound sequences. (Here’s my starter pack for competitor research, ICP research, tone of voice, case studies, battlecards, and win-loss analysis.)

Each skill reads from specific context folders, produces structured output, and dispatches it to a target folder. When programmed correctly, each skill knows what it needs as input, what its output schema is, what an example of good output looks like, and where the output belongs in the tree.

Agents and hooks decide which skills to run, when, and on what inputs, enforcing your rules and conventions. 

A simple example: a refresh agent reads latest.md, sees the win-loss skill hasn't run in five weeks, dispatches the win-loss skill against the latest batch of Gong transcripts, then routes the output to the ICP refresh skill — without anyone typing a command.

Skills use integrations to pull context from or push content to. They feed skills with external data on the way in (Exa for research, Granola for transcripts, Gong for win-loss, Apollo for accounts, HubSpot for customer data). And they route execution outputs to live destinations on the way out (Buffer for content, Google Ads for paid, Smartlead for outbound, Klaviyo for lifecycle).

Wired together, every output feeds the next input, and the inputs keep getting better.

Here's what a mature GTM system looks like as a folder. 

A few things in this diagram that aren’t obvious:

Here’s how the system works in practice: Pivot, a procurement startup I’ve been working with, recently rebranded for their Series B. I had created three vibe coded tools for them. Instead of hand editing these apps one at a time, I updated the brand kit HTML file once via the related brand kit skill. With one Claude Code chat, I then updated all three vibecoded apps with the new fonts, colors, and gradients from the new brand kit, while the underlying design components and copy stayed untouched. The same trickle-down refresh mechanism works for messaging, positioning, and tone of voice.

The execution workstreams each start with research, flow to strategy, and then execution. There’s a fourth stage of work: the refresh stage. This is what makes the system a compounding loop. 

Let me show you how you can replicate each stage for your company. 

As mentioned before, the first step is to generate foundational product marketing context. Gather your company and competitors’ URLs, and sales calls transcripts, and feed them as input to run the following skills in this order:

Each skill writes a structured research file to its relevant domain folder with the following naming convention: dated MMYY-topic.md files.

For example, a per-competitor profile ran in May becomes marketing/competitors/0526-competitor-a.md. A per-persona ICP file ran in June becomes marketing/icp/0626-champion-persona.md. A win-loss research ran in the same month  becomes marketing/icp/0626-win-loss.md because the win-loss signal feeds ICP, not competitors. This embeds also recency in the document, so agents know when to supersede previous versions of a context source, and avoid stale.

Anti-hallucination hooks are built in: confidence scoring on every claim (verified, inferred, estimated, unavailable), source attribution with URLs and access dates, "not available" notation when data isn't there instead of invented filler. The hooks are what keep the inputs trustworthy. If the inputs lie, everything downstream lies with them.

Here’s how the system works in practice: This caught a real one at a PE-backed regulatory-intelligence platform I’m working with. My positioning and messaging skill generated four product messaging houses on its first pass. They were confident, plausible, yet partly wrong. Their PMM director read them and rejected three on sight: "we don't target mid-market." The model had inferred a market that wasn't theirs. Also, there were a bunch of misunderstood proof points, capabilities, and wrong TOV. So we baked all this human feedback back into the core ICP and messaging, and every downstream run now reads correctly.

Without a style guide and a set of explicit rules, models can decide for themselves: how it talks, how it structures information, how it weighs your competitors. Human judgment and taste is what overrides that, and the way you make the judgment stick is what encodes it in the system. Some of those rules are about strategic substance, like tone of voice, positioning, or which segments are in and out. Some are about the meta layer, like how to format a plan, how to name a file, how to review copy after it's written. Both kinds get enforced as hooks and rules, so a correction you make once becomes a constraint the system can't forget. 

That’s the beauty of these systems — you can mold them to work and behave the way you do.

Where Stage 1 produced one PMM spine about your ICP, product and industry at large, Stage 2 uses this foundational context to produce strategies for each GTM lane. For example, your content audit and content strategy skills will pull from your competitors and ICP to generate content themes on channels relevant for your customers. Or when you want to create a paid marketing strategy, your campaign strategy skill will also pull from your positioning and messaging to generate an on-brand campaign architecture across LinkedIn, Google, or the channels relevant for your ICP. 

Now that you have strategies for each GTM lane, you can move into execution. Every execution skill downstream reads from these canonical strategy files, which combine channel-specific strategies with the PMM foundational context. 

Refresh is the operating habit. Here’s a concrete example of what a signal looks like in practice. A new competitor pops up on your LinkedIn — that's a signal for a competitor-research re-run. A sales rep says on a Gong call that buyers keep using a word that isn't in the messaging library — that's a signal for an ICP research refresh. Each signal routes to a specific skill, which writes its updated output to a specific folder, which feeds the next execution cycle.

I get asked about refresh cadence often, so here’s what I recommend:

Here’s how the system works in practice: AdvisoryAI, an AI platform for UK financial advisors, makes for a great example. The market is in a knife fight: competitors entered monthly in the last 2 quarters.  We added 13 new competitor analyses and re-triangulated the positioning on the back of them. Each asset is a dated file that supersedes the last, and the arc across them is the whole repositioning.

The point of a refresh is to interrogate the deltas. The competitor research from last quarter is mostly still right. What you want to know is: which three things moved? Did anyone reposition? Did pricing shift? Did the messaging on the homepage change? A good refresh cycle reads the previous canonical file first, then asks the agent to surface what's changed and what you can make of it.

Here's the full path from context to live destination to git.

The folder structure holds the PMM context files locked — ICP, competitors, positioning, messaging, brand. CLAUDE.md, hooks, ontology, rules, and memory enforce the conventions so the structure can't drift from inside.

Agents are the coordinators. They decide which skill to run when, with what inputs, and how to handle failures. They're the layer that turns "I have a folder of locked context" into "the right skill ran on the right input at the right time."

Skills are the producers who run the actual work. Strategy and execution workstreams are organized by GTM primitive — content, outbound, paid, product marketing, design, sales. Each one has specific audit and strategy skills, reads channel-specific context folders, and writes its output back to a domain folder.

Integrations appear twice in this cascade. MCPs feed skills on the way in (Exa, Granola, Gong, Apollo, GA4 supplying external data the skills synthesize) and MCPs push outputs to live destinations on the way out (Buffer for content, Google Ads for paid, Smartlead for outbound, customer.io for lifecycle, Webflow for landing pages).

Git commit, then push to GitHub. Once outputs are thoroughly reviewed, you — human operator — commit the new files locally and push them to a shared GitHub repo so the team syncs the same folder structure across machines. The repo is the team's shared brain. A new hire clones it on day one on their laptop and is reading the same locked context every existing operator reads. The folder is the onboarding.

Here’s how the system works in practice: For Crescendo, a Series C AI CX scaleup, I packaged their GTM system into a dedicated skills repo: 17 skills plus the role-agents that orchestrate them. When their new VP of Product Marketing joined, her onboarding was a single git pull. She runs the same skills I do, against the same context files, and pulls updates as I push them. That repo is how a team shares and updates everything they do in Claude Code, in one structured place instead of scattered across chat windows and Slack threads.

It's also the cleanest handoff I've found as an external operator. A freelancer or advisor can hand over a working system, with the skills and context and output in one repo, and onboard a team into the AI-native way of working at the same time.

I turned this GTM system into a marketing quick start GitHub repo. My suggestion: clone it, run the interactive onboarding, and watch it build your PMM context spine. You can start creating on-brand artifacts in 30 minutes.

What's in the repo today is just a starting skeleton. The article you're reading shows you the full architecture.

Every team's PMM spine ends up shaped differently — different competitors, ICP segments, brand voice. The starter repo can't pre-populate any of that without making you delete and rewrite. What it can do is give you my opinionated structure, naming convention, and a working seed workstream so the first skill you run lands where it belongs.

If AI feels like a treadmill, shift focus from more agents to better foundation.

The missing layer is the coordination system. Velocity comes from skills, the producers. Coordination comes from agents, the coordinators. But compounding lives in the contextual spine and folder structure — the md files, the ontology, the rules, the memory, the hooks.

Before jumping into full automation, invest in building these strong foundations.

Related resources: