# Process 1 — capturing intent
> **What you will learn**
> How a one-line request becomes an executable specification, and why asking
> back is its own phase.
## It starts as one line
In reality, requests arrive like this:
```
"Make coupons work in the cart"
```
You cannot build from that. Too much is undecided.
## The asking-back phase
A PM agent **removes the ambiguity with questions.**
```
Q: Can several coupons be stacked?
A: No, one only.
Q: What happens if someone enters an expired coupon?
A: Tell them it's expired and don't apply it.
Q: Is there a minimum order condition?
A: It varies by coupon. If they're under it, show them the condition.
Q: Does the total update immediately, or at checkout?
A: Immediately.
Q: Does it apply to items that are already discounted?
A: ...ah, I hadn't thought about that. No, it shouldn't.
```
**The last question is the value of this phase.** Something even the requester
had not considered, found before building.
## Why an agent asks rather than a person
A human PM can ask too. But there are differences.
| | Human PM | PM agent |
|---|---|---|
| Timing | you have to schedule a meeting | immediately |
| Omissions | skips familiar territory | sweeps systematically |
| Record | scattered across meeting notes | **becomes the specification directly** |
The third matters most in practice. The Q&A is the specification, so **there is
nothing to write up afterwards.**
## Output — a specification with no room for interpretation
```
[Feature] Coupon application in the cart
[Behaviour]
- Enter a code in the coupon field; validate and apply the discount
- The total updates immediately on application
[Rules]
- Only one coupon applies (no stacking)
- Expired coupon: "This coupon has expired"
- Below minimum: "Valid on orders over $N"
- Not applicable to items already discounted
[Out of scope]
- Coupon issuance (separate work)
- Coupon analytics (separate work)
```
**Note the "out of scope" section.**
[Writing scope as what not to do](/guide/ai-intent-context) applies here
directly.
## What happens to ambiguity left here
**It does not resolve itself.** In a later phase AI picks one option and proceeds,
and that choice hardens plausibly.
```mermaid
graph TD
A["Not written in the spec"] --> B["AI decides arbitrarily"]
B --> C["It goes into the code"]
C --> D["Tests are generated on the same assumption"]
D --> E["Everything passes · nobody notices"]
E --> F["Found later: 'why does it work like this?'"]
```
**Because the tests get built on the same assumption**, verification does not
catch it either. That is why this is the first phase in the process.
## Practical technique
### Keep a list of questions to ask back
For the same kind of work, the questions are similar.
```
Common questions for screen features:
□ what is shown on failure
□ what is shown while loading
□ what unauthorised users see
□ how it looks on mobile
□ which existing features are affected
```
### "I hadn't thought about that" is a good sign
That is exactly what asking back is for. The cost difference between deciding it
now and discovering it later is large.
---
## Check yourself
**1. Why is ambiguity left in this phase not caught later?**
Answer
Because after AI decides arbitrarily, **the tests are generated on the same
assumption.** Everything passes, so verification reveals nothing, and it turns up
much later as "why does it work like this?"
**2. What is a PM agent's practical advantage over a human PM?**
Answer
**The Q&A becomes the specification directly.** Nothing gets scattered across
meeting notes, so nothing needs writing up. It also starts immediately and does
not skip familiar territory.
**3. How should you read "I hadn't thought about that" from the requester?**
Answer
**As a good sign.** Finding exactly that is the purpose of asking back, and
finding it before building is far cheaper.
---
Once the specification is ready, several agents attach at once →
[Process 2 — agent orchestration](/guide/ha-phase2-orchestration)