Amazing writeup, Emily. I really appreciate the terminology clarifications - makes so much sense now. It also seems I've got a lot to do.
I think the Github concept is the main mental hurdle that we'll have to overcome as a marketing team. I personally prefer Claude Code in the terminal, but most of my marketers feel comfortable working out of Claude desktop/Cowork. Code doesn't come naturally and the Github pull/commit/push sequence feels alien.
Now that they are actively building and sharing Claude projects, I feel that was a necessary first step towards creating an AI-forward mindset. But I've been realizing (and this newsletter reinforces that belief) that that is not true multi-player mode, because the context layer across projects and skills isn't shared and we inevitably end up repeating ourselves in prompt chains.
I wonder if Claude will eventually productize a solution to this problem and handles keeping capability and context layers updated at an org level using ambient actions.
I think Anthropic will put out a solution to this problem for sure. It will create more usage and more virality within teams. Until then just pretend GitHub is called marketinghub and make it happen!
The issue is lock-in.. this doesn't fair well for those working with multiple models (ai labs). On your travels, have you seen any tools working on this.. gh for marketing hub with version control + permission..
Alien is the right word. I'm very used to GitHub, and I still ran into issues when setting it up for sharing context across a team and agents. Git solves for teams sharing code, which is very different to teams sharing knowledge/context.
Most marketing teams are stuck in single-player AI mode: individual marketers build valuable things with Claude, but none of it gets shared. One person may get dramatically more efficient, but that doesn't mean the team does.
The bottleneck is the same one that killed ABM programs five years ago: individual effort that never compounds into a system.
That's a GTM operations problem disguised as a technology problem: the teams pulling ahead are the ones where one person's improvement automatically becomes everyone's next default.
As more agents become embedded in daily GTM workflows, execution may become faster and more consistent, but also could be more mechanical if operators stop developing the judgment needed to evaluate and improve the output.
This is where a decision-logic layer could help by making the reasoning visible: why a choice was made, where human review matters, which exceptions should remain visible, and what evidence should update a skill. How are you thinking about designing that layer so teams build judgment rather than simply reuse context?
This is a really great question. And I need to do more deep thinking and chatting with others about it until I have a better answer. But agree it’s super important. Human Review processes on out puts are always essential though.
Thank you, Emily! I'm doing the same. Hope to exchange some notes later.
And thank you for organizing today's MCP showcase. It was very helpful and your take on buy vs. build during Q&A. So many tools and not enough time:-) My two major takeaways: 1) wrapping skills around MCPs. 2) Zapier is becoming the MCP for MCPs.
Thank you for the time and research you put into this! It's affirming to read about the exact situation I experience daily at work. I just didn't have the words for it. And totally loving the video game analogy! I've built 10+ skills in Claude for our b2b marketing team but am still mostly in single-player mode and struggling with adoption. No answers on a solution - just echoing the sentiments of many other marketers. The biggest win lately has been getting approval on core files to use as context across our skills and team projects such as our positioning, messaging, personas, and brand voice. With that, I created a basic team project with those files loaded in so we can get some consistency in output across the team instead of starting each Claude session as a blank slate.
While I 100% agree that this centrally available context is critical to make these systems work, IMHO it creates a new issue for marketing teams where folks on the team stop internalizing the positioning themselves. For example a growth marketer used to have to talk to the PMM or read the positioning doc, but now they can spin up 100 ad variants on top of it without ever developing a feel for the messaging - which limits both their ability to judge the outputs, and their creativity. I think teams will need to invest more in internal positioning enablement (or we can call it, context enablement).
A related question I keep grappling with: should the centralized context be human readable, or only agent readable?
Also would also love to see a demo of the skill review flow, and how others are doing skill eval.
Great point. You still need to build the foundation and share the why…and Claude can help with both. Especially the sharing updates to strategy and context as they happen.
Both human and agent readable IMO. You need to know what you are feeding the machine!
I’ll make a demo of the skill review flow soon and share it in the next newsletter in the series if not before.
Yes I have a handful of repos and then the mkt1 MCP is the more generic stuff. I send skills to some advisees and that’s a pain i don’t have a solution for yet.
In my experience, a separate vault or repo for each client. Rather than client folders inside one. But it can depend on how you are pulling in the context.
What trips people up with this approach is the skills. You can end up maintaining N copies of the same skill, and they slowly diverge. What works for me was keeping the skills generic and put the client-specific knowledge/skills/process within the client folders.
Mom, I made it - Emily Kramer featured me in her newsletter! ❤️ Proud to contribute. 🎉
Love this one- huge thanks
More and bigger features to come in the future!
Amazing writeup, Emily. I really appreciate the terminology clarifications - makes so much sense now. It also seems I've got a lot to do.
I think the Github concept is the main mental hurdle that we'll have to overcome as a marketing team. I personally prefer Claude Code in the terminal, but most of my marketers feel comfortable working out of Claude desktop/Cowork. Code doesn't come naturally and the Github pull/commit/push sequence feels alien.
Now that they are actively building and sharing Claude projects, I feel that was a necessary first step towards creating an AI-forward mindset. But I've been realizing (and this newsletter reinforces that belief) that that is not true multi-player mode, because the context layer across projects and skills isn't shared and we inevitably end up repeating ourselves in prompt chains.
I wonder if Claude will eventually productize a solution to this problem and handles keeping capability and context layers updated at an org level using ambient actions.
I think Anthropic will put out a solution to this problem for sure. It will create more usage and more virality within teams. Until then just pretend GitHub is called marketinghub and make it happen!
The issue is lock-in.. this doesn't fair well for those working with multiple models (ai labs). On your travels, have you seen any tools working on this.. gh for marketing hub with version control + permission..
Alien is the right word. I'm very used to GitHub, and I still ran into issues when setting it up for sharing context across a team and agents. Git solves for teams sharing code, which is very different to teams sharing knowledge/context.
Most marketing teams are stuck in single-player AI mode: individual marketers build valuable things with Claude, but none of it gets shared. One person may get dramatically more efficient, but that doesn't mean the team does.
The bottleneck is the same one that killed ABM programs five years ago: individual effort that never compounds into a system.
That's a GTM operations problem disguised as a technology problem: the teams pulling ahead are the ones where one person's improvement automatically becomes everyone's next default.
As more agents become embedded in daily GTM workflows, execution may become faster and more consistent, but also could be more mechanical if operators stop developing the judgment needed to evaluate and improve the output.
This is where a decision-logic layer could help by making the reasoning visible: why a choice was made, where human review matters, which exceptions should remain visible, and what evidence should update a skill. How are you thinking about designing that layer so teams build judgment rather than simply reuse context?
This is a really great question. And I need to do more deep thinking and chatting with others about it until I have a better answer. But agree it’s super important. Human Review processes on out puts are always essential though.
Thank you, Emily! I'm doing the same. Hope to exchange some notes later.
And thank you for organizing today's MCP showcase. It was very helpful and your take on buy vs. build during Q&A. So many tools and not enough time:-) My two major takeaways: 1) wrapping skills around MCPs. 2) Zapier is becoming the MCP for MCPs.
Thank you for the time and research you put into this! It's affirming to read about the exact situation I experience daily at work. I just didn't have the words for it. And totally loving the video game analogy! I've built 10+ skills in Claude for our b2b marketing team but am still mostly in single-player mode and struggling with adoption. No answers on a solution - just echoing the sentiments of many other marketers. The biggest win lately has been getting approval on core files to use as context across our skills and team projects such as our positioning, messaging, personas, and brand voice. With that, I created a basic team project with those files loaded in so we can get some consistency in output across the team instead of starting each Claude session as a blank slate.
You could have a review process skill for this that names officially reviewed and source of truth stuff with a specific naming convention.
This is a great and detailed write up, thank you!
While I 100% agree that this centrally available context is critical to make these systems work, IMHO it creates a new issue for marketing teams where folks on the team stop internalizing the positioning themselves. For example a growth marketer used to have to talk to the PMM or read the positioning doc, but now they can spin up 100 ad variants on top of it without ever developing a feel for the messaging - which limits both their ability to judge the outputs, and their creativity. I think teams will need to invest more in internal positioning enablement (or we can call it, context enablement).
A related question I keep grappling with: should the centralized context be human readable, or only agent readable?
Also would also love to see a demo of the skill review flow, and how others are doing skill eval.
Great point. You still need to build the foundation and share the why…and Claude can help with both. Especially the sharing updates to strategy and context as they happen.
Both human and agent readable IMO. You need to know what you are feeding the machine!
I’ll make a demo of the skill review flow soon and share it in the next newsletter in the series if not before.
hot like fire, tysm! Keep dropping marketing bombs 💣💣💣
How do you use Repo or Obsidian if you have multiple clients with specific skills?
Yes I have a handful of repos and then the mkt1 MCP is the more generic stuff. I send skills to some advisees and that’s a pain i don’t have a solution for yet.
In my experience, a separate vault or repo for each client. Rather than client folders inside one. But it can depend on how you are pulling in the context.
What trips people up with this approach is the skills. You can end up maintaining N copies of the same skill, and they slowly diverge. What works for me was keeping the skills generic and put the client-specific knowledge/skills/process within the client folders.