If you've built products with AI agents — or you're about to — you've already felt the problem. You describe what you want. The agent builds something close but wrong. You describe it again, differently. Closer. Still wrong.
The gap isn't the AI. The gap is what you gave it.
Intent engineering is the discipline of specifying what you want built — precisely enough that an AI agent can execute it without guessing.
What Is an Intent?
An intent is a single user problem worth solving, backed by evidence.
It's not a feature request. It's not a Jira ticket. It's not a user story. Here's how they differ:
| Artifact | Example | Problem |
|---|---|---|
| Feature request | "Add dark mode" | No evidence it matters, no success criteria |
| Jira ticket | "Implement dark mode toggle in Settings" | Prescribes the solution, not the problem |
| User story | "As a user, I want dark mode so I can reduce eye strain" | Points at the problem but isn't testable or traceable |
| Intent | Reduce eye strain during extended evening sessions — evidenced by 7 friction reports and NPS comments citing screen brightness | Problem-rooted, evidence-backed, outcome-oriented |
An intent starts with what users are experiencing and ends with what will be true when the problem is solved. It doesn't specify buttons, endpoints, or architecture.
What Is an Intent Spec?
An intent spec is the structured document that makes an intent executable. It contains:
| Component | What it answers |
|---|---|
| Objective | What user problem are we solving and why? |
| Outcomes | What observable state changes happen? |
| Evidence | What user signals prove this is needed? |
| Constraints | What must we NOT do? |
| Edge cases | What happens when it breaks? |
| Verification | How do we prove it works? |
That's it. Half a page. No "Background" section, no implementation notes, no 12-page PRD.
The intent spec is short because it's precise. Every line is testable. If an outcome says "User can export a report in under 5 seconds," you can verify that. If a PRD says "Improve the export experience," you can argue about it forever.
For the full breakdown of each component, see The 6-Part IntentSpec.
Why "Engineering"?
Because this is a precision discipline, not a writing exercise.
Engineering implies:
- Structure over prose. An intent spec has a defined shape. You don't get to freelance the format.
- Evidence over opinion. Every intent traces back to user evidence — friction, quotes, observations, metrics, requests. No evidence, no intent.
- Testability. If you can't verify an outcome, it doesn't belong in the spec. "Improve onboarding" is not an outcome. "New users complete setup in under 2 minutes" is.
- Traceability. From user pain to evidence to intent to shipped code. Every link in the chain is explicit and auditable.
The word "engineering" is deliberate. You don't write intents. You engineer them.
How It Fits Together
The full workflow has three layers:
Evidence → Collect real user signals (friction, quotes, observations, metrics, requests) into an Evidence Board.
Intent → When evidence clusters around a problem, synthesize it into an intent spec. The spec defines the problem, the outcomes, and the verification criteria.
Execution → Hand the spec to your team or your AI agent. The spec is structured enough to execute without ambiguity.
Each layer feeds the next. Evidence creates intents. Intents create alignment. Alignment creates software that actually solves the problem users reported.
What Intent Engineering Replaces
It doesn't replace your PM process. It replaces the artifacts your process produces:
| Before | After |
|---|---|
| PRDs that nobody reads past page 2 | Intent specs that fit on one screen |
| Feature backlogs ranked by gut feel | Intent backlogs ranked by evidence weight |
| "Definition of done" debates | Verification criteria written into the spec |
| Vague Jira tickets that agents misinterpret | Structured specs that agents execute correctly |
| Anecdotal user feedback in spreadsheets | Typed evidence on a searchable board |
You still talk to users. You still prioritize. You still make judgment calls. But the output of that work is now precise, testable, and executable — by humans or AI agents.
Where to Go Next
- Learn the spec format: The 6-Part IntentSpec — the components every spec must contain.
- See a worked example: From Support Ticket to Shipped Feature — a complete end-to-end walkthrough.
- Start collecting evidence: From User Interview to Evidence Board — turn your conversations into structured input.