In October, a client blog passed every check that my system put it through and still wasn’t ready to publish. A dozen pieces of internal shorthand borrowed from a sales deck, phrases like “the objections” and “the edge,” got through two automated style checkers, an editorial review, and a copy edit. I caught them all in one read because I hadn’t worked from the deck while writing the draft. The style checkers looked for banned words, and the AI reviewers before me had all worked from the same deck the draft came from, so the shorthand looked like plain English to all of them. The more go-to-market (GTM) content an AI system produces, the more a miss like that costs you, because nothing in the process was built to catch it.
Catching problems like that systematically and reliably takes more than a good prompt. I’ve now written more than a hundred Claude skills across four Claude Code workspaces, one for my own business and the rest for client work, and the same four layers keep turning up underneath every GTM system that I’ve built that works:
Skills: packaged jobs, such as building a battlecard, that you trigger by name.
Context: the written-down facts, rules, and voice that every job reads before it starts.
Orchestration: what decides when a job runs and what has to finish before it, plus where its output goes.
Evals: the checks that run on the output before it reaches a rep or a customer.
Most teams that I talk to have built one of these and stopped — usually skills. Any one layer on its own is a toy, something that impresses in a demo and breaks in daily use, and each layer fails in its own predictable way. Of the three components I described in What AI GTM engineering is, context comes first; skills and orchestration make up the second; evals check the output of both; and enablement is the third, focused on the people who run the system. These four layers are the stack that the competitive intelligence system I promised in my last post will run on. That post described one piece of it, a battlecard system, which I’ll use as the example here.
A battlecard skill waits for somebody to remember it
My battlecard skill is a good example of the skills layer. It’s one packaged job, triggered by name, and it knows which sections a card needs, which deal scenarios to cover, and which claims a rep should never make. In September, I asked a fresh Claude session, with no files or history, to write a battlecard prompt. It wrote one about as good as mine, which shows how cheap this layer has become.
On its own, though, a skill runs only when somebody remembers it exists, and it runs on whatever that person pastes in. A competitor that changes its pricing in March can go without a new card until June, when a rep finally asks for one, and the skill builds it from whichever notes the rep has open. That’s a prompt library with better packaging, and it keeps most marketing teams at the personal stage of the AI GTM maturity model, where AI is episodic and depends on someone to run it.
Context only counts when the jobs read it
Before a job writes a word, it should know your positioning, voice, and the corrections that come back from sales. It should also know which file is the master copy of each list that you maintain, such as competitors or target accounts. I’ve written about the components that hold that context and what Claude’s memory adds over time, and context engineering gets its own post later in this series. Here, I’ll stick to the bugaboo that bites most teams.
Writing context down isn’t enough, because each job has to find the master copy and read it the way you meant it. In early September, a job of mine updated my content calendar using a column that it mistook for the row number. That column held an old article ID, the sheet wasn’t sorted by it, and the job overwrote two rows and created a duplicate before I caught it. The skill worked as written, and the context existed. Nothing in the context said which column identifies a row, so the job guessed. Every calendar job now reads a rule that names the ID column before it writes, along with an instruction to read the row back afterward.
Orchestration repeats your mistakes on schedule
For one client, a market intelligence scan runs on the 16th of every month at 4 a.m., without anyone starting it. The day before, a Slack message gives me a heads-up so that I can add anything that the scan should cover. Once the scan runs, it files the results in Notion and Google Docs and sends me a summary email. In the battlecard system from my last post, a site monitor watches competitors’ web pages, and a pricing change that it catches is one of four events that tell the battlecard skill to rebuild a card. The other three are a new win-loss analysis, a major deal won or lost, and a correction from the field.
Orchestration also repeats whatever is underneath it, mistakes included. When the corrections that a scheduled rebuild reads from are wrong, the rebuild copies the wrong claim into every refreshed card without anyone touching it. Scheduled jobs also fail where you can’t see them. In September, one of my publishing jobs ran an hour early because of a time-zone mismatch, and I didn’t see its desktop notification for a day, so those publishing jobs now email me when they fail.
For a CMO, or a private equity operating partner overseeing several portfolio companies, the cost of a wrong claim grows with how much the team has automated. A wrong claim in a hand-built battlecard reaches the reps who open it. The same claim in an orchestrated system reaches every rep, every refreshed feature matrix, and every web page built from it, every time it runs, and it looks just as polished as the true ones.
Evals are the layer teams build least
An eval checks a system’s output before it reaches a rep or a customer. It compares the output to something you know is true, and a named person owns the result. In the State of Agent Engineering survey from LangChain, which sells tools for monitoring and evaluating AI agents, 89% of organizations reported some form of observability on their agents, while 52.4% ran offline evaluations on test sets.[1] Watching a system run and testing whether its answers are correct are separate jobs, and I’d bet marketing teams trail software teams on the second by a wide margin.
Most GTM teams already collect the raw material for one eval: corrections from reps. In the battlecard system from my last post, every correction from a rep or the product team goes into a field-intelligence log that records who made it, when, and how confident they are. When the log and the competitor research disagree, the log wins. In that post, a client’s sales materials listed four deployment options when the product had three, and the correction became a test that every battlecard, feature matrix, and web page had to pass. A card that gets a claim wrong in front of the prospect’s own engineers costs the rep credibility with the buyer, and after that, the rep stops opening the card. That’s why checking every claim against the log pays for itself first.
“Orchestration without evals is a confident machine for being wrong.”
— David Sweenor, Founder/CEO, TinyTechGuides
Evals on their own break too. A check with nothing to trigger it runs only when somebody remembers it, which puts you back at the skills problem, and a check against a log that nobody updates passes claims that stopped being true months ago. The check needs the other three layers to tell it when to run and what’s currently true.
The client blog from the start of this post had plenty of checks and no eval of what a reader would understand. Now, a separate AI model reads each draft with nothing but the file, like a first-time reader, and lists every phrase it can’t resolve. The same check applies to the numbers you report up, since a note in my own tracker claimed for three years that the YouTube analytics API couldn’t separate paid views from organic ones, and one test would have shown that it could.
With all four layers in place, here’s how the battlecard from my last post works. The context holds the rule that field corrections outrank the research, and the skill knows what a card needs. Orchestration rebuilds the card when a pricing change or a lost deal makes it wrong, and evals check every claim against the field-intelligence log before a rep sees it.
Four questions for your stack
So, how do you know which layer you’re missing? Answer these for an ordinary week, since your best project will flatter you:
Skills: Which of your recurring GTM jobs is packaged as a skill, and which still lives in someone’s prompt history?
Context: When two jobs need the same fact, such as a competitor’s pricing, do they read the same file, and does that file record who last corrected it?
Orchestration: What event would make your most-used sales asset wrong, and does anything watch for it?
Evals: Before a rep says it on a call, would your system catch a claim that could cost the deal?
Most teams can answer the first question and get stuck on the third. In my next post, I’ll build a competitive intelligence system in four layers and show what each layer reads and hands off, plus how its output gets checked. If you’d like to compare notes sooner, I’m happy to spend thirty minutes walking through your stack with you and naming the layer worth building next.
You can buy the tooling for every layer. You can’t buy the record of which claims your reps stopped trusting, and that record is what the context and evals are built from.
Interested in learning more? Book a meeting.
Frequently asked questions
What is an AI GTM stack?
An AI go-to-market (GTM) stack is the set of layers a GTM team needs for AI work to run as a system rather than as one person’s habit. Skills are packaged jobs, like building a battlecard, and context is the facts, rules, and voice those jobs use. Orchestration decides when each job runs, and evals check AI output before it reaches a rep or a customer.
What is an eval in an AI marketing system?
An eval checks an AI system’s output before it reaches a rep or a customer. It compares the output to something known to be true, such as a log of sales corrections, and a named person owns the result. In LangChain’s State of Agent Engineering survey, 89% of organizations reported some form of observability on their AI agents, and 52.4% ran offline evaluations on test sets.
How is orchestration different from a Claude skill?
A Claude skill is one packaged job, such as building a battlecard, that runs when somebody triggers it. Orchestration decides when that job runs without anyone asking, and what runs first. When a site monitor catches a competitor’s pricing change and tells a battlecard skill to rebuild the card, the skill becomes part of a system. Orchestration also repeats mistakes, so it needs evals to check its output.
Why isn’t a library of Claude skills enough for a marketing team?
A Claude skill runs only when somebody remembers to run it, and it works from whatever that person pastes in. A battlecard for a competitor that changed its pricing in March may not be rebuilt until a rep asks for it in June. Without context that the skill reads, orchestration that runs it, and evals that check it, a skill library is a prompt library with better packaging.
Where should a marketing team start building an AI GTM stack?
Answer four questions for an ordinary week. Which recurring GTM jobs are packaged as skills? Do jobs that need the same fact read the same file? What event would make your most-used sales asset wrong, and does anything watch for it? Would your system catch a claim that could cost a deal before a rep says it? Most teams can answer the first and get stuck on the third.
How does the AI GTM stack relate to AI GTM engineering?
AI GTM engineering is the practice of building AI systems into how a go-to-market team works, and it has three components: written-down standards and context, workflows that run without anyone starting them, and enablement for the people who operate them. Context is the first component. Skills and orchestration together make up the second, since skills are the jobs and orchestration runs them without anyone starting them, and evals check both outputs. Enablement covers the people who run the stack.
About David Sweenor
David Sweenor is the founder and host of the Data Faces podcast, where he talks with the people who are making data, analytics, AI, and marketing work in the real world. He is also the founder of TinyTechGuides and a recognized top-10 AI thought leader and international speaker specializing in practical business applications of artificial intelligence and advanced analytics.
With over 25 years of hands-on experience implementing AI and analytics solutions, David has supported organizations including Alation, Alteryx, TIBCO, SAS, IBM, Dell, and Quest. His work spans marketing leadership, analytics implementation, and specialized expertise in AI, machine learning, data science, IoT, and business intelligence. David holds several patents and consistently delivers insights that bridge technical capabilities with business value.
Books
- Artificial Intelligence: An Executive Guide to Make AI Work for Your Business
- Generative AI Business Applications: An Executive Guide with Real-Life Examples and Case Studies
- The Generative AI Practitioner’s Guide: How to Apply LLM Patterns for Enterprise Applications
- The CIO’s Guide to Adopting Generative AI: Five Keys to Success
- Modern B2B Marketing: A Practitioner’s Guide to Marketing Excellence
- The PMM’s Prompt Playbook: Mastering Generative AI for B2B Marketing Success
Follow David on Twitter @DavidSweenor and connect with him on LinkedIn.
Footnotes
[1]LangChain. “State of Agent Engineering.” LangChain, June 12, 2026. https://www.langchain.com/state-of-agent-engineering.