The intent engineering framework for agent-ready product specs.
Follow the framework from user evidence to product judgment, an eight-part IntentSpec, and verification an AI coding agent can act on.
Intent is judgment under evidence, not a contract you compile.
87.7% of product teams use AI coding assistants. Only 36.1% say it strengthened how they actually work. The tools changed. The work didn’t.
Product Circle, State of AI in Product 2026 (309 product leaders)
From user evidence to an agent-ready IntentSpec
Private evidence becomes a repository-safe decision your coding agent can act on.
Raw friction on the left becomes an agent-ready spec on the right: every requirement explicit, measurable, and verifiable.
Evidence
“I gave up making an account. It asked for my address line by line and I bailed.”
35% of users abandon onboarding at step 3 (address entry). ~200 signups/week lost.
In 6 of 8 usability tests, users paused or sighed at the six-field address form.
IntentSpec
# Objective
Users abandon onboarding at the address step because the form needs 6 fields. ~200 signups/week lost.
# Outcomes
Address entry collapses to one type-ahead field. Step-3 drop-off falls ≥40%. Selecting a suggestion completes the step in <90s.
# Constraints
Do not touch the OAuth provider. Keep PCI scope unchanged.
# Edge cases
Geocoder down → fall back to the manual form. Unsupported region → clear message. PO boxes still enterable.
# Health metrics
Steps 1–2 completion does not drop. Address-validation accuracy holds.
# Verification
Integration test: geocode 5 sample addresses. Fallback test on API 500. p95 < 300ms.
Two definitions of intent engineering
Search the term today and you find two. They point teams in opposite directions.
The prevailing view
Intent as a contract.
Write a precise, machine-readable spec: an INTENT.md, a contract the agent compiles into code. The goal is fidelity: the agent builds exactly what the spec says.
The product-layer view
Intent as judgment under evidence.
A contract tells an agent what to do. It says nothing about whether you should be doing it. Intent engineering captures the judgment (which problem, on what evidence, with which trade-offs), then carries it into the build.
Precision without judgment just lets you build the wrong thing faster.
Prompt vs context vs spec-driven vs intent engineering
| Prompt engineering | Context engineering | Spec-driven dev | Intent engineering | |
|---|---|---|---|---|
| Operates on | A single model turn | The agent’s inputs | The spec’s precision | The product decision |
| Answers | How to ask | What the agent sees | How exact is the spec | What is worth building, and why |
| Basis for each claim | ✗ | ✗ | ~ | Backed / Unreviewed / Assumption / No evidence |
| Defines success | ✗ | ✗ | ~ Implicitly | ✓ Measurable outcomes |
| Mental model | Better question | Better inputs | Tighter contract | Better problem definition |
You need all four. But prompt, context, and spec-driven work all assume someone already decided what to build and how you’ll know it worked. Context isn’t judgment. Intent engineering is where that decision is made, and made explicit enough to delegate.
Going deeper on the prompt/context split? Read Intent Engineering vs Context Engineering →
The eight parts of an IntentSpec
If an agent would still need to ask a clarifying question, the spec isn’t done yet.
Objective
The user problem and why it matters, with the evidence behind it visible.
Outcomes
Observable, measurable state changes. Each verifiable by a test or metric.
Evidence
Each claim shows whether reviewed evidence backs it, and who judged it.
Constraints
Hard boundaries the implementation must respect. What the agent must not do.
Scope
What to touch, and what to leave alone. The fence against stray refactors.
Edge cases
Boundary conditions and failure modes. Empty states, outages, scale.
Health metrics
What must not regress. Outcomes say what changes; this says what stays true.
Verification
How you confirm it works, and the observable signal once it ships.
Evidence → judgment → implementation → verification
- 1
Capture friction
Collect signals: tickets, interviews, drop-offs, NPS comments, session recordings. The raw inputs to judgment.
- 2
Review the proposal
Bring a brief or an agent-written IntentSpec. Inspect the evidence behind each claim and identify assumptions. Keep, edit, or remove draft suggestions; keeping a suggestion clears its marker rather than creating a permanent acceptance record.
- 3
Authorize and build
Authorize an agent-originated proposal before implementation. For repository-owned intents, the recorded authorization names the exact revision. Claude Code, Cursor, or Codex builds from the intent and reports contradictions as findings.
- 4
Verify and close the loop
Checks travel with the spec. When a build contradicts it, the agent writes back a finding that rides into the next prompt and can flip a check to failing, so the spec converges instead of repeating a dead premise. With GitHub connected and the PR linked, the merged diff is reviewed against the spec. That checks the implementation; measurements after shipping establish whether the outcome improved.
Questions
- Why start from evidence instead of an idea?
- An idea is still a hypothesis. Evidence—support tickets, interviews, behavioral observations, and metrics—shows that a concrete problem exists and gives the resulting spec an inspectable reason to exist. Intent engineering does not ban ideas; it makes the evidence and judgment behind choosing one explicit before an agent builds it.
- Do I need a tool to do intent engineering?
- No. You can hand-author an INTENT.md file in any editor; the template above is a starting point. To check a spec before an agent runs with it, the free keyless preflight grades it with no account needed: run npx @pathmode/mcp-server in your agent, or paste it at preflight.pathmode.io. A tool like Pathmode helps you go from scattered user evidence to a structured spec faster, but the discipline is tool-agnostic.
- What does an IntentSpec include?
- Eight parts an agent needs to act without guessing: objective, outcomes, evidence, constraints, scope, edge cases, health metrics, and verification. It follows the open IntentSpec standard (v1.2), so any agent or validator can read it.
- Who owns intent engineering, product or engineering?
- Whoever holds the evidence and makes the call. Intent engineering sits deliberately above the PM-vs-engineer line. It is for builders making products with AI. The person closest to the user problem authors the intent; the agent, and the engineer reviewing it, act against it.
Turn evidence into intent. Turn intent into shipped software.
Pathmode is the platform built for intent engineering: capture evidence, shape IntentSpecs with AI, and export to any agent.