diff --git a/docs.json b/docs.json
index 4a93aba9..7aff813b 100644
--- a/docs.json
+++ b/docs.json
@@ -134,6 +134,7 @@
               "index",
               "overview/features",
               "overview/concepts",
+              "overview/tasks",
               "overview/why-kernel"
             ]
           },
diff --git a/overview/tasks.mdx b/overview/tasks.mdx
new file mode 100644
index 00000000..74705ce5
--- /dev/null
+++ b/overview/tasks.mdx
@@ -0,0 +1,72 @@
+---
+title: "Tasks"
+description: "Give KERNEL the goal behind your agent's work so it can connect actions, outcomes, and recommendations"
+---
+
+A browser session tells KERNEL what your agent did. A task tells KERNEL what your agent was trying to accomplish.
+
+Declare a task once, then attach its task ID to the KERNEL work your agent triggers and the outcome it reports. KERNEL can connect those otherwise separate operations to the same goal without taking control of your agent loop.
+
+## Why declare a task
+
+Your agent already knows its goal, constraints, and definition of success. KERNEL normally sees only the individual operations it runs. If a browser session fails, that operation alone doesn't show whether the site blocked the browser, the agent chose the wrong route, or the result simply didn't satisfy the user's request.
+
+A task supplies that missing context. It lets you:
+
+- **Keep one thread across tools and retries.** Group browser sessions and repeated attempts under the outcome they serve.
+- **Submit actionable reports.** Record relevant intent, conditions, and blockers during the run, then report one terminal outcome against the goal.
+- **Separate execution failures from agent failures.** Task context helps KERNEL distinguish a blocked browser or broken login from a plan that used the wrong site or stopped too early.
+- **Improve the next attempt.** Verified outcomes can support task-specific recommendations, such as which route or browser configuration works best for similar work.
+
+Declaring a task doesn't require you to replace your framework or move the agent loop into KERNEL. Your harness still decides what to do next. The task ID gives KERNEL enough context to help with the parts it runs.
+
+## Choose the right scope
+
+Create one task for one user-visible outcome. Attach every relevant operation to it, even when the agent changes routes or starts another browser.
+
+For example, "download the latest invoice from the billing portal as a PDF without changing account settings" is one task. Navigating to the portal, signing in, opening the invoice, and downloading the file are steps within that task, not separate tasks.
+
+Start a new task when the desired outcome changes. Don't create a task for every click, page, or tool call.
+
+## Describe a useful task
+
+A good declaration gives KERNEL the context needed to evaluate the result without prescribing every action the agent must take. Include:
+
+- **Goal:** the outcome the user expects.
+- **Constraints:** limits such as allowed domains, time windows, spend, or actions that require approval.
+- **Success criteria:** evidence that proves the goal is complete.
+- **Relevant context:** non-sensitive information that changes how the task must be performed.
+
+<Note>
+  Don't put passwords, session cookies, payment details, or other secrets in a task description. Use [vaults](/vaults/overview), [profiles](/browsers/profiles), and [managed authentication](/auth/overview) to give a browser access without exposing credentials to the agent or its logs.
+</Note>
+
+## Use the task throughout the run
+
+The basic flow is:
+
+1. **Declare the task.** Describe the goal, constraints, and success criteria, then keep the returned task ID.
+2. **Associate the work.** Pass the task ID when the agent uses a KERNEL interface that accepts it. Reuse the same ID across retries and route changes.
+3. **Report useful observations.** Submit nonterminal reports for relevant intent, conditions, or blockers. A task can have multiple nonterminal reports, and none of them closes the task or determines its outcome.
+4. **Verify the outcome.** Check the source of truth for the task, not only the last tool response. A successful click or page load doesn't prove the user's goal was met.
+5. **Report the outcome once.** Submit one terminal outcome against the task ID. For a failure, include what the agent expected, what happened instead, and the last verified step.
+
+## Report what the user experienced
+
+Nonterminal reports explain what happened during the run. They don't mean the task succeeded or failed, and their absence doesn't imply failure. Submit the terminal outcome only after the work stops and the agent verifies the result as far as it can.
+
+Report success only when the success criteria are verified. Report failure when the task reaches a terminal condition without producing the required outcome. If the result is unclear, say that the outcome couldn't be verified instead of guessing.
+
+Useful failure context includes:
+
+- the operation or browser session where the task stopped;
+- the last step that completed successfully;
+- the expected and observed result;
+- whether the failure involved access, authentication, site behavior, browser execution, or the agent's plan; and
+- a timestamp and any safe-to-share error message.
+
+You don't need to send the agent's full prompt or chain of thought. Send the smallest amount of context that lets KERNEL reproduce the condition, identify the failing layer, and improve the next attempt.
+
+<Tip>
+  One goal, one task ID, any relevant nonterminal reports, and one verified terminal outcome is the default. Keep the same task ID when the agent retries the same goal.
+</Tip>