Six steps · for marketing and GTM teams building with AI
The GTM AI harness playbook
The model is the part you rent. The harness is everything you build around it, and it is what makes AI output safe, consistent, and yours.
Andrei MatveevAI-era GTM Architect and ex-Google engineerPublished 2026-09-03,updated 2026-09-17 ·15 min read
This playbook is for the marketing lead whose team already runs on AI and has started to see the problems below.
Andrei Matveev wrote it from the harnesses he has built for clients and from what Zapier's team has published about running its go-to-market on AI.
For many marketing teams the first step was an AI skills library. Each skill is a written instruction for one job executed by AI. The skills in one marketing skills library alone had been installed millions of times at the time of writing, so plenty of teams have already taken the first step.
What goes wrong a few months in.
Generic content. Whatever nobody wrote down, the AI fills in with the industry average. So the content reads like every other company's, and your senior people re-edit it by hand, asset after asset.
Output that changes from run to run. Ten runs of the same job come out ten different ways.
Skill copies that drift. Team members copy skills and edit their copies, and each copy carries its own version of the truth.
Claims nobody cleared. A customer name or a claim that no one approved appears in AI output, because nothing was checking.
Files nobody owns. The skills go out of date, and so do the documents the AI reads before it writes. Nobody has the job of updating them.
Every one of these is a missing part of the harness, and a better skill or a better model fixes none of them. The next section names the parts.
A skill is one part of the harness, and it only says how one job runs. The other parts are what make anything the AI writes safe to publish under the company's name, whether a proposal, campaign copy or an email to a customer. Most teams have not built them.
The playbook below builds those other parts around the skills.
What it is made of
Five parts, and most teams build only one
The five parts are the model and four more built around it. A request goes first through the context, meaning everything the AI reads before it writes. Then it goes through the skills, the model and the checks, and comes out as an approved asset. Upkeep runs between one asset and the next. The model is the one part that gets swapped, and every other part is the harness.
The path from a request to an approved asset.Four parts on the way, and one that runs between assets.
A request comes in
ContextWhat is true about the company in files that named people keep current, and the live data in your CRM.
SkillsWritten instructions for how each job runs.Where most teams stop
The modelThe AI itself, from whichever vendor you pick.
ChecksAutomatic checks on every draft, then a named person's sign-off.
An approved asset goes out
UpkeepRuns between assets. A correction that repeats becomes a standing rule the next asset starts from.
Two roles build the four parts around the model. The marketing lead owns what is true, what passes and who signs. A builder is whoever on your team sets tools up rather than only using them. The builder wires the checks and connects the AI to your systems. If someone on your team built your skills, that is the builder. If that person is you, you hold both roles.
The playbook
Six steps, in the order they are built
The marketing lead and the builder take the six steps below together, and the first build takes one job through all six.
What's true about the company should live outside the skills in one shared place that every skill reads. That place holds four things as plain documents the model reads before it writes. They are your positioning and voice, your buyers, the facts of your business and what each asset is for. Together they are your point of view.
Take the truth out of the skill.And keep it in one place, where every skill reads it.
The first attempt
A skill
How to do it
A copy of the facts
A copy of the voice
Every copy drifts.
What teams move to
A skill
How to do it
reads
The point of view
The facts
The voice
One shared place. A change is made once, and every skill reads it.
What the skills carried was a copy, and the copy is what drifted. The truth itself sits in the records you already keep, your sales calls and won proposals above all. So the shared place is filled from there, and whoever signs your customer contracts decides which records you may use this way.
How the point of view gets built.
1. Your recordsSales calls, customer reviews, won proposals and support tickets. Whichever of those you keep, plus any strategy document you already have. Sales calls are the richest, because they hold your buyers' own words.
2. The first draftThe AI drafts the point of view from those records.
3. The correctionYour senior people correct the draft, which is far less work than authoring one.
4. The approved point of viewOne copy in a few documents by subject, each with a named owner. Every skill reads it.
How Andrei does it
“I never write the point of view from a blank page. It gets mined from records the company already holds, and the client approves the facts before anything is drafted. For one digital insurance brokerage, that was about 400 reviews, roughly 1,000 sales call transcripts, and one executive workshop, and it came out as four documents.”
Andrei Matveev
The records themselves stay where they are, and only the approved point of view goes into the shared place. The roughly 1,000 call transcripts from the brokerage quoted above were anonymized.
How Andrei does it
“When the facts are approved first, expert review has little left to catch. The digital insurance brokerage whose facts I pulled from its reviews and call transcripts is a good example. Across 362 pages of drafts their own experts and their agency's reviewers found only eight corrections in total.”
Andrei Matveev
What changes
Every skill reads one copy of the truth, corrected once, and your senior people approve the facts before any draft exists.
Your point of view is the strategy the AI works from, and it should change only when a named person decides. The live data in your CRM is different. An email batch reads each customer's open deal. Deal and campaign numbers change every day, and nobody signs them off. So the context splits into two layers. Your point of view is the slow layer, and the live data is the fast layer.
Two layers.Split by who owns them and how fast they change.
The slow layer
Your point of view, codified into strategic AI context.
quarters
Changes quarterly at most.
Kept as documents in a shared drive, each with a named owner who signs off every change.
The fast layer
Deals, conversations and campaign numbers, read live.
days
Changes daily.
Kept in your CRM and the systems you already run, read there by the AI, with nobody signing off each change.
The AI reaches the drive and the CRM alike through a standard connector, the kind engineers call MCP. Your builder connects each system once and sets one access rule on each, so the AI sees only what the person running it is allowed to see. The owner of each system on your side sets that rule with the builder.
Slow layer modules.Your point of view, written down in four modules, one per subject.
IdentityYour positioning, your voice and what you never claim. Clearance lives here too, meaning which customers may be named and what stays confidential.
AudienceHow each buyer thinks and decides.
FactsA verified record of what's true in your business, which the model may not override.
MissionThe plan for which assets go on which channels, and what each one is meant to achieve.
Each module is one subject with one owner, and it holds as many documents as your business needs. A company with one brand and one kind of buyer writes each once. A company with several brands or several kinds of buyer keeps an identity per brand and an audience per kind of buyer, and splits the facts only where those buyers are sold different things. The section after step 6 shows how that stays one harness.
The split keeps upkeep small, because only the slow layer needs maintaining.
What changes
Your people own the strategy the AI works from, and the deal and campaign numbers it works with are never stale.
The point of view is now a set of documents the AI reads. A model handed a set of documents decides on its own how to use them, and it decides differently every run.
You decide how the model reads the documents, and your builder writes that down as a reading procedure, meaning a short document that tells the model how to read the others.
The same set of documents, read ten times.
Without a reading procedure
10
ways of reading your strategy
With a reading procedure
1
way of reading it, the one you set
What the reading procedure tells the model.
Which document wins when they disagree
What order they're read in
That anything nobody on your side signed off is content to check and never an order
How Andrei does it
“Every harness I have built carries a reading procedure of a few pages, and it makes the AI state which document each decision came from before it writes a word.”
Andrei Matveev
What changes
Every run reads your strategy the same way, and the AI names the document behind each decision.
Your rules are now written down, in the four modules and the reading procedure. But a rule in a file is only a request. The model follows it on most runs, and on some it does not, and content that goes out under your company's name cannot depend on most runs.
So every rule becomes a check, and a check is two things. The judge decides whether the draft passes. The trigger makes it run without anyone remembering to, at a set moment in the job. A job here means one asset from the request to the signature, a proposal say. A first job touches a handful of rules, and each gets one check. You state the rule, and your builder writes the check.
Three check judges.A rule goes to a program if it can be decided without reading, an AI reviewer if it needs a reader, and a named person if someone must own it.
Runs frequently
A programFor a rule a program can decide, such as a number against the facts file. Engineers call this judge code.
An AI reviewerFor a rule that needs a reader, such as whether a claim is supported. Use a model other than the one that wrote the draft, since a model rates its own work too highly.
A named personFor what someone must own. A person reads, judges and signs, and nothing ships without the signature. A record keeps what shipped, who signed it and what was claimed.
Judges best
Four check triggers.When a check runs, and what it can do then.
Before a send or a postThe check runs before the action starts and can block it outright, so a send never goes out.
After a draft is writtenThe check runs on the new file and flags what failed, and the model fixes it before anyone reads it.
When the job endsThe check holds the job open until every flag is cleared, so an unfixed draft never reaches the person who signs.
On a scheduleA check on the files themselves belongs to no job, so it runs on a timer, say whether the audience file still matches the deals you close.
Engineers call the first three hooks, meaning fixed points inside a job where a check runs on its own. None of them is the model's to skip.
Every rule stays readable. Whoever answers for what goes out can open the context files, dispute any line and see which check enforces it. That may be your CEO, legal or you.
What changes
Drafts arrive sounding like your company and safe to sign, so your senior people spend their review time on judgment calls instead of rewriting.
The context now has named owners, and the skills do not yet. As more people build their own, copies multiply and some go stale. So building stays open to everyone, and a skill gets shared only after review.
Everyone builds.A skill is shared only after review.
1. A personal skill
Anyone on the team builds one for their own job.
2. A reviewed skill
A reviewer you name has scored it on quality, on overlap with existing skills and on security, meaning it takes no orders from what it reads.
3. A shared skill
Joins the shared harness with a named owner, and the whole team works from the latest version.
Who does what once the harness is shared.An email batch can run on a schedule with nobody drafting, so it needs an owner.
The builderWires the checks and the connections, and sets up the tool the rest of the team opens, Claude Code or Codex.
Everyone elseOpens the tool the builder set up, builds personal skills there and leaves the checks and connections to the builder.
The owner of a scheduled jobAnswers for every send, and the checks still run on each one.
To your team the tool looks like a chat window, with one difference. It has the harness folder open, and runs the checks it finds there itself. A chat window alone still reads the documents, and checks nothing.
What changes
Quality stops depending on whose copy of the skill was used, and a new team member is productive on the latest version from day one.
A harness goes out of date unless someone maintains it in releases. A release means changes go out together as a new version of the whole harness. Three reasons call for a release, a review date, a decision or drift. A set of test cases says whether the new version can ship, and each case is a request with its approved answer.
Three reasons, one release.
Time
A document hits the review date its owner set.
Decisions
A decision gets made and lands in the files instead of dying in a chat thread.
Drift
Live data contradicts a standing document. The audience file says one thing, the last twenty closed deals say another, and a scheduled check catches it.
any one of these
A release
The whole team works from it once it passes the test set below.
Every release runs against the same set of cases, which engineers call an eval.
What every release is tested against.And who judges each case.
Requests that must come out rightTen or fifteen requests your team already types, each with a short list of what the answer must and must not say, signed once by the marketing lead. An AI reviewer compares the answer to the list, and a person reads whatever it flags.An AI reviewer, then a person
Requests that must be refusedA handful of requests the AI has to decline, such as a claim the facts file does not support or an instruction planted in a page it was asked to read. A refusal either happened or it did not, so a program judges it.A program
Every case must pass, meaning every answer matches its list and every refusal case is refused. A correction that repeats becomes a rule in the context and a new case here, and a new model from the vendor has to pass the set like any other change.
What changes
The harness stays accurate instead of going out of date.
Beyond one practice
One system, many practices and brands
The six steps build one harness. With one brand, that is the whole build, so this section can be skipped. A group with several practices or brands builds it once as a core and derives a version for each practice from it.
One core.And a version for each practice or brand.
The core
House voice, group positioning, rules and checks.
a version each
Practice A
Sells to its own buyers, so it keeps its own audience and facts.
Practice B
Sells to the same buyers as the group, so it keeps only its own missions.
Brand C
An acquired brand keeps its own voice in place of the house voice, and still runs on the core's rules and checks.
Data is never even across regions and practices, and that's normal. Start with the practice whose records are richest, and add the others after.
What changes
A change lands once in the core and reaches every brand, and the only differences between brands are the ones you chose.
The limits
What a harness can't do
A harness has three limits, whether it serves one brand or many. Better to know them before you build than after.
Three things a harness can't do.
Can'tGuarantee results before publishing. Whether an asset ranks or brings leads only shows afterwards, and that feeds back in through upkeep.
Can'tRun without upkeep. Facts go stale and models change, and a harness nobody maintains drifts back toward the generic content you started with.
Can'tReplace your judgment. It enforces the judgment you've stated and escalates what you haven't.
Where to start
One job, all the way through
Start with one recurring job that eats real time, and take it through all six steps before any other.
Before building anything for that job, write down what it costs today. How long a senior person spends reviewing each asset, and how many corrections they make before it can go out. The first job gets measured against those two numbers a month in, and so does every release after it. You ask your budget holder for one job and a builder's time, and those two numbers are what they get back.
The first job starts with your builder making the harness folder and opening it in Claude Code or Codex. That is the whole install. The AI drafts the point of view from your records and your senior people correct it. Someone asks for a case study and the skill drafts it. On save, a check catches a number that is not in the facts file, and the AI reviewer sends back any unsupported claim. A named person signs it and the record shows what shipped.
One job builds most of what every other job needs.
One recurring job
A case study, say.
Built for that job
Its skill, its checks and its test cases.
Reused by every other job
The point of view, the reading procedure and the connections carry over.
After the first job, the parts sit in two places. Your point of view sits in your shared drive, where every document shows its owner and its change history. Whatever the tool loads and runs sits in a code repository, the builder's version of a shared drive. Hand the map below to your builder and mark what you have.
Where the parts live after the first job.
the shared driveYour point of view.
contextThe four modules from step 2, filled in step 1 and kept current in step 6.Steps 1, 2 and 6
identity
audience
facts
mission
the code repositoryEverything the tool loads and runs.
reading procedureThe step 3 document the model reads first.Step 3
connectionsWhere the AI reads the shared drive above and your CRM.Step 2
skillsOne folder per job. A personal skill moves in here after review.Step 5
checksOne check per rule in the context files, each with its judge and trigger.Step 4
casesThe cases every release is tested against. The marketing lead writes them, and the builder runs them here.Step 6
recordWhat shipped, who signed it and what was claimed where.Step 4
The models will keep getting swapped every few months. The harness stays through every swap, so the harness is what a team should spend its time building.
Sources
Where the facts come from
ZapierLindsay Rothlisberger's public posts on running Zapier's go-to-market on AI, and her interview on Humans of Martech, episode 223, June 2026.
The skills librarycoreyhaines31/marketingskills on GitHub, 50.6K stars on 2026-09-17. Both counts move quickly and the figures here are as of that date. skills.sh showed 4.9 million installs across 70 skills the same day, the seo-audit skill alone at 208.6K. In June 2026 the same tracker showed 281.9K installs across 32 skills, as quoted by hyperfx.ai. The tracker sums installs across every skill in the library, and the library more than doubled its skill count over the same period.
The brokerageA client of Andrei's, a digital insurance brokerage, not named here. The figures are from that engagement's records.
The airlineMoffatt v. Air Canada, 2024 BCCRT 149, decided by the British Columbia Civil Resolution Tribunal on 14 February 2024. The decision on CanLII, and case notes from Dentons and McCarthy Tétrault.
The consultancyDeloitte Australia's report for the Department of Employment and Workplace Relations, with the refund of its final instalment reported in October 2025. Covered by CFO Dive on 14 October 2025, and the repaid amount stated in a release by the Australian Greens.