You’ve been building for six months.
Nothing stuck.
Two things kill it every time. The agent has no real context, so it hands back the median of everything on the internet. And when it goes wrong you have no time to work out why, because a launch is happening and the launch always wins. I build the context, and I stay on to fix it when your product moves underneath it.
Four attempts, one reason they died.
None of these failed because you were slow about it. They failed for the same structural reason, and it is underneath all four.
You got better at prompting
Then the chat ended and the context went with it. You explained your product again the next morning, and the morning after that.
You built a custom GPT
It knew your product on Tuesday. By the launch it was quoting positioning you retired in March, and nobody caught it until it was in a deck.
You watched every Claude Code video
They all build a to-do app. None of them build a battle card for a product only you understand.
You started building it yourself
It is in a branch you have not opened in three weeks, because a launch happened and the launch always wins.
Every one of them starts by forgetting who you are.
Give it your context once, in a place it keeps. Every Play reads from that one file, so nothing starts from a blank page again, and when your positioning changes you change it in one place.
What you sell, plainly
Who it is for, and who it is not
Category, alternatives, wedge
POV, value prop, benefits, proof
Words you use, words you never use
Quotes, metrics, customer names
Three Plays. Pick what you actually need.
A battle card that is current
Pulls the real sources when a competitor moves, rebuilds your positioning against them, and waits for your approval.
Drift, caught weekly
Scores your live site, ads, emails and decks against your locked positioning and flags exactly what has drifted.
A brief per feature
Writes the brief and the positioning for your ICP, then maps the timeline so the launch actually lands.
A Play is not one prompt. The bigger builds run several agents together: one pulls the sources, one drafts, one checks it against your positioning, one routes it to you. Nothing goes outward without your approval.
How a Play actually works.
The agent holds your context. Product, customers, positioning, voice. A Play is a workflow it runs. Scoped to one PMM job, producing one specific artifact, always on.
Your context
loaded on Day 1
- ◆
Product
What you sell, plainly
- ◆
ICP
Who it is for, and who it is not
- ◆
Positioning
Category, alternatives, wedge
- ◆
Messaging
POV, value prop, benefits, proof
- ◆
Voice
Words you use, words you never use
- ◆
Proof
Quotes, metrics, customer names
lives in CLAUDE.md
Employee Zero
the brain that never sleeps
It never asks you to re-explain your product, and it already sounds like you.
spec drop / cron / competitor move
pull context → generate → score → rank
artifact committed + Slack notify
Artifacts you can demo
- A launch brief, running on your product
- Battle cards rebuilt from sources you approved
- Messaging drift flagged across your channels weekly
Slack · GitHub · Notion
You already know the number.
Not hours you cannot estimate. The surface you are already responsible for, and how much of it stays current in a month where a launch slips.
Loaded cost, not take home. Used to price what one piece of your surface costs to keep current.
Four levels, and the one you are on.
Every automation sits at a level, and the level decides who checks the work. It is also the honest difference between the two prices, because two Plays do not save twice the hours.
You write it from a blank page every time. Nothing you built last quarter makes this quarter faster.
Where most PMM work still sitsOne agent drafts against your product, your ICP and your voice, so the first version is already close. You read every output before it moves.
One Play, $5,000Sub-agents hand work to each other on one shared memory. A competitor move reaches the battle card and the talk track without you carrying it there. You approve the result.
The pod, $10,000An assistant you point at an objective instead of a task. Real, and honestly out of scope for a seven day Sprint. It sits here so you can see where the ladder goes.
Not sold hereAt level two you are the glue between the steps. At level three the pod is the glue, and that is the whole of what the second Play buys you.
It is also why Enablement is only at the pod. Talk tracks and objection handling run on what Compete and Position already know, so the job needs two Plays sharing a memory before it can exist at all.
What actually happens.
Kickoff and context load
A 45 minute call. We scope the Play. I load your context file with product, ICP, positioning, voice and messaging. Whatever you have today, we use.
Build
I build the agent and scope your first Play. Async updates in Slack. By Day 3 it runs on your real product, not a toy example.
Tune and trigger
We review the first live outputs together. I wire the triggers and integrations. You start using it.
Handoff
A 30 minute call. You own the code, the context file and the Play. It lives in your GitHub, not mine.
All of it. On day seven.
Five agents, in production, today.
A lead generation engine in a regulated market. Five agents, one shared memory, running end to end.
Not a prototype and not a demo. It ran while this page was being written.
After working with me.
Just tested the launch brief. It saved me hours of work.
With Gabriel's help, our response rate increased from 7% to 30% in just a few months, opening up many deal opportunities for us.
Gab's ability to turn complexity into clarity is astounding. There have been times when a simple workshop of 15-20 minutes brings all the insight I need to write a compelling story.
After working on our messaging and ICP, Gab started owning our social content strategy. Within 2 weeks, I've got a 10x impressions boost and my first inbound lead from LinkedIn.
The Sprint ships it. The retainer keeps it true.
Your product changes and your positioning changes. An agent trained in March is wrong by June unless somebody maintains it. That is what the retainer is, and it is why there is a three month minimum: one month is not long enough to know whether it holds.
Tuning and maintenance
When output drifts, I retune. New launch, new ICP, new positioning, I update the context so you do not have to remember to.
Slack on tap
Async by default. Drop a question, get an answer. No daily check ins and no invented urgency.
Monthly review
Thirty minutes. We check the Plays, surface what is not working, and scope what comes next.
Drift detection
Your product moves. I refresh the context when it matters and re-test the Plays against it.
Who this works for.
Book it if
Do not book it if
The things people ask.
Do I need to code?
No. Everything is markdown and a terminal. The terminal is the only new thing, and it is new for about twenty minutes.
What happens if I cancel the retainer?
You keep everything. The code has been in your GitHub since Day 1 and it keeps running. It stops being maintained by me.
Why a three month minimum?
Month one is the build settling. Month two is the first time your product changes underneath it. Month three is the first honest read on whether it holds.
What is the difference between one Play and three?
Scope and memory. One Play does one job well. Three share a single brain, talk to your stack, and keep what they learn, which is more to build and more to keep true.
Can my team use it?
Yes, it is your repo. The one constraint is that somebody has to own the context, and that person should be a PMM.
Seven days from now you could be demoing it.
Twenty minutes to scope it: what your work actually holds, where it drifts, and what the build would take. You leave with the scope whether or not you hire me.