Every Tool Remembers What Was Asked

Five customers asked for export filtering. The requests sat in the feedback repo, tagged to a roadmap item called "advanced exports." A product manager moved the item into the build queue with a one-line description: add filters to the export view.

An agent picked it up and shipped it the same afternoon. The filters worked. The tests passed. The pull request merged.

It also let any admin export a list that included suspended users — the one thing that export was never supposed to reveal. The constraint had been settled in a compliance conversation months earlier. It lived in the head of a PM who wasn't looking at the ticket that day. It was never written anywhere the agent could read it.

The request was captured everywhere. The decision behind it was captured nowhere.

Every product tool remembers what was asked.

The customer quote. The support ticket. The feature request. The sales note. The churn reason. The roadmap item someone attached to all of it. Feedback repositories, roadmap tools, issue trackers, and research libraries are good at preserving the trail of asks.

That memory is useful. It is also incomplete.

What most tools do not remember is the harder thing: what the team decided, why it decided it, how that decision should constrain the build, and how anyone will know whether it worked.

That gap used to be survivable. A product manager could hold the reasoning in their head. A designer could remember the tradeoff from the review. An engineer could ask in Slack before implementation hardened. Execution was slow enough that missing judgment could be recovered through conversation.

The export PR is what that gap looks like at AI speed. When an agent turns a vague ticket into a pull request in an afternoon, the absence of judgment stops being a documentation problem. It becomes a production problem.

Feedback is not judgment

Feedback tells you what happened.

It tells you what a customer asked for, where a workflow broke, which workaround keeps appearing in support, which feature keeps coming up in sales calls, which metric moved in the wrong direction.

But feedback does not decide what matters.

It does not decide whether the right response is a new feature, a smaller workflow change, a pricing clarification, a removal, a migration, or no change at all. It does not decide which edge case is worth protecting. It does not decide what must not regress. It does not decide what evidence is strong enough to override a preference.

That work is judgment.

And judgment is not a vibe. It is not the loudest customer, the most recent conversation, or the founder's taste wearing better clothes. Judgment is evidence under constraints. It is the reason a team says: given what we know, this is the change that should exist, these are the outcomes that would prove it, these are the boundaries the implementation must respect, and these are the ways it could fail.

Most product systems preserve the inputs and lose the reasoning.

They remember the ask. They forget the decision.

The missing memory is the decision

Go back to that export request. The feedback repository did its job. It recorded that five customers wanted filtering and tied them to a roadmap item. What it had no place to record was what the team had already concluded from the evidence.

That the real problem was enterprise admins rebuilding audit reports by hand. That the outcome worth shipping was "an admin can answer a billing-audit question in under two minutes," not "the export has filters." That exports must never reveal suspended users. That archived workspaces have to stay queryable for compliance but invisible in the default flow.

None of that was contained in the feature request. It was the judgment layered on top of the request — and it was exactly the part the agent never saw.

That judgment is the thing an AI agent needs. Not because the agent is clever enough to replace the team, but because it is fast enough to act on whatever artifact the team gives it. If the artifact contains only a task, the agent optimizes for the task. If it contains evidence-backed intent, constraints, edge cases, health metrics, and verification, the agent has something closer to the team's actual decision.

This is the difference between feedback memory and judgment memory.

Feedback memory says: here is what people asked for.

Judgment memory says: here is what we decided, why, how to build within the decision, and how to know whether the decision held.

None of this is free

Capturing a decision is slower than dropping a ticket in the queue. The whole appeal of the agent is that you hand it one line and get a pull request back by lunch. Asking the team to first state the outcome, the constraints, the edge cases, and what would prove it worked is real work, up front, before anything ships. On a calm week it reads as overhead.

And a written decision rots. The constraint that mattered in March is forgotten by June. The agreed outcome drifts as the product changes around it. A spec no one revisits becomes one more stale doc — true the day it was written, misleading a quarter later.

Both costs are real. Neither is a reason to skip the decision. They are reasons to design for it. The upfront cost is the trade you want: it is cheaper to argue about the constraint before the agent ships than to find it in production. And the rot is the whole reason a decision cannot just be written and filed — it has to stay wired to the build, and to the check that tells you whether it still holds.

The spec is not the output

The obvious trap is to hear this and build a better PRD generator.

That is not enough.

A generated PRD still treats the spec as the deliverable. It writes the document, improves the wording, fills in the headings, maybe adds acceptance criteria, then hands the result to a human system that was already struggling with handoffs.

AI-native work needs a different relationship to the spec.

The spec is not the output. The aligned, verified build is the output. The spec is the checkpoint where judgment becomes executable.

That distinction matters.

If a spec is a document, its job is to communicate. It can be persuasive, polished, and still fail the moment execution interprets it differently.

If a spec is an execution artifact, its job is to constrain action. It has to carry the objective, outcomes, health metrics, constraints, edge cases, evidence, and verification in a shape that both humans and agents can use.

The document version asks, "Does everyone understand the plan?"

The executable version asks, "Can the next actor make the right tradeoff without re-running the meeting?"

That next actor might be an engineer. Increasingly, it might be an AI coding agent.

Either way, the standard has changed.

The path has to reach execution

This is why another roadmap view is not the answer.

The important path is not feedback into backlog into status update. The important path is evidence into intent into execution into verification.

A support ticket becomes a friction signal. The friction signal becomes an evidence-backed outcome. The outcome sits inside an IntentSpec with constraints, edge cases, and health metrics. The agent reads that intent through the tools it already works in. The implementation comes back to the same intent for verification.

Without that path, judgment stays in one place while implementation happens somewhere else. A team has captured the reasoning, but the build system still has to rediscover it.

The goal is not to make builders live in another roadmap.

The goal is to make the judgment behind the work available wherever the work is executed.

Verification is the part that proves it

There is one more reason the spec cannot be the endpoint.

A spec can be excellent and still fail in production.

The export agent failed the easy way: it never had the constraint, so it broke it. But failure does not require a missing constraint. The agent can satisfy every visible requirement and still break the adjacent flow. The tests can pass and still miss the user outcome. The team can ship exactly what it wrote down and still discover that the underlying problem did not move.

That is why verification belongs inside the intent loop, not after it.

Verification is not just a list of tests. It is the answer to a harder question: after the implementation shipped, did the intent hold?

For that, the artifact needs more than acceptance criteria. It needs outcomes that can be observed, health metrics that name what must not degrade, edge cases that describe failure modes, and checks that connect the build back to the reason it exists.

This is the line between a spec generator and an intent layer.

A spec generator produces a document that says what should happen.

An intent layer keeps the decision alive long enough to ask whether it actually happened.

What should be remembered

The next generation of product tools will not win by remembering more inputs.

Inputs are becoming cheap to collect and cheap to summarize. Every transcript, ticket, survey response, call note, analytics event, and Slack thread can be poured into a model. The synthesis gap is closing.

The judgment gap is not.

The scarce artifact is the decision: the structured record of what the team chose to do with the evidence.

That record has to be durable enough for humans to review, precise enough for agents to execute, and testable enough for the team to know whether the work held after shipping.

Every tool remembers what was asked.

The product teams that compound will be the ones that remember what they decided, why, how their agents should build it, and how they will know it worked.