> ## Documentation Index > Fetch the complete documentation index at: https://docs.getswan.com/llms.txt > Use this file to discover all available pages before exploring further. # How Swan runs your work > The three ways Swan does work, and how approvals differ between chat and background runs. Swan does work in three ways, and how it behaves — especially around anything that needs your approval — depends on which one is happening. ## The three ways work happens **Chat conversations.** You talk to Swan directly, in real time. Swan reasons, calls tools, and replies in the conversation. **Trigger runs (background).** A [trigger](../triggers/how-triggers-work) fires on its own — on a schedule, from a webhook, from a CRM event, and so on — and Swan works through its instructions without anyone watching live. **Delegation to sub-agents.** Inside a chat conversation or a trigger run, Swan can hand off a batch of tasks to sub-agents — one independent agent run per task, each with its own full reasoning and tool access. A task comes in two shapes: **company-targeted**, where the sub-agent's run is attached to a specific company and starts with that company's context already loaded, or **general-purpose**, with no target at all. (Companies are the only entity a task can target — there's no contact-targeted delegation; work on a contact happens inside their company's task or a general one.) This is how Swan processes things like "research these 40 companies" without doing all 40 in a single thread. Delegating requires enough credit buffer to cover the batch: your org needs at least 5 credits of buffer available per task before Swan will dispatch the work, and it's rejected if that buffer isn't met. Stopping the parent run also cancels the batch it dispatched — sub-agents that haven't started are cancelled outright, and ones mid-run are aborted. ### Working through a list Delegation is also how you process a static list once — a backfill, a migration, "for each of these accounts, check X." Two ways to start one: * **Ask Swan in chat**, describing or pasting the list — up to 100 tasks per batch; for a bigger list, Swan splits it into multiple batches or you can use the CSV upload. You can attach extra context to individual entries, and Swan appends it to that task's instructions specifically. * **Upload a CSV of companies** — Swan creates any companies that don't already exist, up to 1,000 per upload. This path is a bulk import: you map your columns (domain, name, and the like) and it costs no credits. It doesn't attach per-company instructions the way chat delegation does — to run instructions against those companies, delegate them in chat (the path above, 5 credits per task). Uploaded companies then flow into your normal automations. Swan works through the list at a throttled rate rather than firing everything at once, to avoid overloading your CRM, providers, and senders. A task whose run fails outright gets one retry; if it fails again it's reported as failed rather than retried indefinitely. When every task has finished, Swan posts a summary back into the conversation that started it — how many succeeded, partially succeeded, or failed, total credits used, and a link to the results, with any structured data bundled into a downloadable file. If you started it from Slack, you get a completion message there too. ## Approvals work differently depending on where the run happens Some actions are configured to require a human sign-off before Swan executes them (for example, sending a message, or another action your org has marked as protected). What happens next depends on the context: * **In a chat conversation**, Swan pauses and asks you directly — you'll see the pending action in the conversation and can approve or reject it before Swan continues. * **In a trigger run or inside a delegated sub-agent run**, Swan never pauses to wait for you, because there's no one there to ask in real time. Instead, it skips the protected action, continues with the rest of its work, and lets a human know it needs approval — typically by posting in Slack or creating a task — so someone can review and approve it afterward. This means the same instruction can behave differently depending on whether you typed it into chat or it ran as part of a trigger. See [approvals](../outreach/approvals) for how this plays out specifically for outreach sequences. ## Where results land * **Chat replies** — for anything you asked Swan directly, the answer or outcome appears back in the conversation. * **Desk tasks** — anything Swan wants a human to review or act on shows up as a task. See [Desk and tasks](../workspace/desk-and-tasks). * **Slack notifications** — for background work, especially anything awaiting approval, Swan posts to Slack if your org has it connected. * **Sequences awaiting approval** — outreach sequences that need a sign-off before sending sit in the approval queue until reviewed. You can always look back at what Swan did and when in [executions and history](../workspace/executions-and-history). ## Common questions **Does a trigger wait for me to approve a protected action before moving on?** No. Trigger runs never pause. They skip the protected action, keep going with the rest of the work, and notify a human (usually via Slack or a task) to get it approved afterward. **Why does chat sometimes look locked or read-only?** This happens when there's a pending tool approval waiting on your decision, or when sub-agents Swan delegated to are still running in the background. You don't have to wait the sub-agents out — pressing Stop cancels the run and the sub-agents with it. **If I delegate a batch of 100 companies, does that run as one long execution?** No — each company gets its own independent sub-agent run, each contributing to the 5-credits-per-task buffer requirement. **How do I see whether a trigger's run actually completed?** Check [executions and history](../workspace/executions-and-history) for the run's status and outcome.