Company profile · 2 min read
Brief: A decision graph for codebase context
Brief is a memory layer for the decisions behind a codebase.
Published · Updated
Brief is a memory layer for the decisions behind a codebase.
What it does
Brief describes a Product Graph that captures decisions from Linear, Jira, Notion, Slack and GitHub, then makes that context available to developers and agents through an MCP server and CLI. The homepage frames the workflow as capture, connect and navigate: decisions are extracted from the tools where they happen, linked into a graph, and returned when an engineer or agent needs to understand why something exists.
The homepage shows three comparison figures: 95% decision compliance with Brief versus 46% with codebase context alone, 8/8 merge-ready tasks versus 2/8, and 68% lower cost per merge-ready task. The linked company paper describes a controlled benchmark behind those figures: eight tasks, 41 weighted decision points, the same repository, and three runs per task and configuration—48 runs in total. It also says the Brief condition changes product-context retrieval, spec generation, and mid-build consultation together, so the result does not isolate retrieval alone. Those are vendor-authored benchmark results, not independent validation.
Buyer and task
The buyer is a product or engineering team whose agents can read the code but cannot recover the decisions behind it. The first task is not “index everything.” It is one change where the team knows the correct context: a billing rule, an onboarding decision, or a requirement that moved from Slack into a ticket.
The workflow has a useful boundary. Brief can capture and expose context, but the team still needs to decide which decisions remain authoritative, when old decisions expire and who can correct a graph edge that sends an agent in the wrong direction. A searchable memory that preserves stale decisions can make a fast agent confidently wrong.
The first test
Choose representative real tasks with known outcomes. Compare the agent’s answer with and without the relevant decision context. Then change one decision, retire one old decision and deliberately introduce a conflicting source. The acceptance test is whether the team can see which source won, correct it, and keep the correction from becoming another hidden rule.
Sources checked
official Speedrun profile · company homepage · linked benchmark paper
Sources checked — September 20, 2026.
