--- title: "What to delegate" description: "Which tasks suit a cloud agent thread, how to size them, and how to run work in parallel." canonical_url: "https://hoplite.sh/docs/delegate" markdown_url: "https://hoplite.sh/docs/delegate.md" --- # What to delegate URL: /docs/delegate LLM index: /llms.txt Description: Which tasks suit a cloud agent thread, how to size them, and how to run work in parallel. Related: /docs/prompting, /docs/prompt-templates, /docs/threads, /docs/cli/handoff # What to delegate Delegate tasks the agent can verify on its own. Every thread gets a full [sandbox](/docs/sandboxes) — dependencies installed, tests runnable, dev server startable, a browser to check the result — so the best candidates are tasks with a checkable definition of done. This page is judgment, not mechanics: what to send, what to keep, and how to keep several threads moving at once. ## Good candidates for a thread - **Well-scoped changes with clear done criteria.** A bug with a repro, a feature with a concrete acceptance test, a migration with a before/after you can state in a sentence. - **Test-backed work.** The agent runs your suite in the sandbox, and a [`check` script](/docs/sandboxes/scripts) gives it a standing verification command. If tests can prove the task done, the agent can prove it to itself before you ever look. - **UI changes you can see.** The agent starts a [preview](/docs/sandboxes/previews), drives a browser against it, and captures before-and-after screenshots of frontend changes — so "does it look right?" doesn't wait for you to pull the branch. - **Review-loop chores.** Once a thread has a PR, reviewer comments and failing checks feed back into the conversation. "Address the review" is one of the highest-leverage messages you can send. See [GitHub & pull requests](/docs/github). - **Investigation.** The agent reads code, runs commands, and can inspect GitHub Actions runs — including failed-job logs — to answer "why is CI red?" without changing anything. ## What to keep local - **Work that depends on uncommitted local state.** The cloud sandbox sees only what's available from GitHub. If the context lives in your working tree or your head mid-session, use [handoff](/docs/cli/handoff) — it can push your branch and carry the conversation over — rather than retyping the task. - **Tasks you can't define done for yet.** If you'd struggle to tell a colleague when to stop, the agent will struggle too. Explore locally until the task has a shape, then delegate the shaped version. - **Work against services the sandbox can't reach.** The sandbox gets access through [environment variables](/docs/sandboxes/environment-variables); if the required credentials or services aren't something you'd configure there, keep the task local. ## Size tasks to one pull request A thread is one conversation, one sandbox, one diff, and its own pull requests. The unit that works is the unit you'd want to review: one coherent change. If your task description chains unrelated work — "fix the login bug, and also redesign the settings page" — split it into threads. Each half ships independently, reviews cleanly, and neither blocks the other. Conversely, don't shred a single change into fragments; follow-up steps within one change belong in the same thread as follow-up messages. ## Run threads in parallel Threads don't share state. Each has its own sandbox and its own diff, so independent tasks can run simultaneously without stepping on each other — treat parallel threads the way you'd treat parallel teammates on separate branches. Where two tasks touch the same files, expect the second PR to need a rebase, and prefer running those sequentially. While runs are in flight, thread statuses (`running`, `waiting`, `ready`) tell you where your attention is needed. A thread in `waiting` is paused on your [approval](/docs/threads#approvals) or input; everything else is working without you. ## Pipeline with queued messages You don't have to wait for a run to finish before sending the next step. Messages sent mid-run stack in a **Queued** panel above the composer and apply in order once the current run completes — and you can remove a queued message before it runs. This turns a thread into a pipeline: send the task, then immediately queue "now add tests" and "open a PR with `/pr`", and come back when the PR rail lights up. If the run heads the wrong way, `/stop` halts it immediately and your next message takes over. See [Threads](/docs/threads) for the full steering toolkit. ## Sitemap See the full [sitemap](/docs/sitemap.md) for all pages. Well-known sitemap: [/docs/.well-known/sitemap.md](/docs/.well-known/sitemap.md).