Every workspace ships with a few specialist agents and lets you define your own. A chat session either binds to one agent, or runs as an orchestrator that delegates to all of them as sub-agents. This page covers both, plus member clones and the way agents learn skills over time.

Built-in agents

Every workspace is seeded with three specialists. They're marked built-in, so they can't be edited or deleted — they're the baseline every team gets:

DevOps— owns the env's runtime: docker-compose, containerization, and local dev environments. It drives the env lifecycle (start, stop, rebuild, read logs, wait for health) through the docker tools.
QA — exercises the running feature in a real browser via the QA browser, following test plans and reporting what it finds. You watch it work live in the QA Browser tab.
Security — reviews the changed code (scoped to the branch diff) for injection, broken authorization/IDOR, leaked secrets, unsafe deserialization, XSS, and weak crypto.

Each built-in ships with a set of seed skills — concrete recipes and checklists that make it useful from the first turn (see self-learning skills below).

Custom agents

Define your own agents under Settings → Agents. An agent is mostly a name, a description, and a system prompt:

Name and description— the description doubles as the "when to use me" hint the orchestrator reads when deciding whether to delegate.
System prompt— the persona and rules that drive the agent's turns.
Tool toggles— turn individual capabilities on or off (bash, read, edit, write, web fetch, web search, grep, glob). A toggled-off tool is added to the agent's disallowed list, so it physically can't use it.
Greeting— an optional first message the agent posts when a session opens. Leave it blank and withvibe generates one from the agent's persona.

Custom agents are workspace-scoped. Useful examples: a brand-voice reviewer, an accessibility checker, a data-migration specialist, or a domain expert that knows your product's rules.

Orchestrator mode & sub-agents

When a chat session is not bound to a specific agent, the main chat runs as an orchestrator. It can see every enabled agent in the workspace and delegate work to them as sub-agents — the model spins up an agent in its own context, hands it a task, and folds the result back into the conversation.

You prompt the orchestrator in normal chat.
It decides a task is better handled by a specialist (or by a parallel read-heavy survey) and delegates to one of the workspace agents by name.
The sub-agent runs with its own system prompt, its own allowed tools, and its own skills, then returns a result.
The orchestrator continues, using that result.

Bound session vs. orchestrator

If a session isbound to one agent, sub-agents are not loaded — that agent's persona and skills drive every turn. The orchestrator only appears in unbound main-chat sessions. This is why a focused 1:1 with the Security agent stays on-task, while the default env chat can pull in whoever it needs.

Member clones

A member cloneis an agent that stands in for a specific teammate. When you create one, withvibe drafts its persona from that person's profile (name, role/positions, bio) and their recent messages, so it answers from their perspective — a CEO clone reasons about strategy, a designer clone about UX, and so on.

Ownership — only the person a clone represents can edit or delete it. You can have more than one clone.
Escalation — when a question genuinely needs the real person, the clone escalates to them via ask_human instead of guessing.
Training— only the owner can teach a clone. In a session where someone else is talking to your clone, it can read your memory but can't write new skills or memories — it's consumption-only.

Self-learning skills

Agents accumulate skills— short, reusable rules and recipes that make them better over time. An agent writes a skill itself, mid-turn, when it learns something worth remembering (the "always rebuild after editing the compose" kind of rule). You don't have to approve each one.

Scope — a skill is either workspace (always applies to that agent, everywhere) or env (applies only in the env where it was learned).
Per-agent — skills belong to the agent that wrote them; other agents never see them.
Where they live — the database is the source of truth, mirrored to .claude/skills/<slug>/SKILL.md in the env so the agent can also discover them as native skills. The mirror is rewritten every turn, so deleted skills disappear cleanly.

You can see how many skills (and context files) an agent has in a given env from the Agents panel.

Enabling agents per env

Not every agent belongs in every env. From an env's Agents panel you can disable an agent just for that env (and re-enable it later) without touching the workspace-level definition. Disabling is idempotent and reversible — it only changes which agents are available inside that one environment.