An agent question is not free. It creates a synchronous interruption, transfers search work to the person least able to batch it, and often throws away context the system already had permission to inspect.
The standard I use is simple: before an AI agent asks a teammate for information, it should exhaust the context sources attached to the task and show its work. The remaining question should request a decision or genuinely unavailable fact, not an identifier hiding in a nearby system.
- Pattern
- Context before interruption
- Output
- Question policy
- Use when
- An agent is about to ask for an ID, status, owner, link, or environment detail
The avoidable interruption
One session began with a request to check whether an email-delivery problem had been resolved in a cloud account. A weak assistant response would have asked which dashboard page to open, which region to inspect, or for the account identifier.
Those questions would sound reasonable. They would also move the investigation backward. The execution context could inspect the configured account, discover the active region, check the sending status and suppression state, and return the evidence that mattered. The human was needed only if there were multiple plausible accounts or if the result required a policy decision.
The useful distinction is not "ask questions" versus "be autonomous." It is lookup versus judgment.
- A repository path, issue link, recent error, account alias, current branch, or service owner is usually a lookup.
- Choosing between two acceptable risks, resolving conflicting requirements, or approving production impact is judgment.
Agents should spend machine time on lookups before they spend human attention on questions.
Give interruptions a budget
I treat human questions as a limited budget inside an agent task. The budget is not a numeric quota. It is a requirement that each interruption clear three gates:
| Gate | The agent must show | A question is justified when |
|---|---|---|
| Available context | Repositories, linked issues, thread history, browser state, logs, and configured accounts checked | The answer is absent or contradictory |
| Inferable context | Names, IDs, environment, ownership, and recent state resolved from those sources | More inference would be unsafe |
| Human-only input | The precise decision or fact that remains | Progress cannot continue without it |
This policy changes the shape of the question. Instead of "Which account should I use?" the agent can say:
I found two configured accounts.
Checked:
- The deployment points to account A in region X.
- The incident link names account B but is six months old.
- Recent delivery logs exist only in account A.
I can continue with account A read-only. Confirm only if the old incident link
means account B is still authoritative.That message is useful even before the human replies. It records the search, exposes the ambiguity, and offers a safe default.
Build the context waterfall into the agent
Prompting the model to "be proactive" is too vague. The behavior needs an ordered retrieval policy:
- Task-local state: current files, branch, open page, command output, and error text.
- Linked state: issue, pull request, runbook, thread, design, or document referenced by the task.
- Nearby authoritative state: runtime configuration, logs, deployment metadata, ownership records, and recent history.
- Cross-check: compare at least two sources when the answer can drift, such as active account, deployment status, or current owner.
- Interrupt: ask for the smallest decision that cannot be safely derived.
The order matters. Searching every connected system is wasteful and can create privacy problems. Start with sources already scoped to the task, then widen only when a concrete gap remains.
The review artifact is the question packet
For team use, I would require an agent-generated question to carry four fields:
QUESTION
The one decision or missing fact needed.
CHECKED
Sources inspected and relevant result from each.
WHY INFERENCE IS UNSAFE
The ambiguity, contradiction, permission limit, or freshness problem.
DEFAULT
The reversible action the agent can take if no answer arrives.This turns interruptions into reviewable engineering output. It also makes broken integrations visible. If CHECKED repeatedly says a linked tracker or document could not be read, the problem is not that humans need to answer more questions. The agent is missing a capability.
Where this rule becomes dangerous
Context gathering can become its own form of waste. An agent that searches six systems to avoid a 20-second clarification has optimized the wrong resource. It may also retrieve information outside the task's intended access boundary.
The stopping rule is proportionality: fetch the sources that are already linked or cheap, and ask when further retrieval costs more than the interruption or would widen access. For urgent incidents, a short question plus parallel read-only investigation can be better than silent searching.
The goal is not a question-free agent. It is an agent whose questions arrive with enough context that answering them is the smallest remaining piece of work.