Service Itsm Agentic Setup Agentforce Coordinate

Agentforce for ITSM Setup Orchestrator

Guide the user through setting up Agentforce Studio, the IT Service Fulfiller agent, the IT Service Employee agent, specialized employee agents, and Employee-Agent to human escalation in Salesforce Service Cloud ITSM by presenting the available capabilities, delegating to specialized child skills, and tracking progress.

Goal

Act as the coordinator for Agentforce feature configuration in ITSM. Present the user with a menu of configurable features, invoke the appropriate child skill for each selection, and after each feature completes, return to the menu with updated progress until the user is done.

Behavior

1. Extract context from conversation

Before presenting options, scan chat history for:

• Which features the user has already set up (skip or mark as done)
• Any preferences or constraints mentioned (e.g., "just enable Agentforce Studio", "we already have Studio on")
• The target org (if mentioned)
• Business context that informs which features are relevant

2. Confirm the target org

Agentforce setup performs writes against a real org (feature-toggle enablement, agent creation and activation). Before delegating to any child skill, confirm the target org with the user and state plainly that this org will be modified. Never assume production is safe to change — ask for explicit confirmation of the org.

3. Present the Agentforce feature menu as a multi-select

Show the user what's available and what's done, organized into the two sequential setup stages — Stage 1: enable platform features (Agentforce Studio enablement) and Stage 2: install & activate agent templates (the Fulfiller and Employee agents). This separation is load-bearing: Stage 1 enables org-level platform toggles/preferences, while Stage 2 installs and activates agents from a template — they are distinct kinds of action and must read as distinct stages, not one undifferentiated list. Only features with a working child skill appear in the menu — use the Feature menu template in examples/output-templates.md. Collect the user's selections through a single multi-select prompt (use AskUserQuestion with multiSelect: true when tooling permits, otherwise ask the user to reply with a list of numbers such as 1, 2). Use the exact Item names from the Feature menu table as the multi-select option labels — verbatim, including each item's parenthetical note and the word "Agent" and its capitalization (Agentforce Studio enablement (Foundation for all agents), IT Service Fulfiller Agent, IT Service Employee Agent, Specialized Agents for Employee, Employee Agent escalation) — so the picker options and the table never diverge. Each item's Description column matches the wording on the Salesforce Setup → Agentforce for IT Service page (the Fulfiller and Employee agent-template descriptions and the Specialized Agents for Employee text are used verbatim) so a user evaluating which template to install reads the same purpose/scope here as they would in Setup — do not paraphrase or shorten that product copy. For the three Stage 2 agent items, follow the verbatim product copy with one short trailing Setup: line stating what installing does (Setup: creates the agent from this template and activates a version. for the Fulfiller and Employee agents; Setup: pick one specialized template (e.g. Password Manager, Onboarding), then create and activate that standalone agent. Re-run this item to add more. for Specialized Agents for Employee, for which you first ask the user which specialized template they want and pass that name to the child skill) so a single row carries purpose, scope, and the install action together. The Stage 1 row (Agentforce Studio enablement) is a platform-enablement toggle, not a template install, so it carries no Setup: line. When raising AskUserQuestion, put that same Description text (product copy + the Setup: line) in each option's description field so the picker carries the detail too. Do NOT show placeholder features that cannot be executed.

Report file (harness / non-interactive runs). If a ${outputDir} is provided (via the harness's generated-file location directive), write the menu emission (attribution header + feature table with status + delegation targets + dependency signal + the multi-select prompt itself) to ${outputDir}/report.md before raising AskUserQuestion — so the report file always exists even when the harness parks at the confirmation gate. Overwrite the same file after each feature completes with the updated status table. Skip these writes when running interactively for a user in a chat surface — write only when ${outputDir} was passed as an explicit destination.

4. Delegate to child skills in dependency order

Studio-first rule (unconditional). If Agentforce Studio enablement (#1) is in the user's selection and not already done, run it first, always — regardless of the order the user listed their numbers in. The Fulfiller Agent (#2), Employee Agent (#3), and Specialized Agents for Employee (#4) all depend on Studio being enabled and will fail if attempted first. Reorder the queue silently so Studio runs before any agent. This rule is non-negotiable and applies whether the user selected two features (Studio + one agent) or everything. Employee Agent escalation (#5) is a post-setup action that also never runs before Studio.

User-order rule (among #2, #3, and #4 only). The Fulfiller Agent (#2), Employee Agent (#3), and Specialized Agents for Employee (#4) are independent of each other — none depends on the others. If more than one is selected, run them in the order the user listed them (default 2 → 3 → 4 when unspecified). This rule applies only to the ordering among #2, #3, and #4; it never overrides the Studio-first rule above.

Escalation-after-Employee rule (#5 depends on #3). Employee Agent escalation (#5) configures the Employee agent's hand-off to a human, so it requires the Employee Agent (#3) to exist and be Active first. If #5 is selected, ensure #3 has completed successfully in this run (or was already done) before delegating to it; otherwise queue #3 ahead of #5. #5 never runs before Studio (#1) either.

Runtime-access-after-creation rule (unconditional). Whenever any Stage 2 agent (#2, #3, #4) returns a live verdict this session (CREATED/ALREADY-CREATED/ACTIVATED), append an automatic Stage 3 runtime-access step at the back of the queue — the post-requisite mirror of the Studio-first pre-requisite: appended always, never a menu pick — and delegate it once after the last Stage 2 agent to service-itsm-agentic-setup-agent-runtime-access-assign, covering every newly-live agent (its own target-user + confirm-to-write gates govern the grants; Stage 3 guarantees the offer, never a silent grant). It is non-negotiable: a live agent's actions fail on missing user permissions until this sets them up. Do NOT append it when only Studio ran or no agent went live (FAILED/PARTIAL/PENDING CONFIRMATION/DECLINED, or a Stage 2 verify that stopped the queue). Narration + status mapping: Runtime access hand-off in examples/output-templates.md.