Imagine asking a coding agent to change a checkout screen. The prompt says what you want. It probably doesn't say whether the agent can read the whole repository, fetch outside information, edit files without approval, or keep spending when the task drags on.
Those aren't advanced settings for later. They determine what kind of work you have authorized. I would rather see a small preflight before Run than a prettier progress animation afterward.
This is a UI proposal, not a feature claim about any particular agent. The useful distinction is between telling an agent what to accomplish and deciding the conditions under which it may attempt it.
A preference is not a limit
A recent roundup of agent tooling puts managed sessions and cost-aware model routing in the same conversation. It is tempting to turn that into one friendly UI control: "prefer a cheaper model." But that preference doesn't tell an operator how much the run may cost. It also says nothing about which commands the agent may execute.
If the interface says "economical," I want to know whether it means:
- a model-selection preference that can choose differently for a given step;
- an enforceable stop condition, if the product has one; or
- just an estimate shown after the work finishes.
Those are different promises. Don't call a routing preference a budget. If a product cannot enforce a monetary cap, say so instead of painting a green "within budget" badge over an estimate. A bounded run might use an explicit limit on tool calls or model usage, but the UI must name the rule it actually enforces.
Permission is a separate axis. A cheap model with broad file and network access still has broad file and network access. One developer in a coding-agent guardrail discussion argues for a distinct guard rather than relying on opaque model safeguards. That's one builder's position, not a referendum on safety tools, but it points to a useful design boundary: the application should decide which actions require approval.
Put the operating conditions next to Run
Here's a hypothetical preflight for that checkout task. It describes an interface I would build, not an existing product's API:
Task Change the checkout screen
Workspace Current repository; show permitted paths
Context Repository files only; outside retrieval off
Actions Read and propose patches; ask before running commands
Routing Prefer the lower-cost route (preference)
Stop rule No enforced spend cap configured
Show the effective defaults, even with a saved preset. "Outside retrieval off" is worth spelling out: a discussion about local coding models and world knowledge illustrates why a user might care whether a run can consult outside context. It doesn't establish that local models perform better or worse. Retrieval is an interface decision independent of the model name.
If the environment is remote, say where work runs and which workspace is available to it. If the interface offers a path restriction, the executor has to enforce it; a path label that an unrestricted tool can bypass is decoration. The same goes for approvals. A button can request a policy, but the tool boundary must apply it.
This need not become a giant settings page. A compact card with expandable detail can carry the defaults, with a confirmation step when a run requests more authority. For implementation patterns, Generative UI resources collects SDKs, open-source projects, and technical explainers. Borrow presentation ideas if they fit, but don't mistake a UI pattern for enforced permissions.
Let the run report the boundary it used
The preflight is a promise about the run, so the interface should reconcile that promise with what actually happened. Show the model route used, which tool actions were allowed or held for approval, whether outside retrieval was used, and the usage or cost information the system can actually observe. Label estimates as estimates.
If the agent asks to leave the agreed scope, the approval prompt should name the action and why it exceeds the current grant. "Needs permission" tells the operator almost nothing. "Wants to run a command with network access; this run is local-only" gives them a decision to make.
This is not a substitute for verifying the eventual code change. A bounded run can still produce a bad patch. Preflight answers what the agent was allowed to try; tests and review answer whether the result works. Keeping those questions apart makes both screens more honest.
Keep the contract small and real
I wouldn't put every tool switch in front of every user. Most runs can start from a sensible, visible preset, provided the operator can inspect its actual scope and change it before work starts. More detail belongs at the moment a requested action crosses that scope.
Show the authority, context, and stop rule you can enforce before the agent begins. Label preferences as preferences. If enforcement doesn't exist, a toggle shouldn't imply that it does.
Source notes
- AI Dev Weekly #26 — readable Stage 1 roundup; context for routing and application-policy distinctions, not primary vendor documentation.
- Claude Opus 5.5 discussion — one builder's guardrail concern; not representative sentiment.
- LocalLLaMA discussion on coding models and knowledge — supporting discussion of offline context and retrieval tradeoffs, not performance evidence.
Top comments (0)