State Estimate

A backlog is a measurement. A roadmap is a claim. Neither is the state of the system. A product agent needs a live estimate of what work is actually considered, committed, in flight, shipped, or retired.

August 27, 2026 9 min read

A product agent looks at a backlog with 183 items and says the roadmap is full. Then an engineer points out that half of it is abandoned, three items shipped already, one has been split into four pull requests, and the thing the customer is actually waiting on changed shape in review. The agent was not dumb. It was looking at measurements and mistaking them for state.

That mistake is everywhere in product work. A Linear issue is a measurement. A pull request is a measurement. A Notion task, a Jira ticket, a GitHub branch, and a project status are all measurements. They are not, by themselves, the state of the product system. The state is the thing a product agent actually needs before it recommends anything: what is being considered, what is committed, what is building, what shipped, and what quietly stopped being real.

A product agent cannot act on a sensor reading

The simplest failure case is a recommendation that ignores work already in motion. Ask an agent what to build for enterprise onboarding, and it may propose a new onboarding checklist because the idea appears in three docs and two customer calls. That sounds reasonable until the team remembers a related Linear project is already halfway built, the design changed last week, and the remaining constraint is not "should we build it?" but "which edge cases are still blocking release?"

The agent did not need a better brainstorm. It needed state.

This is the difference between a list of observations and a model of the system those observations point at. The backlog says something exists. The pull request says someone touched code. The merged commit says something crossed one boundary. The shipped flag says it crossed another. The stale ticket says nothing unless you know whether stale means waiting on someone, abandoned, or already completed somewhere else. Treating each record independently turns the product world into a pile of facts with no dynamics. A product agent can summarize that pile, but it cannot reason from it safely.

The hard part is not gathering more records. It is deciding which records describe the same piece of work, which stage that work is actually in, and whether the apparent activity changes the product state or merely repeats something already known.

Where this gets its shape

Control systems have a useful word for this: state. In a dynamic system, the state is the information you would need now to predict what the system can do next. In 1960, R. E. Kalman published "A New Approach to Linear Filtering and Prediction Problems", the paper behind the Kalman filter. The product lesson is not that roadmap planning needs a Kalman filter. It does not. The useful distinction is simpler: a system's internal state is usually not handed to you directly. You infer it from imperfect measurements, update it as new measurements arrive, and keep the estimate coherent enough that control decisions are not made off noise.

Product work has the same shape, even if the math is not the same. The tools give you measurements: issue status, branch names, review events, linked docs, assignees, timestamps, comments, project fields. None of them alone tells you the true state of the work. A ticket can say "in progress" while the branch is abandoned. A pull request can be merged while the customer-facing feature is still behind a flag. A roadmap item can stay "planned" after the team has already narrowed the problem and shipped the first slice. The state has to be reconstructed from the measurements.

That reconstruction is where a product agent either becomes useful or starts hallucinating confidence. Without a state estimate, it does not know whether it is recommending a new initiative, duplicating an active one, reopening a closed one, or contradicting the constraint that is actually shaping the team's next move.

Why Work Agent is not just a list of tickets

This is the substrate behind Brief's Work Agent. Source adapters for Linear, GitHub, GitLab, Asana, Jira, and Notion persist normalized work rows into the canonical work_items table. In the product itself, Work Agent is intentionally deterministic: the current architecture reads those canonical rows and projects them through a code path rather than asking an LLM to re-copy thousands of records. That is a technical detail, but it matters because the job is not creative synthesis. The job is to keep the state substrate faithful.

The canonical row is the important part. It gives downstream agents one place to ask the boring but load-bearing questions: what is this work item, where did it come from, what stage is it in, when was it committed, when did it start, when did it complete, and what source URL or cross-source identity anchors it back to reality. Once that exists, other agents can reason against the same state instead of each rebuilding its own private version of the world.

That is why Work Agent sits beneath so many higher-level product judgments. Velocity Agent needs shipped and timestamped work to measure delivery from activity rather than estimates. Feature Agent needs work items so it does not propose a feature detached from what the team is already building. Decisions Agent can treat committed, shipped, or deprecated work as evidence that a decision has happened, not just that someone discussed one. Strategy and CPO-style synthesis need the same substrate for a more basic reason: a strategic recommendation that ignores actual work in flight is not strategic. It is fan fiction with a backlog export.

The estimate has to be live

The failure mode is not only missing data. It is stale data.

A work-state estimate that was correct last Friday can be wrong by Monday afternoon. A customer escalation moved one item from "considering" to "committed." A review changed the remaining path for another. A bug fix shipped and made a roadmap item obsolete. A project got renamed, so the same work now appears under two labels. If a product agent reads the old state, it will make recommendations that are internally logical and operationally wrong.

That is why work ingestion has to be a background process rather than a one-time import. The source-adapter path writes current work into the canonical table and uses change gates so repeated runs do not pretend unchanged rows are new state. Work Agent then reads that canonical state and projects it forward for the rest of the agent system. A good product agent does not need every raw event every time it thinks. It needs the latest coherent state, with enough provenance to trace the estimate back to the measurements that produced it.

This also explains why "just let the product agent query Linear" is not enough. Querying a tracker gives it one measurement surface. Product state lives across trackers, repositories, documents, and source-specific conventions. It needs normalization, identity, stage mapping, and freshness. Without those, the product agent is not reading the work state. It is reading whichever sensor happened to answer first.

What Work Agent cannot decide

The honest limit is that a work-state estimate is still not a product strategy. Knowing that something is committed does not prove it should have been committed. Knowing that a feature shipped does not prove it mattered. And in the current substrate, blocked work is not preserved as its own first-class state, so a product agent still needs surrounding evidence before it can say whether to unblock something, cancel it, or change the goal around it.

That judgment belongs to the layers above it and, ultimately, to the team. Work Agent gives the product agent the current state of execution. It does not decide the value of that execution. In fact, that is exactly why it is useful: it separates the factual substrate from the strategic call. Once a product agent can see what is actually moving, it can stop wasting intelligence on reconstructing reality and spend it on the question a product team actually needs answered.

If your product agent recommended the next thing to build today, would it know what your team is already building, or would it be reasoning from a pile of measurements and calling it context?

Frequently asked questions

What is a state estimate in product work? A state estimate is the reconstructed view of what is actually true about work right now: what is being considered, committed, building, shipped, or deprecated. It is inferred from measurements such as tickets, pull requests, docs, timestamps, and source statuses, but it is not identical to any one of those records.

Why does a product agent need Work Agent? Because a product agent cannot safely recommend, prioritize, or explain work without knowing the current execution state. The source-adapter path keeps the canonical work_items substrate current from tools like Linear, GitHub, GitLab, Asana, Jira, and Notion, and Work Agent projects that normalized work state so higher-level agents do not reason from disconnected tracker snapshots.

Is Work Agent an LLM that reads my backlog and summarizes it? Not in the current Brief architecture. Work ingestion lands normalized rows in work_items, and the Work Agent path deterministically projects those rows rather than asking a model to creatively reinterpret them. That is the right shape for this job because the point is faithful state, not new judgment.

What does Work Agent not solve? It does not decide whether the work is valuable, whether a shipped feature mattered, or whether a stalled item should be unblocked. The current substrate also does not preserve blocked work as its own first-class state. Work Agent gives the product agent the execution state those judgments have to start from; strategy still requires judgment.