GTM OS · What it actually is
The version I would say to you across a table, in six short beats.
GTM OS is open-source software that runs a company's marketing and sales motions on its own data, by definitions the team writes down once and every tool, agent and person then follows.
Your motions, run on your data, by your rules, on code you own
Beat 01
I have built the same lead scoring engine for more companies than I can list. Same outreach chain. Same page generation with the same quality checks. Same budget maths. Same reporting. Different company, different logo, almost the same code underneath.
Every company I work with runs a version of the same short list.
Today a company has two ways to get those. Rent them back as SaaS at a price that stopped making sense, or pay an agency to rebuild them from zero. Both burn money on work that was already done somewhere else. GTM OS packages that shared code once, in the open, so nobody pays for it a third time.
Beat 02
When you strip two of those builds down side by side, almost everything matches. Two things never do.
Scoring logic, outreach chains, page generation and quality checks, budget maths, data mirrors, reporting, approval gates.
The wiring to their tools. Their definitions.
The wiring is a solved problem. Connectors to the hundreds of tools a company might use can be rented, then they read your data where it already lives. We put our own interface over the top so nobody is locked to whoever we rent from this year.
That leaves the definitions. Nobody has done those properly. They are the rest of this page.
Beat 03 · the one that matters
Your CRM has a lifecycle stage. Your SDR keeps a sheet with a different one. Your ads platform counts a form fill as a conversion. Finance counts a customer at first invoice. Every tool in the building has its own private idea of what a lead, an account and a customer is.
People paper over that in meetings. An agent cannot. Tell an agent to qualify accounts while three definitions of qualified are live and it will do damage quickly, confidently, at scale.
| The word | What it means in your building, right now |
|---|---|
| Lead | A form fill in ads. A stage in the CRM. Anyone the SDR has emailed twice. |
| Qualified | Fits the ICP. Booked a meeting. The rep says so. |
| Customer | Closed won in the CRM. First invoice paid in finance. Live in the product. |
So before a single agent runs, somebody has to write down one answer to a short list of questions. What is a company, a contact, an opportunity, a signal, a campaign. What stages does each move through. Who is allowed to do what to each one, meaning research it, enrich it, contact it, disqualify it, write it back to the CRM.
That written, signed answer is the rules book. Engineers call it an ontology. Same thing.
We take read-only access to your top two or three tools. We look at what is actually in them, field by field, stage by stage, with a model doing the reading. Then we ask what your definitions already are in practice, rather than what the process document claims. What comes back is a list of contradictions. A typical one reads "1,400 contacts marked customer, no closed deal against any of them".
Then each contradiction goes in front of the person who owns it. They decide. They sign. That takes about three weeks. Almost none of it is technical. It takes three weeks because it forces decisions nobody wanted to make in public.
For scale, a very capable team at a large company spent four to six months doing this by hand before anything else could start.
Every agent, every app and every person now means the same thing by qualified.
You say "move our ICP from SMB SaaS to enterprise logistics" and the system works out what has to change. This is the part we are building, it does not run today.
HubSpot to Salesforce becomes a connector change. The definitions stay exactly where they are.
It is the one piece of your go-to-market that is genuinely yours. A file, in your repo, that no contract can take back.
One person who owns definitions, for two hours, then fifteen minutes a week.
Being straight about it. The rules book is the slow part and the political part. That is also exactly why nobody has packaged it.
Beat 04
Once meaning is shared, everything built on top gets cheap and safe. Here is what sits on top, in the finished version. Agents do the research and the qualifying. Plays run a motion step by step, with a human approving whichever steps you want approved and the rest running on their own. Apps are the real screens your team works in. And an AI engineer changes the system when you ask it in plain language.
The human gate is a setting per move. Some moves should never wait for a person.
Read from the tools you already pay for.
The rules book, as something software can read. Exists per client today, the shared format lands with motion one.
The motions themselves, with the gates you set.
The screens your team works in. A clickable prototype exists, the first real one ships with the proof.
Builds the system and changes it when you describe what you want. The proof is its first test.
Plan it, review it, ship it, roll it back.
Green means it runs inside client builds today. Everything else is dated against the roadmap below. Those six are the engineering order, the six beats on this page are the order it makes sense in.
Beat 05
The most important decision on this project was what to refuse to build. Every competitor rents the same models and the same connectors we do. Nobody has ever won a market on commodities.
All commodity. All cheaper every quarter.
Rent anything anyone can buy. Build only the layer that makes the rented parts behave like one system.
Everyone rents the same models. The only place left to win is the layer that turns them into one system.
Every deployment teaches the format and the templates something new. That data never touches the public internet. More installs, better core.
The licence is AGPL. You cannot be held hostage on price. A competitor cannot fork it, close it and sell it back.
It sits in your own rules book and in the people who know how to write one. Both grow with use.
On what it costs to run. Rented parts carry a bill and that bill lands on you. The order we work in is deliberate. Prove the value on one narrow motion, measure where the bill bites, then replace that specific piece. Because the code is open, the community can do a lot of that replacing. Optimising cost before the value is proven is how platforms die.
Beat 06
We are in closed alpha with a founding group of about ten implementers. Motion one, outbound plus signal scoring, runs end to end for that group in September and installs into their own stacks in October. The repo opens after it has been used on real projects, when it is good enough that you would not look at it and say you could have built it yourself. No public date for that, on purpose.
One motion running end to end on one real company, from a blank sandbox to a deployed app. If it is not impressive, nothing else gets built.
In buildOutbound plus signal scoring, in closed alpha. Five objects, five building blocks, five connectors. The founding group installs it into their own stacks.
NextDescribe the change you want in plain language and the system works out every object, agent and app it touches.
PlannedEnterprise controls, the apps platform, then an ecosystem where people publish their own connectors, rules books and plays.
PlannedThe repo opens on a condition. Once the founding group has shipped it on live client work. No date on that, on purpose.
I told some of you three to four weeks for motion one. Update. The founding group sees it run end to end in that window, on one real company. Installing into your own stack is October. The public repo comes after that. We chose to do the definitions work first because that is the part that breaks every project.
The same rules-book idea works for finance and operations. That is years away and we say nothing more about it.
Appendix · for the build team
Everything below comes out of four real builds. It is here so the same lessons do not get relearned. Three of these are open questions with no owner. Those are marked.
The August design has seven canonical tables, accounts, contacts, deals, events, signals, scores, actions, with one generated adapter per client and a definitions.yaml holding weights, bands, caps, suppression and stages. The September design has objects carrying properties, relationships, actions and permissions together, plus a resource graph.
They are the same idea at different fidelity, with one real difference. Behaviour attached to the object is new. Three things do not map cleanly. scores is a table in August and a property in September. events is roughly Activity. Campaign, product and territory do not exist in August at all.
This is the most consequential decision on the build. Deciding it late means rewriting every adapter.
On the 2 September call the answer was no, revenue comes from building. The architecture doc written the same day describes white-labelled hosting on Cloudflare where the customer never needs a Cloudflare account. Both cannot be true. It changes the revenue model, the security surface and what a client signs.
It appeared independently in three of four builds, for two different reasons.
Design for read-from-mirror, write-back-on-approval, from the first line.
Real numbers from one build. Email was 63 percent filled, so a third of contacts had none. The national tax ID that actually identifies a buyer was spread across about eight fields. Two of them, at 30 and 28 percent fill, disagreed with each other. Phone lived in three fields. Company domain was 2 percent filled. The reliable keys were an internal user ID at 100 percent and a technical ID at 97.5 percent.
Four algorithms were needed, in this order of usefulness. Tax-ID clustering, which collapsed about 25 percent of records. Phone and messaging-number matching. Email, the least reliable. Edit distance on phone numbers to catch typos.
Treat email as unreliable. Make the key configurable per client, then make entity resolution a first-class step ahead of any scoring.
One build began with an export of 32 objects, one file each, with a fill-rate column on every property. Scale, for a sense of it, was 687 properties on a contact, 715 on a deal, 476 on a ticket.
That single column is what exposed a written company-wide funnel definition resting on a field filled 0.01 percent of the time. Design against fill rates, never against the schema as documented.
Every client has different stages. One had New, Attempting, Connected, Meeting booked, Placed an order, Lost and Disqualified, with over 53,000 in Lost and two of the named Lost reasons being data problems wearing a stage label.
Every action needs a gate stored beside it, with at least three values, automatic, human-approved and human-sent. One client gates outbound entirely. Another gates only large amounts and accepts a three to five percent error rate on the rest. That belongs in configuration. A fork of the code for each client is how this dies.
A single global score is wrong. Grade sets the bucket first, then the score means something inside it, because a score means a different thing to an enterprise rep than to an SMB rep. Score the contact, not only the company, because a company has around ten contacts and you talk to a person.
The output shape that worked, worth copying exactly. A number, the band, the reason written in plain words, then the next best step. Then the next step lands as a task in the tool the rep already lives in. Weights self-recalibrate in roughly two weeks, so build for tuning rather than for correctness on day one.
Roughly 70 to 80 percent of the largest build is deterministic. Rubrics, dedup, joins and thresholds are ordinary code. The model reads documents and drafts language. Keeping that boundary is what makes the output explainable to a rep, keeps the weekly run cost around 500 dollars and heading toward 50, then lets a client say they know exactly what is happening.
Their repo, their database, their deployment target. One engagement forbade hosting on our infrastructure outright because of client data and penalty clauses. Expect four different stacks and design the adapter boundary so the engines never care which one they landed in. So far that has meant a CRM-centric stack, a Salesforce plus mirror stack, a Microsoft stack built by the client's own people, plus a warehouse-centric stack handling about a terabyte a month of logs.
One team evaluated a major cloud's AI platform and rejected it because the SDKs were not fluent enough. Stack choice belongs to the client, so treat it as an input.
These are already documented and each one broke something. If the model survives all of them, it is probably right.
Phase one is five objects, five building blocks and five connectors. Resist widening it. The proof phase exists to be killed, so if one motion end to end on one real company is not impressive, the rest should not get built.
Before anything goes on a public page, apply this test. Which file in the repo is this? The rules book passes today. The graph, the resource graph and the AI engineer do not, yet.
GTM OS · what it actually is
internal · not for sharing