Your own agents

Besides the six seeded role agents, you can create as many of your own agents as you like — a second QA agent for a different repository, a technical writer, an agent that runs on a different CLI or a different model entirely.

Creating an agent

Click the + next to Agent Chats in the sidebar. The dialog offers:

• From scratch — an empty agent; you fill in everything below.
• From template — a list of templates, built-in ones (the six roles) and any you have saved yourself, each showing its name, description, and how many skills and rules it carries. Picking one copies those fields, skills and rules onto a new agent; editing the new agent never changes the template it came from.

Either path lands you on the new agent's Settings tab to finish setting it up, then Save.

Fields on the Settings tab

A model you type in that the selected provider does not list is flagged, not rejected outright — on the CLI providers the curated list is a shortlist, not a hard contract, since the CLI itself accepts any --model value. On an HTTP provider a name outside its catalog is a real mismatch and is marked as an error.

The Provider dropdown lists every provider that is actually usable right now: the four local-process CLIs (Claude Code, Cursor, Antigravity, OpenCode) that are available whenever their binary is on PATH, plus any OpenAI-compatible endpoint you have connected on the LLM Connection settings page (OpenAI, Anthropic, Google Gemini, Groq, or a custom endpoint such as LM Studio, Ollama or vLLM). A provider that TaskTrooper knows about but cannot execute on this build is never offered here, even though it may still be listed elsewhere as "coming soon".

If the agent's tool policy allows any of the browser or mobile tools (or has no restriction at all, which allows everything), the form warns when the chosen model has no vision — those tools return screenshots, and a text-only model cannot judge a screenshot it cannot see.

Two fields exist on every agent but are not yet exposed on this screen, so they are set through the admin API rather than a form control:

• Effort (low/medium/high/xhigh/max) — the CLI effort level a session runs at. Empty uses the CLI's own default.
• Max turns — a per-agent turn ceiling for one Claude Code session. 0 uses the executor's own default.

Columns

The Columns tab lists every non-backlog board column with a checkbox. Checking one subscribes the agent to it, so a task landing in that column is dispatched to the agent even when it is not the task's assignee — this is how the seeded QA agent gets woken by "Ready for QA" without being anyone's assignee. Leave a custom agent unsubscribed if it should only ever work a task it is explicitly assigned.

Skills, rules, and tech stacks

The Skills tab lists the agent's skills grouped into sections: a General section for skills that apply regardless of language or framework, plus one section per tech stack you add with "Add Tech Stack" (name + description, e.g. "Go" or "React"). Filing a skill under a stack is one field on the skill's own form (or "General" to leave it unscoped); deleting a stack does not delete its skills, it just files them back under General.

The Rules tab lists the agent's rules with name, priority, status and created date; a rule's content and priority (higher runs first when rules would conflict) are edited the same way skills are — see Skills and rules for what goes in each and the budgets that apply.

Memory

The Memory tab (per agent) and the sidebar's "Team Memory" link (shared across every agent) both open the same memory manager: a scope filter, a list of saved memories with their scope badge, and forms to add, edit or delete one. See Memory for the four scopes and what content is refused.

Saving an agent as a template

POST /admin/agents/:id/template snapshots an agent's fields plus its current skills and rules into a template with the same name (calling it again on the same agent updates that template rather than creating a second one). This is available through the admin API today; use it to turn a hand-tuned agent — your own QA setup for a particular stack, say — into something you or a teammate can spin up again with "From template" without retyping the prompt, skills and rules by hand.

Mixing runtimes on one board

Nothing requires every agent on a board to run the same way. One agent's Provider can be Claude Code, another's Cursor, another's a plain API key on Anthropic or OpenAI, and they all work the same board: each task is dispatched to whichever agent is assigned or subscribed, and that agent's own Provider and Model decide how its session actually runs. See Agent CLIs and API providers for what each provider needs.

This is a reasonable way to, for example, keep your subscription-backed Claude Code sessions for the roles that write the most code, and put a lighter, cheaper API model on an agent that only triages incoming bugs.

Deleting an agent

The delete button lives on the agent's own layout, next to its name (not on the seeded six alone — any agent can be deleted). Deleting it:

• Removes the agent's skills, rules, memories, reflections and chat sessions with it — they belong to the agent and do not outlive it.
• Does not delete its tasks. Every board task the agent was assigned to has its assignee cleared instead, so the task stays exactly where it is on the board, unassigned, for you to hand to someone else.
• Does not affect any template saved from it, or any other agent created from that template.

There is no undo — re-creating an agent with the same name does not restore its skills, rules or memory history.

A worked example

Say you want a second QA agent dedicated to a mobile app repository, running on a cheaper API model instead of your Claude Code subscription:

1. Open the + next to Agent Chats, pick From template, and choose the built-in qa-agent template. This copies its manual-testing skills and rules onto a new agent.
2. Rename it (e.g. "mobile-qa") and switch Provider to an API endpoint you have already connected on the LLM Connection settings page; pick a model that supports vision, since QA relies on screenshots.
3. On Columns, subscribe it to Ready for QA, In QA and Done for the mobile repository's board, and leave the original qa-agent subscribed only to the repositories it should still cover — subscriptions are per-agent, not per-repository, so this only works cleanly when each repository's board is otherwise handled by a different agent for that column.
4. On Skills, add a "Flutter" tech stack if this repository's QA notes are framework-specific, and file any new skill you write under it.
5. Save. The new agent now works exactly like a role agent from the outside — it appears on cards, can be reassigned tasks, and builds up its own memory and performance history independently of the one you copied it from.