I get this same question in my DMs about six times a week. It's coming from MITL Pro members, fractional CMOs, and a few in-house marketing leaders who've been quietly learning Claude Code on nights and weekends. They've shipped five or ten workflows that actually work, and they can see exactly where their team could be in six months. What's stopping them isn't the building part, though – it's everything around it: where the files go, how to hand a workflow off, how to actually train the team to use the thing. This leads to... them continuing to do the work themselves, the team never being "armed" with the new tools, and the compounding "AI efficiency flywheel" never starting.

The mirror version is just as common. In this scenario, the leader has not actually learned what their operators are building. The operators are asking how to share what they have made. The leader has no answer.

This week, I am summarizing what I know about the four real surfaces, the decision frame I use with paid clients, and the thing nobody is naming about why even Notion's design team prototypes outside of Notion.Separate the context from the workflow

Your marketing second brain holds the context: brand strategy, positioning, personas, messages, and product information. This guide explains what goes in it.

The workflow tells the agent how to do a job using that context: write the weekly ads report, repurpose a webinar, or draft a post for a particular product. This article is about where those instructions live and how the team runs them.

Claude Code and Codex both use skills: reusable instructions, often packaged in a SKILL.md file with a YAML header and Markdown body. Supporting scripts and references can live alongside them. Loading and execution depend on the tool; see OpenAI’s skill documentation.

You may already have the beginning of one: the brief you keep pasting into Claude, the document a contractor uses for repurposing, or the steps for a landing-page copy review. A repository gives the team a place to review and improve those instructions. You still need to decide who can access the files, how changes reach users, and which tool runs the work.Choose a surface the team can use

Ask where the agent will execute the workflow and who needs to run it on a Tuesday morning. The four options below cover different parts of that decision: storing instructions, giving people access, and running the work.

Teams reach for this first because it is where every other document already lives. Permissions, sharing, training, all sorted. Adding another folder costs nothing on Monday.

It is also the worst option for the AI execution layer, and the reasons are mechanical, not religious. The files are not flat markdown on the operator's filesystem. Every time the agent needs them, it has to call out through a connector (an API integration, or an MCP server if the platform offers one). Slow, token-heavy, sometimes outright blocked by IT. Notion's MCP server mitigates the speed problem but every team member has to install and authenticate it themselves; Confluence and SharePoint vary widely. Word docs, decks, and PDFs are slow for the agent to parse and cost more tokens than markdown for the same instructions.

These tools were designed for humans to read, not for agents to execute against. Keep them as the human-reference layer. Stop using them as the execution layer for AI workflows. This is the single most common mistake I see right now.

Native markdown, native version control, fast for agents. Claude Code, Cursor, Codex, Copilot, and Gemini CLI all integrate directly. Open the repo, agent reads the file, done.

What matters more than the storage is change management. When an operator uses a skill and notices something is off, they can open a pull request directly from inside Claude Code or Cursor. You review. You merge or branch. This is the missing affordance in every Notion-based system: structured human review of changes to shared workflows. Without it, every well-meaning edit becomes a fork and the team's "shared system" is actually six private copies that drifted last quarter.

The newer piece worth knowing: GitHub launched gh skill on April 16, 2026, a CLI package manager for agent skills that works across all the major coding agents and writes to .agents/skills/ or .claude/skills/ automatically. GitHub is now the formal distribution layer the way npm is for JavaScript packages. If you have at least one builder on the team, this is what I usually recommend.

Quick definition, because I get this question every week: an MCP server is like a USB port for AI. Companies (and individuals) set up MCP servers so AI tools can plug in and use their software without ever seeing the underlying code. Notion has one. So do Stripe, Cloudflare, Salesforce, Auth0, New Relic. As of March 2026 there are over 10,000 public MCP servers, 97 million monthly SDK downloads. OpenAI adopted MCP in March 2025, Google in April, Microsoft Copilot Studio in July. One-year-old protocol, integration layer already won.Why I moved most of my distribution here:A remote MCP server can expose tools without distributing the full implementation. People still need compatible clients, authorized access, useful instructions, and a way to review the results. Limits what you distribute. Keeping implementation on a server can reduce how much code you share, but MCP does not itself protect your IP. Returned instructions, prompts, and outputs can still reveal parts of the system.

