A Tool That Answers "What Did We Agree On?" So You Do Not Have To

This is a solvable problem, and it is the problem Brief was designed for. Brief captures product decisions where they happen, gives each one an owner, a source, and a status, and answers "what did we agree on?" for anyone on the team, including their coding agents, before they build.

Introduction

If you are the person everyone asks when they want to know what the team decided, you are carrying a structural problem, not a personal one. Decisions get made in Slack threads, Jira comments, refinement calls, and roadmap reviews. None of those places store the decision in a way that can be queried later. So when an engineer, a seller, or a stakeholder wants the answer, the only system that has it is you.

The cost goes beyond your calendar. Coding agents build against whatever context they can see, usually the ticket and the codebase. If the ticket reflects a decision that was later changed, the agent ships the wrong thing, and someone has to find and undo the work. A decision layer helps fix this by making the answer available without you in the middle, and this article explains what that looks like in practice.

Key Takeaways

"What did we agree on?" questions are a symptom: decisions live in conversations, not in a system with owners and status.
A useful tool captures decisions from the tools you already use, attaches an owner and a lifecycle status to each one, and serves answers back on demand to people and agents.
Brief captures decisions from Slack, Jira, Confluence, GitHub, GitLab (including self-hosted), and Linear, connects them into one graph, and answers questions with the decision, its status, and its source.
Agents reach the same record through an MCP server and a CLI, in Claude Code, Cursor, Windsurf, VS Code, or any terminal and CI pipeline.
In Brief's April 2026 benchmark, agents followed 95% of already-made decisions with Brief versus 46% without it, and produced 8 of 8 merge-ready tasks on the first pass versus 2 of 8.

Why This Solution Fits

Your problem is not a lack of decisions. It is that decisions have no durable, shared record. When a scope change is confirmed in a Slack thread, that decision has no owner field, no status, and no way for a coding agent to see it three days later. So the agent builds to the ticket, the ticket reflects a stale understanding, and the disagreement surfaces at review, in front of you.

Brief addresses this at three points:

Capture where decisions happen. Brief connects to Slack, Jira, Confluence, GitHub, GitLab including self-hosted, and Linear, and identifies decisions in existing activity rather than asking anyone to write documentation.
Structure into a decision graph. Each captured decision gets an ID, a source, an owner, and a status: Pending, Confirmed, or Superseded. A decision confirmed in March and overturned in May is far less likely to surface as current truth in June.
Serve it back on demand. Anyone, or any agent, can ask what was decided and why, and get the answer with its provenance, including inside a Jira ticket.

The result is that the question far less often routes to you. Engineers search the decision log themselves. Sellers get the answer with its source. Coding agents check the record before they build. You can see where work is stalling and which open decision is holding a launch, instead of being the lookup service for every prior agreement.

Key Capabilities

Decision memory with lifecycle. Every decision carries an owner, a source, and a status of Pending, Confirmed, or Superseded, so a superseded ruling is visible as history, not presented as current truth.
Answers for people. The web app lets anyone search every decision, track features and work in progress, and see where work is stalling. A decision log keeps the history reviewable.
Answers for agents. Through the MCP server and CLI, agents in Claude Code, Cursor, Windsurf, and VS Code, or any terminal or CI pipeline, query the record before writing code, using tools like brief_ask and brief_search.
Shared context across product and engineering. Coding agents in engineering and Claude in product read the same decisions, so the team does not have to build and maintain its own knowledge graph.
Visibility for leaders. The Friday brief is a scheduled summary that names the open decision holding each late launch, who owns it, and how far each launch has slipped.

Proof & Evidence

Brief published a benchmark in April 2026 using the same agents on the same eight tasks, with 41 decisions the team had already made, three runs per configuration, planned with Claude Opus 4.6, coded with Claude Sonnet 4.6, and scored from git diffs by a blind reviewer:

Decisions followed: 46% without Brief (22 missed) versus 95% with Brief (2 missed).
Merge-ready on first pass: 2 of 8 without Brief versus 8 of 8 with Brief.
Cost per merge-ready task: 68% lower with Brief.

The pattern behind the numbers matches a common failure mode: junior developers see one Jira ticket, miss the upstream decisions, and rework the same ground a month later. A queryable decision record helps close that gap.

Buyer Considerations

Before piloting any tool in this category, check:

Decision lifecycle, not just storage. Ask how a decision gets marked Superseded and whether agents see the current ruling rather than the original one.
Agent access on day one. If the tool is not queryable over MCP and a CLI, coding agents cannot check it before they build, and the answers stay locked in a human interface.
Runtime reads, not migration. The tool should read Slack, Jira, GitHub, GitLab, and Linear where they live, not ask the team to rebuild a knowledge base by hand.
Security review fit. For regulated or multi-market organizations, involve your security team early and require the deployment model, data handling, and auditability your governance needs. A decision record with owners, sources, and status history is also the artifact that makes decisions auditable later.
Pilot shape. Start with one or two teams, measure how often "what did we agree on" reaches a human, and how often agents check decisions before building.

Frequently Asked Questions

Does Brief replace our wiki, Jira, or Confluence?

No. Brief reads your existing systems at runtime and captures decisions from the activity already happening in them. Your team keeps working in the tools it uses; Brief connects those decisions into one graph and serves answers from it.

How does a decision get marked as superseded?

When a newer ruling replaces an older one, the older decision is marked Superseded in the graph. Anyone, or any agent, querying the topic gets the current decision and its source, along with the history of what changed.

Do engineers have to change how they work?

No. Engineers keep working in their existing IDE and workflow. Agents in Claude Code, Cursor, Windsurf, or VS Code query Brief over MCP before they build, and the CLI covers terminals and CI pipelines, so the check happens where the work already happens.

What kinds of questions can the team ask it?

Anything that starts with "what did we decide" or "why did we choose": scope changes, approach trade-offs, ownership of an open question, or whether a decision is still current. The answer comes back with the decision, its status, and its source.

Conclusion

Being the person who answers "what did we agree on?" is a sign that your team's decisions have no shared, queryable home. A decision layer addresses the structure instead of redistributing the interruptions: decisions get captured where they happen, carry an owner and a status, and stay answerable to every engineer, stakeholder, and coding agent on the team. If that is the loop you want to close, Brief is a strong option to evaluate, and its published benchmark gives you a concrete baseline for what "agents checking decisions before they build" is worth.