Agent types

An agent type is a reusable definition for an agent’s instructions, model choice, skills, and tools. An agent is a running participant created from a type. Editing a type does not create a task or start an agent by itself.

You can use the bundled types without configuring them first. For a first project, create a squad and choose a workflow. Customize a type when you want the same instructions or tool choices reused across work.

Inspect an existing type

Open Settings → Agent Types → Types, search for a type, and open it. Review its description, model source, System Prompt, Skills, and tool lists.

Bundled examples include Engineer for implementation, Architect for design, and Reviewer for review. Their starting tiers are Standard, Exhaustive, and Deep respectively. Your instance may have overridden these defaults; the resolved model text shows where the current choice comes from.

Tau CloudSwitch to Self-hosted

Changes apply within your Tau workspace. If you can view types but cannot add or save one, ask an administrator for agent-type configuration access.

Self-hostedSwitch to Tau Cloud

Bundled types originate in your installation’s configuration templates. The Settings editor shows template differences and field overrides where available. Review those differences before reverting: a revert restores the template value for the selected configuration.

Create a type

1. Choose + Add type.
2. Enter a unique ID, a name, and a description. For example, use release-writer and Release Writer for an agent that prepares release notes.
3. Choose a model tier. Leave the optional override chain empty unless this type needs its own model order.
4. Write the System Prompt: explain the job, what evidence to use, and what the finished output should contain.
5. Select relevant Skills and configure the tools the job needs.
6. Choose Create. For an existing type, choose Save after editing.

A release-note prompt could be:

Prepare release notes from the changes supplied in the task.
Group the notes into features, fixes, and breaking changes.
Verify claims against the supplied changes and identify anything uncertain.
Return a Markdown draft with a short list of questions for the reviewer.

Keep project-specific facts in the squad or task context so the type remains reusable. Put the desired sequence of participants and review steps in a workflow.

Expertise and flow instructions

systemPrompt contains the type’s full expertise and applies inside and outside workflow flows. Shared includes add operational guidance. Keep planning, implementation, audit techniques, and reporting standards here. Put the order of work, participants, review gates, return paths, and delivery policy in the flow.

Agent types use one expertise prompt. The former flowPrompt field has been removed. Existing saved content is folded into systemPrompt during upgrade, including pinned participant snapshots. YAML definitions should put expertise in systemPrompt and orchestration in the workflow. Existing runs keep snapshots, so subsequent type edits apply to new runs or an explicit flow revision.

Worker and system-only types

Worker choices in workflows, the squad spawn dialog, and schedules exclude disabled types and types marked System-only. Use systemOnly: true in an agent-type YAML definition to reserve a type for a Tau-managed role. It defaults to false for custom types. Manager, System Manager, Consultant, Artifact Builder, and the internal Subagent type are reserved this way; SysOps remains a worker type.

System-only types remain visible in Agent Types administration. The flag describes how a type is used; it does not grant permissions. Workflow validation also rejects system-only participant types, including definitions supplied through YAML or assistant proposals.

Choose tools and skills

Skills provide reusable guidance. Tools Allow and Tools Deny control the tools exposed to the agent. These lists use comma-separated tool names or supported patterns. Deny patterns take precedence. Leaving the allow list unset uses the runner’s available tools; it does not mean no tools. Select tools already available to the type’s runner; entering a name does not install a new tool.

Start with a known working type’s tool choices and narrow them to the job. An allow list is not an access grant: an agent still needs permission to use the target squad or resource, and external services need an assigned connection. Giving a type a name such as “administrator” does not make it an administrator.

When Bigbrain access is shown, Agent tools and Conversation export are separate capabilities. Agent tools also need explicit bigbrain_* tool allowances and an enabled connection assigned to the squad. Conversation export additionally requires human consent for the conversation; enabling the type capability alone does not start exporting history.

Check the result on a small task

Use the new type as a participant in a workflow, then start a small task with a clear deliverable. Confirm that it can access the intended materials, has the expected tools, and produces the requested output. Inspect the actual agent’s model if it differs from the tier: individual and type overrides take precedence.

The CLI can inspect definitions:

tau agent-type list
tau agent-type get engineer

engineer is a bundled type ID; replace it if your instance uses a different type. The CLI also supports creating and updating definitions, but tier selection is currently in Settings. See the CLI reference for login and command discovery.