Building a Second Brain for Product Marketing: What I Learned by Making an AI Agent Read My Company's Mind
Most of the AI conversation in marketing today runs in one of two directions. There’s the outside-in direction — competitive intelligence, analyst coverage, social listening — where AI helps you understand the market. And there’s the forward direction — campaigns, ABM, lead nurturing — where AI helps you move people through a funnel.
Both are well covered. Every marketing tool roadmap from here to 2030 has a slide about AI-powered competitive monitoring or AI-generated ad copy.
What’s almost never discussed is the third direction: inside-out. What happens when you point an AI agent at your own company’s internal knowledge — specs, tickets, call transcripts, win/loss notes — and ask it to do the unglamorous but critical work of product marketing? Not “tell me about the market,” not “write me an ad,” but: generate the battle card, draft the release note, and tell me if what we’re saying externally still matches what’s true internally.
That third lane is what I wanted to explore. So I built PMM Second Brain — a working AI agent, backed by a real (if fictional) company’s internal wiki, that produces actual PMM deliverables and catches messaging drift before a customer does.
This post is the story of how it came together: the thinking behind it, the architecture, the build process, and a few things I learned along the way — including some genuinely humbling moments getting it to run on my own laptop.
The starting idea: PMM work has a “second brain” problem
If you’ve worked in product marketing, you know the feeling. The feature shipped six weeks ago. The Jira ticket has the real ship date and a known edge case. The Slack thread has the launch announcement. The win/loss notes have the actual reason you lost that one deal. And the landing page still says what it said in Q1.
All of that information exists. It’s just scattered, and nobody has time to cross-reference it before every battle card, release note, or competitive deck. The result is a slow but constant drift between what the company internally knows to be true and what it says externally — and PMMs are usually the last line of defense against that drift, armed with nothing but tribal memory and a search bar.
So the idea was simple: what if an AI agent had access to all of that internal context — structured, indexed, and queryable — and used it to do the work, not just answer questions? And what if one of its jobs was specifically to compare “what we say” against “what we know” and flag the gap?
That second part — the drift checker — became the centerpiece of the whole project. Everything else exists to support it.
Grounding it in a real (fictional) company
Generic demo data is the fastest way to make a portfolio project feel like a tech demo instead of a product. So before writing any code, I built a small fictional SaaS company to anchor everything: FlowPilot, a workflow automation platform for operations teams — think “Zapier for ops approvals and handoffs.”
FlowPilot has two competitors with distinct personalities: OpsChain, the enterprise-grade, compliance-heavy option with a brutal 6–8 week implementation; and Routely, the cheap, fast, SMB-friendly option that falls apart once a team needs real permissions or audit logs.
And FlowPilot just shipped a feature called AutoSync — automated data synchronization with Salesforce, HubSpot, and NetSuite every 15 minutes, replacing what used to be manual CSV export/import.
AutoSync became the spine of the entire dataset. Every file in the vault references it from a different angle:
The product spec describes what it does and when it shipped (May 26, 2026).
The Jira ticket (AUTOSYNC-142) confirms the same ship date and flags a known NetSuite duplicate-entry edge case as a follow-up.
The Slack launch thread announces it internally — and contains the seed of the drift bug: someone from marketing promises to update the landing page “by end of week” and never does.
The current landing page, dated before launch, still describes manual CSV export.
A pre-launch customer call (Brightline Logistics) shows the pain point that justified building AutoSync in the first place.
A post-launch customer call (Hearth & Co.) reports the exact NetSuite bug from the Jira ticket — a less-flattering detail that a good agent should surface, not hide.
The win/loss notes tie AutoSync to a real competitive win over Routely, and tie a separate audit-log gap to two losses against OpsChain.
By the time the vault was done, the AutoSync story ran consistently through eleven interlinked markdown files — with the landing page sitting there, quietly wrong, waiting to be caught.
The architecture, in plain terms
The system has five layers, and I wanted each one to be legible on its own — not a black box, but something a PMM reading the code could actually follow.
The vault is just a folder of markdown files, organized the way a real internal wiki might be: product/, competitive/, customers/, engineering/, external/. It’s Obsidian-compatible, with [[wikilinks]] connecting related notes — the win/loss notes link to both competitor profiles, the Brightline transcript links to the AutoSync spec, and so on.
The ingestion pipeline walks that vault, parses each file’s frontmatter, and splits it into chunks along heading boundaries — not arbitrary character counts. Headings are natural semantic units for this kind of content, and chunking along them keeps each piece of retrieved context coherent. Every chunk gets tagged with its source file, document type, title, and related links.
The vector store is a local Chroma collection. Chunks get embedded — either with a local sentence-transformers model (no API key required) or OpenAI’s embeddings — and persisted to disk so the index only needs to be built once.
The agent tools are where retrieval meets generation. Each tool follows the same pattern: pull the relevant chunks, drop them into a prompt template, and ask for a structured JSON response — not free text. A battle card has a defined shape (positioning summary, objections with counters and proof points, win themes). A release note has a defined shape (headline, summary, details, known limitations). Treating PMM deliverables as having schemas, not just topics, was one of the choices I cared about most — it’s the difference between “AI wrote some marketing words” and “AI produced the artifact a PMM actually ships.”
The UI is a Streamlit app with six tabs — one per tool, plus a free-text “Ask the Brain” tab for open-ended Q&A over the vault.
Building it: six phases, one storyline
I built this in phases, each one a complete, testable slice rather than a half-finished version of everything.
Phase 1 — the vault. All eleven content files, written in the natural register of their format (Slack messages short and informal, specs structured, transcripts with speaker labels), wikilinked, and checked for internal consistency. This phase mattered more than it might seem — if the AutoSync timeline didn’t line up across files, every downstream tool would inherit that inconsistency.
Phase 2 — ingestion. parse_vault.py and build_index.py, plus a pluggable embeddings layer with three modes: local, OpenAI, and a dependency-free “hash” mode used purely for testing. The hash mode was a small decision with an outsized payoff — it meant the test suite and CI pipeline could run without downloading any models or needing any API keys, while still exercising the real chunking, metadata, and retrieval logic.
Phase 3 — agent tools. A provider-agnostic LLM wrapper (Claude by default, OpenAI optional, and a “mock” mode with hand-written, vault-grounded responses), a retrieval helper, five prompt templates stored as their own markdown files rather than buried in Python strings, and the five tools themselves. I tested every tool via a CLI before touching the UI — generating a battle card, drafting a release note, building the comparison table, and running the drift check, all from the command line, all citing real sources.
Phase 4 — the drift checker. The differentiator. It retrieves the current (outdated) landing page copy alongside the most recent product and engineering chunks, then asks the model to identify specific factual mismatches and rate their severity. In the demo run, it correctly flagged the landing page’s “export your data manually via CSV” claim as a high-severity mismatch against the shipped AutoSync feature — and, as a bonus, also caught a subtler one: the page’s “full control over when your data moves” framing no longer holds now that sync is automated on a 15-minute interval.
Phase 5 — the UI. Six Streamlit tabs tying everything together. One design choice I’d highlight: the sidebar always shows which LLM and embedding providers are active, with an explicit “demo mode” banner when running on mocks. Nothing is hidden about what’s real generation versus canned output. And for the free-text Q&A tab specifically, mock mode doesn’t fake a chat response — it shows the raw retrieved chunks with an honest note about why. I’d rather a demo be transparently limited than quietly dishonest.
Phase 6 — packaging. README, MIT license, sample outputs, and a GitHub Actions workflow running pytest on every push — using the hash embeddings so CI needs zero secrets.
The unglamorous part: making it actually run
Here’s the part that doesn’t usually make it into a portfolio writeup, but probably should.
Having a working sandbox demo is one thing. Getting it running on a personal Windows machine — installing Python, creating a virtual environment, editing a .env file, and debugging a ModuleNotFoundError because Streamlit’s working directory assumptions didn’t match the project’s import structure — is a completely different exercise. None of that is exotic to anyone who’s set up a Python project before, but it’s exactly the kind of friction that makes “I built an AI agent” and “I can run an AI agent” two different claims.
I’d rather say plainly: getting from generated code to a running app on a real machine took its own round of debugging, one terminal command at a time, including a Notepad copy-paste that silently truncated a file mid-save and produced a syntax error that looked far scarier than it was. The fix, in the end, was a two-line sys.path adjustment and a clean file re-download. Small bug, but it’s a reminder that “the code is correct” and “the code runs on this machine, right now” are not the same milestone — and that the gap between them is often where the real debugging happens.
What this demonstrates — and why it’s Lane 3
A few things I’d point to if asked about this project in an interview:
The framework-level thinking — the three-lanes model, and specifically the argument that Lane 3 (company-centric, inside-out) is the most underused — is itself a piece of product marketing judgment, separate from any code.
The RAG architecture — chunking strategy, metadata tagging, embeddings, retrieval — is the baseline AI engineering literacy that’s increasingly table stakes for GTM and AI-enablement roles.
The structured generation — designing a JSON schema for each PMM asset type — reflects an understanding that PMM deliverables have form, not just content. A battle card isn’t “some text about a competitor”; it’s objections, counters, and proof points in a specific shape.
And the drift checker is the strongest signal of PMM-specific value, because it’s not a tech demo wrapped in marketing language — it’s a feature idea, born from a real, recurring PMM problem: the slow, silent gap between what a company says and what a company knows.
Try it yourself
The full project — vault, ingestion pipeline, agent tools, Streamlit UI, tests, and CI — is on GitHub: github.com/yotamgutman/pmm-second-brain. It runs entirely in “mock mode” with zero API keys, so you can clone it and click through every tab — including watching the drift checker catch FlowPilot’s outdated landing page in real time.
If you’re a PMM thinking about where AI actually fits into your workflow beyond “write me a blog post” — I’d argue the most valuable lane is the one pointed at your own company, not just the market around it.