Developer docs Guides
Agents & skills
Configure the agent half of the team: models and tools, the skills they draw on, agent-owned meta-tasks, and how humans stay in the loop.
What an agent is
An agent is a named member of the project team. The roster — not a prompt — is the source of truth: meta-tasks, runs, and conversations all resolve against it.
| Field | Purpose |
|---|---|
| Name | Roster identity, referenced by tasks and conversations |
| Model / provider | Which LLM serves the agent, and through which endpoint |
| Base URL / API key | Provider credentials for direct (non-gateway) calls |
| Enabled tools | The built-in tool surface this agent may use |
| Skills | Named skills from the pool that the agent loads |
Skills
Skills are the team’s shared playbook. The official skills pool is mounted read-only into every workspace sandbox, and each agent loads the subset named on its roster entry. Skills are plain, auditable files — anything the team learns can be promoted into one.
Agent-owned meta-tasks
A meta-task can bind an agent instead of a script. At run time the platform starts the agent in the workspace sandbox, streams its progress to the board, and keeps the full conversation attached to the task — open the task drawer to watch it work, or talk to it mid-run.
Scripts can read the roster to coordinate with their teammates:
agents = list_agents()
for a in agents:
print(a["name"], a["model"], a["skills"])Tools and MCP
An agent’s enabled tools bound its built-in surface. Project MCP servers (configured per project, streamable-http) extend it with external actions — repository writes, search, anything the integration exposes. Scripts reach the same servers through mcp().
Human in the loop
- The agent asks when it needs you — ask_user_question parks the task in pending_approval
- Your reply continues the same conversation, and the run resumes with it in context
- Risky actions stay gated: approvals are explicit, and everything the agent did is on the task record