Tasks are the distinct journeys an agent can run, each with its own objective, step-by-step instructions, tools, and — optionally — its own execution model.
Overview
Tasks are described in the UI as "Tasks define different journeys allowing you to structure different flows your agent can execute." Each task bundles an objective, a set of step-by-step instructions, the tools it's allowed to use, optional conditions for when it runs, and (optionally) its own execution model. At runtime the agent detects which task fits the user's request and runs it.
Structuring an agent into clear tasks makes its behavior predictable: instead of one giant instruction set, each journey is scoped and tooled on its own.
Note: Tasks is the current name for this feature, but the older name Topic still surfaces in a few places you'll see below — the task list's Topic Name column, the Topic Execution prompt type, and trace entries logged as a Topic Selection. These refer to the same thing as a Task.
Creating a Task
Use Add Task to open the full-page task editor and fill it in:
Field | Description |
|---|---|
Objective (required) | "What should this task accomplish? Describe the goal clearly." Example: "When a new marketing team member joins and needs access to brand guidelines, social media accounts, and analytics platforms." |
Instructions | The ordered, "Step-by-step actions the agent must follow in sequence." Add steps one at a time. |
Tools | "Actions the agent can take. The agent picks the right tool based on context." |
Conditions (optional) | "The task only runs when the conditions are met." |
Execution model for this task | By default the task inherits the agent's model; override it here when one journey reads better in a different model's voice or needs more reasoning depth. |
Give the task a name in the header and Save. Save stays disabled until the task has a name and you've made a change.
Tool Selection Strategy: Routed vs Direct
Tool selection controls how all of an agent's tasks are exposed to the model. Open it from the task list header and pick one of two strategies. You need Edit access to the agent to see Tool selection.
Strategy | Description | Tags |
|---|---|---|
Routed | "Tasks are grouped behind a single router tool that dispatches at runtime." | Recommended · Scales past ~15 tasks |
Direct | "Every task becomes its own tool. The model picks directly via function calling." | Fastest · Best under ~15 tasks |
Use Direct for a handful of tasks where speed matters; switch to Routed as the agent grows past roughly fifteen tasks so the model isn't overwhelmed with choices. With Direct selected, the Task Detection model isn't used — the main model picks tasks directly. The header shows the current strategy, plus a +N badge when this agent overrides the Task Detection or Task Execution model.
Task Processing Models
The Tool selection dialog also has a Task processing models section — per-agent overrides for the models set on the Models page:
Task Detection — picks which task to run based on user input. Not used in Direct mode, where the main model picks tasks directly.
Task Execution — runs the selected task and generates step-by-step actions.
Each model shows Default until you pick a different one, then Custom. Click Reset to go back to the default model.
What Happens at Runtime Under Each Strategy
Both strategies expose your tasks to the model as tools — the difference is how many:
Routed — the model sees one router tool. Its input is simply the task name, chosen from the list of your enabled tasks (each task's description tells the model when to pick it). One tool in the catalog no matter how many tasks you have, which is why it scales.
Direct — each task becomes its own tool, named after the task (a "set" variant when no journey is active, and a "switch" variant once one is). The model picks the task by calling its tool directly — faster, but every task adds an entry to the tool catalog the model must reason over.
In both cases, tasks whose governance rules don't pass for the current user are filtered out before the model ever sees them. When the model selects a task, the task's step-by-step instructions are injected into the conversation as the tool's result, so the very next reasoning step runs under that task's rules, tools, and (if set) its own execution model. Every selection is logged as a "Topic Selection" entry in traces.
Task State at Runtime
Each task runs as its own thread inside the conversation. The runtime keeps a per-task state record holding which agent triggered it, its current topic, and its own loop counter — separate from the conversation-level state. Practically this means: a task only sees the conversation history that belongs to it (its own messages, not the whole session), its loop-limit budget is counted separately, and instructions it sets don't leak into other tasks. When the task needs a final answer in a specific shape, the expected output format is appended to the model's instructions at the end of the run.
Dynamic Task Instructions
Besides the static instructions you write in the task editor, a task can carry a dynamic-instructions automation. When the task is selected at runtime, that automation runs and its output is appended to the task's written instructions before they're handed to the model — useful when part of a journey's guidance depends on live data (current promotions, per-customer policy, and so on).
Managing Tasks in the List
The task list shows each task with its Topic Name, Description, Owner, and Last Updated. Each row has an enabled toggle so you can turn a task on or off without deleting it (tasks are on by default). Row actions let you Edit, Share, and Delete a task — deleting asks you to confirm because it can't be undone. Search by name to find one quickly.
If you haven't made any yet, the empty state reads No Tasks — "You haven't created any tasks yet." Created On and Last Updated By columns are also available, hidden by default — turn them on from the column-visibility control, or hover the Last Updated date for the same detail as a tooltip. This applies to a team's Tasks list too.