Product Graph (VibeGraph)by VibeLevel
Research preview β€” Product Graph is evolving fast; expect changes. Share feedback
All agents and humans, together across the enterprise

Make your agents smarter across your products, skills, standards.

Product Graph (VibeGraph) is the living graph for AI-native teams. It tracks the relationships that matter across enterprise products, features, skills, and standards so agents can collaborate with other agents, developers can work with better context, and product teams can understand impact across upstream and downstream systems.

Smarter agents with enterprise product and skill context
Cross-product impact visible before changes spread
Autonomous build-and-test workflows with governance built in

Example

Agents build using skills and standards, then propose changes for PM to approve

How agents and humans work together:

  1. 1.Agents connect to the graph via MCP and read approved skills and standards.
  2. 2.Agents build product features using those shared skills and standards.
  3. 3.After building, agents propose structured changes back to the graph.
  4. 4.PM reviews the diff, approves what becomes canonical, and the graph updates.

Why Product Graph

Agents lack shared product knowledge

When agents build features, they need to know your product's structure, approved patterns, and business rules. Without a shared source of truth, every agent session starts from scratchβ€”asking you to explain the same context over and over.

πŸ”„

Repetitive context

You explain the same architecture, standards, and patterns to every agent in every chat session.

🚫

Inconsistent knowledge

Different agents (Claude, Copilot, Perplexity) build features using different interpretations of your product.

πŸ“š

Stale documentation

Manual docs fall behind as products evolve. Teams waste time updating Confluence, Notion, and wikis.

What breaks as teams scale with agents

The operational cost of drift shows up before the product does.

Product knowledge goes stale fast.

Features ship, behavior changes, and docs fall behind.

Skills and standards get scattered.

Every repo, product, and team ends up with its own version.

Agent output moves fast, but governance does not.

Teams need speed without losing approvals, traceability, or control.

Benefits

Why this matters for every part of the team.

Benefits for agents

Agents become smarter because they can reuse enterprise skills and standards, cross-reference connected products, and coordinate with other agents using the same approved graph.

Benefits for developers

Developers stop rebuilding context repo by repo. Their agents can build and test with shared standards, product links, and system dependencies already in view.

Benefits for product teams

PMs, TPMs, and business users can understand capabilities across the enterprise and generate product guides or technical guides from current approved relationships.

Blast radius and impact analysis

Agents can trace upstream and downstream systems before a change ships, so cross-product dependencies and likely impact are visible earlier.

Governance with humans in the loop

Agents can move faster, but humans still control what becomes canonical through approvals, provenance, and reviewable changes.

Self-updating graph

As developers and agents work, the graph stays current automatically, reducing manual maintenance while preserving a shared enterprise knowledge layer.

Before Product Graph
Stale docs
Orphaned wikis
Repeated skills.md files
Standards buried in repos
Agent instructions that drift by team
After Product Graph
One living graph
Shared enterprise standards
Auto-synced agent skills via MCP
Clear approval workflow
Full provenance for every change

Who it's for

One graph for every persona shaping the product

Product Graph is built for AI-native enterprises where product, engineering, platform, and business teams all need to work from the same shared context β€” whether they're shipping code, running agents, or reviewing roadmaps.

Product and TPM teams

Keep features, requirements, dependencies, and standards aligned as the roadmap changes.

Engineering teams

Reuse shared skills and standards instead of recreating them in every repo, service, or workflow.

Platform and AI teams

Distribute approved coding and non-coding agent skills through MCP at enterprise scale.

Business and leadership

Get visibility, consistency, and provenance without slowing teams down.

Coding agents and developers

Use the graph to reuse skills, follow standards, and understand upstream and downstream dependencies so agents can build and test before shipping changes.

Non-coding agents and business users

Use the same graph to generate product guides, technical guides, and dependency views without reverse-engineering repos.

Enterprise teams across products

Bring product, platform, and AI teams into one relationship layer for collaboration, impact analysis, and governance.

How it works

Built for the Agentic Era