Two months ago, I watched Brian Lovin (who runs design at Notion) walk through their internal "prototype playground" on Claire Vo's How I AI. It is the cleanest articulation I have seen yet of what the fourth surface actually is, so it is worth putting on the table even though it is mostly premature for the teams reading this piece.

Prototype playground is a Next.js app on Vercel. A single repo. Every designer (and any PM or engineer who opts in) gets a namespaced folder. There's no backend. All metadata as files on disk. The transferable lesson is not the React app. It is what they bolted on top of the repo to make it usable for people who do not want to learn git:

Brian's foundational rule is the line I want you to take from this whole piece: "Anytime the AI asks you to do something, before responding, try your best to see if you could teach the AI to answer that question for itself." That move is what turns a junior-developer harness into a team-usable system.

Adoption reality matters, and Brian was honest about it. He is the most active user. About five to ten people at Notion use it regularly. A bunch of designers tried it and it did not stick. He shipped a feature to link to external prototypes (v0, Lovable, Figma Make) because not everyone wants to live in Next.js. The pattern works. Rollout, even at Notion, is uneven.

Which is why I treat the custom-app surface as almost always premature. Build it only when you have outgrown MCP and GitHub, and a non-technical UI is the actual unblock. If you have not yet validated the workflow with three to five documented runs, do not yet have the second brain in place, and your team is not yet using GitHub or MCP, you are reaching for the most expensive option because the cheaper ones felt "not professional enough." Most teams reach for this eighteen months too early.

The four surfaces above read like parallel options. They are not. In practice, most workflows start in the wrong home and migrate up the stack as the work hardens, and the migration is the part that is missing from almost every "where should we put this" conversation I have.

The sequence I see most often: a prompt and a couple of context notes start in Notion because that is where the rest of the team is already working. The output gets useful, then someone changes the prompt on a Tuesday and quality drifts on Wednesday. That is the moment the workflow earns GitHub (the diff is the whole reason). Cross-tool coordination becomes real, the agent now needs CRM context, then product docs, then campaign calendars in the same call, and that is the moment it earns MCP. Daily use plus a non-technical reviewer who has to participate is the moment it earns a custom app on top of the repo.

Each layer has to be earned by the workflow's actual behavior, not by how serious you want the system to feel. Most teams skip the migration entirely and pick the most expensive surface first because it sounds like the right answer. (It almost never is.)

The frame is one question per workflow: who needs to be able to run this on a Tuesday morning?

Treat the agent like a new employee. The skill file is the SOP you would hand a new hire. You do not bury new-hire SOPs inside a twelve-layer SharePoint folder, and you do not write them in PowerPoint. You write them in plain language and put them somewhere fast. The only difference is the "employee" is an agent, so optimize for what the agent reads well: flat markdown, fast location, clear instructions.

If you are anywhere on the spectrum I described in the opening, here is the action list.

Brian's rule, slightly adapted, is the closing thought: every time your AI asks you to do something, ask whether you could teach it to do that itself. That is what scales the system from one technical operator to a team. It is also what kills the "I'll just keep doing it myself" loop most leaders are stuck in right now. Shadow AI does not break because the team becomes more disciplined. It breaks because the leader picks a surface, says it out loud, and gives one Tuesday morning to migrating the first workflow.Get curious. Then put the file somewhere your team can actually run it. If you are weighing a managed platform against building your own system, read the AirOps review. It looks at the maintenance and team responsibilities behind that decision.

I’m Hanna Huffman. Marketer in the Loop is my weekly letter about doing good marketing work as AI changes how we do it. Expect useful ideas, people worth knowing, and things I’m figuring out in my own work.

Published by MultiplAI Growth Partners.