Execution is becoming abundant. Coding agents, review agents, triage agents, planning agents — the coordination layer is racing to plug them in. The bottleneck is shifting.

When execution is cheap, the scarce input is intent: a clear, evidence-backed answer to what the agents should build, and why.

Intent is a team's working belief about what should be true for a user. It holds evidence, names outcomes, declares constraints, and defines how success will be checked. It is the standard work is measured against.

Compare an observation to its standard. An issue says "checkout fails for users on Safari." An intent says "any user with a saved payment method should complete checkout without error; we're optimizing for completion rate over upsell, and we'll accept a slower path for users without a saved method." The issue is one observation. The intent is the line that observation crossed.

You can pile up ten thousand issues. They will not, in aggregate, become an intent. Aggregation is not compilation.

Agents make the difference operational. A coding agent handed an issue executes against the symptom. A coding agent handed an intent executes against the standard. Both are useful work. They are not the same work. The first ships a patch and closes a ticket. The second asks whether the patch defends the standard, whether a trade-off the team said it wouldn't make is being made, and whether an edge case the intent already named is being violated.

The raw layer — notes, threads, tickets, transcripts — is necessary. It is not the product. The compiled layer is the small set of beliefs you actually build against. Issues are raw. Intent is compiled.

Intent is an artifact, not a status.

The work of compiling is where the leverage lives, and it is not fully delegable to agents. They can read the raw, suggest the shape, summarize the threads. They cannot decide what the team is willing to defend. Someone has to make that call and write it down, so the rest of the system has something to check itself against.

Three questions a product-building system should be able to answer about any shipped feature:

What evidence drove this? Specific quotes, observations, metrics — not "the team decided."
What were we willing to trade off? Constraints, named.
Where does the code disagree with what we said? A list of drifts.

A system organized around issues can answer the first weakly. The second is rarely written down. The third is structurally outside its frame — issues do not hold beliefs, and code cannot be reconciled against a system that does not hold any.

A system organized around intent answers all three by construction. Evidence anchors to outcomes. Constraints sit next to objectives. Spec and code are reconciled as a first-class operation.

Issue trackers are not going away. Teams need a place to track work, and work will keep arriving as issues and tickets and threads. But the moment agents enter the loop, the layer above the issue stops being implicit. Agents work better with explicit intent than implicit intent.

The next generation of product systems will be defined by what feeds the agents underneath — a clean intent layer that holds beliefs, not just observations.