Having interviewed 50+ marketers in the first half of the year for roles from marketing coordinator to VP, I see people fall into three broad buckets:
I use ChatGPT/Claude to help me do tasks.
I’ve automated a task (competitive monitoring, reporting, dashboards, alerts, research, etc.) that helps me do my job more efficiently.
I’ve built a system that can execute work, observe the result, learn from it, and only pull me in where judgement is required.
I saw lots of two, but never really came across three. (I’m not alone. Matt Swulinski (Growth at Viktor AI) says fewer than 1% of candidates he meets demonstrate that level of depth.)
So I wanted to do something a little more meta: try to articulate what actually blocks people from getting to bucket three, and illustrate a different way of thinking about your work that may make it possible.
Why most teams can’t get to three, even when they want to
One thing that gets my goat is the tendency to treat AI adoption as an enablement or individual employee problem. Teach people Claude, run a hackathon, hand out a skill library, and adoption will follow.
I think this gets the problem backwards.
If I’m a solo marketer at a seed-stage startup, I’m going to automate as much as I can because I need every edge. More importantly, I have the autonomy to do it because I own the outcome.
If you own the outcome, you tend to own the path towards it.
Nobody particularly cares how you get there, only that you do. Given enough autonomy, most rational people will gravitate towards the most efficient path.
The dynamic changes inside established organizations, where the real impediment to agent adoption is often less individual capability and more culture and operating structure.
A few examples:
Agents can’t align stakeholders or make compromises. At least not yet. The more consensus, approval, and compromise required to get something done, the harder it becomes to build a genuinely autonomous system around it.
Fragmented ownership creates handoffs. Someone owns copy, someone else owns design, another person owns messaging, another owns the CMS. But every human-to-human handoff breaks the loop.
The incentives often punish experimentation. The very ingrained “nobody got fired for buying IBM” mindset matters here. Agentic systems are inherently iterative. They will make mistakes. They will occasionally produce something embarrassing. It’s a tradeoff that few leaders are willing to acknowledge.
Security and data constraints are real. Established companies have legitimate reasons to be cautious about what systems can access, what they can change, and where data can flow. (This is probably the most understandable constraint of the lot; you don’t want to end up on the news.) But free access to data and systems is how most systems add value.
Which is why hosting an AI hackathon or running another training session can feel a little like giving a multivitamin to someone who eats junk food every day, never leaves the couch, and hasn’t drunk water in two years.
Instead I think marketing leaders should spend less time asking, “How do we get our people to use AI?”
A better set of questions is:
Who owns the outcome? How much of the path do they control? Where are the handoffs (are they necessary?)? What decisions genuinely require a human? What permissions would an agent need to close the loop? And what level of failure are we prepared to tolerate while the system improves?
Because if you want people to build systems, you have to give them an environment in which systems can actually exist.
What differentiates automating systems from tasks
Normal task automation is a pipeline. It takes something in, does something, and produces something out. Tomorrow, if you built it well, it does essentially the same thing again.
This can be incredibly valuable. Most of the workflows I’ve described in this newsletter fit this description, with some additional intelligence layered on top.
But the real transformation happens when you start thinking in systems.
Task automation:
Input → AI → Output
System automation:
Input → AI → Action → Result → Measurement → Memory → Better next actionThe key difference between the two is that a task ends when the output is produced. A system exists to achieve some outcome, which means the system has to know whether it’s on track or not.
If an AI writes an ad, its job is done. If an AI is helping run paid for you, writing the ad is only one step. It needs to know whether the ad ran, how it performed, what that performance means, what should change, and whether the next iteration did any better.
In other words, the output of one run becomes context for the next.
Questions as the design tool
The classic way of thinking about a job is that it’s a set of tasks. I think that applies to some work, but it’s a dangerous framework for modern knowledge work because:
It confuses the means with the end
It leads to the problematic output > outcome thinking
Anyone who has ever been responsible for something fuzzy (grow trials, reduce churn, increase ARPA, increase efficiency) knows this especially well. There are so many variables, inputs, and factors at play that you need to become very good at asking the right questions so you know what to do.
In other words, questions expose the decision-making structure of the job while tasks often hide it.
Here’s how you might apply this content.
1. What should we work on?
2. Is this actually ours to write?
3. Make the thing.
4. Should it go out?
5. Did it work?
6. So should we do more of this, or less?
7. What did we learn that we should never argue about again?
This is also why outcome ownership matters. If your job is “write the blog post,” the natural thing to automate is writing the blog post.
If your job is “grow qualified organic acquisition,” suddenly the relevant system includes deciding what to publish, creating it, distributing it, measuring it and changing what you do next.
If this all sounds super fuzzy, here’s a more practical/detailed example.
1. What should we work on? Back in my day (old man yelling at clouds) I built content calendars based on keyword data from Semrush and feedback from sales. Now several agents run on their own schedules and write into one shared backlog: search decay, competitor pages outranking us, People-Also-Ask, customer language from sales calls and support. Then a routine ranks them against each other so I’m looking at one ordered list instead of a bunch of dashboards.
2. Is this ours to write? Does it match our positioning and who we sell to, and have we already covered it. The second question was a little trickier to solve. I needed to build an index of everything published that returns “we own this,” “new angle on something we own,” or “genuinely new.”
3. Make the thing. Here there are separate flows that generate a first draft that I then work through and adjust depending on the topic.
4. Should it go out? These ship on a schedule unless I type HOLD and the slug into Slack.
5. Did it work? A routine goes back two to six weeks later and asks what happened to those specific pages. Did Google index them, did clicks hold, what does GA4 tell us, are they being cited by LLMs.
6. More or less? On Sundays, one routine reads the answer to question 5 and rewrites the volume limits every other routine runs at.
7. What did we learn? Every correction I make becomes a written rule.
The last routine to build is the one that watches the other routines and alerts you in Slack when something is off.
Rome wasn’t built in a day
The temptation is to perfect one part of the system before moving on.
Having done both, my advice is to build the thinnest possible version of the entire loop first, even if half the steps are crude or still involve you.
What matters is that an action produces an outcome, the outcome gets measured, and that measurement changes what happens next.
That makes it easier to improve the weakest parts of the loop.