What should an AI agent’s task setup screen ask for before a long run?

Illustrative situation: on a Friday at 5:40 p.m., a finance operations lead types “Clean up our vendor list” into an AI assistant and closes the laptop. The agent works through the weekend. By Monday the vendor table is half changed, and some records with open invoices have been merged. The run stopped somewhere in the night, and the only message says “Something went wrong.” Nobody told the agent which records were off limits, how much it could spend, when to stop and ask, or what “clean” meant. The scene is invented. It shows the step this guide covers: the one between the prompt and the run.

Humbleteam, a digital product design agency, publishes this guide. It covers the task setup step before a long, multi-step agent run: plan preview, scope, hard limits, check-in points, stop conditions, defaults, and the screen people see when a limit is hit. It includes a setup worksheet and an invented worked example. Product behavior is described as of November 4, 2026 and can change.

Why is a prompt not yet a task?

A prompt states a wish. A task an agent can run safely also says what is in bounds, what the run may use up, and how anyone will know it is finished.

Devin’s documentation makes the last point directly: good tasks have “a clear start and end, plus explicit success criteria”. Microsoft’s HAX guidelines add guideline 10, “Scope services when in doubt.” NN/g’s 2026 usability study of Alibaba’s Qwen agent saw a prefilled prompt send an order for noodles when the participant wanted milk tea. The authors suggest asking a clarifying question first.

Our suggestion is six fields on the setup screen: goal, scope, limits, check-in points, stop conditions, and defaults. Each should stay readable after the run ends.

Should the agent show a plan first, and can the user change it?

Several tools now put a plan between the prompt and the work. Claude Code’s plan mode tells the agent to research and propose changes without making them. When the plan is ready, the user can approve it and start in auto mode, approve it and review each edit, or keep planning. Ctrl+G opens the plan in a text editor.

Cursor’s Plan Mode asks clarifying questions and produces a plan the user can edit through chat or markdown files. If the build misses, Cursor recommends reverting, making the plan more specific, and running it again instead of patching with follow-up prompts.

Google’s Jules also plans first. Its plan review page says the user can approve the plan or revise it through the chat box, and describes no direct editing. If the user navigates away, Jules eventually auto-approves the plan on a timer.

A plan the user cannot change is a receipt, and a plan that starts itself after a timer is a preview, not a gate. Both can be right, but the screen should say which one the user sees. For a run with real cost or outside effects, we would make the plan a gate by default, with each step carrying its own scope and limit, so that editing the plan edits the task.

What scope should the user set?

Scope is the set of things the agent may touch: repositories, folders, accounts, sites, record types. GitHub’s Copilot cloud agent, per its documentation, can change only the repository named when a GitHub Actions task starts. It works on one branch and opens one pull request per task. OpenAI’s Codex separates two controls: a sandbox that limits what commands can touch, and an approval policy for when it must stop and ask. Its network access is off by default.

A business product has no repository to anchor on, so the screen has to name the boundary. We suggest showing scope as a list the user can read and subtract from, with a count: “1,240 vendor records in the US entity. Excluded: 312 with open invoices.” A label such as “all vendors” hides the number that matters. The same question for one action is covered in our approval guide, linked at the end.

Which hard limits belong on the screen?

A limit is a number the agent cannot pass, whatever it decides. The sources show three cases, and they differ in who sets the number.

The user can set limits in Claude Code’s command-line reference: --max-turns and --max-budget-usd, both for print mode only. The turn limit has no default. The budget flag stops the run at an estimated spend and warns that the figure can differ from the bill. The Agent SDK documentation adds that spend can pass the cap by the cost of one response, so teams should leave headroom.

In other products the platform sets the number. A Copilot session on GitHub Actions has a maximum run time of 59 minutes, which the page says cannot be extended. Jules’ usage page lists 15 daily tasks and 3 concurrent tasks on its base plan, and says new tasks cannot start after the daily limit.

Some products set none: Cursor’s agent overview states there is no cap on the tool calls Agent can make in a task.

Developer tools expose limits as flags. A business user needs them in their own units: dollars or credits, records changed, and elapsed time. We suggest one hard limit for each and a clear label on any estimate.

Where should the agent pause and wait for a person?

A check-in point is a place the agent must stop and let a person decide. Unlike a one-action approval, it can be set in advance for a step, a phase, or a share of the budget.

Claude Code’s agent view shows the waiting state. Background sessions show “Needs input” for work only the user can provide, and while agent view is open, Claude Code notifies the user when a session needs input, finishes, or fails. A reply typed in the peek panel waits in a queue until the user attaches and answers the dialog itself. If a reply does not unblock the agent, the screen must say so.

Check-ins also come from the agent. Anthropic’s study of Claude Code usage, published February 18, 2026, found that on the most complex tasks the agent stops to ask for clarification more than twice as often as people interrupt it. Setup should let the user say which of those stops are required.

