The conversation I run before every significant piece of work covers the same ground every time.
What’s the actual problem? Not the stated feature request. The underlying need.
What does success look like from the user’s perspective? Not completion of the feature. The moment they feel like the thing worked.
What are the constraints? Technical, organizational, timeline, scope. What are we explicitly not building?
What assumptions are we making? What would have to be true for this to be worth building at all?
What would change the answer? If we discovered X, would we stop?
This takes fifteen minutes. It saves days. Not because I have better answers at the end, but because the questions themselves clarify what the agent needs from me to be useful.
The plan is only as good as the conversation that preceded it.
When intent becomes a specification
For personal work, the conversation is enough. When agents ship inside products and act for users who may not know an agent is involved, intent has to graduate from a habit to a specification: an objective that explains the problem and why it matters, outcomes described as observable states from the user’s perspective, and health metrics that say what must not degrade along the way, because an agent chasing a single target will game it tirelessly.
Then constraints, and here’s the distinction most teams miss: steering constraints live in prompts, hard constraints live in architecture. Prompts are suggestions. Architecture is enforcement. If an agent has access to a tool, assume it will use it.
One rule ties it together: the less the user understands about what the agent is doing, the tighter your constraints need to be.
Also in June: Intent Engineering for AI Agents · Shallow Intent Ships Confident Failures · Agents Fail Users at the Decision, Not the Execution
Daniel Arevalo is Product Experience Lead at Omny Security. He builds AI-native tools and writes about design, product leadership, and what it means to direct systems that execute at a speed humans never had before.