Before an agent changes the billing table
A coding agent finds a failing test near a billing calculation. It can change the implementation, update the expected result, or ask which behavior is correct. All three may produce a green check. Only one may preserve the intended contract.
The useful boundary is not between easy and difficult work. It is between decisions the agent can justify from available evidence and decisions that require someone else’s authority. Here is a side-by-side comparison of where that boundary falls.
§ Clear intent beside ambiguous intent
Continue: The task specifies that invoice totals must include a documented rounding rule, and existing examples establish the expected result. The agent can implement the rule, add a regression test, and explain the change.
Stop and ask: The implementation rounds each line item, while the failing test rounds only the final total. Neither the task nor the documentation resolves the conflict. Changing either side would silently choose a billing policy.
A useful question names the disagreement: “Should rounding happen per line item or once on the invoice total?” Asking for a specific decision is better than asking whether to proceed.
§ Local edits beside external effects
Continue: The agent modifies a local function and runs a known test command in an isolated environment. The changes are inspectable, and reverting them does not require coordination.
Stop and ask: The next step would execute a migration against a shared database, publish a package, send customer messages, or deploy a service. These actions affect people or systems beyond the working tree.
A command that sounds harmless can still have external effects. Before running an unfamiliar script, inspect its behavior. Explicit authorization for one deployment does not automatically authorize subsequent deployments.
§ Established patterns beside new policy
Continue: The repository already defines how adjacent endpoints validate input and report errors. Applying that pattern to a new endpoint is usually an implementation decision within the assigned scope.
Stop and ask: The agent must choose a retention period, change who can access invoices, or decide whether failed payments receive another retry. These are product, security, or operational policies, even when the code change is small.
The size of a diff is a poor measure of its authority requirements. A one-line permission change can deserve more review than a large mechanical refactor.
§ Bounded investigation beside expanding scope
Continue: A targeted test fails because a fixture is outdated, and the correct fixture follows directly from an approved interface change. Updating it remains part of the original task.
Stop and ask: Fixing the test appears to require replacing the database adapter or upgrading a major dependency. The agent has discovered a larger project, not merely another implementation step.
Report what is blocked, the smallest plausible remedy, and the broader alternative. Do not present an architectural rewrite as an unavoidable prerequisite without evidence.
§ Useful verification beside repeated guessing
Continue: Each test run checks a distinct hypothesis, and the results narrow the problem. The agent stays within an agreed time, tool, and spending budget.
Stop and ask: The same failure persists after several materially different attempts, necessary credentials are unavailable, or verification depends on an inaccessible service. More edits would add uncertainty rather than evidence.
This boundary matters with token-based tooling. Vana API provides one OpenAI-compatible endpoint that also supports Anthropic Messages and Gemini native protocols, and works with Claude Code, Codex, and Gemini CLI. Billing is per real token, with no monthly fee; that makes explicit investigation budgets useful, not unnecessary. Create an account to try a bounded coding session with a clear stopping rule.
§ A decision request beside a progress report
Continue: Routine progress belongs in a concise report: what changed, which checks passed, and what remains unverified. The user should not have to approve every reversible edit.
Stop and ask: A genuine boundary deserves a decision request containing the missing fact or permission, the available options, and the consequence of each. Preserve the current work and avoid consequential actions while waiting.
A dependable coding agent does not stop whenever it feels uncertain. It stops when uncertainty would force it to invent intent, exceed permission, or spend beyond an agreed limit.