What is an intent?
An intent is a single user problem worth solving, backed by evidence and defined by the outcomes that prove it's been solved.
That's the whole definition. Three parts:
- A user problem — not a feature idea, not a stakeholder request, not a hunch
- Backed by evidence — friction signals, quotes, metrics, observations, requests from real users
- Defined by outcomes — observable state changes that make "solved" unambiguous
An intent doesn't say what to build. It says what's wrong and what "fixed" looks like. The solution stays open.
Why the noun matters
Most product artifacts collapse the problem and the solution into one thing. A Jira ticket says "build the dropdown." A PRD says "we will ship a notification center." A user story says "as a user, I want to filter results." All three skip past the actual question — why are we doing this, and how will we know it worked?
An intent forces that question to the front. You can't write an intent without naming the problem. You can't validate an intent without naming the outcome. The solution is deliberately the last thing decided, and often the thing the AI agent figures out.
This is why intents are the unit of work in Pathmode rather than tickets or stories. Tickets describe handoffs. Intents describe problems.
Intent vs. related artifacts
| Artifact | Anchored to | Defines success | Open about solution |
|---|---|---|---|
| Feature request | A solution idea | No | No (solution is the request) |
| Jira ticket | A task | Implicitly | No (task is the solution) |
| User story | A user role + desire | Acceptance criteria (often soft) | Partially |
| PRD | A planned feature | Sometimes | No |
| OKR / goal | A business metric | Yes | Yes — but at company scale, not buildable |
| Intent | A user problem with evidence | Yes — observable outcomes | Yes |
An intent sits between an OKR and a ticket. OKRs are too coarse to build against. Tickets are too solutioned to question. The intent is the level where evidence meets execution.
Intent, IntentSpec, Intent Engineering
These three terms get used interchangeably and shouldn't be:
- Intent (noun) — the unit. One user problem worth solving.
- IntentSpec (artifact) — the structured six-part document that makes an intent executable: Objective, Outcomes, Evidence, Constraints, Edge Cases, Verification.
- Intent Engineering (discipline) — the practice of producing intents and the IntentSpecs that capture them.
You have an intent. You write an IntentSpec. You practice intent engineering. The intent is the idea; the spec is the artifact; the engineering is the work.
What an intent looks like
Compare the same problem expressed three ways:
Feature request: "Add address autocomplete to onboarding."
User story: "As a new user, I want my address autocompleted so I can sign up faster."
Intent: Users abandon onboarding at step 3 (address entry) at a 23% rate. Seven support tickets in the last quarter cite the form being "too long." A complete signup at this step takes a median of 87 seconds. We'll know this is solved when drop-off at step 3 falls below 10% and median time-to-complete drops under 15 seconds.
The first two pre-decide the solution. The third describes the problem and what "solved" looks like — and stays silent on how. An AI agent or a developer could propose three different solutions, and the outcomes would tell you which one worked.
Where intents come from
Intents are not invented in planning meetings. They're synthesized from evidence.
The flow:
- Friction signals accumulate on the Evidence Board — support tickets, user quotes, metric anomalies, observations, feature requests.
- Patterns emerge. Multiple signals point at the same underlying problem.
- An intent crystallizes. You name the problem, link the evidence, define the outcomes that would prove it's solved.
- The intent becomes a spec. When the team is ready to build, the intent is captured in an IntentSpec and handed to an AI coding agent or an engineer.
If an intent doesn't trace back to evidence, it's a feature idea wearing a costume. Send it back.
How AI agents use intents
The reason intents are structured this way is that AI coding agents need three things to execute autonomously: the why, the what success looks like, and the edges where things break. They do not need (and are slowed down by) a prescribed solution.
Hand an agent a ticket that says "add address autocomplete" and it will build exactly that — even if a different approach would solve the underlying problem better. Hand it an intent and it has the context to make good design decisions, propose alternatives, and verify its own work against the outcomes.
This is why intents are the input to agent-ready specs rather than tickets. The agent works best when it knows the problem, not just the task.
Try writing one
Pick a real piece of user friction from this week — a support ticket, a drop-off in your funnel, a complaint in a sales call. Don't write what to build. Write:
- The problem (one sentence)
- The evidence (what makes you believe it's real)
- The outcomes (what would be observably true if it were solved)
That's an intent. Everything else — the spec, the agent, the code — comes after.