
SERIES · THE PM AGENT STACK
Five parts. Roughly 30 minutes total read. This is one connected system, not a set of independent tools. Read in order.
- 1. Overview ← you are here
- 2. Discovery agent stack
- 3. Build agent stack
- 4. Measure agent stack
- 5. The PM Agent Stack handbook chapter (canonical reference)
The short version
The destination for every product organization is one AI brain that has read access to every system the company runs. Slack, email, calendar, meetings, documents, source code, dashboards, CRM, design files. All of it. Not parts. All. Most companies are 6 to 18 months from that destination because procurement, security review, and data governance move slowly and PMs are not the buyers for the platform layer.
This series is the bridge. It is the practical guide to building a personal PM agent stack that runs today, on the inputs a single PM has access to, and that compounds the work in measurable ways while the enterprise version is being procured. Five parts. One connected system. Read in order.
The destination: an enterprise-wide AI brain
The strongest possible PM agent has access to everything. Every Slack conversation, public or private channel the PM is in. Every email thread. Every meeting recording, every Zoom transcript, every Gong call, every Otter note. Every PRD, RFC, design doc, retro, post-mortem. Every Jira ticket, every Linear issue, every GitHub PR, every commit message. Every Salesforce account, every HubSpot contact, every customer support thread. Every Looker query, every Tableau dashboard, every analytics event. Every Figma file. Every Notion page.
Not your documents. Every document the company produces.
Full stop.
When the agent has access to everything, three things change. First, it stops feeling like a tool and starts feeling like a colleague who has been at the company for years. Second, the answers compound: a question about why a feature performed the way it did is answered by reading the design discussion, the PRD, the customer call transcripts, the experiment configuration, and the post-launch metric movement at the same time. Third, the institutional memory of the company stops being trapped in individual heads and starts being queryable.
This is not speculation. The companies that have built this layer first are already pulling ahead. R&D figured it out earliest. Go-to-market is catching up. G&A is right behind. In every category, the gap between teams operating against a shared context layer and teams still working from their personal silos is widening every quarter.
If your company is on this track, congratulations. You have a tailwind most PMs do not. Skip ahead to the trailing posts; they teach you how to use the pieces you will plug into the enterprise brain when it arrives.
If your company is not on this track yet, this series is for you.
The gap: why most PMs are still on the wrong side of this
Three structural reasons your company is not there yet:
Procurement and security move on a slower clock than capability. The vendor your CISO will approve has not shipped the connector you need. The data governance review has not started. The CRM source-of-truth question is still open. The retention-policy question is unresolved. None of these are fixable from the PM seat. The realistic timeline is 6 to 18 months for most enterprises.
You are not the buyer. This is the harder reason. The decision to build an enterprise AI brain happens in the office of the CTO, the CIO, or the COO. Sometimes it happens at the CEO level. PMs influence the prioritization of products that ride on the platform. PMs do not get to write the multi-million-dollar check for the platform itself. If you are below VP level, you are watching this happen, not driving it.
The org has tried something like this before and it underdelivered. Many companies are scarred from earlier knowledge-management projects, data lake initiatives, or enterprise search rollouts. The skepticism about AI-powered context layers is residual scar tissue, not opposition to AI itself. It still slows the rollout. The decision-makers want to be sure this time is different before signing.
So the practical question for any individual PM is not "do you need an enterprise-wide AI brain?" The question is "what do you do this quarter while the enterprise version is still being procured?"
The bridge: a personal PM agent stack
A personal PM agent stack is a curated set of open-source Claude tools layered on top of Claude Code. It does not replace the enterprise brain. It is the bridge to it.
The bridge has three properties that matter:
It works on the inputs you have access to today. Your customer call transcripts. The repos you can see on GitHub. The metrics database your team has read access to. The dashboards you have a login for. The Slack channels you are in. Limited compared to the enterprise brain. But within those limits, the leverage is substantial.
It is single-PM scope by design. The personal stack does not solve the company's knowledge management problem. It solves your knowledge management problem. The trade-off is intentional. You can stand it up in a week of evenings without asking anyone for permission.
Every component is replaceable. The enterprise brain, when it arrives, will have its own memory layer, its own skills system, its own MCP equivalents. The personal stack is engineered so that when the enterprise version shows up, you migrate the practices and the patterns, not the specific tools. The investment is not in the tools; it is in the workflows you build with them.
The series that follows takes you from this framing to a working personal stack. By the end of it, three to twelve open-source repos are installed, wired to real PM work, and compounding institutional memory at the personal scale.
What you can actually do once it is set up
This is the part most posts about agent tooling skip. Here is what changes, in concrete terms. Each outcome below is the subject of one of the trailing posts in this series.
Six specific outcomes:
Customer call synthesis collapses from a Friday afternoon ritual to a 90-second job. Drop a transcript in. Get a structured note out, with themes, evidence, and the delta against the last five calls. Continuous discovery becomes possible at the speed of the calls themselves rather than at the speed of weekly batch processing. Detail in Part 2: Discovery.
Cross-source signal monitoring runs while you sleep. Support tickets, public reviews, your subreddit, competitor pages. The agent reads them on a schedule and reports new themes daily. Three sources you swore you would read but did not, suddenly read by a process that does not get tired. Detail in Part 2: Discovery.
PRD-to-prototype shrinks from weeks to a day. A working prototype, with TDD discipline and a security pass, in a single afternoon. Engineering reacts to a real artifact instead of debating a doc. The cycle gets tighter. Detail in Part 3: Build.
Weekly stakeholder updates draft themselves from raw evidence. Numbers, ship status, risks, surprises. The agent assembles the structural draft. The PM adds the narrative voice. The Friday evening ritual goes away. Detail in Part 4: Measure.
The dashboard hamster wheel ends. The agent watches the metrics, flags variance worth attention, and surfaces what changed before someone else asks. The morning ritual of opening the same five dashboards stops. Detail in Part 4: Measure.
Cross-session memory means the agent remembers what was decided last Tuesday. Without this, the agent is a tool you re-explain to every session. With it, the agent is a colleague who took notes. Detail across all three trailing posts.
These are not hypothetical. They are the specific outcomes the trailing three posts each unlock, with install commands, recipes, and the daily rhythm.
Critical limitations: what the bridge cannot do
The bridge has real limits. Naming them honestly is part of the deal. If a post about a personal agent stack does not list the limitations, the post is selling, not teaching.
Single-PM scope. The personal stack only sees what one PM can give it access to. It cannot read Slack channels the PM is not in. It cannot see deals in the CRM the PM is not on. It cannot read meeting transcripts from meetings the PM did not attend. Cross-team patterns that span outside the PM's visible work are invisible to it. The enterprise brain solves this. The bridge does not.
No team-wide memory. Cross-session memory works for one PM's filesystem. It does not propagate across teammates. Each PM on the same team rebuilds the memory layer separately. There is no shared "what did we decide as a team last quarter" without an enterprise platform.
Limited write access. The personal stack reads. The agent can be configured to write, but write actions outside the PM's own filesystem (sending email, posting in Slack, updating Notion) are fragile, require explicit per-tool setup, and have no audit trail by default. The enterprise version normalizes write actions across systems with auditing and approval flows. The bridge does not.
Security boundary is your laptop. Enterprise agents have audit logs, role-based access, retention policies, and data loss prevention. The personal stack inherits the security posture of the laptop and the source systems being connected. PII handling stays the PM's responsibility. Treat customer transcripts the way they should be treated today, not differently because an agent is reading them. Follow your company's data handling policy.
Tool drift. Open-source repos move fast. A repo that is hot today could be unmaintained in 18 months. The stack requires ongoing curation. Plan for it. Subscribe to the awesome lists as feeds, check them monthly, replace tools that go quiet.
Cognitive overhead is real. Twelve installed tools is a lot to track. The first time the agent surprises you (in either direction) the trust drop costs a session of productivity. Start small. Add tools only when the friction the new tool solves is something you can name in a sentence.
Won't replace the data team. Or the security team. Or the legal team. The personal stack augments individual PM work. It does not refactor company governance, replace specialist functions, or solve organizational problems. Use it as a tool for a person, not as a substitute for an org.
If any of these limitations is a deal-breaker for your situation, this series is the wrong starting point. The right starting point is then to push your CTO/CIO toward the enterprise version directly.
How the series is structured
This is one piece of a five-part series, designed to be read in order.
Part 1 (this post): Overview. The destination, the gap, the bridge, the outcomes, the limitations.
Part 2: Discovery agent stack. The seven repos that turn customer interviews, support tickets, and public reviews into a continuous discovery loop. Three concrete recipes, install commands, daily rhythm.
Part 3: Build agent stack. The eight repos that take a PM from blurry idea to a working prototype the team can react to. TDD enforcement, design review, security review built in. Three concrete recipes.
Part 4: Measure agent stack. The seven repos that turn dashboards, databases, and post-launch results into a daily outcome digest, a variance detector, and a stakeholder update writer. Three concrete recipes.
Part 5: The PM Agent Stack handbook chapter. The canonical reference. The full taxonomy of 18 categories of open-source Claude repos, mapped to the 7-stage PM operating system. The install order. The rules of the road.
Each post is short on its own. The system is the series. Read in order. The recipes in parts 2 through 4 are the same shape, deliberately, so the rhythm of "five repos, three recipes, what stays human" carries across. Skim if necessary, but do not pick a single trailing post in isolation; the recipes only land if the framing is in place.
What to do this week
Three concrete actions:
First, decide if the organization is on the enterprise-AI-brain track. If it is, set a calendar reminder for six months and check in with whoever owns the platform. If it is not, or if the answer is unclear, continue the series.
Second, install Claude Code if it is not already on the laptop. npm install -g @anthropic-ai/claude-code. Run a real PM task through it tonight. Not a synthetic example. A real interview transcript, a real PR review, a real weekly digest. The point of the bridge is to feel the leverage, and the only way to feel it is on real work.
Third, walk through one of the three trailing posts based on which stage of work most needs help right now. Discovery is the gentlest entry point. Build is the most transformative. Measure is the highest-calendar-leverage.
The shared context layer is coming whether your company is ready or not. The bridge gets built first. The destination follows.
Build a Discovery Agent Stack
Continuous customer listening on autopilot. Seven repos, three concrete recipes, the daily rhythm. The Friday afternoon synthesis ritual goes away in week one.
Sources: hesreallyhim/awesome-claude-code, anthropics/claude-code, anthropics/skills, obra/superpowers, github/github-mcp-server, crystaldba/postgres-mcp, microsoft/playwright-mcp, thedotmack/claude-mem. The 18-category taxonomy of the Claude open-source ecosystem is adapted from Divyanshi Sharma's Instagram carousel on the Claude ecosystem.
Download the artifact
Ready to use. Copy into your project or share with your team.
Also on Medium
Full archive →AI Agents and the Future of Work: A Pixar-Inspired Journey
What product managers can learn about AI agents from how Pixar runs a film team.
Many AI Agents Are Actually Workflows or Automations in Disguise
How to tell agents from workflows from cron jobs, and why it matters for what you ship.
Frequently asked
What is the destination this series is bridging toward?+
An enterprise-wide AI brain. One agent with read access to every Slack thread, every email, every meeting recording and transcript, every Notion page, every Jira ticket, every Salesforce opportunity, every Looker dashboard, every Figma file, every commit message. Not your documents. Every document the company produces. When that layer exists, the agent stops being a tool and starts being a colleague who has been at the company for years. That is the destination.
Why isn't my company already there?+
Three structural reasons. Procurement and security cycles take 6 to 18 months for a system that touches this many sources. The decision to build the platform layer happens in the office of the CTO, CIO, or COO; PMs influence prioritization but do not write the multi-million-dollar check. And many companies are scarred from earlier knowledge-management projects (data lakes, enterprise search, knowledge graphs) that consumed budget and shipped underwhelming. The scar tissue is residual; it still slows the rollout.
What is a personal PM agent stack and how is it different?+
A personal PM agent stack is a curated set of open-source Claude tools (skills, subagents, MCP servers, hooks, slash commands) layered on top of Claude Code. It runs against the inputs one PM has access to: their transcripts, the GitHub issues they can see, a metrics database read-replica, the dashboards they have a login for. It is single-PM scope by design. The trade-off is intentional. It can be standing in a week of evenings, without permission from anyone.
What can I actually do with this once it's set up?+
Six concrete outcomes. Customer-call synthesis collapses from a Friday ritual to a 90-second job. Cross-source signal monitoring runs while you sleep. PRD-to-prototype shrinks from weeks to a day. Weekly stakeholder updates draft themselves from raw evidence. The dashboard hamster wheel ends. Cross-session memory means the agent remembers what was decided last Tuesday. Each outcome is the subject of one of the trailing posts in this series.
What are the critical limitations of the personal version?+
Single-PM scope (the agent only sees what one PM can give it access to, cross-team patterns invisible). No team-wide memory (each PM rebuilds). Limited write access (reads are easy, writes outside your filesystem are fragile). Security boundary is your laptop. Open-source repos drift over time. Cognitive overhead of installed tools is real. And the personal stack does not replace the data team, the security team, or the legal team. It augments individual PM work. It does not refactor company governance.
How does this series flow and where do I start?+
Five parts in order. Part 1 (this post) is the framing. Parts 2 through 4 are the concrete how-tos for the Discover, Build, and Measure stages of the PM operating system. Part 5 is the canonical handbook chapter with the full taxonomy. Read part 1 first, then pick the trailing how-to whose stage of PM work most needs help right now. The recipes only land if you have the framing.
What happens to this stack when the enterprise version arrives?+
The tools migrate with translation; the practices migrate cleanly. The skills you wrote, the subagents you tuned, the workflows you codified, the prompts that work for your company's voice, those all transfer to the enterprise version. The MCP servers and memory layer get replaced by the enterprise platform's native equivalents. The investment is not in the specific repos; it is in the institutional knowledge of which workflows actually save PM time. That knowledge lives in the people who built personal versions first.