We suggest four triggers a user can switch on: before any irreversible step, at the end of each phase, when half the budget is spent, and when the agent reports low confidence. Say what happens if nobody answers. Waiting is the safe default. Jules’ timed auto-approval is the opposite choice, made for plans.

How do you define “done” and the other reasons to stop?

“Done” is the field most often missing. Claude Code’s /goal command is a precise model. The user sets a completion condition, and after every turn a separate model checks whether it holds, so a fresh model judges completion, not the one doing the work. The page advises one measurable end state, a stated check such as a command that exits 0, and constraints that must hold on the way. To bound the run, it suggests a clause such as “or stop after 20 turns.” The evaluator returns not yet met, met, or impossible, and can judge only what the agent has shown, so the end state has to be something the run can demonstrate. A business version: “No duplicate vendor pairs remain in the preview list, or 10 are left for review.”

We suggest a closed list of stop reasons so the final screen never improvises: done check met, limit reached, repeated failures, no progress, outside scope needed, and an error only the user can fix. Claude Code’s goal handling shows that last category. It clears the goal after errors the user must fix, such as an exhausted credit balance, and pauses it after a rate or usage limit.

What happens when a limit is hit mid-run?

This is where error recovery starts, so the setup screen has to plan for it. In the Agent SDK, hitting the turn or budget cap returns a result with its own subtype, and every result carries the cost, turn count, and session ID, so the run can be resumed. A resumed /goal keeps its condition but resets the turn count, timer, and token baseline. The limit ends the run, not the task.

We suggest a limit screen with five parts: which limit was hit, what was done, what is saved, what has not started, and the exits. Example wording, ours: “Stopped at the 400-action limit. 372 merges done. 19 waiting for your review. 61 pairs not started. Continue with 200 more actions, narrow the scope, hand to a teammate, or stop here.” The record of what the agent changed belongs to a separate screen, covered in our activity history guide.

Should every task start with a setup screen?

No. Setup has a cost. Anthropic’s same study reports that among new users roughly 20% of Claude Code sessions use full auto-approve, rising to over 40% as users gain experience. Manual approval is the default there, so part of that rise may be users changing settings. Either way, people move toward fewer prompts, and a screen that asks the same six questions forever will get skipped.

Google’s People + AI Guidebook says that for AI products there is an essential balance between automation and user control. Cursor’s docs say that for quick changes, jumping straight to Agent mode is fine.

We suggest three tiers. Quick tasks, such as read-only or easily reversed work under small limits, get no screen, only a line stating what the run will touch and its limits. Standard tasks open a prefilled screen with the plan, saved limits, and a start button. Full setup, every field, appears when scope, cost, or outside effects exceed what this user has approved before. Remember choices, and re-ask when the numbers grow. Even Claude Code’s docs note that auto mode reduces prompts but does not guarantee safety.

Illustrative worked example: the vendor cleanup

Everything here is invented. Ledgerlark is a fictional finance assistant. Ravi Tolland leads finance operations and types “Clean up our vendor list” at 5:40 p.m. on Friday.

The setup screen shows a four-step plan: find duplicate pairs by tax ID, rank them, merge the safe ones, and queue the rest for review. It is a gate, so the run waits. Ravi sets the goal as “no duplicate pairs remain, or 10 are left for review.” Scope reads “1,240 vendor records, US entity; excluded: 312 with open invoices,” and he leaves the exclusion on. Limits are a $15 allowance, 400 actions, and 3 hours. Check-ins are before any merge that involves bank details and at half the allowance.

At 11:48 p.m. the run reaches the action limit. On Monday the screen shows 372 merges done, 19 waiting for review, and 61 pairs not started. Ravi approves the 19 in a few minutes and raises the action limit by 200 for the rest.

Where do these defaults stop working?

The sources are product documentation, one vendor study of usage data, one small usability study, and design guidance. We found no study of setup screens for long agent runs, so the tiers, triggers, and worksheet values are suggestions to test. NN/g’s Qwen study had six participants ordering consumer goods and did not test plan previews. Several limits cited here are developer flags, not screens. OpenAI’s ChatGPT agent help article could not be opened, so that product is not covered. Regulated settings, shared accounts, and multi-agent runs need their own review.

What can you produce now?

Five things, before anyone draws the screen:

1. A one-page setup worksheet, with the table above filled in for your three longest-running tasks.
2. A scope statement with counts, written the way a user would read it.
3. A closed list of stop reasons and the exact message for each.
4. A limit screen spec: what was done, what is saved, what has not started, and the exits.
5. A tier rule that says when setup is skipped, prefilled, or full.

With those, you can test the vendor cleanup above on a real run. For the moment before a single action, including proposals, approval, and the difference between cancel and undo, read our guide to approval, undo and human handoff for AI agents. For the record after the run, see what an agent’s activity history should show. If you are choosing a partner for this work, our comparison of agencies with published agent-flow cases is a starting point.