Agents
Autonomous specialists that combine multiple skills with a defined persona to handle complex, multi-step tasks on your behalf.
What agents are
An agent is a specialist with a defined role, a set of instructions, and access to one or more skills. When you hand work to an agent, it decides how to approach the task, which skills to invoke, and in what order - then executes autonomously and returns its results.
This is the key difference between agents and skills. A skill is a single, repeatable workflow - like running a security review or creating a git commit. An agent is a persona that can orchestrate multiple skills together, making judgment calls along the way. Think of skills as tools in a toolbox, and agents as the specialists who know which tools to pick up and when.
For example, a "Builder" agent might receive a feature request and decide to first run a planning skill, then implement the code incrementally, then run a code review skill before presenting the finished work. No single skill covers that entire workflow - the agent ties them together with its own reasoning.
Built-in agents
PandaOS ships with a set of pre-configured agents covering common roles - planning, code review, UI design, QA testing, and more. Each built-in agent comes with curated instructions and a pre-selected skill set tuned for its domain. You can browse available agents from the sidebar catalog, where each listing explains what the agent specializes in and the kinds of tasks it handles well.
Built-in agents are ready to use immediately and serve as good examples of how to structure your own custom agents.
The @mention interface
To invoke an agent during a conversation, type @ followed by the agent's name in the chat input. This hands the current task to that agent, which then works through it autonomously.
The agent's output appears as a distinct card in the conversation thread, making it easy to see what the agent produced separately from the rest of the discussion. You can @mention different agents at different points in a conversation - for instance, @planner to break down a feature, then @builder to implement the first slice.
Because agents return structured output rather than blending into the chat, you get a clear audit trail of who did what and can review each agent's contribution independently.
Creating custom agents
When the built-in agents don't match your workflow, you can create your own. In the agent editor you set:
- A name that you will use to @mention it
- A description of what it does, which is what the roster shows and what the model reads when deciding to use it
- Instructions that define its persona, priorities, and approach - this is where you encode domain expertise, team conventions, or specialized judgment
- Skills, apps and integrations it may draw on, which is what the agent is actually capable of doing
- Scope, whether the agent belongs to this project or follows you everywhere
- Default mode, how much autonomy it starts with
The instructions are the most important part. They shape how the agent reasons about problems, not just what tools it has access to. A "Frontend Reviewer" agent and a "Security Reviewer" agent might share the same code-review skill but apply it through completely different lenses based on their instructions.
Once saved, your custom agent is available via @mention across all your chats. You can edit, duplicate or delete it at any time, and a built-in agent you have modified carries a Reset to defaults control that puts the shipped version back.
Giving an agent its own model
An agent can carry a model binding, so the right work runs on the right model without you switching by hand. The editor's model section offers three modes:
| Mode | Behaviour |
|---|---|
| Inherit | The agent runs on whatever the chat is already using. This is the default. |
| Tier | The agent runs on your High, Medium or Low tier for whichever connection is active. A planner on High and a quick formatter on Low keeps cost sane without pinning either to a model name that will be superseded next month. |
| Model | The agent is locked to one connection and one model. When it activates, PandaOS switches the harness if it has to, then switches back when the agent is done. |
An agent can also carry a reasoning effort override, so a reviewer thinks harder than the chat that called it.
The first time an agent switches model automatically, PandaOS tells you it happened. You stay in control: the Tools menu in the chat bar carries a toggle that disables agent-driven model switching entirely, and with it off every agent runs on what you picked.
Agents that keep working
An agent handed a long task keeps going while you do something else, and you can stop it at any point: cancelling a running agent ends the run cleanly instead of leaving a half-finished turn behind.
Agents are not limited to chat. An automation can delegate a step to one, which is how a scheduled workflow gets an agent's judgment rather than a single prompt. Agents work the same way on every harness, so an agent written while you were on Claude Code still behaves when you switch to Codex or OpenCode.
When to use agents vs. skills
Use a skill when you have a clear, single-step task - "/git-commit", "/security-review", "/code-review". Skills are direct and predictable.
Use an agent when the task requires judgment, multiple steps, or a specific perspective. Agents shine when you need someone to own a workflow end-to-end rather than just execute one piece of it. If you find yourself chaining several skills together in a predictable pattern, that pattern is a good candidate for wrapping in a custom agent.