The “Marketing OS” that SaaS vendors sell is an AI platform you buy to replace your stack. The one that actually works you build yourself, piece by piece, because a CMO’s operational knowledge (what you decide, in what order, under what constraints) does not come packaged. The barrier to building it was never technical. It is turning years of marketing judgement into instructions a system can run. This post was written by the system I built.
- The barrier to building a Marketing OS is judgement, not technology: turning your experience into runnable instructions.
- I built it without knowing how to code: 12 agents, 82 skills, 28 pipelines, 4 clients.
- I launch a pipeline and it runs on its own, except where I want to decide.
- I recovered the days that used to go into research, writing and assembly.
- Start with one task and grow from there.
A Tuesday with no surprises
The day disappears into operations and the decisions that move the business get made in the gaps.
You have had the same feeling for years. The day disappears into operations. Coordinating the calendar, reviewing drafts, pulling together the research, chasing metrics, building the presentation. And the decisions that genuinely move the business, the ones that justify your seat at the table, get made in the gaps, usually in a rush. You buy one more tool to save time. Three months later you have one more tool and the same problem. The stack grew. Your capacity to decide did not.
It was 8:30 on a Tuesday. Before I opened my laptop, the system had already finished the research for this post, drafted it in Spanish and validated the keywords against real search data. It was waiting for me in the review folder.
I arrived, read it, corrected what did not convince me and approved it. The heavy lifting was already done.
That is what I mean by a Marketing OS. It is not a robot taking my seat. It is a system that runs the predictable work so I can spend my hours on what defines the outcome: the judgement, the angle, the final call. This is the difference between what AI actually does in a real marketing operation and the hype. The starting pain, the operational load that eats the day, has a solution. And it is not buying tool number eleven.
So the scale is clear before we go on: what runs behind it is 12 specialised agents, 82 skills, 28 pipelines and 4 active clients. It was built by someone who cannot code. Me.
What a Marketing OS is, and what it is not
No software platform knows how a specific CMO thinks. That knowledge does not export to a SaaS.
If you search “Marketing OS” on Google right now, you will find SaaS platforms promising to “bring your entire marketing function under one unified intelligent system”. Some are good products. But that is not what I built.
What I built is different for a practical reason: no software platform knows how a specific CMO thinks. It does not know which messages they have approved for a given client. It does not know which tone works with their audience. It does not know what to avoid because you tried it six months ago and it did not work. That knowledge lives in you, and it does not export to a SaaS.
A system you build yourself can carry it. Because you write the instructions. You define what a good piece of content is and what it is not. You document the decisions. And when the system learns from your feedback, it learns your way of working, not a generic one.
Marketing OS
Marketing OS is a system of AI agents with specific instructions that run the operational work of marketing in an orderly way, with your oversight at the steps that matter. A skill is a standard procedure written for the AI to run the same way every time. The agents are the specialists that run them. The orchestrator decides which one to route each task to.
The barrier to building a Marketing OS was never technical. It is turning years of marketing judgement into instructions a system can run. — Reyes Brusola, CMO
How I got here without knowing how to code
When I started I had no idea how to build anything like this. I put in weeks of learning before I had anything that worked.
The theory sounds good. The problem is that when I started I had no idea how to build anything like this. No Claude Code. No agents. No APIs. I put in the time, weeks of it, learning to build before I had anything that worked.
I learned from what I found in public sources. Rubén Hassid opened the door to the world of Claude and AI tools for me. Ryan Doser taught me to get started with Claude Code from scratch, and some brilliant things about systems. I watched The Viable Edge build marketing systems and it inspired me to create my own without any technical background. Simon Scrapes translated the technical side into something I could apply the next day. Rananjay Raj shares marketing skills on LinkedIn that helped me structure mine. Álvaro Morales helped me understand how AI works under the bonnet, not just how to use it.
My method is not inventing from scratch. It is watching the people who know, taking what makes sense for my way of working and adapting it. Not copying it word for word. Adapting it.
I am still a beginner compared with the experts I follow. That has not changed. What changed is that the time I invested turned into a system that genuinely changes my work.
What actually broke (and what I learned from each failure)
Building a system like this without being a developer has a cost: you learn from the failures.
These are the real ones, documented. First, three words I will use, so I do not have to repeat them. A skill is a procedure written for the system to run. An agent is a specialist that runs those procedures. A hook is an automatic instruction that fires after each action the system takes.
The sub-agents that shut down on their own after six minutes
You give an agent a task and wait for it to finish. The problem I found: there is a hard time limit in the system, around six minutes. When it is reached, the agent stops and drops whatever it has, with no warning, no visible error.
Why it matters: if it has to write five documents and it cuts off halfway through the third, you are left with half-finished work without knowing it is half-finished. The fix was to split tasks into smaller batches with a verification step at the end. Having a system and not designing it for its own limits means the limits work against you.
The hook that closed the turn in silence
One of my hooks made a call to the AI after every file was written, to check quality. The problem: if that check returned “no”, the system ended the turn without saying anything. The agent closed having written one file out of five, with no error message at all.
Why it matters: automation fails in ways you do not see until you count the results. The fix was to swap that check for a deterministic script, one that looks for patterns in the text instead of asking the AI. Faster and more predictable. What I learned: check how your automation actually behaves, do not assume it behaves the way you think.
Designing a skill that already existed
At one point I designed a new one in detail and started building it. It already existed. A planning document said “pending”. The disk said “done”.
Why it matters: when you plan a lot in writing, and this system involves a lot of planning, it is easy to believe what you meant to do is what you did. The fix was simple: always check against the real system before acting. Notes describe intent. The disk describes facts.
Launching tasks in the background when they have to deliver something concrete
Some tasks can run in the background, without me watching. Others have a delivery commitment: these files must exist at the end. If you launch the second kind in the background, you can find the agent closed happily, “now I will write the files”, before writing them.
Why it matters: the background is for exploring, not for delivering. Anything that has to deliver something concrete stays where I can see it. It sounds obvious. It was not when I found out.
The value of documenting failures is not only learning from them. It is that the system does not repeat the same mistake twice, whoever operates it. Each of these failures is documented inside the system: the mechanism, the fix and the rule that prevents it. The system learns from its own mistakes because someone took the time to write them down.
A normal week for the system
I launch the pipeline and it runs on its own, except at the points where I want to decide. That boundary I draw myself, deliberately, in every flow.
The abstract is easier to grasp with the film of a week. This is what happens, in practice, with my oversight at the marked points.
- Client and competitor research. I launch a pipeline and it runs on its own: it analyses the market, maps the competition, profiles the audience. This used to be a day or two of an analyst pulling sources together by hand. Now I review the brief it leaves me and decide what goes in. That part, the decision, stays mine.
- A bilingual blog post. Research, a draft in Spanish, a rewrite into English, SEO with real search data and layout. The full assembly of a piece like this took several days between a writer and an SEO. The system has it ready in hours. I approve the angle, fix the voice and sign off each version.
- A newsletter design. Structure, copy, template. The system builds it. I decide which story opens and what stays out.
- The LinkedIn calendar. Topic proposals, writing, image, scheduling. I review before anything goes out.
The pattern is always the same. I launch the pipeline and it runs on its own, except at the points where I want to decide. That boundary, where the system moves on its own and where it stops to wait for me, is the important part. I draw it myself, deliberately, in every flow.
What changed is not that I work faster. It is that I recovered the hours that went into gathering, assembling and laying out, and put them where I add value: analysing a client, reading the competition, deciding the angle. The work that justifies a CMO being at the table.
Why operational knowledge does not come packaged
Platforms standardise what works the same for any company. What a senior CMO knows is written down nowhere.
AI platforms for marketing are good at what they can standardise: the operations that work the same for any company in the sector. Generic content creation. Standard approval flows. Common metrics reports.
What they cannot standardise is what a senior CMO knows and that is written down nowhere: that this message works better with this audience, that this week is not the right moment to publish this, that this client prefers to see it before it goes out even when they are not in the formal process, that this brand’s voice sounds different on LinkedIn than in email and that the difference matters.
That knowledge does not export to a SaaS. It gets encoded in the instructions of the system you build.
The market’s “Marketing OS” gives you a platform. What I built is a system that knows how I work, what I prioritise, what I will not approve and why. That difference is accumulated judgement, not technology.
The hard part does not show up in the list of agents and skills. The hard part is deciding what to build first, what to automate next and where to place the review points so that quality does not depend on me watching over every task.
Building a system like this takes time, and a CMO’s time is limited. Is it not faster to buy a platform?
Fair in the short term. In the long term, a platform that does not fit your way of working creates constant friction. The bespoke system has it at the start and removes it afterwards.
And start with one task, not the whole system. I started with the LinkedIn calendar. The full system came later.
No conclusion
If you have spent 15 years making marketing decisions, you already hold the hardest knowledge.
The kind you do not learn on a course or buy in a SaaS.
The barrier to building a system like this was never technical. It is judgement: knowing what to automate, what to keep in your own hands and in what order to build it. A senior operator has that, and a generic software product cannot replicate it.
Start with one task. Document how you do it. Write the instructions for the system to run it. Check that it works. Repeat.
Nobody builds a Marketing OS in one go. You build one useful task. Then another. And one day you realise you have a system. The one that runs this blog started with one. The other 81 came later.
Frequently asked
How do I know I need my own system and not another platform?
If your marketing tool stack grows but your capacity to decide does not improve, the platform is not the problem. It is that the tools do not have your judgement built in. Your own system starts by documenting that judgement, not by adding another tool.
What makes a skill different from an AI prompt?
A prompt is a single-use instruction. A skill is a standard procedure the system runs the same way every time, with your judgement encoded in it. The practical difference: the skill improves with every piece of feedback you give it. The prompt starts from zero each time.
How long does it take to build a working Marketing OS?
It depends where you start. A well-designed single task can work in days. A system with 12 agents and 82 skills takes months of iteration. Most of the time is not code: it is deciding what to build and writing the instructions well.
Free · 8-minute audit
Find where your AI value is leaking.
The PDF arrives when you confirm your subscription. 12 questions, 8 minutes, the 4 value gaps.
Send me the checkEvery question with its source. One email a week. One-click unsubscribe.
