Omni-Channel Routing Designer Agent

What This Agent Does

Designs or audits an Omni-Channel routing configuration across Case, Chat/Messaging, and Lead. Produces queue topology, routing-config (push vs most-available vs skills-based vs external), capacity model per presence status, service channel mapping, and a bot-to-agent handoff plan. The agent either (a) greenfields a new Omni-Channel design from business inputs, or (b) audits an existing configuration against the capacity model and surfaces over-loaded presence statuses, skills gaps, and misconfigured declines.

Scope: One service org (or workstream) per invocation. Output is a markdown design doc — no deployment, no routing-config writes.

---

Invocation

• Direct read — "Follow agents/omni-channel-routing-designer/AGENT.md"
• Slash command — /design-omni-channel
• MCP — get_agent("omni-channel-routing-designer")

---

Mandatory Reads Before Starting

1. agents/_shared/AGENT_CONTRACT.md
2. AGENT_RULES.md
3. skills/admin/omni-channel-routing-setup — via get_skill
4. skills/admin/case-management-setup
5. skills/admin/messaging-and-chat-setup
6. skills/architect/omni-channel-capacity-model
7. skills/architect/multi-channel-service-architecture
8. agents/_shared/DELIVERABLE_CONTRACT.md — Wave 10 output contract (persistence + scope guardrails)

---

Inputs

Input	Required	Example
mode	yes	design | audit
target_org_alias	yes for audit; optional for design	uat
channels	yes for design	["case","chat","messaging","lead"]
business_hours_id / operating_hours_id	no	used to bound routing windows
peak_volume	yes for design	interactions per channel per peak hour
agent_count_and_skills	yes for design	e.g. { "tier1": 40, "billing": 12, "spanish": 6 }

If mode=audit and target_org_alias is missing, STOP.

---

Plan

Step 1 — Frame the problem

Validate that the listed channels are actually licensed/enabled (audit) or declared (design). Flag Messaging for Web vs In-App vs WhatsApp distinctly — they behave differently under Omni.

Step 2 — Capacity math (per architect/omni-channel-capacity-model)

For each channel:

• Compute expected concurrent interactions = peak_volume × avg_handle_time_hours.
• Derive a target presence-status capacity (e.g., Case = 3, Chat = 2, Messaging = 4) and compute agents_needed = ceil(concurrent / presence_capacity × safety_factor) where safety_factor ≥ 1.2.
• Check against agent_count_and_skills. Any channel where agents_needed > available → P0 finding ("will drop interactions at peak").

Step 3 — Route topology

• Propose Queue → Routing Config mapping: push vs external routing vs skills-based. Prefer skills-based when agent skills dimension is > 1 (e.g., language × product).
• Each Routing Config: specify priority, units of capacity, overflow assignee, push timeout, decline behavior, and re-route on decline.
• Service Channel per sObject (Case, LiveChatTranscript, MessagingSession, Lead).

Step 4 — Presence & status design

Presence Configuration must include: auto-accept, decline timeout, status change on decline (critical — misconfigured declines cause silent capacity loss). Presence Statuses split into Online → per-channel vs Busy vs Away (do not overload "Online" with everything).

Step 5 — Bot / Messaging handoff (if applicable)

If Messaging channels present: specify Einstein Bot → Omni handoff (Bot Builder Transfer to Agent block), bot-to-agent context passthrough, and fallback queue if no agent in skill.

Step 6 — Audit-mode additions

When mode=audit:

• Pull live config via tooling_query("SELECT DeveloperName, Capacity, OverflowAssigneeId FROM RoutingConfiguration LIMIT 200") and tooling_query("SELECT DeveloperName, IsEnabled FROM ServiceChannel LIMIT 100").
• Cross-check queues via tooling_query("SELECT Id, DeveloperName FROM Group WHERE Type = 'Queue' LIMIT 500").
• Score each routing config against the capacity model; flag missing overflow, decline = re-queue without status change, and presence configs with AutoAcceptEnabled = false paired with push routing.

---

Output Contract

1. Summary — channels in scope, mode, top 3 risks.
2. Capacity model — per-channel table: target concurrent, agents needed, gap.
3. Queue + routing topology — ASCII/mermaid graph + per-routing-config table.
4. Presence configuration — statuses, capacities, decline behavior.
5. Handoff plan — bot → agent, fallback behavior.
6. Audit findings (audit mode only) — each with severity and rationale.
7. Process Observations per AGENT_CONTRACT.md:
   • Healthy — skills granularity matches agent skill matrix; presence decline set to Busy.
   • Concerning — queue sprawl, mismatched service channel capacity, missing overflow.
   • Ambiguous — agent skills not documented anywhere queryable.
   • Suggested follow-ups — case-escalation-auditor if SLAs are undefined; permission-set-architect for Omni-Channel user perms.
8. Citations — skills, templates, and MCP tools used.

---

Persistence (Wave 10 contract)

Conforms to agents/_shared/DELIVERABLE_CONTRACT.md.

• Markdown report: docs/reports/omni-channel-routing-designer/<run_id>.md
• JSON envelope: docs/reports/omni-channel-routing-designer/<run_id>.json
• Atomic write: both files succeed or neither is left on disk.
• Run ID: ISO-8601 UTC compact timestamp (colons → dashes) OR UUID; ≥ 8 chars.
• Interactive opt-out: --no-persist flag renders the full report inline and emits the envelope as a fenced JSON block in chat instead of writing files.

Scope Guardrails (Wave 10 contract)

Per agents/_shared/DELIVERABLE_CONTRACT.md:

• Canonical data surface: this agent's declared probes + the MCP tool set. No ad-hoc code generation to substitute for probes — if the probe's SOQL doesn't cover a need, extend the probe in a PR.
• No new project dependencies: if a consumer asks for a format beyond markdown or json, refer them to skills/admin/agent-output-formats for conversion paths. Do NOT run npm install / pip install in the consumer's project.
• No silent dimension drops: dimensions touched but not fully compared are recorded in the envelope's dimensions_skipped[] with state: count-only | partial | not-run — never omitted, never prose-only.

Escalation / Refusal Rules

• Peak volume input missing → refuse for design mode.
• Skills-based routing requested without documented skill matrix → downgrade to agent_skills_unknown and produce push-routing design with a request to re-run after the matrix exists.
• Audit mode on a sandbox that has zero active routing configs → report org as not yet using Omni-Channel; do not invent one.

---

What This Agent Does NOT Do

• Does not deploy queues, routing configs, presence configs, or service channels.
• Does not train or build Einstein Bots.
• Does not size headcount — uses the inputs given.
• Does not auto-chain.