The problem: you rolled out AI, adoption looks great, and the system works exactly the way it did before.
The frame: adoption is people going faster. Transformation is the system working differently. They are not the same number.
The 3 lessons that close the gap: data is the ceiling, the hard part is how you operate, agents need oversight and context.
The proof: each lesson sits on a top-down CRO talk, a bottom-up workflow a rep on my team built, and a named external operator with real numbers.
The action: pick the one lesson your team is weakest on, run its Do-first step today, and paste the oversight prompt at the bottom.
Read time: 10 min
Skip this if you already operate this way
90% of our GTM team used AI within months, and per-rep research dropped from 2 hours to 15 minutes. That is adoption. It is the easy part.
Transformation is the system working differently, and it needs 3 things data is the ceiling, the operating model is the hard part, agents need oversight and context.
Under each lesson sits a real workflow a rep on my team built bottom-up, plus a named external operator who proves the lesson is universal.
Each lesson ends with a tiered action ladder: Do first, Do this week, Do this month, and the signal that tells you it worked.
The agent-oversight prompt at the bottom is runnable today. No GTMcraft Operator Room membership needed.
2 numbers before we go in
90%. The share of our GTM team using AI within the first few months. The easy part.
2 hours to 15 minutes. The drop in daily research time per rep. Also the easy part. Neither number means the system changed.
Hi, it is Koen Stam and welcome to GTMcraft: The Future GTM Operator. This newsletter is built from 100,000+ GTM signals collected from 100+ operators and founders, combined with 13+ years of my own lessons and failures from the trenches. I write at the intersection of go-to-market practice and AI-powered systems for founders scaling 0 to 10M+ ARR.
100,000+ GTM relevant signals from LinkedIn, Newsletters and Podcasts indexed. 100+ playbooks structured. 3 GTM operator jobs across 3 GTM motions (SMB, MM, ENT). Same recipe. Now all part of the GTMcraft Operator Room.
Consider joining? (send me a DM for access).
Two things happened this quarter that only make sense next to each other.
My CRO, Philip Lacor, stood on a stage and laid out how Personio is moving from a traditional GTM to an agentic one. Top-down. The strategy, the operating model, the 3 hard lessons from doing it.
In the same quarter, I watched account executives and account managers on my own team screenshare systems they had built themselves. Bottom-up. No mandate, no central project. Just reps removing their own repetitive work.
The interesting part is not either layer on its own. It is that they matched. Every lesson Philip named from the top, someone on my team had already proved from the bottom. That is what transformation looks like when it is working. The strategy and the screens agree.
Here is the frame, worth stealing as-is. Adoption is individuals working faster. Transformation is the GTM system working differently. The 2 numbers above are adoption numbers. The system only changes when you get the next 3 things right.
The whole edition in one slide. Adoption is the easy 90%. Transformation is the system working differently.
Lesson 1: data is the ceiling
The top-down version.
You can buy the best models, the best agents, the slickest tooling, and none of it climbs higher than the quality of the data underneath. An agent reading messy Salesforce, stale ICP definitions, and an intent score nobody trusts will confidently produce garbage. Philip’s framing was blunt: treat the data layer as infrastructure, not a project. It is never finished. Deduplication, enrichment, scoring models, intent iterations. The work never stops because the ceiling moves every time the data improves.
Bottom-up proof:
one of my account managers built a portfolio dashboard that scores every account on risk and expansion by combining live Salesforce data with Gong call sentiment. It works because the underlying signals are clean: license gap, last contact, renewal proximity, adoption score, sentiment. When a rep can see all five in one view and trust them, prioritisation stops being a guess. The interface is not what makes it useful. The data feeding it is. The same dashboard on dirty data is a liability, because it routes reps toward the wrong accounts with total confidence.
External proof:
Yamini Rangan, HubSpot, at SaaStr. Across 2,500+ customers their support AI resolves an average of 52% of tickets, but top performers hit 70 to 80%. The gap between 80% and 40% resolution comes down to knowledge base quality and completeness. Same agent. Different data underneath.
Real signals, scored in one view. The dashboard is only as good as the data feeding it.
Do first (under 30 min): name the one data source your team distrusts most. The one that makes reps say “I do not believe that number.”
Do this week: pull 20 records from that source and check them by hand against reality. Quantify the error rate so it stops being a feeling.
Do this month: assign one owner to that source and treat it as infrastructure, with a recurring clean-up cadence. It is infrastructure, so it never closes as a project.
You know this worked when: a rep pulls a number off that source in a deal review and nobody in the room questions whether it is real.
Go deeper: my breakdown “Before GTM Engineering, Fix Your Architecture” walks the full sequence, architecture before data before signals before execution. It lives in the Operator Room at gtmcraft.circle.so.
Lesson 2: the hard part is not AI, it is how you operate
The top-down version.
The technology is the easy part now. Anyone can spin up an assistant. The hard part is redesigning how the team works around it: who owns the agent, what the rules of engagement are, how a frontline experiment becomes a standard instead of dying as a one-off. Philip’s model is three tiers. Locked foundations the centre owns and governs. A structured program that ships within those standards. Permeable grassroots experimentation where reps try things, log them, and the best ideas escalate. Ideas flow up, standards flow down, one front door, no side channels. That is an operating model, and it is the actual thing that moves the needle. The tools are downstream of it.
Bottom-up proof:
An account executive on my team automated his entire morning inbox review. It used to take an hour: open Gmail, cross-check Salesforce, search Slack for context, write replies from scratch. Now a scheduled routine runs at 7:30am, reads 8 live data sources, drafts every reply in his own voice, flags what needs a decision, and lands a summary in Slack before he sits down. The build is impressive. What keeps it alive is operating discipline. He trains it in a dedicated Slack channel, a thumbs down and a note, and the next morning it has adjusted. That feedback loop is the operating model in miniature. The agent improves because he operates it like a new hire. The cleverness of the tech is beside the point.
External proof:
Yamini Rangan, HubSpot. When they went AI-first, HubSpot spent 4 months planning their 2023 roadmap, then in January 2023 said pivot, that entire roadmap is not what we are building, and shipped first AI features 2 months later. The decision was an operating decision made at the top. The tooling followed. Same shape as Philip’s three tiers, same shape as my AE’s feedback loop, just at company scale.
The operating model in one frame. Ideas flow up, standards flow down, one front door.
Do first (under 30 min): pick one AI experiment a rep is already running quietly. Just name it and write down what it does.
Do this week: give that experiment a home. Name one owner, write the single rule it must follow, and decide how it escalates if it works.
Do this month: stand up the smallest version of three tiers. One locked standard the centre owns, one place experiments get logged, one path for the best ones to become the standard.
You know this worked when: a rep’s side experiment becomes a team default without you personally carrying it there.
Go deeper: my AI-SDR operating-system playbook is built entirely on this idea, that the challenge is never deploying the agent, it is designing the operating model around it. In the Operator Room.
Lesson 3: agents and assistants need oversight and context
The top-down version.
An agent without oversight drifts. An agent without context guesses. Both fail quietly, which is worse than failing loudly. Philip was direct that this is where most of the real work lives: purpose-built context rather than reused decks, daily review like you would give a new rep, guardrails before scale, metrics defined upfront. The honest half of his lesson was the failure list. Light training leads to fast degradation. Too much or outdated context makes outputs worse. Parallel agents dilute quality. Scope creep kills focus. None of that is a technology problem. All of it is an oversight problem.
Bottom-up proof:
The same inbox agent from lesson 2 makes this concrete. It never sends anything automatically. It drafts, it flags, a human decides. That is oversight built in on purpose. Nothing about it is accidental. And it only drafts well because it is fed purpose-built context: this rep’s voice, his accounts, his product channels, his feedback from yesterday. Strip the context and it writes generic email. Strip the oversight and it sends the wrong thing at 7:30am with nobody watching. The system is good precisely because a human stayed in the loop and the context was built for the job.
External proof:
Jason Lemkin, SaaStr. As AI gets better, the remaining human work gets harder, not easier. SaaStr sent 4,495 AI emails with top response rates, but it required 90 minutes every morning training the AI and an hour every night reviewing performance. And the iteration cost is brutal: their AI SDR handling sponsor inquiries needed 47 iterations to stop being too aggressive on pricing. 47, not 4. On context, Rangan’s framing is the cleanest I have heard. When an employee joins, you give them your products, your ICP, your brand voice, your competitive differentiation. The same thing is happening with agents. An agent is a new hire.
Do first (under 30 min): take one agent or assistant your team already uses and answer two questions. Who reviews its output, and how often. What context was it given, and was that context built for this job or borrowed from a deck.
Do this week: if either answer is weak, fix the weaker one. Add a daily review owner, or rebuild the context file for the specific job.
Do this month: write the context file properly, the way you would onboard a rep, and set a standing review cadence before you scale the agent to anyone else.
You know this worked when: you can hand the agent to a second person and it holds quality without you in the loop.
The honest half. What broke when oversight and context were missing.
Run this today. Paste it into a Claude Project to audit one agent or assistant for oversight and context before you scale it.
You are an AI operations reviewer for a B2B SaaS GTM team. Your job is
to stress-test one agent or assistant for the two things that make
agents fail quietly: missing oversight and missing context.
The agent I want to audit:
- What it does: [one or two sentences]
- Who uses it and how often: [fill in]
- What it is connected to (data sources, tools): [list]
- What context it was given: [paste it, or describe what you fed it]
- Who reviews its output today, and how often: [fill in, or "no one"]
Do this:
1. Oversight check. Tell me where this agent can fail without anyone
noticing. Name the single highest-risk unreviewed output and what
a bad version of it would cost.
2. Context check. Compare the context I gave it to what you would give
a new hire in this role (ICP, voice, product, guardrails, what good
looks like). Name exactly what is missing.
3. The fix. Give me a daily or weekly review cadence sized to the risk,
and a rewritten context outline built for this specific job rather
than borrowed from general material.
4. The scale gate. Tell me the one signal that means this agent is safe
to give to a second person, and the one that means it is not ready.
Ask me for anything you need before you answer.
Go deeper: the full reality of running agents in production, including the iteration counts and the daily-review cadence, is broken down in the Operator Room alongside the AI-SDR playbook.
Steal this move
Close the adoption-to-transformation gap in 4 weeks. For you if you are 0 to 10M+ ARR and your AI rollout looks busy but the system has not actually changed.
Week 1, raise the ceiling: name your least-trusted data source, hand-check 20 records, and assign it an owner. Data before agents.
Week 2, build the operating model: take one quiet rep experiment, give it an owner, one rule, and an escalation path. That is your smallest three-tier system.
Week 3, install oversight: run the prompt above on one live agent. Add the review cadence and the rebuilt context file it gives you.
Week 4, connect the three: pick the one workflow where clean data, a clear owner, and human oversight all meet, and make it the reference example you point the rest of the team at.
Why this matters now
Where the operator role is going. From executing the work to governing the system that does.
The teams winning with AI in 2026 are not the ones with the most tools. They are the ones who rebuilt the system underneath the tools. Clean data so the agents can see. An operating model so good ideas compound instead of dying as one-offs. Oversight and context so the agents act like trained hires instead of confident strangers. None of that is a purchase. Every bit of it is work you do over time, learning, breaking it, iterating, the same thing every operator winning with AI will tell you off stage. Adoption is a Tuesday. Transformation is a quarter. The reps on my team did not wait for the quarter. They started bottom-up, one removed job at a time, and the strategy from the top met them halfway.
Reply to this email with the one lesson your team is weakest on right now: data, operating model, or oversight. I read every reply, and the patterns tell me what to build next.
