Agent Types

Every agent has a type, chosen when you create it. The type decides what the agent does with a message.

Code agents appear only when the coding agent is enabled in Settings.

Conversational

The default, and the right answer for most work — research, writing, analysis, support. It keeps full multi-turn history and runs the ReAct loop against whatever tools you gave it.

Code

A conversational agent with repositories and database connections attached. It can search code semantically before reading or editing, which is what makes it useful on a codebase too large to put in a prompt.

Assign its repos and DB configs in the agent editor; configure them under Settings → Repos and Settings → DB Configs. See Code repositories.

Orchestrator

Wraps a workflow. Sending it a message triggers that workflow rather than starting a conversation, which lets you expose a multi-step pipeline as something that looks like a chat. It still keeps the conversation: the recent turns reach the workflow's model steps, and its answer is what the workflow made (the workflow's Result). An Orchestrator agent is made with Deploy as Agent on the workflow — see Creating Workflows.

It runs the workflow wherever the agent is reached: in Chat, through the chat API, on a messaging channel it is assigned to, and when an agent schedule targets it.

Use it when the work is fixed and you want a simple front door to it. If the agent should decide what to do, you want conversational or Team instead.

Team

A lead with members: other agents of yours, each with its own tools and approvals. The lead answers small questions itself and hands bigger or parallel work to its members, one at a time (it waits for each) or as a team (they work in parallel and share a task list), then answers with what they found. The API and exported files store this type as delegate.

Use a Team agent when you want one entry point in front of specialists: a support agent, a billing agent and an engineering agent behind one address, or several agents working on parts of one job at once. What each member is for is written in its description, which is what the lead reads when it decides who does what; a vague description is a misroute.

A Team agent also works as a workflow's Agent step. See Team agents for its setup, Watching a team work, and A team in a workflow.

Handing work to an Orchestrator agent runs its workflow. If that workflow stops to ask a person, the lead is told where to answer it and carries on without its result. When a member's call needs approval, approving it runs the call as that member, under its own tools and policy.

Helpers: splitting work without a Team agent

Any agent can hand a focused task to a short-lived helper, if you turn on Can send helpers (the native spawn_subtask tool). A helper runs with a subset of the agent's tools and returns; several can work at once from one response, and in the app's chat one can work in the background. See Helpers.