Skip to main content
Early access — Examples use illustrative IDs. Join the Product Brain Community.
The Chain is Product Brain’s core idea: product knowledge connected by relationships. A small Product Brain Chain graph showing a standard governing a work package, a tension resolved by the work package, a decision included in the work package, and an insight informing the decision. Each box is an entry on the Chain. The codes (DEC, TEN, WP, STD, INS) are entry types. The arrows are relationships.

​
The problem

AI agents are powerful, but they usually start work with partial context:
  • The important decision was made three chats ago.
  • The rationale lives in someone’s head.
  • The standard exists in a Markdown file nobody loaded.
  • The product tradeoff is buried in Slack, Linear, Notion, or a meeting note.
The problem is not that there is no context. The problem is that the context looks plausible while it drifts. Different agents get different fragments. A context file says one thing, a recent decision says another, and the agent has no way to know which one still holds.

​
The model in one example

Imagine you are improving mobile onboarding. Without Product Brain, you give the agent the goal, project context, and recent notes, then hope none of that conflicts with a decision that changed last week. With Product Brain, the agent orients from the Chain:
  • WP-42 says onboarding redesign is the current work.
  • TEN-31 says auth breaks on mobile.
  • DEC-89 says user-visible work uses feature flags.
  • STD-12 says API changes require review.
  • INS-7 says 60% of users drop at step 3.
Those are not separate notes. They are connected entries. The Chain answers questions like:
  • What are we trying to achieve?
  • What did we already decide?
  • What constraints must not be broken?
  • What tensions are still unresolved?
  • Which context is still current?

​
Why connections matter

Memory systems can store what you decided. The Chain stores why. A decision on the Chain is not just a note. It can be connected to the tension that triggered it, the insight that informed it, the standard it created, the work package it serves, and the later tension that challenges it. That ancestry is what lets an agent answer “should I change this?” instead of only “what is this?” Without the connections, an agent knows the fact. With them, it knows the reasoning. Reasoning is what prevents an agent from confidently undoing a decision that was made for a reason it cannot see. This is what decision ancestry looks like in the graph above: STD-12 governs WP-42. TEN-31 is resolved by WP-42. INS-7 informs DEC-89. Remove any connection and the agent loses context it can never reconstruct after the Slack thread scrolls away or the meeting note gets buried.

​
How work flows

  1. Orient before meaningful work.
  2. Work with the relevant Chain context loaded.
  3. Capture durable decisions, tensions, and insights as they appear.
  4. Close the session so the next person or agent starts grounded.
This is why Product Brain is different from a wiki. A wiki stores pages. The Chain stores governed product knowledge in a form agents can use during work.

​
Why this matters

Solo builders and product teams do not just need more notes. They need continuity. Continuity means an AI agent can understand the current work package, the product standards, the decision history, and the open tensions without asking someone to rebuild the story from scratch. That is the aha moment: Product Brain is not where you write docs for humans to browse. It is where you make product knowledge usable by every future AI-assisted workflow.

​
Next