The era of the "AI marketing OS"
And why the FOMO is real this time
For the last three years, the big debate inside marketing teams was which AI model to pick. GPT, Claude, Gemini? Which one for visuals? Which one for automations? That debate is settled, and let’s be honest: mostly because it doesn’t matter. On almost every marketing task, they land within a few points of each other.
The real bottleneck is everything around the model: your context, your workflows, who can access what, what gets updated and what rots in a corner. An org problem, not a model problem.
Kieran Flanagan, put it plainly on Momentum: “model capabilities are moving really really rapidly, but integration into how companies work is moving really really slowly.”
So here’s my conviction. The next work surface for modern marketing teams won’t be a new tab in a SaaS tool, and it won’t be another dashboard. It’ll be Claude (or Codex, or an equivalent). Engineering already made that move. Marketing is next.
The market has noticed. Notion, Clay, Profound, DOJO: they all sell you a “system” now. Four different words for the same idea, the AI marketing OS.
(Be honest: when your competitor, your CRM, and your note-taking app all call themselves an OS, the word stops meaning much.)
Before playing critic, we built our own OS.
To do it, we mapped every marketing workflow we run at Bulldozer. Webinar production, the Momentum podcast, ICP (Ideal Customer Profile) and jobs-to-be-done pulled from sales calls, SEO/GEO, LinkedIn ads management, the performance dashboard... Thirty-two in total.
We didn’t rebuild all thirty-two. We ranked them by frequency × revenue impact, kept the top three, and rebuilt those properly: documented, AI in the loop, one measurable output each.
Eight weeks later, monthly pipeline went from €1.7M to €2.4M. That’s +41%, with no new hire.
I’m not sharing this to show off or wave a trophy (I already posted the number in May). I’m sharing it for what came next, and for what it cost to get there.
What the landing pages leave out: building an OS is mostly writing down what you never wrote down.
Most of the companies we see getting started are rebuilding the internal wiki they never took the time to create. The ICP that lived in one person’s head. The positioning that changed twice and got documented zero times. The data infrastructure nobody had time to lay down.
That work is worth doing. It’s how you onboard people faster, and how agents finally get real material to run on. BUT be honest about what it is: documentation. It doesn’t make your team smarter. Writing a “skill” for your job doesn’t deepen the expertise behind the job.
That’s where most AI OS projects stall. The wiki isn’t refreshed. It ages in place. Six months in, half of it is wrong and the agents are running on stale context. In short, you used AI to build... a filing cabinet.
Context has two layers:
Everyone has the first: who your ICP is, what you sell, how you position.
The second is the hard one: domain expertise. Not “here’s our brand voice,” but “in this situation you make this call, in that one you make the opposite.”
That second layer is exactly why companies hired agencies for thirty years. A good agency has seen your situation fifty times, across fifty clients. It knows which lever to pull and when, before you’ve finished describing the problem. That judgment doesn’t come out of a “skill” you cloned off GitHub last week.
The gap between a wiki and an OS is that judgment layer, kept alive. That’s exactly the direction we’re taking at Bulldozer (and rolling out with clients over the past few weeks): running the change with a team until AI is genuinely productive everywhere, instead of shipping a template and leaving.
If you want to build one, here’s the order I’d recommend.
Split context into two layers. Personal knowledge (your notes, your methods) lives in .md files in Obsidian, private. Company knowledge (ICP, objections, positioning, proof) lives in Notion, shared with the team. One partner reads both. Two tools, because two jobs.
Add a hierarchy of context files. One master file for who you are and how you work, then one per folder explaining what’s inside and how to read it. When an agent works in a folder, it reads the local file first. Right context, never too much, never expired.
Turn your recurring prompts into named “skills.” A skill is like a recipe. When I say I’m making a “tiramisu,” that naturally includes eggs, sugar, mascarpone... in a precise order with precise quantities. With skills, you stop rewriting the same instructions and build a library of recipes instead. Our “Monday” routine chains several skills and turns two hours of content production into twenty minutes.
Schedule routines to keep context alive. A monthly task that rereads the month’s sales calls, pulls new objections verbatim, and proposes updates to Notion and Obsidian before anything rots. A six-month-old context is a dead context.
Build feedback loops. An agent that scans what you shipped, pulls the performance data, and updates the system based on what worked. Without it, you’re guessing.
Dictate your context, don’t type it. Tools like WisprFlow let you talk into any field. Two minutes of voice after a prospect call carry more nuance than the three lines you’d type between meetings. Roughly 3x more context in the same time.
And build it inside a cloud or agent environment, Claude Code or Codex, not a chat window. That’s where the work surface is moving.
Every “AI OS” on the market sells the same promise: plug it in, the system runs itself.
None of them ship the two things that matter: your domain expertise, and someone to keep it alive.
You can keep buying this kind of tool and hope it’s plug and play (spoiler: it isn’t). Or you can start building the connection layer yourself, one context file at a time, and own the judgment inside it.
The tool was never the question. The context was. We can help you work on it. Reach out if you’d like to talk :)
Let’s grow 👊
— Jordan