The workflow stays familiar for teams, but the relationship layer underneath becomes structured, shareable, governable, and useful for autonomous build-and-test decisions.

1

Connect your agent

Add the Product Graph MCP server to your agent, pointed at your workspace. One token, one config block.

{
  "mcpServers": {
    "product-graph-my-app": {
      "type": "http",
      "url": "https://graphapi.vibelevel.ai/mcp?workspace=my-app"
    }
  }
}

Works with Claude Code Β· Cursor Β· Windsurf Β· any MCP client.

2

Seed your graph

Open your product repo in the agent and ask it to scan the codebase. It proposes the initial graph β€” features, skills, and standards.

"Scan this project and create a product graph for workspace my-app."
3

Use it and keep it in sync

Agents read approved skills and standards over MCP as they build, then propose updates at the end of each session.

"Update the product graph in my-app with the changes from this session."
4

Humans stay in control

Proposals land in the Pending tab. Review the structured diff and one-click approve β€” only approved changes become canonical, with full provenance.

Examples

Ask the graph about work, not just context.

Because the graph links products, features, skills, standards, and dependent systems, teams can ask for impact analysis, product guides, technical guidance, and build-test plans directly from their agents.

"Show the upstream and downstream products, features, and standards affected by this change."
"What should the agent build and test across upstream and downstream systems before this change ships?"
"Create a technical guide for this product using the approved features, dependencies, and standards in the graph."
"Create a business-facing product guide that explains how this capability connects across products and teams."

Use cases

How teams use Product Graph in practice

Use cases from solo builders to enterprise teams, with the same human-review workflow and MCP-enabled agent collaboration.

Solo developer / personal project

Keep a living map of your own product that never goes stale.

  • β€’Your coding agent scans your repo and seeds the graph.
  • β€’At the end of each session it proposes updates and you approve.
  • β€’Use it as context so the agent builds consistently with what exists.
Get started

Small team - shared private workspace

One graph the whole team co-maintains, kept private.

  • β€’Create an org workspace and add teammates as members.
  • β€’Everyone can propose changes and members approve them.
  • β€’Nobody outside the team can see it.
How workspaces work

Public product - readable by your users

Publish your product graph so others can build on it.

  • β€’Anyone can browse it on the web with no login.
  • β€’Any AI agent can read it via MCP to integrate with your product.
  • β€’Only members can propose changes, so publishing never exposes editing.
Browse the catalog

Open source / community

Share publicly and accept contributions safely.

  • β€’Publish so the community can consume your graph.
  • β€’Add trusted contributors so they can propose changes.
  • β€’Maintainers review and approve every proposal before it goes live.
Read the docs

Blast radius

See upstream and downstream impact before the change ships.

When the graph connects products, features, skills, and standards, agents and humans can trace what will be affected, where it flows next, and what needs to be tested before rollout.

1

Map dependencies

Before making a change, see what upstream systems feed into it and what downstream products depend on it.

2

Assess impact

Understand which products, features, skills, and standards are affected by the proposed change.

3

Plan testing

Let agents use the same dependency context to automatically plan build-and-test workflows.

Example

MyApp depends on Upstream and impacts Downstream. Risk Skill analyzes the change. The app must follow the Test Policy standard β€” ensuring safe rollouts.

Governance

Humans stay in the loop while agents keep moving.

Agents and developers can propose updates, but PMs, product owners, and leads still approve what becomes canonical. That keeps the graph fast, reviewable, and governed.

1

Agent proposes

Your coding agent (or a dev) proposes a graph change via MCP β€” a new feature, updated skill, changed standard.

2

Lead reviews

The diff appears in the pending queue. Reviewer sees exactly what changed, what it connects to, and why.

3

Approver signs off

One click to approve. The change goes live with a full provenance trail β€” who proposed it, who approved it.

Example

An agent proposed adding Dark Mode to MyApp, flagged pending. PM reviews the diff and approves it. The feature must follow the A11y standard β€” enforced automatically.

Stop maintaining documentation that agents outgrow in days.

Bring product relationships, agent skills, and standards into one living graph your whole team can trust.