Agents and teams
Creating and configuring agents — models, tools, sandboxes, evolution; agent teams as pipelines.
An agent is a named configuration: a model, a system prompt contract (purpose,
constraints, completion checks), tools, a sandbox, access grants. Managed on
the Agents page (/agent-config).
#Creating an agent
Three ways:
- From a template — ready-made roles: Lead, Developer, Reviewer, QA, Analyst and more.
- From a description — describe in plain words what the agent should do; the builder drafts the name, purpose, constraints and completion checks (as a draft until you confirm).
- Manually — the full form: model, tools, MCP servers, sandbox.
#What is configurable
The agent switch is the toggle in the bottom-right corner of the mini-card: a disabled agent starts no new runs — API starts, intake, triggers and delegation all refuse — while runs already in flight finish. Every flip is recorded in the audit log.
| Setting | What it gives |
|---|---|
| Model | The model name; if the default provider does not have it, the call is routed to a provider that declares it |
| Tools | Allowlist/denylist over the shared catalog (files, commands, web, knowledge, skills, artifacts, MCP) |
| Capabilities | Declarative permissions ("read files", "network", "modify files") — delegating agents and policies rely on them |
| Sandbox | The execution profile: image, memory, CPU, tmpfs limits, cache variables (see Administration) |
| Notification channels | Where ask_human questions are delivered |
Constraints and completion checks are part of the contract: they enter the prompt and the result verification.
#Background commands
Long sandbox operations — dependency installs, builds, big test suites — no
longer block the agent. run_command with background: true runs detached:
the tool returns an operation id immediately, the agent keeps working, and
the result (exit code + output tail) arrives automatically as a follow-up
message in the conversation.
- the run does not finish while background operations are in flight; ready results are drained in one batch — the agent spends a single turn incorporating them instead of waiting for each command;
- each background command's live console is visible in the trace (the pinned "Live background operations" panel);
- cancellation — the
kill_operationtool (kills the process tree by marker, never a foreign process); - background commands get their own time budget: 900 seconds by default,
a 1-hour ceiling (
timeout_secup to 3600,KERNEL_BG_TOOL_MAX_SECONDS); ordinary commands stay at 300/900 (KERNEL_TOOL_MAX_SECONDS).
Details and delivery guarantees — docs/agent-async-operations.md.
#Agent evolution
The agent can propose changes to its own configuration (the agent_propose
tool): the problem with evidence (run ids), the change and the expected
effect. The proposal lands in the agent's card as a draft.
Applying it goes through the quality loop: a proposal is applied only on top of a fresh green evaluation run (golden cases from real runs, optionally a calibrated LLM judge). A human decides; a proposal can never widen the agent's powers. Details — docs/agent-quality-loop.md.
#Teams
A team is a slot manifest: roles (Developer, Reviewer, QA…), their bindings to concrete agents, the execution protocol (pipeline/DAG), rework limits and a budget. Built from a description ("A team with quality control: Developer implements, Security and QA review, Reviewer accepts") and versioned.
Launching a team from chat or a trigger starts a DAG execution with review gates — see docs/agent-teams.md.
#Proposals and versions
Every applied change creates a new version of the agent definition; the version history with who and why is in the agent's card. Rollback is picking a previous version.