> ## Documentation Index > Fetch the complete documentation index at: https://docs.getpioneer.dev/llms.txt > Use this file to discover all available pages before exploring further. # Tasks & Automation Overview > Use Pioneer tasks to run repeatable, scheduled, and subagent-backed work. Threads work well when you are present and steering the work. Tasks are for work with its own schedule, state, or completion rules. A task can run manually, on a schedule, after another task, or as part of a larger workflow. The gateway owns the run, so tasks can keep working in the environment where the gateway lives. Tasks are useful on remote gateways because the gateway can run a morning research pass, check a repository, prepare a summary, or coordinate smaller agent steps while your laptop is closed. ## Tasks and ordinary background work Pioneer also runs messages asynchronously in collaborative threads. Sending a message is enough when you want the agent to keep working while you continue the conversation. The request gets its own live task card and child conversation, and its result returns to the thread that started it. Use an explicit task when you need a schedule, dependencies, retries, deliveries, write locks, subagents, or a workflow that should remain meaningful after the original conversation ends. A background request keeps a conversation responsive; an explicit task defines durable automation. ## Start with boring tasks Your first task should be simple and read-only: ```text theme={null} Summarize the current workspace and list any obvious setup issues. Do not modify files. ``` Run it manually. Read the result. Open the timeline. Check which tools were called and what the agent saw. Only after that should you add schedules, write access, dependencies, or multi-agent workflows. A task that runs by itself deserves more caution than a thread you are watching. Task tools run through the gateway and follow the task or turn permission profile, including sandbox/resource policy and audit events. Use **Supervised** for first manual runs, then move to **Auto-accept edits** or **Full access** when the workflow is predictable. ## Subagents Pioneer can create subagents automatically as part of a task workflow. You do not have to manually delegate every piece of work. A task can define the prompt, model, context policy, tool policy, result expectations, review policy, and child-thread behavior for agents that run under it. Pioneer can then break work into smaller parts and attach the results back to the parent task. This helps when one large job needs focused passes: gather information, inspect files, draft a result, verify it, and report back. Each agent should have a clear job and result contract. Subagents run in hidden child threads. The child thread gives the subagent a normal agent environment with its own timeline, tools, context, and artifacts. The parent thread still owns the workflow: it creates the task, waits for the result, reviews the candidate output, and decides what happens next. ## Parent review and revisions Attached subagent tasks do not have to become final just because the child agent stopped. When a subagent finishes a turn, Pioneer stores the output as a result candidate. The parent agent can then: * accept the candidate when it satisfies the task; * request a revision from the same subagent with concrete feedback; * cancel the task when the result should not be used. When the parent requests a revision, Pioneer records the rejected candidate, sends the feedback back into the same child thread, starts a new revision turn, and waits for a new candidate. The cycle can repeat up to the configured revision limit. The default parent-agent review policy allows up to five revision rounds. This keeps multi-agent work auditable. The timeline retains the first answer, parent feedback, revised answer, and accepted candidate instead of replacing rejected work with a single final result. Scheduled and detached work is treated differently from foreground attached delegation. Those runs should not get stuck waiting for a parent turn that is no longer active, so they can be finalized automatically according to their task policy. ## Subagent artifacts Files created by subagents are still workspace artifacts when the subagent registers them. The artifact is bound to the child thread and task lineage, and the parent thread can list artifacts created anywhere in its delegated child-thread tree. If a subagent says it created a file but the file is missing from the artifacts panel, the file was probably written as an ordinary gateway file and not registered with `artifact_register`. ## Where task work happens Tasks run on the gateway. If the gateway is local, task tools run locally. If the gateway is remote, they run on the remote host. This affects file paths, credentials, network access, installed commands, and side effects. Before scheduling a task, make sure you are on the gateway where you actually want the work to happen and that the task's permission profile and security cap match the level of supervision you expect. Run tasks manually or on a schedule. Connect tasks, dependencies, and subagents. ## Further reading * [Tasks Architecture](/architecture/tasks) explains task records, runs, subagent threads, review, retries, and write locks. * [Agent Loop](/architecture/agent-loop) explains how task tools and child turns fit into ordinary turns. * [Permission System](/architecture/permissions) explains task permission/security caps and approval prompts. * [Artifacts Architecture](/architecture/artifacts) explains how subagent outputs become workspace artifacts.