Engineers describe an AI agent as a model plus a harness. The model can be swapped for another vendor's, while the harness stays.
This playbook is for growing marketing and GTM teams who want to go AI-native, and it exists to help them skip the problems that catch most teams a few months in.
For many marketing teams, their AI-native GTM journey begins with building an AI skills library. Each skill serves as a written instruction for one job executed by AI. The most-installed marketing skill library on GitHub is past 280,000 installs, so plenty of teams have already taken the first steps.
The trouble starts a few months later, and it tends to look like this.
A skill should only define how a specific job runs. The full GTM AI harness is everything else needed to make AI outputs safe to publish under the brand's name.
The playbook below is about building those parts around the skills. Andrei Matveev wrote it, and it combines what he has learned building harnesses for clients with what teams like Zapier's have published about running their go-to-market on AI. It starts with what a harness is made of, then walks through the six steps that build one, and it ends with what a harness can't do and where to start.
An agent has five parts. One is the model, which can be swapped. The other four are the harness. Follow one asset, say a blog post or a customer deck, and it passes through all five on its way from the request to the approved version.
Notice where the skills sit. They are one part in the middle, and the parts before and after them are what let the asset go out under the firm's name. The playbook below builds those other parts one at a time.
The harness is built in this order, because each step builds on the ones before it. Every row links to its section, and every step ends with what changes for the team once it is done.
What's true about the firm should live outside the skills, in one shared place that skills can read. Keeping the truth apart from the skills is the first thing to build.
That shared place holds your point of view, and every company needs one because the model has none of its own. Luckily, a lot of your point of view already sits in records you have. Sales calls are often the richest, because they hold your buyers' own words.
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 the four documents above.”
Andrei Matveev
The same files also record clearance, meaning which clients may be named and what stays confidential. So the model's limits are written down rather than assumed. And none of it gets written from scratch. Have AI draft it from the records, then have your senior people correct the draft. Correcting a draft is far less work than authoring one.
The content stops sounding like every other company and starts sounding like yours.
Some of the context changes every quarter and some of it changes every day, so it splits into two layers.
Your point of view, written down in step 1.
Changes quarterly at most.
Kept in files that your senior people review on a schedule.
Deals, customer conversations, campaign numbers.
Changes daily.
Stays in your CRM and the other systems you already run. The AI reads it live through a standard connector, which the field calls MCP. The AI sees only what the person running it is allowed to see.
The slow layer only gets written if someone writes it, which is why writing it down was step 1. The fast layer already stays current inside your systems, so don't copy it into files. Connect the AI to those systems instead.
The model works from live numbers, and the systems you already run keep doing their job.
A model handed a folder of documents decides on its own how to use them, and it decides differently every run.
So the harness should include a reading procedure, meaning a short document that tells the model how to read the other documents. Few guides mention this step, and it is the one that removes the guesswork.
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. The brokerage's ran five pages.”
Andrei Matveev
Every run reads your strategy the same way, so the content stops changing from one run to the next.
The context files from step 1 say which clients may be named and which claims are off limits. Written as a sentence in a file, that rule depends on the model reading it and obeying it on every run. It usually does. For content that goes out under your firm's name, usually isn't good enough.
So every rule gets a check that is not the model. This is the step that stops claims nobody cleared from going out. There are three kinds of check.
The four rules below are examples from a working harness. Yours will be different, and each one still gets one of the three checks.
No client is named without clearance, and no off-limits claim goes out.
Nobody already contacted gets contacted again.
Every fact is checked before it ships.
A named person signs everything that leaves the building.
How Andrei does it“When the facts are approved first, expert review has little left to catch, and what it catches sits mostly outside the approved file. On the brokerage build, the client's experts and its agency's reviewers found eight corrections across eighteen web pages and twenty-one emails.”
Andrei Matveev
Every rule stays readable. Legal and leadership can open the rulebook, dispute any line, and see how it is enforced.
A lesson from Andrei's builds“Readers miss things, and so do AI passes. On the brokerage build, two facts in one email contradicted the approved file. My checking pass and two rounds of human review all missed them, and an audit found them later. What would have caught them is code, meaning a check that compares every number in a draft against the facts file and blocks the draft on a mismatch.”
Andrei Matveev
Rules move toward the strictest check over time. A check that starts as a separate pass becomes code once it is clear enough to write down.
Drafts arrive close to final and safe to sign, so your senior people spend their review time on judgment calls instead of rewriting.
Up to here, all of this could live on one laptop. Once more people build their own skills, the copies multiply and some go stale. So the working rule is that everyone builds, and a skill gets shared only after review.
Anyone on the team builds one for their own job.
Scored on quality, security, and overlap with what already exists.
Carries a named owner. The whole team works from the latest version.
Once the harness is shared, the roles look like this.
Quality stops depending on who wrote the draft, and a new team member is productive on the latest version from day one.
A harness goes out of date unless someone maintains it on a schedule. So it gets maintained the way software is, in scheduled releases, which content teams already know as sprints.
A document hits its review date.
A decision gets made and lands in the files instead of dying in a chat thread.
Live data contradicts a standing document. The audience file says one thing, the last twenty closed deals say another.
The whole team works from it. Next cycle, the same three triggers say what to update.
A release ships only after it passes the same set of cases every time. The set is small, and the marketing team owns it. Engineers call this set an eval.
Keep the process light.
The harness stays accurate instead of going out of date, which is what makes it infrastructure rather than a one-off project.
A firm with several practices doesn't build a new harness for each one. It builds one core and derives a version for each practice from it.
House voice, group positioning, rules and checks.
Its own audience, its own facts, its own missions.
Starts from the core, so it is never built from scratch.
An acquired brand keeps its own 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.
A change lands once in the core and reaches every brand, and the only differences between brands are the ones you chose.
Don't take all six steps at once. Pick one recurring job that eats real time, and build the whole path for that one job.
The one that eats real time.
Its context, its checks, its release schedule.
The point of view, the audience, and the cleared facts carry over.
After the first job, the shared folder looks like this, seven things in all. Each folder and file was built in the step marked beside it. The file the AI reads first sits at the top, and the model has no folder at all, since it is whatever vendor you connect.
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.