PMPilot

Inspiration

Product managers rarely struggle because information is unavailable. They struggle because information is fragmented.

A typical product decision can involve a Figma flow, a Notion PRD, Linear tickets, Slack conversations, customer feedback, analytics, and competitor research—all spread across browser tabs. Connecting those sources manually is slow, and asking a generic AI assistant to synthesize them often produces confident answers without sufficient evidence.

We wanted to build an AI Associate PM that works where PMs already work: inside the browser.

PMPilot was inspired by a simple question:

What if every AI-generated product decision came with its evidence, uncertainty, contradictions, and next executable action?

That led us to build PMPilot around an evidence-first workflow rather than a text-generation-first workflow.

What it does

PMPilot turns browser context into evidence-backed product decisions.

A PM can capture context from Figma, Notion, Linear, competitor websites, and other product surfaces. PMPilot sanitizes the information, identifies what is actually known, and classifies every important claim as OBSERVED, INFERRED, ASSUMED, or UNKNOWN/VALIDATE.

From there, a multi-agent system:

Extracts and normalizes product requirements. Cross-references information across multiple sources. Detects contradictions before sprint planning. Researches competitors and market patterns using Exa. Builds an interactive Evidence Graph with source-level provenance. Generates evidence-backed PRDs and user stories. Converts validated requirements into executable Linear/Jira/GitHub tickets. Runs longer workflows asynchronously through Trigger.dev. Maintains working context and decision history through Redis. Provides Copilot actions such as “Shrink to 2-week MVP,” “Challenge decision,” and “Resolve contradiction.” The core principle is simple:

No important recommendation should appear without showing where it came from and how certain it is.

How we built it

PMPilot is built as a browser-native multi-agent product workflow.

The Chrome extension captures relevant browser context, while a CopilotKit overlay provides the interactive Associate PM experience.

The architecture is divided into several layers:

Context & Trust Layer Mozilla.ai-inspired processing sanitizes browser content, removes irrelevant boilerplate, and separates observed facts from inference and assumptions.

Agent Layer The OpenAI Agents SDK orchestrates specialized agents:

Context Agent Requirements Agent Research Agent Product Strategist Delivery Agent The Product Strategist acts as the contradiction gatekeeper, preventing conflicting requirements from silently propagating into the final PRD.

Research Layer Exa performs real-time competitor and market research, allowing PMPilot to compare products, discover UX patterns, and identify market gaps.

Memory & Workflow Layer Redis stores active tab state, working memory, sessions, and decision history. Trigger.dev handles longer-running workflows such as PRD generation, sprint planning, and competitor scanning.

Delivery Layer CopilotKit powers the UI and action experience, while integrations with Linear, Slack, Jira, GitHub, calendars, and document platforms turn decisions into actual work.

We also added an OpenRouter-based fallback layer and local simulation modes so the product remains usable even when external APIs or credentials aren't available.

Challenges we ran into

The hardest problem wasn't generating text—it was knowing when the model should not trust its own answer.

Browser context is messy. Pages contain navigation, advertisements, duplicated content, tracking elements, dynamic UI, and information that may be irrelevant to the product decision.

We therefore had to design around several difficult cases:

Distinguishing useful product context from browser noise. Preserving provenance while transforming raw DOM content. Handling contradictory requirements across Figma, Notion, and Linear. Preventing inferred requirements from being presented as facts. Making asynchronous agent workflows feel responsive. Maintaining useful behavior when APIs or credentials are unavailable. Preserving partial progress instead of showing a blank failure state. This led to our epistemic contract: PMPilot explicitly communicates whether something was observed, inferred, assumed, or still needs validation.

Accomplishments that we're proud of

The hardest problem wasn't generating text—it was knowing when the model should not trust its own answer.

Browser context is messy. Pages contain navigation, advertisements, duplicated content, tracking elements, dynamic UI, and information that may be irrelevant to the product decision.

We therefore had to design around several difficult cases:

Distinguishing useful product context from browser noise. Preserving provenance while transforming raw DOM content. Handling contradictory requirements across Figma, Notion, and Linear. Preventing inferred requirements from being presented as facts. Making asynchronous agent workflows feel responsive. Maintaining useful behavior when APIs or credentials are unavailable. Preserving partial progress instead of showing a blank failure state. This led to our epistemic contract: PMPilot explicitly communicates whether something was observed, inferred, assumed, or still needs validation.

What we learned

We learned that an AI product assistant becomes much more useful when it knows the difference between “I found this” and “I think this.”

We also learned that product management is fundamentally a synthesis problem. The valuable output isn't a beautifully written PRD—it is the chain of reasoning connecting customer evidence, product requirements, design decisions, technical constraints, market, unavailable APIs, and uncertain requirements shouldn't break the workflow. They should become explicit states that context, and an executable plan.

Another important lesson was that failure states are part of the AI experience. Missing context, conflicting sources, unavailable APIs, and uncertain requirements shouldn't break the workflow. They should become explicit states that guide the PM toward the next action.

That's why PMPilot doesn't try to hide uncertainty.

It makes uncertainty actionable.

What's next for PMPilot

The next step is making PMPilot a persistent AI product teammate rather than a browser tool used only when prompted.

We're exploring:

Deeper integrations with Linear, Jira, GitHub, Slack, Teams, Notion, and customer-support platforms. Persistent product decision memory across projects and sprints. Automatic detection of requirement drift between PRDs, designs, tickets, and shipped functionality. Continuous competitor monitoring and market-change alerts. Richer Figma and analytics understanding. Automated user-research scheduling and synthesis. Collaborative Decision Rooms with real-time stakeholder voting. Mobile decision cards for quick asynchronous approvals. Autonomous browser workflows with visual execution traces. Stronger evaluation and verification systems for measuring evidence quality and agent reliability. Ultimately, we want PMPilot to close the loop:

Observe → Research → Challenge → Decide → Validate → Execute → Learn.

The goal isn't to replace the Product Manager.

It's to give every PM an Associate PM who never loses the context behind a decision.

Built With

• authentication:
• chrome-extension-apis
• exa
• figma
• for-the-technology-section
• github
• google-calendar
• gpt-4o
• i'd-enter:-languages-/-frameworks:-typescript
• intercom
• javascript
• jira
• manifest-v3-ai-/-agents:-openai-agents-sdk
• microsoft-outlook
• mozilla.ai-agent-ui-/-infrastructure:-copilotkit
• node.js
• notion
• openrouter
• react
• redis-integrations:-linear
• slack
• trigger.dev
• zendesk