Product Graph and agent memory: why AI can't save a product that lacks structured knowledge

AI agents can already write code, update tickets and assemble PRs, but that doesn't solve the basic problem of most product teams: the memory of the product is still stored in pieces. As long as decisions, research and constraints are scattered across meetings, chats and employees' heads, automation will speed up confusion, not understanding.

Where context gets lost

As a product grows, companies almost inevitably split it among separate teams. Each gets its own backlog, its own metrics and its own part of the user journey. From the outside, this looks rational: fewer dependencies, more autonomy, faster local decisions.

But autonomy brings fragmentation of knowledge. One team remembers why onboarding was changed, another knows which constraints exist in billing, a third knows that users don't understand the current access-rights model. As a result, the coherent picture of the product breaks into local versions of reality.

The problem isn't just poor documentation. Even if a team carefully maintains PRDs, research notes and decision records, they remain a set of separate artifacts. Notion, Confluence, Jira and Google Docs store fragments well, but do almost nothing to help see the links between them. A document records a fact, but doesn't create understanding on its own.

So companies often fall into a repeating cycle: they re-argue old questions, repeat research that has already been done and make decisions without accounting for earlier constraints.

Why agents don't save the day

Against this backdrop, the temptation to hand part of the work to agents looks logical. A model can read a task, open a repository, propose code, update a ticket and generate a convincing result in minutes.

But the agent works inside the same information environment as the team. If past decisions are not recorded anywhere, it won't take them into account. If an important study is buried in an old presentation, the agent won't know about it. If the strategy exists only in a manager's head, the agent will optimize execution, not meaning.

AI doesn't necessarily reduce chaos.

Sometimes it just increases its throughput.

This is where the author introduces the idea of meta-work. It isn't bureaucracy for bureaucracy's sake, but a layer of actions that turns scattered events into a knowledge system. Someone has to connect new research to an old insight, record which data a requirement is based on, and show where two teams are already moving in different directions. For agents, this may even be a more useful role than writing code from scratch: not replacing product work, but maintaining collective memory and bringing back into context everything the team manages to forget.

Why a Product Graph is needed

As an alternative to the familiar task-first approach, the author proposes Product Graph. It is not a new task tracker but a model in which the main object is not a card on a board but connected knowledge. In such a system, a task matters not on its own but as a link in a chain: signal source, insight, decision, requirement, implementation and result. If the chain isn't broken, the team can at any moment trace back from a release to the reason the work appeared in the first place.

This approach rests on several practical principles:

• every task must have a clear source: a user signal, a metric, research or a strategic bet
• a decision must exist as a separate object, with alternatives, arguments and conditions for revisiting it
• new results must return to the system and refine old conclusions, not vanish after release
• contradictions between strategy, UX, research and technical constraints must become visible as early as possible

If Product Graph really works, the agent receives not just a ticket but a map of causes and consequences. It can then do more than execute: it can check coherence, surface forgotten research, find conflicting assumptions, remind the team of unresolved hypotheses and help it learn from its own results. In this model, AI is not a machine for closing tasks but a participant in product memory.

What this means

The article's main point is simple: AI is useful where a team already has a knowledge structure to which automation can be attached. Without that structure, the speed of agents merely scales the old problem faster: organizational amnesia.

So the next step for AI-first teams is not only to deploy agents, but to build a system in which decisions, research, requirements and results are linked to one another.