đ This is a monthly free edition of MKT1 Newsletterâa deep dive into a B2B startup marketing topic, brought to you by Framer, Profound, and Closing Media.
âŹïž Upgrade to a paid subscription for: Full access to our MKT1 MCP | 100+ templates & resources | Post to MKT1 Job Board | MKT1 Newsletter Archive | $40K+ in discounts in the MKT1 Perk Stack
đ
Just announced: MKT1 x Lovable Buildathon on 10/28 at 10AM PT. Come build apps and MCPs alongside Kramer and the Lovable team. RSVP â
Agents that are more useful than interns. A clean library of skills without gaps or duplicates. A GitHub repo every marketer uses. AI that makes sales and marketing the best of friends. The ability to run your skills anywhere you want. Self-updating, self-maintaining, never-stale routines. Connected MCPs for every tool you use with no feature gaps...the stuff marketing team leaders' dreams are made of?!
We all want a multiplayer AI system that makes our team more efficient, and weâre all stumbling our way there. Right now thereâs an overload of new tools, models, and âhacksâ and not enough clarity on how to pull them all together into something efficient and effective for your team.
âWeâre still in the early innings of what an AI-native GTM org looks like.â
âDanny Lambert, Head of GTM Engineering, LangChain
I described many of the attributes of an ideal multiplayer AI system in the first newsletter in this series last month. In my definition, it has 4 parts:
But I wanted to bring this to life and give you a real glimpse into what teams are doing here right now, instead of leaving you with frameworks only. So, I chatted with 3 team leaders from 3 different companies. I teased some of their quotes and thinking in the first newsletter, but this newsletter details their setups.
I selected these 3 very intentionally: They're all in different leadership roles, but they all own pieces (or all) of the AI system for marketing. Each of the companies has a unique head start or advantage for building a multiplayer system. And while I talk about this stuff constantly, these three conversations changed or expanded my thinking about building for multiplayer AI.
The variability in how these teams have approached this same problem is in itself a lesson: You can't just copy another marketing teamâs setup. Take the best practices and adapt them to your specific company. This holds for building out multiplayer AI and across all of marketing. As I always say, find your advantages, and double down.
âThe problem is an AI workflow without context is running at maybe 60% of its potential. Your business context is what makes the output relevant and genuinely useful.â
âSimon Heaton, from his LinkedIn post about our chat
Recommended products & agencies
We only include sponsors weâd recommend personally to our community.
Framer is the AI website builder that has agents inside of the canvas. You get the speed and capabilities of an agent working alongside you, while maintaining structure and control for a full company site.
đ Offer: Get 30% off annual pro via the code MKT1
â
Profound: Understand and control your brandâs presence in AI Search. Track how your brand shows up across LLMs, then have its background agentâAimâsurface and execute on high-impact opportunities.
đ Offer: Get a free AI Visibility Report and see how your brand is showing up.
â
Closing Media is a boutique agency that runs LinkedIn and Google campaigns for growth-stage startups. They know the best ways to build and scale ad campaigns in 2026 (hint: thought leader ads and video!) and have years of expertise (I worked with them in 2018!).
đ Offer: Reach out to Closing Media here & mention MKT1 to get $5,000 of free ad spend for your next campaign.
In this newsletter:
This is part 2 of 3 in our newsletter series about multiplayer AI for marketing teams.
This newsletter:
How 3 real teams build and run multiplayer AI: Buffer, LangChain, Mintlify:
How they handle each of the 4Cs in multiplayer AI framework
Multiplayer AI FAQs: Who should own the system, if humans should stay in the loop, how to keep your system from going stale, and more.
Part 1 - In case you missed it: Marketing teams are stuck in single-player Claude mode. Hereâs how to go multiplayer.
Part 3 - Coming later this month: A deep dive into team MKT1âs multiplayer AI system
And a heads up: MKT1 Newsletter paid subscription prices will increase for new subscribers on October 1, 2026. Subscribe now to an annual plan to lock in $99/year for 2 years. More details at the end of the newsletter.
RSVP: MKT1 x Lovable Buildathon on Wed 10/28 â
10am PT / 1pm ET, 45 minutes
Come build in Lovable with us. Bring an idea, and 45 minutes later, leave with something useful.
Weâre hosting a buildathon with Lovable, the easiest place to build apps and now MCPs that bring those apps to Claude, ChatGPT, etc.
Iâll build two apps live:
A brand guide app that checks your marketing assets against your guidelines
A benchmark tool for your customers built from real report data
Then youâll start on your own build, with 20 prompts to pick from
Fern and Skyler from the Lovable team will answer questions
Buffer: Growth marketing manages the system, the whole team contributes
I talked to Simon Heaton, Senior Director of Growth Marketing and Data at Buffer. Before Buffer he spent 6.5 years at Shopify, going from content marketing to Senior Growth Lead, and he's been building Buffer's growth engine since 2022.
"That's just the culture: high agency, high ownership.
We're small, independently owned, and bootstrapped. We're pretty agile, there's no heavy procurement. We can build and ship and deprecate as needed. That gives the team a lot of agency and ownership to just do it."
âSimon Heaton, Senior Director of Growth Marketing and Data, Buffer
The marketing team at Buffer runs on what Simon calls their marketing OS, built with Claude Cowork and Code, with skills shared through a GitHub plugin and context stored in Notion.
Buffer's multiplayer system works because the process fits into the culture they already have. They have a small team that's been around for years, public salaries, an open revenue dashboard, a 4-day work week, and a unique financing structure (they bought out their investors!). This is all well-documented and pretty interesting if you want to go down a rabbit hole...
Given that culture, contributing to the AI system is just part of everyone's job at Buffer. The team wants to build stuff and share it, not keep it to themselves or work in silos. This is ideal for building multiplayer systems, they are trying things out and learning fast.
This example also stands out because I get a ton of questions from people about ownership for multiplayer AI and AI GTM tools generally, and Buffer has a really solid setup. It achieves 2 things: Everyone becomes a builder (and gains a Gen Marketer skillset), and there's still a keeper of the overall system with clear ownership for how it all works together. It's both decentralized and centralized at the same time!
Here are the details of their multiplayer system:
Claude?
The team works in Claude Cowork and Claude Code, whatever they feel most comfortable in.
Skills reach everyoneâs Claude through a Github plugin: One push to the shared GitHub repo and every team member's Claude picks up the update.
MCPs connect Claude to the rest of their stack: Notion for context, plus tools like Profound and Granola that are called via individual skills.
For more on how to use MCPs, read my last newsletter with 24 real MCP Workflows and a video recap from our MCP Showcase.
Context
"The reason we put context in Notion is because a lot of the marketing team isn't git friendlyâit's super easy for them to go into Notion. We can edit their strategies for the blog or whatever it might be as it evolves without having to make pull requests."
âSimon Heaton, Senior Director of Growth Marketing and Data, Buffer
Buffer's context layer is a set of docs the team keeps current, all living in one place Claude can read:
Buffer's context lives in Notion, on purpose: The marketing team already works there, and it's agent-friendly, meaning Claude Code and Cowork read it easily.
Every functional owner has codified their strategies into docs, all in a Notion database that Claude pulls from every time a related skill (which lives in the GitHub repo) runs.
The Notion docs all come from the same starter template, which keeps them structured the same way and easier for Claude to read (without the individual creator of the doc having to think much about this). Simon made the template.
For example, when the AEO reporting skill runs, it reads the AEO strategy doc first, so the report is grounded in how Buffer defines success rather than a generic take.
"The subject matter expert owns the skills and context. We've created a couple scaffolded templates for system prompts and whatever contextual document is needed for these workflows so that, say, our lifecycle marketer is able to put her knowledge down on paper in a structured way. And then I'll review them and we'll get them into the system on their behalf."
âSimon Heaton, Senior Director of Growth Marketing and Data, Buffer
Capabilities
"There's the capability layer, which is the executional stuff like skills, workflows, reusable prompts, reference files, the things that actually do the work.
And then there's the contextual layer which is like the knowledge base."
âSimon Heaton, Senior Director of Growth Marketing and Data, Buffer
Buffer categorizes their capabilities into 2 buckets: capabilities that do the work and capabilities that keep the system up to date. You may remember in Part 1 of this newsletter series, I broke down capabilities in the same way, and that's not a coincidence. Talking to Simon helped me define this!
And after many conversations with marketing leaders about their AI setups, I've realized you can tell a team has gone multiplayer when they have skills or agents running just to maintain the system. It's a clear measure of how far along you are, and Buffer passes the test!
Capabilities that do marketing work
Here are a few examples of what Buffer has running:
Monthly reporting skills. Covers every area of marketing. E.g. the AEO report reads their AEO strategy doc and uses the Profound MCP, so the numbers come back framed around how they define success at Buffer specifically.
Website skills. Lets marketers add an FAQ, swap an image, or ship an A/B test themselves through Claude Code.
Note: Buffer hasn't had a CMS in about 5 years (Simon posted about this). This freed up their designers and engineers for the bespoke work and resulted in faster shipping. (I am still a CMS believer, and love using the Framer CLI in Claude Code, but to each their own!)
A Reddit thread finder. Surfaces the Reddit threads AI engines cite most, so the community team knows which conversations to join. The community team requested this "artifact," and Simon's team built it using the Profound MCP plus the Reddit API (hereâs his post on it).
A broken-link fixer. Crawls the site, decides what to revive, redirect, or remove, and a custom Claude Code skill ships the fixes. This was built by stitching together Screaming Frog, Google Search Console, and the Ahrefs MCP; the first pass cut internal broken links 87% (read more in Simon's post).
A partner-applications agent. Works the queue of partner applications (they get dozens) with a daily human-review loop (more in this LI post from Simon).
Despite how much they have built out, they aren't trying to automate out the stuff that still requires a human:
"Anything we ship to users has to be written by a human, or human in the loop to a very high degree."
âSimon Heaton, Senior Director of Growth Marketing and Data, Buffer
Simon posted about this recently too: A CMO was visibly shocked to hear that humans still write every blog post, social post, and landing page at Buffer. Simon clearly posts a lot of good stuff, give him a follow!
Capabilities that maintain the system
I think about capabilities to maintain your system as covering 3 jobs: building new skills the right way, catching fixes and duplicates as you work, and checking the whole system on a schedule. In Bufferâs setup and MKT1âs, these are skills built in Claude Code.
Here are some specifics on how this works at Buffer:
A monthly context refresh workflow. Looks across sources via MCP (like Granola), then pings each functional owner in Slack to decide what updates to make to their context docs. This way, the docs Claude reads from stay current without someone having to remember to check.
Skill testing before team-wide release. The subject-matter expert tests every new skill until it's producing quality output before it ships to the whole team.
Self-updating content workflows. The content workflows that need human input each run also check what changed and push updates back to themselves. Simon runs versions of this on his personal workflows too.
Since Simon and I spoke, their capabilities have advanced. Buffer now has a deployed agent named Roo that lives in Slack, Linear, and GitHub (Iâll talk all about deployed agents in the LangChain section up next). He says working with Roo in Slack might overtake Claude Code. More in Simonâs 9/1 Linkedin Post â
Need a headstart on building skills to maintain a multiplayer system?
The MKT1 MCP has pre-built skills to help you build a multiplayer AI system including: Build, Review, Publish, Dupe Check, and Repo Stats skills. Plus 30+ additional skills for getting marketing work done.
Collaboration
"As the Head of Growth Marketing, most things martech-related fall under my umbrella. So anything related to how the engine works and how we get leverage is something that growth marketing owns. And so Claude and this marketing OS has naturally fallen into that space. My view: Growth marketing roles go in many ways but they should create leverage, and use tech to do that."
âSimon Heaton, Senior Director of Growth Marketing and Data, Buffer
Buffer's collaboration setup combines decentralized building with centralized shipping (my summary, not Simon's). Here's what that looks like in practice:
They build locally first. Simonâs team made skills for building skills, so nobody starts from scratch and everyone feels enabled to get started.
If it's a complex build and many people on the team will benefit, Simon and his team step in and help with that specific skill build.
When a skill is producing quality output, Simon reviews it and ships it into the GitHub plugin, so that everyone's Claude gets the update.
Skills in progress are tracked in Linear, and everyone shares what they're building in a Slack channel.
Simon owns maintaining the system: Martech falls under growth marketing at Buffer and he was one of the team's earliest Claude adopters.
"The people we have internally are excited to solve these problems. Everyone's sharing transparently what they're building. Siloing is actually not happening at Buffer because that's just the natural way we communicateâwe're just so transparent."
âSimon Heaton, Senior Director of Growth Marketing and Data, Buffer
Simon connected this to my Gen Marketer thesis without me bringing it up (which obviously delighted me). Giving a skill to teammates in another area of marketing enables and upskills them, whoever runs it is being trained in someone elseâs discipline every time.
"Kirsty, our content marketer, creates these great content marketing skills. There's no reason why our growth marketer shouldn't have access to those to round his skillset out."
âSimon Heaton, Senior Director of Growth Marketing and Data, Buffer
To drive adoption of the system, Buffer ran a scheduled company-wide "Build Week." Before this, they built internal AI training, including an assessment and courses matched to various levels.
Hailley Griffis, their communications director, wrote about the result: She went in identifying as non-technical and came out having shipped 50 pull requests and 6 internal tools that week, ranked 3rd on Buffer's internal makers list. Her words: "What shifted was not only my knowledge but my identity."
Build Week itself is basically an internal hackathon, and I wrote a whole newsletter on running marketing AI hackathons last year that I think still holds up as a way to drive team adoption â
What I'd steal from Buffer
Context can and should live outside of Claude and GitHub, where the team can quickly update it and âagentsâ and âAI harnessesâ (like Claude Cowork and Code) can access it. Having that source of truth in a place like Notion, Asana, Airtable, or Softr (or some combo) that Claude reads via MCP or CLI works great.
Let everyone build, and keep one standard-bearer. Buffer allows for both, which is the best of both worlds if ownership is clear. Most teams settle for one or the other.
Your capabilities will be "set in stone" in some areas and still being defined in others, and that's what this looks like for most teams. Trying to get to 100% everywhere all at once will frustrate you more than help you! (I guess the cliche "Rome wasn't built in
a day" really applies here.)
LangChain: GTM engineering builds & deploys agents for the whole org
I talked to Danny Lambert, who leads GTM Engineering at LangChain. Before LangChain he spent 3.5 years at dbt Labs as Director of Marketing Operations, then ran LangChain's marketing ops for a year before LangChain launched its GTM Engineering function this June.
The GTM eng team also includes Jan, Amal, Immanuel, and Nicholas.
"Our initial hypothesis was that we should be able to make the SDR teams at least 3 times more effective, a 10-to-1 manager ratio instead of 3-to-1, by taking out all the monotonous work that agents are already just fundamentally much better at."
âDanny Lambert, Head of GTM Engineering, LangChain
When the LangChain GTM Engineering team formed this summer, they focused on building agents for SDRs to improve efficiencies first. As Danny put it in his announcement LI post: "What started as a handful of experiments quickly became a core part of how we operate, so we're formalizing that work by launching GTM Engineering."
They've since expanded the GTM Engineering team, and the team's charter is now to manage multiplayer AI by building production-grade agents for anyone who touches the sales cycle, marketing included. Given this is a full team's focus, Langchainâs multiplayer setup is also the most centralized in this series, with a 4-person team building most of the agents for the whole GTM org.
They also take a slightly different approach than most teams I've spoken to: They build production agents. Much like how Buffer's company ethos shapes their marketing AI system, it's the same at LangChain.
LangChain is an AI infra company that makes products for building agents. So it makes a ton of sense that they use their own products to build agents, store context, monitor, and evaluate agent performance, instead of the GitHub repo setup many marketing teams are adopting. Their system might seem a little more advanced than you and your team are ready for, but there are tons of learnings even if you aren't here yet.
One other interesting thing before we get into the details: Open sourcing is in LangChain's DNA, and that extends to their multiplayer AI system. They've already open sourced 11 of their internal skills and OpenSWE, their software engineering agent. They plan to release more, including a paid media agent.
Langchainâs approach to sharing skills is similar to how we open source what we make into the MKT1 MCP: I make things to market MKT1 and run my team, then I can ship them to the MCP, which gets more people using them, feedback helps me improve, and it repeats.
Remember: I'll cover more about our own multiplayer system in part 3 of this series!
Here are the details of LangChain's multiplayer system:
Claude?
"Our team is not trying to solve a repo of skills management challenge. We're solving a production agent challenge."
âDanny Lambert, Head of GTM Engineering, LangChain
This quote isnât a dig on other teamsâ setups, but rather a statement on how GTM Engineering operates and stays focused at LangChain.
LangChain's GTM team doesn't use Claude as an interface. Claude is one optional model provider inside the agent interfaces they build. Agent interfaces include Slack or a dedicated UI.
The agents are built and run entirely on LangChain's own products: LangGraph, Deep Agents, or managed deep agents to build them, LangSmith to host and trace them.
The agents are intentionally model-agnostic, so they arenât locked to one provider. They run Claude models alongside OpenAIâs Luna for subagents and other workflows, and switching to a better or cheaper model would take an afternoon.
Here's a screenshot of LangSmith, where you can build, trace, and monitor agents, so you get a sense of how this all gets built and where to start if you want to test this out. I personally had to setup an account to wrap my head around it and now Iâm planning on building stuff out later this week.
Context
"We don't want other GTM tools to be the primary interface, but we also don't want to have to build what they do."
âDanny Lambert, Head of GTM Engineering, LangChain
LangChainâs context lives in the tools their agents already read from, plus a set of context files. Even though this setup is LangChain-product centric, the ideas apply no matter how you set up: You need an easy way for agents to reach your teamâs context, wherever it lives.
Here's how it works for LangChainâs GTM team:
Agents read from their source-of-truth platforms directly through APIs: the CRM and data warehouse, plus point solutions like Apollo, Reo.dev, and Centralize. The goal is that people don't have to log into those tools anymore, because the agents bring the answers to where people already work.
Fresh context gets gathered on every single agent run. For example, when a new lead comes in, the contact enrichment workflow pulls from web search and a stack of data vendors, then writes what it finds back to the records. Nobody has to keep this context up to date: The agents update it themselves every time they run.
In addition to agents gathering context from tools, there is still human-written context that's consumed by agents. For example, before drafting outreach, the GTM agent reads a written doc they call the "outbound skill," covering how to treat a warm lead differently from a cold one (more in LangChain's blog post).
The teammates who know the material best edit those files directly. They have files for things like blog writing, brand design, and product messaging.
The system keeps learning: As an example, when an SDR edits an agent's draft that's pushed to Slack, the system saves what changed, without anyone having to ask. Each person can also set their own preferences, like the tone and format they want their emails in.
"Every edit teaches the agent, and the next draft reflects it."
âLangChain's blog post on how they built the GTM agent for SDRs
Capabilities
"We're doing the same thing that you're doing in the GitHub repo anyway, just end-to-end quality controlled."
âDanny Lambert, Head of GTM Engineering, LangChain
In a GitHub + Claude setup, like Buffer's or the setup I recommended in Part 1 of this newsletter series, everyone runs the skills themselves in their own Claude. LangChain deploys agents that run in the cloud, and the marketing team typically âtalksâ to them in Slack. Another big advantage to this setup: You can see whoâs using what. And you get flexibility on when an agent runs. Someone can kick one off in Slack, another tool can trigger it with a webhook, or it can run on a schedule.
Capabilities that do marketing work
Here are a few examples of what LangChain has running:
The GTM agent for SDR workflows: Picks up every new Salesforce lead, checks nobody's already talking to them, researches the account across their tools and web search, and drops a draft in the rep's Slack DM to send, edit, or cancel. It handles email today, flags at-risk accounts, and phone calls are next.
LangChain wrote about their GTM agent in this post and shared some stats: Lead-to-qualified conversion went up 250%, pipeline 3x'ed, follow-up on lower-intent leads went up 97%, and reps are getting about 40 hours a month back, with 86% of the team using it weekly. Impressive!A paid media agent. Provides weekly analytics across their ad platforms (campaigns, ad groups, keywords, landing page checks), gives recommendations, then can make those changes in the ad platforms. And they are building weekly report agents for several other areas of marketing.
Content studio agent. Produces creative in any format: long-form video, short-form with voiceover, display ads. It started as the paid media agent's sub-agent and now serves their social, field marketing, and out-of-home teams too.
An artifact generator for sales collateral. Builds the one-pagers and POV plans reps used to make by hand, on brand, and hands them back as editable Google files.
Other capabilities include: account health alerts, weekly account intelligence reports, pre- and post-meeting briefs, signal-based outreach drafts, and enrichments that write back to the CRM.
Note: Like Buffer, a human reviews everything customer-facing. This seems to be a theme and necessary guardrail to keep these systems in check!
LangChain is demoing their new paid media agent on 9/23, including how they built it and what they learned, RSVP â
Capabilities that maintain the system
Here are some specifics on how this works at LangChain:
LangSmith Engine, one of their own products, is an agent for improving other agents. It watches for failures each time an agent runs, clusters them into named issues, reads the code to find the cause, and writes the fix for someone on the team to approve. When they ran this on their own setup, Danny told me it found improvements to their contact-enrichment workflow and cut the per-run cost by almost 60%. Sounds kind of like magic to be honestâŠ
An adoption heat map. Tracks who runs which agent, which features they use, and how often, based on a database that tracks agent actions. One finding Danny mentioned to me: The best-performing SDRs are also the heaviest agent users.
Note: You canât get this kind of adoption tracking in a Claude + GitHub setup, because skills run in each person's own Claude and there's no central record of who's running what. For example, in the MKT1 MCP, our /repo-stats skill is only able to show who's contributing skills, not who's using them. But you should still try it out, itâs better than nothing!
And when thinking about building your own capabilities and graduating to fully deployed agents, I really like Danny's 4 checks for agents:
"The pillars I rank a high-quality agent on: ease of use, model-agnostic, traceable and self-improving. Traceable means you can fundamentally understand it and fix it."
âDanny Lambert, Head of GTM Engineering, LangChain
Collaboration
"We have 4 GTM engineers managing our system right now, and we're probably not going to go above 4 people for the foreseeable future, because we found that we have enough headcount to get functional alignment."
âDanny Lambert, Head of GTM Engineering, LangChain
At LangChain, Dannyâs team of 4 builds all the agents for sales and marketing, and the rest of the GTM org. Nobody outside the GTM Engineering team is building their own production agents that are used teamwide. This reminds me of pre-AI days when a centralized RevOps team owned all sales, CS, and marketing systems, with a dotted line to other teams like marketing.
Here's what collaboration looks like:
Each builder on the GTM Engineering team (Jan, Amal, Immanuel, and Nicholas) owns a slice of the funnel and works closely with the relevant team. They spend a lot of time understanding what each function needs, and shipping is not what limits them.
Hereâs how they work with the rest of the GTM org:
Identify high-leverage GTM workflows where AI can dramatically improve speed, quality, or scale.
Build, design and deploy AI-powered agents and workflows that automate these processes across GTM.
Enable and lead the rollout and drive adoption across GTM with playbooks, best practices, and enablement.
Evangelize what they build externally through content, demos, and talks.
People still solve things locally by building their own solutions, but when a use case gets big enough, the team rolls it up into a shared agent. If it's just a one-person use case, they deliberately leave it alone.
One agent can serve multiple teams, but not identically. The agent assembles a different set of tools and instructions depending on whoâs asking and what they have access to. Example: The sales version of an agent reads Apollo and market data, the support-engineer version reads Salesforce, Gong, and ticket history, so the reports come back different for each.
âSaying everyone's going to work from the CLIsâI think that's nonsense. Across a team of 100 on GTM, I might get 20 to 30 who actually know how to use CLIs well, versus everybody else who knows how to use natural language.
And if you have flexibility in the form that your agent takes, it doesn't matter if it shows up in Slack, as a standalone agent, or in the command line. With our setup we can put the agentâs capabilities wherever we want.
Most of our agent consumption is done through Slack. And then the more advanced users can use these agents via MCP on their command line or we can set up webhook triggers.â
âDanny Lambert, Head of GTM Engineering, LangChain
What I'd steal from LangChain
Don't be afraid to try an agent builder and expand beyond Claude Cowork and Code + GitHub. There's a learning curve for non-developers, but there's also a learning curve for Claude Code!
Find what people are solving on their own, and when a use case gets big enough, build a shared skill or agent. Don't worry about standardizing the one-off use cases. This encourages everyone to build, but adds more checks for things shipping to multiple people.
Have a standard for what you ship to the team. LangChain uses the four checks I mentioned: ease of use, model-agnostic, traceable, and self-improving. Without something like this, and a process for getting your team to adopt the right skills and agents, you may end up in a more chaotic place than you were before AI!
"We have all the highly technical people who say, I need an agent, so I'm going to build something locally for myself. When they get busy, they no longer support it and the thing breaks... And then if they leave, that's even worse. If you let that local development cycle get too far away from you, to reel it back in is actually a nightmare."
âDanny Lambert, Head of GTM Engineering, LangChain
Mintlify: Living and breathing context engineering
I talked to Lauren Volpi, Head of Marketing at Mintlify. Lauren spent a decade at Pivotal Software, was CMO at DataGrail, and recently joined Mintlify in May 2026. Ethan Palm, Mintlify's knowledge engineer, and Neha Halebeed, a PM, also joined the call.
"Our bet is that being agent-ready will be important not only externally, but even for internal systems."
âNeha Halebeed, Founding Product Manager, Mintlify
Mintlify's AI setup runs on their own product for context. Their product is the context layer for AI agents, so what better team to talk to about multiplayer AI systems?!
The marketing team at Mintlify is 7 people, while sales is at 40+, so they have to be really efficient! They already have a great system for building out a context layer that keeps track of everything going on in marketing. But they are still admittedly figuring out how to share skills most effectively across the team (as I imagine most marketers reading this are too!).
But, getting context right is more than half the battle, so I think they're off to the races on a really robust multiplayer AI setup.
If you haven't used Mintlify, they are best known for developer documentation, and they're now expanding into help centers and internal knowledge bases. Marketers, if you aren't paying attention to Mintlify, it's time to check it out! (This is not sponsored, I just believe it to be true!)
What I took away most from their setup: Everything you write now has two readers, a person and an agent, and thatâs true internally and externally. Your teamâs agents and skills need your companyâs context to do anything useful, and LLMs and your buyerâs agents read your public docs to generate answers.
Here are the details of Mintlifyâs multiplayer system:
Claude?
The marketing team mostly works out of Claude Cowork, from the shared marketing brain Lauren set up (more on that in the Capabilities section).
They also work through the Mintlify agent in Slack, where they can @mention it with a question and it answers through the company knowledge base.
Context
"Few marketing teams think about documentation. That's a mistake."
âLauren Volpi, Head of Marketing, Mintlify, from her blog post "Your documentation is a demand channel" (worth a read!)
Most teams are trying to jump right in and build skills that never end up seeing the light of day. Some of that is because of a lack of collaboration, but it's also because the skills don't work well. And usually that's because the context the skills are working on is shaky.
Mintlify is in the opposite spot: Their context layer is well built out. When they build out team-wide capabilities, they have a massive headstart and better success rate.
Their context used to live in Notion, next to project management, but they moved it to Mintlify as the product became more robust for internal knowledge base use cases.
Here's how their internal knowledge base, powered by Mintlify, works:
The same infrastructure runs their internal knowledge base and their public help docs, and they can easily set permissions on who can see what. In Mintlify, docs are files in a folder that their whole team can edit and publish. It's also git-based, so version control is easy.
(Note for marketers learning the lingo: âGit-basedâ isn't the same as GitHub-based or GitLab-based. Git is the version control system that tracks every change to a set of files.)These docs stay current on their own, but with a human-in-the-loop for quality control: You set up automations so the system knows what to watch for (like product changes, code pushes, release notes, updates in other tools, etc), and it drafts the update for someone to approve. At Mintlify, building those and approving them is someone's (Ethanâs) actual job (more on that in Collaboration section).
Case in point: When the company migrated their internal knowledge base to Mintlify, the team made 419 contributions in 66 days, with every single team member authoring something.
Treat docs as a product
Way back when I was leading marketing at Asana, a decade+ ago, marketing owned the support site called âThe Guide.â We believed that if we could make this a first-class experience about using Asana to change how you work, we could win. It had SEO benefits at the time too.
That pays off even more today, because docs are the most agent-friendly content marketing produces. They're plain, structured, and factual, so agents can actually use them.
And agents are overtaking humans as the readers of docs sites. Mintlify runs a live counter on their site comparing agent traffic to human traffic across every site they power. It's at about 66% right now, up from 15% in January of 2026, and Lauren expects it to pass 90% by the end of the year. I wrote a LinkedIn post about this before I even spoke with Lauren for this newsletter!
This is changing how we work, how we consume the internet, and who consumes the internet. As Lauren wrote in her blog post, the companies best at developer-led growth âhave almost universally invested in their company knowledge as a product, not a cost center.â
âMarketers donât always own docs. Sometimes they do, sometimes they donât. But agents prioritize docs now, and itâs the first site they review and search. Marketers need to be paying attention to whatâs on docs and reviewing what the traffic is, because for our company the most highly visited content is our own documentation.â
âLauren Volpi, Head of Marketing, Mintlify
Capabilities
"We're building agents that have the ability to comment and suggest on pieces rather than just totally rewrite it."
âLauren Volpi, Head of Marketing, Mintlify
Right now, the team is doing a mix of building skills on their own, using MCPs, and benefitting from the company-wide agents.
Capabilities that do marketing work
Here are a few examples of what Mintlify has running:
The shared marketing brain. Lauren set it up in Claude Cowork, and it runs off their own Mintlify knowledge base as the context source. Individuals build their own skills that reference it.
They also have a brand design system in Claude Design, which allows the team to create sales-ready assets much faster.
Everyone is connected to the CRM, sales call recordings, and product tracker MCPs. And uses these to identify potential case studies, surface customer feedback, and align go-to-market planning with the product roadmap.
Their GTM engineer, Cole Gottdank, built âSignal,â an agent that watches for buying intent. It scans signups and website activity every 30 minutes, judges intent, and routes the useful signals to the right rep in Slack. It runs on a shared set of customer, product, and intent data, which marketing also uses directly to build audiences, generate buyer maps, and check fit scores.
The marketing team also benefits from a set of company-wide agents: a support-ticket-to-PR pipeline, an email agent, a weekly intel agent, and a morning sales brief that runs on a schedule pulling from Salesforce and Granola.
Everyone on the marketing team has the MKT1 MCP connected too. This gives them 30+ skills prebuilt for B2B startup marketers by yours truly. A true headstart! (Howâs that for shameless self promotionâŠ)
Capabilities that maintain the system
The biggest investment the Mintlify team has made in maintaining the system isn't on building skills and agents, it's on leveraging their own product and having a dedicated "knowledge engineer," Ethan.
Collaboration
"Keeping things up to date is no longer a job you do by hand. It's a job for automations and agents.The end state is an internal knowledge base that updates itself as the company grows. I think knowledge engineer becomes a standard role at every fast-growing company within a few years."
âHan Wang, co-founder, Mintlify, from his LinkedIn post announcing their first knowledge engineer
Mintlify built a great product for auto-updating context, and they're dogfooding it extensively. But they went a step further, treating their internal knowledge as the backbone for every other capability they build and creating a dedicated role for keeping context current.
Ethan Palm joined as their first technical writer, and a year later he became their first "knowledge engineer." More details in this announcement post.
Now instead of just making external context (the docs) best-in-class, he also manages the internal context (the team's knowledge base). But he's obviously not doing all this writing by hand, he's also building and maintaining the automations.
He's also documenting what a knowledge engineer does and how other teams approach this. He wrote about how Anthropic's Claude Code docs team does it.
"Just in the meeting before this, we were brainstorming a campaign on our whiteboard, and part of it was having Ethan in the room updating a bunch of our competitor docs. It's not just about making a landing page anymore. We've got to look across our other properties, because that's the first place people, or at least their agents, are searching."
âLauren Volpi, Head of Marketing, Mintlify
What I'd steal from Mintlify
Getting your external docs and your internal knowledge right are two sides of the same coin. Both are extremely helpful for internal and external agents to read, and both take the same level of discipline. You can build agents to help you here and/or use the Mintlify product (just like team Mintlify does).
Focus on the context layer before you build a pile of skills. Most teams I talk to have this backward and then wonder why their skills aren't adopted or produce bad outputs. The skills are only as good as the context they run on.
Design your team and roles in a way that works for you. At Mintlify that means a "Knowledge Engineer" owning internal and external knowledge. But no matter what, have clear ownership for all parts of your multiplayer system (you can use the 4Cs framework to help here!).
âIf you put it on Mintlify, you now have shared context in Claude Code, Cursor, whatever youâre using, and everyone can contribute. You donât need someone who knows the tool. They can just tell Mintlify in Slack to update the knowledge for the entire team, so a conversation doesnât get lost.â
âLauren Volpi, Head of Marketing, Mintlify
Putting it all together: Multiplayer AI FAQs
Based on what I learned researching and building this series, and conversations with people like Simon, Danny, and Lauren, here are my recommendations on the common questions I get about multiplayer AI setups.
Who should own a marketing team's AI setup?
Every part of your system needs an owner (all 4 Cs). That can be one person or several, as long as each piece has a DRI. All 3 companies here have clear owners and they're all different, which is the point!
Buffer: Simon and growth marketing, which includes marketing ops and data functions, build and maintain the system. The whole team updates the context docs and builds individual skills.
LangChain: A 4-person GTM Engineering team builds for the whole GTM org. Each engineer owns a slice of the funnel and works directly with the associated team.
Mintlify: Ethan owns context in his role as âKnowledge Engineer,â and Lauren and her marketing team own the rest of the system.
Where should a marketing team's AI context live?
Your context has to do a lot: pull from the tools and docs you already use, be a source of truth without duplicate copies, be easy for people and agents to read, be easy to update with version history, and still be curated enough that it isn't too long to parse on every skill or agent run. Claude Cowork, Claude Code, or a GitHub repo alone won't get you all of that, which is why none of the 3 teams here keep their context in those places.
Buffer: Notion, because the marketing team already lives there and it's agent-friendly. A monthly workflow pings each doc owner to update theirs.
LangChain: Their GTM tools connected to their agents via APIs, plus human-written context files. The agents refresh what they pull on every run.
Mintlify: Their own product, with the internal knowledge base and public docs running on the same infrastructure. Mintlify itself drafts the updates to the internal knowledge base and Ethan approves them.
Do you need to be technical to build out a marketing team's AI setup?
There is a learning curve for Claude Code, GitHub repos, and building deployed agents. But I'm a marketer, a systems thinker who's good with tools and rev ops work, and I figured it out with help from AI, friends, conversations like the ones in this newsletter, and LinkedIn and Substack. Not everyone needs to own the system, but everyone in marketing can and should contribute.
Buffer: Nobody on the marketing team is an engineer. Their communications director went into Build Week identifying as non-technical and came out having shipped 6 internal tools.
LangChain: They're building on developer-focused tools (LangChain's products!) and open sourcing what they make, so they have a GTM Engineering team running it. But Danny came from marketing ops, not engineering.
Mintlify: A 7-person marketing team with no engineers. Lauren set up their shared brain herself, and Ethan has âengineerâ in his title but came from technical writing.
Do a marketing team's AI workflows need humans in the loop?
The answer here seems pretty clear across teams: Before something ships or is sent, it needs human review, including the skills themselves.
Buffer: Anything shipped to users has to be written by a human or have a heavy-handed human in the loop. New skills get tested by their subject matter expert before they reach the whole team.
LangChain: A human reviews everything customer-facing, so agent drafts land in Slack for someone to send, edit, or cancel. LangSmith Engine's fixes also go to the team to approve.
Mintlify: Their product is built to update knowledge base content on its own, but they still keep a human in the loop to improve what goes in, and that's Ethan's job. Their PM Neha's bet is that this matters more than ever, not less.
How do you keep a marketing team's AI setup from going stale?
There are multiple pieces to keep from going stale across the 4 Cs. You need your system to stay up to date, with your GitHub repos still connected to Claude and your agents still running. You need your context to stay fresh as a source of truth. You need your capabilities to update on their own, not just when you remember to update them. And you need to make sure the whole team knows the latest and greatest process.
Buffer: They have a set of capabilities built specifically to maintain the system, including a monthly workflow that pings each context doc owner to check what changed. One push to the GitHub repo also updates everyoneâs Claude, so the system itself stays current.
LangChain: Their agents run in the cloud, so there is nothing on anyoneâs machine to keep connected, and context updates on every run. LangSmith Engine watches those runs, clusters failures into named issues, and writes fixes for the team to approve.
Mintlify: The Mintlify product has workflows to draft the knowledge base updates and Ethan approves them. They also have company-wide agents running on schedules, like a support-ticket-to-PR pipeline and a morning sales brief.
While each of these companies had a headstart, there are big learnings to take from each one. Buffer has a culture where everyone already shares what they build, so getting people to contribute wasn't the hard part. LangChain makes the tools for building agents, so their GTM team has experts surrounding them! Similarly, Mintlify's entire team is thinking about building perfect context layers.
But you have a headstart now too. Itâs this newsletter series and the MKT1 MCP, which has skills for both doing marketing work and maintaining a multiplayer system.
Hereâs what to do now: Revisit the 4 Cs and pick and choose what will work for your company from the approaches presented here. You should not directly copy any of these 3 approaches! Just get started, andâas I said earlierâremember Rome wasnât built in a day.
Thank you to everyone who helped with this one. It was truly a multiplayer newsletter effort! Simon Heaton at Buffer. Danny Lambert, Jan Glanc, and Amal Irgashev at LangChain. Lauren Volpi, Ethan Palm, Neha Halebeed, Cole Gottdank, and David Isquick at Mintlify.
Thatâs all for this edition of MKT1 Newsletter. Subscribe to get Part 3 of this series in the coming weeks. And donât forget to install the MKT1 MCP and get a paid subscription, itâs the best way to get started with skills built (by me!) specifically for B2B startup marketers.
More from MKT1
Upcoming changes to MKT1 pricing for new paid subscribers
On October 1, 2026, we are increasing prices for new paid subscribers: $16/month or $144/year (thatâs 3 months free for annual subscribers!). For existing paid subscribers, nothing is changing right now.
Upgrade to an annual subscription before October 1 to lock in the current price of $99/year for 2 years.
Why:
We havenât changed prices in almost two years, and weâve added a lot to the paid plan since.
Weâre investing more in the MKT1 MCP, which is included in every paid plan. This requires more MKT1 resources dedicated to development and support.
Other newsletters with similar perks and extensive archives charge $18 to $20 a month. Our perks include $40K+ in discounts on GTM tools, the full MKT1 archive, our 100+ template library, free posts to our job board and job search MCP skill, and more coming soon.
If you have any questions please let us know.
đ Brought to you by: Framer, the site builder now equipped with Agents; Profound, the AI Search platform that thinks like a marketer; and Closing Media, a LinkedIn & Paid Media Agency.
đŹ Bring this newsletter to Claude: Chat with this newsletter with this pre-built promptâthis is a long one, so this is a good way to get a refresher or summary!
đ MKT1 x Lovable Buildathon on 10/28 at 10AM PDT / 1PM EDT: Come build apps and MCPs for your team or your customers alongside Kramer and the Lovable team. Register here.
đ„ Come see me twice at UNBOUND in Boston: Grab coffee and pastries with me, Kyle Poyar, and the Capsule and Gamma teams at The B2B Bakery pop-up on 9/16 from 12-2PM, then watch me judge Battle of the Builders, HubSpot's $100K AI transformation pitch competition, on 9/17 at 3:30PM.
đ€ MKT1 MCP Server: Add MKT1 skills to your LLMs. Paid subscribers get our full library of 30+ skills and templates, including the multiplayer skills featured in this newsletter.
đ§âđ MKT1 job board - new & improved: Jobs from the MKT1 community (itâs free to post as a paid subscriber). And our candidate form if youâre looking for a new role (option to remain anonymous included!).
đ„ MKT1 Perk Stack: Exclusive discounts worth $40K+ on our favorite GTM tools. For annual & superfan paid subscribers only.
𧰠Template & resource library: We have 100+ templates and resources available to paid subscribers in our template & tool library.
Great post. Love seeing how teams are building. Just here to add Obsidian into the conversation around knowledge base / context layer. Itâs been mentioned on this Substack before and is my favorite digital toolâperiod. User-friendly, no lock-in (itâs just .md files), and the community plugins make it super extensible for every use case.
Agents more useful than interns starts with giving them the full picture. I work with models the way I work any room: real source material first, an example of good, then one correction per round. The teams in this piece seem to have landed on the same rhythm.