| name | agent-builder-skill |
| description | How to use the Agent Builder tool's five canvas-mutation operations to inspect and grow your own toolset / skills / teammates / workflows mid-execution |
| allowed-tools | agentBuilder |
| metadata | {"author":"machina","version":"3.0","category":"autonomous"} |
Agent Builder
You are connected to an Agent Builder node. It exposes ONE
LLM-callable tool, agentBuilder, which dispatches to FIVE
canvas-mutation operations via the operation field:
operation value | Purpose |
|---|
inspect_canvas | Read-only view of the canvas PLUS the full catalogue of every tool, agent, and skill you can spawn. ALWAYS call this first. |
add_tool | Spawn a tool node + wire it to your input-tools handle. Idempotent — already-wired tools return success with no change. |
add_skill | Toggle a skill on your Master Skill (auto-creates one if missing). Idempotent — already-enabled skills return success with no change. |
add_subagent | Team-leads only — spawn a delegate agent + wire to your input-teammates. Idempotent — already-wired teammates return success with no change. |
create_workflow | Temporarily disabled. Mutate the current workflow instead. |
Every call is agentBuilder({operation: "<one-of-above>", ...op-specific-fields}). There are no separate tools.
The cardinal rule
Call agentBuilder({operation: "inspect_canvas"}) BEFORE any
mutation. The response carries the full registry of spawnable types
(plus the live canvas) so you can pick the right one in a single
follow-up call instead of guessing. Skipping inspect_canvas means
you're flying blind on what's available.
Hot rebind (default: ON)
By default, tools / skills / teammates you spawn become callable
in the same run, on your very next response. The mutation summary
ends with "Available immediately — call it in your next response."
Take this literally: you may invoke the new tool right away. No need
to tell the user "send another message".
If the user has disabled the "Auto-Rebind Tools After Canvas Changes"
toggle in Settings, mutation summaries end with "Available on your
next turn." In that case the new wiring is staged but not callable
this run — tell the user and stop calling that tool.
The summary text is your signal. Read it.
Operation reference
operation: "inspect_canvas"
No additional fields. Returns:
{
"operation": "inspect_canvas",
"summary": "<live counts: nodes, tools wired, available types>",
"nodes": [{ "id", "type", "label", "key_params" }, ...],
"edges": [{ "source", "target", "source_handle", "target_handle" }, ...],
"you": {
"node_id": "agent-1",
"incoming": [...], "outgoing": [...]
},
"available_tools": [{ "type", "display_name", "description" }, ...],
"available_agents": [{ "type", "display_name", "description" }, ...],
"available_skills": [{ "folder", "name", "description" }, ...]
}
available_tools — every value add_tool({node_type: ...}) will accept, with descriptions.
available_agents — every value add_subagent({agent_type: ...}) will accept (team-leads only).
available_skills — every value add_skill({skill_folder: ...}) will accept.
you.incoming — connections wired TO your handles. Use this to see what tools / skills / teammates you already have.
API keys, prompts, and other secrets are stripped from
key_params. Only safe planner-relevant fields surface
(provider, model, operation, url, query).
operation: "add_tool"
Required field: node_type (string).
Spawns a tool node and wires it to your input-tools handle. Pick
node_type from inspect_canvas.available_tools.
Idempotency: if a tool of this exact type is already wired to
you, add_tool returns success with operations: [] and a summary
like "Tool 'httpRequest' is already wired (node id=…). Reusing
existing instance." Don't loop trying again — the tool is callable.
If the tool has a paired teaching skill, the auto-add-skill
handler enables it too — no separate add_skill call needed.
operation: "add_skill"
Required field: skill_folder (string).
Enables a skill on your Master Skill. Pick skill_folder from
inspect_canvas.available_skills. If no Master Skill is wired to
your input-skill yet, one is created and wired automatically.
Idempotency: if the skill is already enabled=True in your
Master Skill's config, add_skill returns success with operations: []
and "Skill 'X' is already enabled on your Master Skill. No change
needed."
operation: "add_subagent"
Required field: agent_type (string).
Team-leads only (orchestrator_agent, ai_employee). Pick
agent_type from inspect_canvas.available_agents. Spawns a
specialized agent (coding_agent, web_agent, task_agent, etc.)
and wires it to your input-teammates handle. The new agent appears
as a delegate_to_<name> tool on your next turn.
Idempotency: if a teammate of this exact type is already wired
to you, add_subagent returns "Teammate 'X' is already wired
(node id=…). Reusing existing instance."
The new agent starts with empty configuration — the user will need
to set its provider/model after the run. Mention this in your
response.
operation: "create_workflow" — temporarily disabled
This operation is currently disabled. Calling it returns a polite
"temporarily disabled" summary; no workflow is created. Mutate the
current workflow instead via add_tool / add_skill /
add_subagent.
Worked examples
Adding a new tool and using it immediately
User: "Search the web for current weather in Tokyo and tell me."
1. agentBuilder({operation: "inspect_canvas"})
→ summary: "1 nodes, no tool(s) wired to you, 4 tool / 18 agent / 62 skill types available to spawn."
→ available_tools: [..., {type: "duckduckgoSearch", display_name: "DuckDuckGo Search", description: "..."}, ...]
You see no web-search tool wired and one in the catalogue.
2. agentBuilder({operation: "add_tool", node_type: "duckduckgoSearch"})
→ "Added 'duckduckgoSearch' as a tool. Available immediately — call it in your next response."
3. duckduckgoSearch({query: "Tokyo weather today"})
→ search results
4. Tell the user the weather.
Handling an already-wired tool
User: "Add the calculator tool and compute 17 + 25."
1. agentBuilder({operation: "inspect_canvas"})
→ you.incoming includes a tool wired with source_type "calculatorTool".
2. agentBuilder({operation: "add_tool", node_type: "calculatorTool"})
→ "Tool 'calculatorTool' is already wired to you (node id=calc-1). Reusing existing instance."
→ operations: []
3. calculator({a: 17, b: 25, op: "add"}) ← already callable; no rebind needed
→ 42
4. Tell the user the answer.
You did NOT need to retry add_tool or wait for "next turn" — the
existing instance is callable right now.
What NOT to do
- Don't skip
inspect_canvas. It's read-only, cheap, and gives
you the full catalogue + canvas state in one call.
- Don't guess
node_type / agent_type / skill_folder values.
Pick from the catalogues returned by inspect_canvas.
- Don't retry
add_tool / add_skill / add_subagent on success
with operations: []. That's an idempotent success, not a
failure. The existing instance is callable.
- Don't add
agentBuilder to yourself via add_tool (rejected
— avoids recursion).
- Don't spawn another team-lead as a subagent (rejected —
team-leads delegate to specialists, not to other team-leads).
- Don't call
create_workflow — it's temporarily disabled and
will return a no-op summary. Mutate the current workflow instead.
- Don't ignore the "Available on your next turn" wording. If
you see it (toggle is OFF), the tool is staged but NOT callable
this run. Tell the user and stop.