Understanding and carrying out user intent is critical to assistant success. Here are the “habits” of assistants that get what you mean and do what you want.
1) They summarize intent as a structured guess (not a vibe)
Simple assistants treat intent like a single label (“search,” “write,” “plan”) and then sprint. When the user’s ask is ambiguous, they hard-commit to the wrong thing. The strongest assistant frameworks represent intent as a structured object (intent + extracted entities/slots), and the system can decide what to do based on what’s missing.
Effective assistants quickly assemble a tiny “intent object” (goal, output type, constraints, missing fields, confidence). If confidence is low or key slots are missing, they don’t guess – they clarify just enough to route correctly, then proceed. (Rasa slot-filling is one example)
2) They don’t reach for tools until they’ve earned the right
Tool calls feel like progress, but they’re also a commitment to an interpretation. A good example of “earning the right” is Cursor’s Plan Mode: it creates a plan (and asks clarifying questions) before it starts making edits or running long agentic flows.
The habit is gating: “Do I have enough intent/constraints to make a tool call worth it?” If not, the assistant asks one high-leverage question or proposes defaults – then it uses tools with a crisp target (what it’s trying to fetch, why, and what would change the plan). (Cursor)
3) They run a real context pipeline: retrieve and prepare
“Use the right context” fails when assistants either (a) retrieve nothing and hallucinate, or (b) paste raw docs/notes into the prompt and hope. Microsoft’s Copilot architecture is basically a production-grade version of the right idea: retrieve relevant chunks from an index grounded in your org’s data/Graph, then use them to generate.
A real pipeline is two stages: retrieval (hybrid/semantic index + filters like recency/access/project) and prep (dedupe, rerank, extract decisions/constraints/action items, compress to a brief). Your assistant should treat the brief as the “model-ready interface,” not the raw sources. (Microsoft Learn)
4) They plan like a GPS (plan → act → observe), not like a screenplay
Most toolchains fail because assistants write an end-to-end screenplay and assume every step works. The strongest research-backed pattern here is ReAct: interleave reasoning and actions so the model can update the plan after each tool result and handle exceptions instead of plowing forward.
So: take small steps, checkpoint after each, and reroute. “Plan → act → observe” becomes a product behavior: after every tool call, the assistant explicitly answers “what did we learn?” and “what changes now?” before deciding the next action. (arXiv)
5) They minimize the Question Tax with progressive disclosure
Assistants often front-load 10 questions because they’re optimizing for “completeness,” not momentum – users bounce. Progressive disclosure is the UX pattern that fixes this: don’t dump everything at once; reveal complexity only when it becomes necessary.
In assistant terms: give a useful partial result fast (a shortlist, a draft, a couple options), then ask one fork-in-the-road question that meaningfully narrows the space. You’re trading “interrogation” for guided iteration – and it’s dramatically easier to stay aligned. (Nielsen Norman Group: Progressive Disclosure)
6) They show progress in a legible, reversible way
Trust dies when the assistant feels like a black box – or worse, when it takes irreversible actions. OpenAI’s Operator makes this concrete: it’s designed to ask for user confirmation before significant actions (like sending an email or submitting an order), and uses “takeover mode” for sensitive inputs.
The habit is simple: surface a short plan + assumptions, show what’s done, and keep early work in draft mode. Make “undo” cheap: propose, don’t commit; confirm before external side effects; and treat changes as expected, not failures.
7) They capture constraints by offering choices, not by interrogating
Open-ended questions (“what tone?” “what budget?”) are exhausting and vague. A strong product example is Bing Chat’s tone toggle – Precise / Balanced / Creative – letting users steer behavior with a single choice instead of a long back-and-forth.
In engineering terms: infer defaults, then offer a few high-signal toggles that route most work (do vs advise, fast vs accurate, short vs thorough, polish vs authentic). Users will correct you faster than they’ll specify everything upfront – and you’ll get to “good” with far less friction. (Bing Blogs)
In summary, when GPT-4 landed in 2023 with sufficient reasoning power to build BabyAGI, agents became inevitable but elusive. Even SOTA 2025 LLMs still can’t be relied upon to understand intent, sort through huge context, plan, and execute without error. Instead, engineers are chipping away at the problem, building a reliable cognitive architecture piece by piece.