The first few times I connected an agent to real marketing systems, I thought the hard part was access.
Can it read Google Ads?
Can it pull Merchant Center data?
Can it search the repo?
Can it post the answer into Slack?
That feels like the unlock when you are setting it up. Then you use it on a real account and realize access is the floor.
We had versions of this where the agent could pull ad performance, but it did not know which revenue was actually profitable. It could see Merchant Center issues, but it did not know which countries mattered or which products were even worth fixing. It could summarize meeting notes, but unless those notes turned into action items with owners and a place to show up again, the summary was just another nice little artifact nobody needed.
Useful? Sure.
An operating system? Not yet.
That is what I have been building toward the last few months. Not one magic bot. A working layer of repos, playbooks, credentials, workflows, meeting notes, safety rules, and reports that an agent can actually use.
The agent is the worker. The operating system is how the work gets done.
Access is the easy part
Most AI agent projects start with the same checklist.
OAuth works. API key works. Service account works. 1Password item resolves. Slack webhook fires. The agent can finally touch the thing.
That is useful.
It is not the same as knowing what to do.
Giving an agent Google Ads API access does not mean it knows how to manage Google Ads. It means it can touch Google Ads. That is a very different thing.
If the agent does not know how you define profit, which campaigns are allowed to be unprofitable for strategic reasons, when Google ROAS is lying, which Merchant Center issues matter, or what budget changes should be staged for approval, then you do not have an operator.
You have a smart intern with a dangerous amount of access.
Fun. Also mildly terrifying.
What became a system
The clearest version of this for me right now is paid media.
I have been wiring together the same pieces over and over:
- Google Ads API access
- Merchant Center read/write access
- n8n workflows for scheduled reporting
- Slack for daily and weekly updates
- Granola for meeting notes and action items
- GitHub for playbooks and templates
- 1Password for credentials
- staged approvals before anything touches money
- a public Google Ads agent playbook repo
None of those pieces are the whole thing. The value is in how they work together.
n8n can pull the data every morning.
Claude or Codex can read the account, compare the numbers, and write the memo.
Slack can show the team what happened.
Granola can capture the promises people made in the meeting.
GitHub can store the rules for how the agent should think.
1Password can keep the credentials out of random config files.
The approval layer can stop the agent from doing something stupid just because the numbers looked bad for two days.
That is the operating system.
One real example: the Tuesday ads notes workflow.
We have a recurring weekly ads conversation. Granola captures the notes. The workflow pulls out action items, owners, blockers, and follow-ups, then posts the recap into Slack where the work actually happens.
That is the difference between a one-off answer and a workflow the team can trust.
The same thing is true for the daily ad results flow. Pull spend and performance every day, compare it against the business rules, suggest changes, then write those recommendations into a sheet for review instead of letting the agent smash buttons inside the ad account.
That is the line I care about.
Use agents to reason.
Use systems to make the reasoning repeatable.
The Monday memo is one interface
The Monday memo is a good example because it looks simple from the outside.
Every Monday, I want to know:
- what happened in the last seven days
- whether the account was profitable
- what won
- what looks like an opportunity
- what needs to move this week
- what action items are still open from Slack and meetings
That used to be reporting work. Now it is more like reviewing a decision packet.
The agent can pull spend, revenue, profit, buyer mix, campaign performance, product performance, and action items. Then it can turn that into a memo that actually says what to do next.
But the template matters. The business context matters. The definition of profit matters. The action item source matters.
Without those, the agent gives you the same generic report every dashboard already gives you.
With them, it starts to feel like an operating rhythm.
Merchant Center is where this gets real
Merchant Center is another place where agents make a lot more sense when you think in systems.
A normal AI prompt says:
Audit my Merchant Center.
That is too vague.
An operating system says:
Pull all products and statuses.
Join them to store catalog data.
Separate primary-country issues from noise.
Group problems by product family, approval status, URL, item group, attribute, and recent spend.
Stage safe feed fixes.
Escalate anything that could affect source-of-truth data.
Completely different job.
The first version asks the agent to be smart.
The second version gives the agent a way to work.
That distinction matters when you are dealing with thousands or tens of thousands of SKUs.
The agent should not just say "you have 800 feed issues."
It should tell you:
- which issues block products that actually matter
- which warnings are from countries you do not sell in
- which missing attributes can be fixed safely
- which broken URLs have replacement products
- which product titles are making reporting useless
- which fixes should happen upstream in Shopify or the feed app
That is not a better prompt.
That is a better operating system.
Codex breaking was useful too
The other lesson came from Codex itself.
Last week I had too many automations running inside the app. Threads, scheduled checks, old logs, repeated jobs, all stacked on top of each other. Eventually the useful work started getting buried under its own history.
We had to clean it up and delete a bunch of old automation and log baggage.
Annoying.
Also a good reminder.
I like Codex and Claude Code for building, debugging, writing, and thinking through messy work with me. That is where they are strongest.
But for repeating systems, I would rather move the job into n8n, Make, a cron script, or a small workflow that has one job, clear logs, and a predictable place to fail.
Codex is great for building the machine.
I do not want every recurring machine living forever inside Codex.
That is how you end up babysitting the babysitter.
The repo is the brain that compounds
This is why I keep coming back to repos.
A prompt disappears. A chat thread gets buried. A repo compounds.
Every time I add a playbook, the next agent gets better.
Every time I write down a rule, the next report gets sharper.
Every time I add a template, the next output gets more consistent.
Every time I document a mistake, the agent does not have to relearn it the expensive way.
That is why I built the Google Ads agent playbook:
github.com/nickyc1/google-ads-agent-playbook
It is not meant to be some perfect universal truth about Google Ads.
Please do not treat my repo like a new Google rep. We have enough of those.
It is a starting point.
Search campaigns.
Shopping.
PMax.
Merchant Center.
AI Max.
Bidding.
Audiences.
YouTube creator partnerships.
Monday memos.
Safety rules.
The stuff you usually learn by burning money, getting yelled at by a dashboard, or realizing three weeks later that the platform took credit for demand you already had.
The future marketer is an operator
This is where I think the role of a marketer is going.
Smaller teams. More agents. More tools connected to more data.
But the best marketers will not be the ones with the most random automations.
They will be the ones who can turn judgment into systems.
They will know what the customer cares about.
They will know when the dashboard is lying.
They will know which metric matters for the business, not just the platform.
They will know what should be automated, what should be reviewed, and what should never be delegated in the first place.
That is the part AI does not magically hand you.
You have to build it.
You have to write down how the work should be done.
You have to give the agent the context a good operator would have.
Otherwise you are just connecting tools and hoping the robot has taste.
Not a plan I would bet my own money on.
Where I would start
If I were starting from zero, I would not start by building a giant agent.
I would start with one workflow, one decision, one report, one place where the work happens every week and the rules are clear.
For paid media, I would start with a weekly memo.
Then I would add the repo.
Then the business context file.
Then the data sources.
Then the approval layer.
Then the action item crawl from Slack and meeting notes.
Then the write access, only after the agent has proven it can diagnose the account without doing anything dumb.
That is less exciting than a browser agent clicking around on a demo account. Good.
I am not trying to win the demo. I am trying to build the system that still works next Wednesday.
That is the whole game.
A prompt is disposable.
A repo compounds.
An agent can do the work.
The operating system teaches it what good looks like.