AI MarOps from Anthropic & AI Brain Hype
How Anthropic's marketing ops team really uses AI, the skills-vs-tools line every team gets wrong, and cutting through the AI-brain hype.
In this newsletter:
How Anthropic’s marketing ops team really uses AI (and what I’d do differently)
Cutting through the “AI brain” hype
What to actually build, and where to put it
Hellloooo again, everyone 👋 lakeside from Virginia. It’s a beautiful day out here after a run of oppressive, hot days where even the lake water felt like it came out of the hot tap and the air felt heavier than butter.
For some reason, as soon as July 4 hits, it feels like summer is in its waning phase. We have months of good weather ahead - outdoor rides, hikes, pool time, and blissful sunsets - but the mood has shifted. For me, this wind-down into fall is usually a season of reflection and refocusing.
Every year I set a goal list, and because the weather in DC from January through March is so terrible, I tend to overcrank in the first part of the year. Then there’s this brief little blip in July, and a bit of refocusing. Where are we with our goals? What have we accomplished? Are we on target? If not, what adjustments do we make to feel proud of how we tackled the year, come winter?
Today’s newsletter is a bit of a buffet. There’s a lot swirling in the air around martech and AI, and I’ve been doing some of this reflecting out loud:
Dissecting how Anthropic’s marketing ops team uses AI, and what I’d do differently if I were there
Unfurling the “AI brain” hype, and how to actually build something useful
What to actually do for both
Let’s dig in.
Anthropic’s team shares how to marop with AI
First, let’s start with Anthropic’s recent article on their marketing ops AI workflows.
In it, the Anthropic team - Ian Chan and Annabel Custer - walk through their marops workflows on Claude. Neat. They’re effectively using MCPs and connectors inside Claude Cowork to do tasks, then repeating those tasks with routines.
This is a core part of the educational program I’ve been delivering internally at Khosla and to dozens of portfolio companies.
Most of their examples focus on repeated work they have to do anyway: building reports, triaging run-of-the-mill marops tasks across different tools, automating campaigns. Ian’s reporting workflow runs on a three-skill build:
Prep skill: drives the report assembly, including focus, headlines, and expansion with supporting detail.
Proofreading skill: checks every number in the draft against a verified source.
Action-items skill: turns follow-ups into Asana tasks.
Later, Annabel goes deeper on a set of skills that deliver an end-to-end event, like a webinar:
Dispatcher skill: reads the intake channel and routes each request to the right specialist skill below.
Event-build skill: drives the end-to-end setup across platforms.
Webinar-landing-page skill: spins up landing pages for webinars.
Audit skill: verifies the event-build skill’s output before the task is marked complete.
Apply-to-attend skill: handles in-flight changes to the registration flow.
Approval-support skill: handles event approvals and sends the appropriate emails on a schedule.
Data-import skill: scrubs lists and processes attendee data.
The core idea: take the work you’re already doing and break it into bite-sized chunks Claude can reasonably handle. Each chunk is a skill. Over time, as you do more tasks, you build more skills. As you build more skills, you string them together into workflows. And sometimes you’ll have Claude build skills you never would have thought to write yourself, but which help it become more deterministic.
On skills
What I loved about this article is that they name the AI learning loop I’ve been shouting from the mountaintops:
Turn repeated corrections into skills. When you find yourself correcting Claude on the same thing more than once, that feedback belongs in a skill. You don’t need to build skills, either: Claude can do that for you.
That last sentence is the real sauce. You barely even have to know what a skill is. A skill is just a markdown file. It’s a big blob of text that fixes the age-old (October 2025) problem of copying and pasting the same context over and over to get repeatable outcomes with AI.
Likewise:
Ask Claude to reflect. Claude reads instructions differently than a human writes them, so after the first runs of a new workflow, ask what was difficult about the instructions.
This is one of the skills I’ve hardwired into a /done post-session hook. When I finish work in a session, I run a modified version of Garry Tan’s /skillify skill, which includes a /reflect step. /skillify turns any conversation into a generalized skill anyone can use, making sure it follows MECE, DRY, and sanitization principles.
/reflect is a small prompt that tells the AI to “think about this entire conversation and all the parts that were hard, difficult, or where I had to prod you, or where we got stuck. Imagine we were doing this exact same thing again. How would you do it better and faster? What would you change about the skill? And what would you need from me to make it better, if anything?”
In the beginning, there’s activation energy required to get value out of AI. You have to build skills. But the hard problem isn’t building the skills. It’s sharing them across your peers. If you have a multi-pronged team like Ian and Annabel, they’re both building skills at the same time. It would be great if their AI sessions could “look across” each other’s skills and use them to solve new problems. That’s the AI learning loop.
The loop looks like this:
Build something unique with MCPs, connectors, and APIs.
Get to an outcome once.
Generate a skill with /skillify.
Sharpen it the next time with /reflect.
Automate it into a cron (in code) or a routine (in Cowork).
The punchline from the article: “Annabel feeds what surfaces back into the skill as part of her broader practice of constantly updating skills.” Rather than doing that maintenance yourself, build a skill that does it automatically.
If you’re using Cowork, that maintenance can take the shape of additional skills. If you’re using Claude Code, it can start as a skill, but eventually it should be a hook.
Validation
Another interesting part of the article, though under-explored, is proofreading:
Build a proofreading skill first. The proofreading skill checks that every number Claude puts in a report traces back to a verified source.
What they’re really getting at is data validation. And here’s the catch: data validation usually runs on code or SQL. This is exactly where skills are weak and tools (deterministic code) are strong.
Think about it like this:
Non-deterministic work: handling many differentiated parts that don’t require exact precision. Use a skill. Let AI absorb the randomness.
Deterministic work: making sure a number is correct, that you pulled data from the warehouse the right way. Use a tool.
This has been one of my key learnings, one I first saw clearly at Eight Sleep a few months back, and it keeps creeping into my observations of AI-native teams.
A tool here is something like “get last week’s activation numbers” or “pull the number of weekly signups.” In both cases, the number has to be 100% accurate and reliably pulled. The problem with a skill is that it may not be 100% repeatable. If it’s generating a query on the fly, in any language, the output can drift.
One way to handle this is to instruct the AI to include the exact query inside the skill. But that’s still fragile, because when you /reflect or /skillify, you don’t have total control over what the AI writes back to the markdown file.
So the better solution is to build robust, 100% reliable and accurate SQL queries, encode them as query tools, and manage them in a central place. That way, when anyone on the team “pulls leads from HubSpot,” they pull the same number - not different ones, and not by trusting AI to nail something it can’t promise.
Of course, this only matters when data needs to be perfectly accurate. In plenty of cases, data can be “directionally good enough.” It’s the same distinction humans make between eyeballing a segmentation chart in Amplitude and reporting actuals to the CEO from the warehouse. Skills that work against data are fine when the stakes are low. Tools, especially shared tools, are the right primitive when you and your whole team need to pull data accurately.
Cloud vs local crons
In the last part of the article, another buried nugget:
Lean on scheduled tasks. Work that runs on its own every Sunday night or every hour is work no one has to remember to do.
Routines are simply skills that run on a fixed schedule. They require your computer to be on, connected to the internet, and holding the right permissions. They also require that you have all the relevant MCPs and connectors available.
In essence, this is what we call a “local cron.” A cron is just a task that runs at a specific time. In code, you can build crons to fire at any time. You can set up local crons on your computer using Claude Code. You just can’t visualize them anywhere per se, unless you ask the AI to build you a view, or you build one yourself.
Routines, or local crons, are genuinely valuable, especially for beginner and intermediate AI operators. They turn day-to-day basic tasks into automated work.
For example, I recently helped a team member automate really basic accounting work that used to eat 20 hours a week. First, we built a “ramp triage” skill. Then we improved it. Now it’s running. It’s not perfect, and there are still a few things she has to clean up, but it’s proof that routines take people from “this takes me hours” to “this takes minutes.”
Over the last few months, I’ve seen routines pop up in every department. Routines for invoices, expenses, email follow-up, Slack messages, growth reporting, channel execution. Anything you do more than once can be a routine. The key question is whether the up-front time to build the skill is worth it. Technically, your entire life can be skillified and then routinified. But time is finite, so pick the highest-value surface areas first.
Singleplayer to multiplayer: how do you share AI across a team?
An obvious question falls out of the Anthropic piece. It’s cool to build skills and routines, but how the heck do you share these things?
And the bigger one: how do you build an “AI brain” that shares not only skills and tools, but knowledge?
Everyone is talking about the AI brain. A few months ago I built my own, Taurus, with a local claw in my basement named Gary. It feels like every day I see another post calling for one and asking for help, like this one. I had a long conversation with an operator this week about exactly this, so here’s a recast of where I landed.
What an AI brain actually is, stripped of hype
Taurus is a collection of databases with an MCP wrapped around them. That’s it. Instead of wiring up a separate Gmail MCP, then a calendar MCP, then a Drive MCP every time I start a session, one code word - Taurus - points my AI at everything at once. That single-word-points-to-many-resources trick is a real benefit on its own. Honestly, it can start life as nothing more than a Skillify.
Who it’s actually for. Not someone whose whole life lives on one work machine. If everything you do sits inside one company’s laptop, you don’t need this. The payoff shows up when you have multiple jobs, consulting work, side businesses, or a personal life you want AI to reach across. I told an operator recently that it’s worth building if she ever wants to become a growth advisor and reuse the lessons from one company at the next.
Why I built mine. Two reasons. One, I wanted a single MCP that could search my whole life in one shot instead of ten different places. Two, I wanted a cheap, forever home for a decade-plus of consulting history: emails going back to 2017, downloaded calendars, contacts, Strava, health data, financials. My rule now is simple. Anytime I’m doing something in a non-unique surface area, I ask, “should this just live in Taurus?”
The real value is functional, not the “brain.” The best thing Taurus does is kill subscriptions. I had Claude learn the APIs for every call recorder I’d ever used - Clarify, Granola, Zoom, Grain, Fireflies - pulled all the recordings into my warehouse with vector embeddings, then cancelled every one of them. Same move with Ordinal, a $135/month LinkedIn scheduler, and a $10/month macro tracker left over from Ironman training. Both got rebuilt inside Taurus. Use a tool, pull your data out via its API when you’re done, store it, stop paying. The mono-repo becomes a place to build little micro-services for your life.
Where it’s going. I want these services connected to a cloud environment so the AI has what it needs without me granting MCP authority every single time. I also bought a machine to run a local model over the next few months, so Taurus can eventually do work on its own hardware without depending on OpenAI or Claude for every call.
The honest caveats
Now let me be the skeptic, because most of the AI-brain trend is hype.
The pretty graph means nothing by itself. The Obsidian “look at my beautiful synthesized graph of connections” thing is not a use case. It’s a screensaver. You have to start from a real problem you’re trying to solve, not from the visualization.
The graph only pays off with a decade of data behind it. The one person I know who genuinely benefits from that kind of graph is someone like John Cutler, who has been writing prolifically for over a decade in Obsidian and can surface everything he’s ever said on a topic mid-call. The value was the ten years of writing, not the display.
You can spend more time automating work than doing it. I promised someone a doc on a call recently. Auto-generating it would genuinely be useful, but it’s roughly twenty hours of engineering, it won’t always work, and it burns tokens the whole way. Not worth it yet. That math matters.
Building can tip into bingeing. This is the AI vampire problem I wrote about a couple of weeks ago. High-functioning people binge on building with AI, then overdose and feel depleted. Building to learn is great. Past a point, build for a purpose, not for the high of building.
And one more, for anyone working inside a company right now. The company you work for is building a version of how you work, whether you like it or not. If you ever leave with no logging strategy of your own, you’re back at zero, rebuilding everything from scratch. So if you’re working with a company’s Claude or Codex, keep a personal one on the side where you build a generalized version of what you make at work. Log how you do the work, so your career compounds instead of resetting every time you switch jobs.
What to actually build
So when someone asks me what to actually build, here’s what I tell them.
Don’t start with GitHub, unless you’re a fully technical team. Most non-technical teams simply can’t use GitHub. It’s messy, it’s complicated, and you have to hand out permissions and access just to get people in the door. The Git-as-knowledge-base idea was pioneered at DoorDash, and it’s clever, but it only works for teams that are already tech-pilled. For everyone else, it falls apart.
So where do the primitives actually live? Notion. A Notion hub, built from pages and databases:
Pages (and collections of pages) hold written knowledge you can always update.
Databases hold the repos: one for skills, one for tools.
Nice to have: learning pages where people can figure out how to use the hub, and where their AI can learn it too.
For a growth team, it might look something like this:
Hub Home
AI Wiki - the AI’s index of every page and all the meta-knowledge it needs
The skills you use every conversation (/skillify, /reflect)
If read-only: how to submit suggestions to update a skill, the library, or the index
Team structure, who’s who
Domains of expertise
Pre- and post-conversation hooks
Service tokens: what’s needed for which tools, links by access role, or how to request access
A maintenance worker: rules and scripts that keep the hub tidy
Skill Library - a database where each markdown file is a skill, with its required tools and connectors
Tool Library - a database of raw, sanitized Python, SQL, and other scripts
Team Meeting Library
OKR Library
Knowledge Library
Brand guides: style guide, color schema, brand guidelines
Voice guides: LinkedIn tone, Substack tone, founder voices
Strategy guides: your ICP page
Stack guide: tool architecture, vendor selection matrix and criteria, vendor docs, and vendor-specific knowledge about how each tool is set up
Why Notion? Because the out-of-the-box MCP works for almost every non-technical operator. Sharing is a single URL, pre-bundled with everything a teammate needs to be successful. The permissioning model is easy: flip someone between read-only and edit, and their MCP updates by virtue of the access change. Version control is built in, so you can roll back the changes people inevitably make with their AI. And setup is basically turnkey.
It’s not perfect, but it’s the best system I’ve seen work in practice across dozens of AI-native startups.
It’s a great starting place for small teams and folks who want an uncomplicated place to begin. The natural place to graduate is a third-party tool, especially once you want tighter control over documents and which LLM you’re running. Three worth looking at:
Runlayer - a control plane and gateway for MCP servers, skills, and agents.
Indigo HQ - a shared context layer for teams building with AI.
Vector - Mike Molinet’s take on how GTM teams should run (or just email mike@vector.build).
That’s the buffet for this week.
If you’re building any of this - a skill, a routine, a scrappy little AI brain of your own - I’d love to hear what’s working and what isn’t.
Reply and tell me. Thanks for reading. 🙏