How to give an AI marketing team useful approval gates
Where a founder should sign off on an AI marketing team's work, and where the team should just get on with it: pages, posts and paid search, approving the work versus approving what goes out, and the limits. From our own team's gates.
Most of what ranks for approval gates is written for engineers, uses invoices and bookings as its examples, or treats a marketing approval as people reviewing people. This page is for a founder weighing an AI marketing team. It covers where a person should sign off, where the team should just get on with it, a workflow you can copy, and what our own gates don't do yet.
It is written from our own records. Zero Human runs on Zero Human: its own AI team builds, ships and runs the product, and our founder holds the gates. Marketing is one of its teams. AI agents for business covers the general case. Here we go into the marketing gates themselves.
Approve the work, then approve what goes out
A marketing team asks for two kinds of yes, and they are easy to mix up.
The first is a yes to the work: write about this topic, plan this week's posts, set up paid search. The second is a yes to the exact thing that goes out: this page, this post, this budget. Kristian Papadakis's guide to approval gates explains why the second must name the exact thing. If it doesn't, "you have built an approval for 'a refund' rather than 'this refund', which is a meaningfully weaker thing."
This page is our own example. On 4 November our founder chose its topic and put it on Marketing's work list. That approval let the team work the item: research the topic, write the brief, propose the first-hand material, draft the page and open a pull request. It let nothing go live. The item says so in its own text: approval authorises working this item, and publication still needs approval at its usual gate, the merge.
The first approval didn't move the work on its own either. The first copy of the item sat on a team list the brief writer couldn't read, so it was added again on 6 November, and the brief was written on 9 November. A yes to the work starts it. It doesn't deliver it.
A yes to the work lets the team start. Only a yes to the exact merge puts the page live.
What the founder sees at the page gate
A page reaches our founder only after the writing task has opened a pull request and passed five checks: sources, links, overlap with our other pages, voice and images. The publish task then stops at the merge. The gate holds that exact merge, and approving runs it as stored. A rejection merges nothing.
The "no" has a path too. Papadakis says most systems neglect it: "A rejection should be able to carry a reason, and that reason should reach the agent as actionable input." Ours does. Request changes needs a note. The note goes back to the writing task, which makes the change on the same pull request, runs the five checks again and brings it back to the same gate.
Most of the reading happens before the last gate
Here is the honest part. Our founder almost always approves the publish gate without reading the page. It is the final sign-off, and he has been involved in the whole process, so in practice it is a go or no-go.
Papadakis calls approval fatigue a failure mode: "A human who approves forty things a day stops reading them by the tenth." Omni Studio's explainer on approval-gated automation puts it more bluntly: approve without reading, and "the step has become decoration."
Our case is different. The reading hasn't stopped. It has moved earlier. The founder picks the topic. Before a word is drafted, the writing task asks him to confirm, edit or strike every first-hand line, each with a recommended answer and the records it came from. Then the task checks its own draft against five written rules before it asks for the merge. By the last gate there is little left to read. The gate still matters, because it is the one point where the page goes live, and the system holds it.
Which marketing work waits, channel by channel
AI agents for small business suggests one approval per job, at the point where the work leaves your company. Here is how that works out across our marketing, as of 9 November.
Runs without a gate. The daily read of our search numbers, the weekly marketing review, keyword research and briefs, a weekly scan of competitors' pages, and drafting a page up to an open pull request.
Waits for our founder. A page going live. Each X post: the week's plan is approved post by post, and the post announcing a new page waits at its own gate. Any new or changed marketing task.
Not live. Reddit replies are only drafted, because no task has a tool that can post. Paid search is set up but not running. Its four tasks were approved on 7 November. Pausing a keyword or a campaign runs on its own, since a pause can only lower spend. Every budget raise, new keyword and new ad waits for the founder. Launch is blocked until conversion tracking is connected and our margins are known.
Reading and drafting run on their own. Anything that goes out, or spends more, waits for the founder.
Omni Studio sets a gate with three questions: "Can it be undone? What history does it touch? How much money or trust is at stake?" Our marketing lines follow the first and the last. A draft can be thrown away. A published page, a post under our name and a raised budget can't be taken back so easily.
The gate that mattered most came before any spend
As our earlier post says, the gate that matters can come before anything is signed off. In marketing, ours came before a single ad existed.
On 7 November the team drafted the four tasks that will run our paid search, and each one stopped for our founder before it was created. The founder sent every one back with notes. One rule would have paused a campaign with no conversions on its first day. The founder's note read: "Don't pause a new campaign the day it starts."
The next day the paid set-up task asked the founder for the margin behind break-even. The answer was "too soon to tell", so the task blocked the launch rather than guess.
Neither stop was a review of an ad. One caught a rule before it ever ran. The other left a number to the person who knows it.
What the system holds, and what only instructions hold
Papadakis draws the line that decides whether a gate is real: "A prompt instruction is not a gate." A rule in an agent's instructions holds most of the time. A gate the system enforces holds whatever the agent was told.
Some of our lines are held by the system and some only by instructions. The system holds the gates. A gated call stops before it reaches the tool and, once approved, runs exactly as stored. A task that can merge must declare a gate on the merge. A tool can also be pinned so a task never makes a call, which is why the task writing this page can open a pull request but can't merge one.
A task's own steps, like asking for first-hand material before writing, are instructions. Our docs on gates say it plainly: guardrails "are instructions to the model, and they stop nothing on their own." The per-run spend cap is only partly enforced today. It holds on an OpenRouter connection, but not during a run on a Claude connection (Spend and models).
So when you weigh an AI marketing tool, ask which of its "always asks first" rules the system enforces, and which are only written down.
A workflow you can copy
- Approve the work. Put the topic, the week's posts or the campaign idea on a list. A yes there lets the team start, and sends nothing out.
- Let reading and drafting run. Search numbers, research, briefs and drafts need no gate. A draft can be thrown away.
- Answer the questions only you can answer. Your own stories, your margins, what you will say about your company. Have the team ask with a recommended answer, so you decide on a draft rather than from nothing.
- Make the team check its own work first. Write the rules down (sources, links, voice) and have it run them before it asks you.
- Gate the exact thing that goes out. The merge, the post, the ad going live. Approve it, reject it, or send it back with a note that says what to change.
- Gate spending more, not spending less. A pause can run on its own. A budget raise waits.
Start tight, then loosen
Our founder's advice to another founder: put more gates in at the start. As you refine the workflow and build confidence in the work, start removing them. The aim is work that can run fully on its own.
We are not there. Every outward marketing action on this page still waits for our founder. Omni Studio's advice has the same shape: "Loosen one gate at a time," after you've read enough drafts of that kind, and tighten it again whenever you like. Our publish gate suggests a question to ask of each gate as you go: is the reading happening here, or somewhere earlier?
Where to start
Pick one marketing job. Sort its actions into what runs on its own and what waits for you, and put the gate on the exact thing that goes out. Gates and tool scopes shows how a gate is declared, and Concepts shows how tasks, runs and gates fit together. The free plan costs $0 a month.
Sources
- Our own records, as of 9 November 2026: the work list, task records, run history and decisions at gates, confirmed by our founder.
- Our own search research for this page: Google results for "ai marketing team approval gates", US, 9 November 2026.
- Kristian Papadakis, "Designing human approval gates for AI agent systems", 31 July 2026, read 9 November 2026, for the patterns quoted.
- Omni Studio, "Approval-gated AI automation, explained", 31 July 2026, updated 9 October 2026, read 9 November 2026, for the three questions and the advice on loosening a gate.
- Zero Human docs, Gates and tool scopes and Spend and models, read 9 November 2026.
- Zero Human pricing, read 9 November 2026.