How I Built a GTM Cockpit on Headless Connectors (MCP + API)
The headless GTM argument is that one neutral control center should be the head - the interface where you see, decide, and steer - on top of the bodies underneath. That is easy to say. This is how I actually built it: a build log of the cockpit I assembled on top of headless connectors instead of living across a dozen vendor UIs, what is wired into what, and the parts that bit me. That cockpit is now the hosted product, GTM OS - so you can run it without building it. I am not going to pretend my stack is special or the only way. The point is the shape - one head, many bodies, joined by API and MCP - because that shape is the thing the vendors did not price in when they went headless, and it is now a hosted control center any operator can run.
The architecture, in one sentence
A single control center is the head. Every data source, sending channel, and record store underneath it is a headless connector it calls. The cockpit holds no proprietary data engine of its own - it is an interface, not a database company. It reads from and writes to services over their APIs and, increasingly, their MCP servers, on your own AI keys, and it presents one screen where a human runs the whole motion. Swap any connector and the head does not change. Change the head and the connectors do not care. That decoupling is the entire benefit.
The bodies (what I rent)
Concretely, the connectors my cockpit calls: Data: Apollo for contact and company data, over its API. A commodity I pay for by the credit; I would rather buy it directly than through a platform markup, and I can swap it without touching the head. Sending: Amazon SES or a Google Workspace mailbox, switchable per domain. The cockpit talks to SES over the AWS SDK and to Gmail over an app password; the head does not care which is active. Replies: IMAP, read straight from the active mailbox and parsed in the app. When a known lead replies, the cockpit stops their sequence and drafts a response for me to approve. Records: HubSpot as the CRM of record, synced over its API. The cockpit is where I work; HubSpot is where the data is canonical. Everything else: Google Search Console and GA4 via a service account, Stripe for payments, and the model APIs (Claude, plus OpenAI for one connector) for research and drafting. Each is a rented, swappable, agent-callable body. A deliberate choice: the clients for these are thin, direct-fetch wrappers, not heavyweight SDKs. The surface used from each is small, the APIs shift, and changes stay localized to one file. Running the head from one place means holding these seams on purpose.
The head (the control center)
The head is GTM OS: one operator surface for the whole motion - outbound, replies, demand signals, lifecycle from trial to paid, deliverability health - with a hard rule that a human approves anything that leaves the building. Every draft is shown byte for byte before it sends. It started as a boring build with Claude Code; it is now the hosted product. Because you run it on your own AI keys, the model spend, the data calls, and the bill are all yours to see at cost, and your leads and replies stay on your keys, not in a vendor's multi-tenant store. None of that is impressive engineering - it is deliberately boring engineering. The value is not the tech; it is that the interface is one neutral place, and so are the decisions encoded in it.
Why one neutral head beats a single vendor platform
Three reasons, the same ones I lay out in consolidating your GTM stack, aimed at the interface. Control: the views operators see are the ones the motion needs, not the ones a single vendor's roadmap landed on this quarter. Marginal cost: the cockpit is one subscription with the rails reached on your own keys at cost, not a per-seat platform margin stacked on every tool, so the cost curve flattens as the motion scales. Optionality: because every connector is headless and swappable, you are never locked in. A better sender, a cheaper data source, a new agent - all of them plug in under the same head.
What broke, and what is genuinely hard
Building the head was not free, and the honest part is the useful part - it is also the part the hosted control center now absorbs so you do not have to. Amazon SES starts in a sandbox that only emails verified addresses and caps you at 200 a day until you request production access - useless for cold outreach on day one. I bridged on a Google Workspace mailbox while approval cleared. The hosted cockpit handles this transport wrangling for you. Rented APIs fail in ways a polished platform hides from you: rate limits, partial responses, the occasional silent failure where a call "succeeds" and returns nothing useful. Building the head myself, those were mine to detect and handle - the cockpit needs the gates and retries the vendor UI used to provide invisibly. In the hosted version, that hardening ships in the box. And the big one when you build it yourself: you become the vendor. Deliverability questions at 11 p.m., maintenance, the connector that changes its API on a Tuesday - all your job. None of it is hard in isolation; all of it is a tax on your time. That tax is exactly what running the hosted GTM OS removes: you keep the control and the own-keys economics, and hand off the platform itself.
Build your own head, or run the hosted one?
The same test as the hub: the question is no longer whether you can build a cockpit - you can, the floor dropped to a weekend - it is whether you should, when the hosted version already exists. If tinkering on the codebase is itself the point for you, build it. For everyone else, the move is to run the neutral control center rather than letting a single vendor's surface become your head by default. There is no wrong answer, only an unconscious one: never deciding, and living across a dozen vendor UIs because you never picked one place. If you want the skills that assemble this kind of thing, the Operator Playbook is the set of GTM Claude skills I use - the cold-outbound-sequence skill wrote the sequences inside this cockpit. If you want the hosted control center itself, GTM OS is it - a free trial, your own AI keys, the whole motion from one place.
Frequently asked questions
Do I need to be a software engineer to build a GTM cockpit like this?
You need to be comfortable in a codebase and reading API docs - the level of a technical operator or GTM engineer, not a career software engineer. Tools like Claude Code do most of the actual writing; your job is the architecture, the connector choices, and the judgment encoded in the interface.
Is this just reinventing what Clay or a CRM already does?
No - it sits on top of them. The cockpit is the interface and the decisions; the data and execution are still rented from headless bodies like Apollo, your sender, and your CRM. You are not rebuilding a data company, you are building the one screen where you steer the ones you rent.
How long does it take to build?
The first usable cockpit - pull leads, draft, review, send - is a weekend for a technical operator now that the backends are headless and an AI writes most of the code. The depth (lifecycle, signals, deliverability health) accretes over weeks. The point is that the floor dropped from a platform migration to a weekend.
What happens when a connector API changes?
You fix one thin client file and the head stays the same. That is the upside of keeping connectors as small, isolated wrappers - a vendor's breaking change is a localized repair, not a platform-wide outage. It is your job now, but it is a contained job.
Can AI agents run inside this cockpit?
Yes - that is the direction. A crew of named AI agents does the work underneath (research, drafting, list-building) and the cockpit is where a human approves and steers. One neutral control center is exactly what gives you a place to keep agents on a leash instead of letting them run inside a vendor surface you do not control.