ROOT agent
Designate your first orchestrator as the workspace ROOT and grant it meta-tools to manage itself.
The ROOT agent is the single top-level orchestrator in your workspace. It has access to meta-tools — for creating and updating agents and skills, attaching agents/skills/MCP servers/connectors, and managing its own cron schedules — that let it extend the workspace on your behalf: writing new skills, creating agents, and wiring them together, all from within a chat or automation.
How ROOT designation works
You do not pick the ROOT manually. The first orchestrator agent you create in a workspace is automatically designated ROOT. Open Settings → Safety → ROOT agent to see which agent that is and configure its powers.
The row itself states the answer before you open it: the ROOT's name and its autonomy level, or No ROOT agent yet when you have not created an orchestrator.
Configure the ROOT's powers
ROOT powers are all off by default on a freshly auto-designated agent. Open Settings → Safety → ROOT agent to opt in:
Allowed actions
Toggle each meta-tool grant independently. A single grant can unlock a set of related tools — the attach grants also unlock their detach_* mirror, and the schedules grant unlocks the full cron CRUD (RootGrants in packages/shared/src/root-agent.ts):
| Grant | Meta-tool(s) unlocked |
|---|---|
| Create agents | create_agent |
| Update agents | update_agent |
| Attach agents | attach_agent, detach_agent |
| Create skills | create_skill |
| Update skills | update_skill |
| Assign skills | attach_skill, detach_skill |
| Create MCP servers | create_mcp |
| Attach MCP servers | attach_mcp, detach_mcp |
| Create connectors | create_connector |
| Attach connectors | attach_connector, detach_connector |
| Manage schedules | create_schedule, update_schedule, toggle_schedule, run_schedule |
Only enabled grants appear as tools in the ROOT agent's system context. Disabling a grant removes the tool immediately on the next job.
Autonomy level
Every agent holds one setting per tool it has: Run without asking, Ask for approval or Block, shown on its Autonomy tab, and that setting is what applies. The autonomy level is what a setting starts with, when an agent is created or a tool becomes available to it (a skill, a connector, an MCP server, a new version of Nodal):
| Level | A new tool starts on |
|---|---|
| Propose and confirm | Ask for approval, for every tool that asks by default (commands, scripts, meta-tools, connector writes, third-party tools). The others run without asking. |
| Autonomous, gate destructive | Run without asking, except a tool declared destructive (skill scripts, coding tasks, a connector delete), which asks. Commands follow the agent's shell checklist. |
| Fully autonomous | Run without asking, except what runs code on this machine (commands, scripts, coding tasks), which asks. Catastrophic commands always ask. |
The default is Propose and confirm. Changing the level changes no existing setting. Apply to all agents, under the level, sets every agent's tools (and its shared-file setting) from the level, after a confirmation; server settings and rules for all agents are removed, rules limited to one folder are kept.
Save
Click Save after adjusting grants and autonomy. Changes take effect on the next job — already-running jobs are not affected.
Approvals queue
When the ROOT runs in Propose and confirm mode, each meta-tool call appears as a pending approval on the Approvals board in the rail. You can approve or reject each call individually, with a note. The ROOT resumes immediately after approval.
The second gate: an agent's own team
A grant says what the workspace allows. A separate per-agent setting, may_change_team, says whether that agent may rearrange its own team, and it is off by default — including for the ROOT, and including for every agent that already existed when the setting shipped.
While it is off, the three team meta-tools (create_agent, attach_agent, detach_agent) are not in the list the runner computes for the job, so the model never sees them. It is not a refusal at call time.
The setting can only take away. It never grants a tool that a disabled grant already refused.
Example: a self-extending orchestrator
With create_skill and attach_skill enabled in Propose and confirm mode:
- You chat with the ROOT: "Create a skill that can fetch the current Bitcoin price and assign it to the Market-Watcher agent."
- The ROOT proposes a
create_skillcall — you approve. - The ROOT proposes an
attach_skillcall — you approve. - Market-Watcher now has the skill and can use it immediately.
Notes
- There is exactly one ROOT per workspace. The auto-designation cannot be changed — the ROOT is always the first orchestrator created.
- The ROOT receives meta-tools in addition to any skills you assign to it manually on the agent's Skills tab.
- Revoking all grants does not delete the ROOT designation — the agent remains structurally ROOT (top of the hierarchy, primary chat target) but holds no meta-tools until you re-enable them.
- The learning loop (when enabled) runs reflection post-job and writes skills with
created_by = 'agent'. The ROOT curator consolidates these independently of the meta-tool grants.
Coding with an agent
Hand a real development task to Claude Code or Codex running under your own subscription — read-only by default, approved by you, and traceable afterwards.
Reference
Reference for everything Nodal-Agents ships with — skills, connectors, MCP servers, models, and the CLI/dashboard/API surface.