--- title: "Post | LinkedIn" url: https://stacklist.com/card/9f09a06a-a472-4925-98c8-730eecb84bf5 source_url: "https://www.linkedin.com/posts/angelalsun_were-building-an-ai-gtm-brain-share-7481046941569630208-AtSH/" stack: https://stacklist.com/stack/2b72dea2-1800-44ce-a6b3-7a1b4186801a summary: "Angela Sun discusses building an AI GTM \"Brain\" that consolidates customer knowledge, market insights, and messaging to automate asset creation and propose narrative shifts. The post explores best practices for organizing and hosting the underlying knowledge infrastructure, with community responses recommending GitHub over Google Drive and emphasizing the importance of a query layer over raw file storage." tags: "ai-gtm, knowledge-management, sales-enablement, ai-agents, file-systems, positioning, product-marketing" key_entities: "Angela Sun (person), Tim Liu (person), Will Allred (person), Hallie Condon (person), Josiah Purss (person), Melanie Crissey (person), GitHub (technology), Google Drive (technology), Slack (technology), Obsidian (technology), Google Sheets (technology), Google Docs (technology), AI GTM Brain (concept), knowledge-graph (concept), ICP (concept), positioning (concept), narrative-shifts (concept), LinkedIn (organization)" classification: "transcript" content_hash: "sha256:1ef717c73ad92c7bfef6368cd4a5282ba466c56a5efc09f9486cbcf036f0c619" acp_version: "0.2" token_counts_approximate: 1940 visibility: public agent_accessible: true status: "final" --- # Post | LinkedIn Angela Sun 1w Report this post We're building an AI GTM "Brain." ๐Ÿง  ๐Ÿ‘€ One that knows everything that we, on the team, know about our customers, ICP, personas, positioning and messaging, competitors, account tiers, routing logic, etc. One that listens for what's changing in the market from our recorded sales calls and proposes narrative shifts... One that can either create new or update all our existing assets when we launch a new feature... One that's hooked up to the brain that Product is creating in tandem... Question to anyone who's doing something like this today: How are you tackling the file system that holds all the info? Where are you hosting it? Google Drive? GitHub? Right now, we're sending and resending zip files in Slack to a small group of folks when we make a change in our .md files. ๐Ÿ˜… Curious if anyone's figured out a good solution! 145 141 Comments Like Comment Share Copy LinkedIn Facebook X Angela Sun 1w Report this comment Tim Liu Like Reply 2 Reactions 3 Reactions Angela Sun 6d Report this comment Wow, this post blew up in a way I did not expect! SOOO much to think about. Clearly this is concept is top of mind not only for marketing and GTM teams, but for the entire company based on how many founders/CEOs and other department leaders chimed in in the comments! Really appreciate everyone taking the time to contribute their thoughts, insights, and approaches. ๐Ÿ™ Iโ€™m reading through each and every comment and may share a recap/summary on LinkedIn shortly...๐Ÿ‘€ Like Reply 3 Reactions 4 Reactions ๐Ÿ’œ ๐Ÿ”ฎ Will Allred 1w Report this comment I just wrote a 50+ page doc on this (Iโ€™ll dm ya) ๐Ÿ˜… to answer your question- docs, and sheets are fine. Sure you can use a file system like obsidian but your agents should be able to use Googles MCP to edit docs/sheets/slides ongoing too. For my consulting co I run with a mix in drive and on prem in my Mac mini. Ive seen better and worse ways to set this up. Big thing you want to make sure is that you balance centralization of the building (think infra) with the enablement of everyone (think daily use). Too many smart people become the bottle neck (ego doesnโ€™t help). That infra decision is imo way more important than where you store files haha Like Reply 2 Reactions 3 Reactions Hallie Condon 1w Report this comment I just launched this at the company level, so not GTM specific, but same problem underneath. Here is what I learned through the process: On your question, Github over Drive. Put the .md files in a repo and make that the single source of truth. The zip files in slack phase can be over the day you do this. So if your team is like most of the employees at our company then you might be thinking that they will never touch github and/or they don't know how it works. That's ok because AI can read and write to the repo for you. Think of the repo as the plumbing and not the interface. That's the part that I'm betting on making this actually work for non-engineers. Something not in your question, but I think is really important. Where you host the files barely matters compared to how you surface them. The files are the brain, but a brain no one can query is just a folder. So you should plan to have a layer on top that pulls the right thing at the right moment, and stays fresh so it isn't confidently serving up old positioning. Happy to share anything if it's helpful, just send me a DM. Like Reply 2 Reactions 3 Reactions Josiah Purss 1w Report this comment Angela Sun I thought about this a lot. I would try and separate canonical information files built for AI (knowledge graph) from the interface that humans read from, eg. Slack answers, custom decks, customer specific battle cards Canonical knowledge -> AI -> Human interfaces Happy to chat about this sometime, doing something very similar. Like Reply 1 Reaction 2 Reactions Melanie Crissey 1w Report this comment We should talk and compare notes! Working on exactly this right now Hosting in GitHub with a docs UI layer that feels like a wiki MCP hooks to Claude and Google Drive for artifact creation Still early, not completely proven but better than a bunch of people individually uploading .md file to Claude projects that don't converse with one another Like Reply 3 Reactions 4 Reactions Slava Baranskyi, FCIM 1w Report this comment GitHub's the right call for versioning, but the file system won't be your hard problem for long. Two things replace it. First: structure the files around what the agent needs to retrieve, not how your team likes to organize. Retrieval quality lives or dies on that. Second, and bigger: a brain that "proposes narrative shifts" from sales calls will propose confident wrong ones, and without an eval set to catch them you find out when the campaign is already live and off-message. I've spent nine months building exactly this kind of system. The .md structure took a week. Retrieval and evals took the other eight. Like Reply 5 Reactions 6 Reactions Sean Cardenas 1w Report this comment This is one of the harder problems we work on with enterprise teams, and the honest answer is that where you host it matters less than how the information is structured. Google Drive, GitHub, Notion, they all work until an agent has to reason across it. If the underlying data isn't structured for agents to read consistently, the output varies wildly from person to person, and no folder setup saves you from that. Funny enough, we think "agent enablement," getting your knowledge into a shape agents can actually use, is becoming one of the most important things for GTM teams to get their arms around Like Reply 2 Reactions 3 Reactions Ido Goldberg 1w Report this comment most of this thread is solving the knowledge-wiki half.. positioning, playbooks, personas in github. that half is pretty well understood at this point. the harder half is per account memory, and that half is really a crm not a folder. what we landed on (and run our own gtm on with Swan AI ) is two connected layers. a shared versioned wiki for skills/playbooks/icp/positioning.. and native crm memory where every account and contact is a living entity. an account.md the agent keeps current, a structured record.json , and an append only activity log of every change and encounter. versioned with history the agent can reach back into, team permissions, entity strucutre it maintains itself. thats what makes it more than a folder. next up is extracting the entities into a graph on top. happy to compare notes with anyone buildng this Like Reply 3 Reactions 4 Reactions Brian Kyed 1w Report this comment We used to keep our gtm-os on GitHub. It was fine, but slow, and the tools around it (Conductor, Cursor and friends) are built for engineers. So we built Palette Desktop for exactly this. To work with coding agents like Claude code etc on our own shared files. Our gtm-os now lives as folders on Google Drive. Everyone point Palette desktop at it and can now work with Claude Code, Codex, Gemini etc using the same skills and same context files. Every chat/session gets its own copy of the folder, so the team can work in it at the same time without stepping on each other. We use Git under the hood, you just never see it. You click any markdown file to read or edit it right there, so no need for Obsidian or Zed etc.. The whole idea is to give non-engineers coding agents, pointed at the context files they've built up themselves. Happy to get you set up if you want to try it. Screenshot from where I spent all my day :) https://palette.team / No more previous content No more next content Like Reply 6 Reactions 7 Reactions See more comments To view or add a comment, sign in