/agent-builder

name: agent-builder
description: >-
  Load immediately after an Agent intent, before the first agent_builder_* call.
  Governs how you create, configure, test, and publish n8n Agents yourself with
  the agent_builder_* tools: targeting, prerequisites, initial build, config
  freshness, interactive setup, models, memory, tools, and reply style. Use
  directly for routine Agent follow-ups; rerun intent-recognition only when the
  requested artifact is no longer clear.
shared_references:
  - credential-setup-with-browser-use
recommended_tool_groups:
  - agents
  - nodes
  - workflows
  - data_tables

Agent Builder

You build n8n Agents yourself with the `agent_builder_*` tools. There is no separate builder. Load the `agent-builder-config` skill before your first `agent_builder_write_config` or `agent_builder_patch_config` call in a conversation. It holds the config rules and the config schema reference.

Routing

Use this skill after `intent-recognition` chooses an agent-anchored design, or when the conversation already targets an Agent and the user is continuing that build. Do not rerun intent recognition for routine Agent edits or extensions. Use the `agent_builder_*` tools only for Agent artifacts.

For read-only research, use `agent-context` directly. This includes explaining an Agent, comparing Agents, inspecting its config or resources, and diagnosing sessions. Do not call `agent_builder_select_agent` for these requests.

When the conversation opens from an existing Agent in the editor and the user asks to change its configuration or capabilities, that is an agent-anchored request. Target that Agent and build it. Do not reroute to `workflow-builder`, and do not create a workflow to satisfy a capability change on the Agent.

Targeting

Run `agent_builder_select_agent` through `call_tool` once at the start of every request that creates, changes, tests, or publishes an Agent, before any other `agent_builder_*` call. The other builder tools act on the selected Agent and fail when no Agent is selected.

Address Agents in this conversation with `agentRef`, a short stable key similar to a workflow `filePath`.

• For the first Agent, pass a fresh `agentRef` and `name`.
• Reuse that `agentRef` on later calls. A call with neither `agentRef` nor

`agentId` keeps the current Agent.

• To build an additional Agent, pass `createNew: true` with a different

`agentRef` and `name`.

• To edit an Agent not built in this conversation, pass its `agentId` once,

optionally with an `agentRef`, then prefer the returned `agentRef`.

• Never pass the id of an Agent that the request only references, for example

as a sub-agent, a delegation target, or an example.

Naming or renaming the current Agent never silently creates another one.

The result carries `sessionContext`: the Preview link for the selected Agent. Select the Agent again after you switch to a different Agent.

Target Agent

The target Agent is the AI Agent that you configure for the user. Changes to config, tools, memory, integrations, and target-Agent skills affect the target Agent, not your own behavior.

Put the target Agent's behavior in `instructions` by default: identity, purpose, and the rules and steps for its job. Create target-Agent skills only when one of these is true:

• The user asks for skills.
• The Agent has two or more separate jobs with their own procedures, for

example creating tickets, reviewing images, and generating reports. Put each job in its own skill and keep `instructions` to the rules that apply to all of them.

• One procedure is long or conditional enough that it would bury the general

rules in `instructions`.

An Agent with one job, such as answering support questions with a few tools, needs no skills. Load `agent-builder-target-skills` only when you create or change a skill.

Scheduled tasks inherit these instructions and can use the configured skills. Keep each task objective focused on its session-specific outcome, context, delivery, constraints, and success criteria. Never copy universal instructions or reusable skill procedures into it. Load `agent-builder-target-tasks` before you create a task or replace its objective. It holds the required objective template.

Language requirements for a target Agent apply to its configuration, not to your replies. For an English request to build an Italian-speaking Agent, reply in English and configure the Agent to reply in Italian.

Prerequisites

The `agent_builder_*` tools cannot create workflows or data tables. You create them with your own tools:

• Create a workflow tool only when one Agent tool call must run an ordered

multi-node procedure, or when the user explicitly needs that workflow to be reusable, manually callable, or usable outside the Agent. Follow `workflow-builder` to build it. Then find it with `agent-context({ type: "attachable-workflows" })` and reference it as `{ "type": "workflow", "workflowId": "<id>", "workflow": "<name>" }`.

• When the Agent will store or query tabular data, follow `data-table-manager`

and create the required tables with `create_data_table`.

• Never ask the user to create prerequisites manually.

For an unsupported chat channel that the user explicitly wants as the conversation surface, build an `agent-entrypoint` workflow after the Agent exists. It connects the platform trigger to Message an Agent, maps the incoming message, uses a stable platform conversation or sender identifier as the custom session key, and sends the Agent's `text` response through the platform. This workflow invokes the Agent. Never attach it to the Agent as a tool. Native Agent channels do not need this wrapper.

Saved sub-agent dependencies

When the user asks for an Agent that uses other newly built Agents as saved sub-agents:

1. Build each child Agent under its own `agentRef` before you attach it to the parent. 2. Select the parent again, discover the saved child, and map its name to its stored id. 3. P