Both inputs were supplied, so this is a full run, not a demonstration fallback. Where the inputs are silent (volumes, permissions, API access, headcount), the output marks the fact UNKNOWN rather than inferring it. --- # 1. WORKFLOW MAP **ACTORS** - Customer (submits ticket) — {CONFIRMED — evidence: "Customers submit tickets through email and an in-app support form"} - Support agent (classifies, searches docs, answers, escalates, updates status, follows up) — {CONFIRMED — evidence: "Support agents classify issues, search documentation, answer common questions, escalate technical problems, update ticket status"} - Engineering (receives escalations, holds internal notes) — {CONFIRMED — evidence: "sometimes follow up with engineering"; "internal engineering notes"} - Support manager (reviews escalations and unresolved tickets) — {CONFIRMED — evidence: "Managers review escalations and unresolved tickets"} **TRIGGERS** - New ticket via email or in-app form — {CONFIRMED — evidence: "submit tickets through email and an in-app support form"} - Customer reply on an existing ticket — {HIGHLY LIKELY — evidence: Zendesk ticket threads imply reply events; not stated} - Engineering response in Slack — {PLAUSIBLE — reasoning: Slack is listed as an existing system and follow-up with engineering occurs; the channel used is not stated} **INPUTS** - Ticket text, customer identity/account reference — {HIGHLY LIKELY — evidence: tickets arrive via email/form; account fields unspecified} - Product documentation, internal engineering notes — {CONFIRMED — evidence: "product documentation, internal engineering notes"} - Attachments, logs, screenshots — UNKNOWN — evidence needed: whether tickets carry diagnostic attachments **DECISIONS** - Classify issue type — {CONFIRMED — evidence: "classify issues"} - Answerable from docs vs. needs escalation — {CONFIRMED — evidence: "answer common questions, escalate technical problems"} - Whether to involve engineering, and how urgently — {HIGHLY LIKELY — evidence: "sometimes follow up with engineering"; the criteria are unstated} - Refund / account-access / high-impact decisions — {CONFIRMED — evidence: constraint on "refunds, account access, or high-impact customer decisions"} **ACTIONS** Search docs; reply to customer; set ticket status; escalate; follow up with engineering; manager review — {CONFIRMED — evidence: workflow sentence in DOMAIN_OR_WORKFLOW} **HANDOFFS** - Agent → engineering (escalation) — {CONFIRMED — evidence: "escalate technical problems"} - Agent/engineering → manager (review) — {CONFIRMED — evidence: "Managers review escalations"} - Escalation medium (Zendesk internal note, Slack, Jira-like tracker) — UNKNOWN — evidence needed: how escalations physically move to engineering **SYSTEMS** Zendesk, product documentation, internal engineering notes, Slack — {CONFIRMED — evidence: "Existing systems include Zendesk, product documentation, internal engineering notes, and Slack"} **DATA** Ticket records, docs, engineering notes, Slack threads — {CONFIRMED — evidence: same systems sentence}. Customer/account/billing data — UNKNOWN — evidence needed: whether any system exposes account state to support. **WAIT STATES** - Awaiting engineering response — {HIGHLY LIKELY — evidence: "slow escalations" named as a problem, which implies waiting} - Awaiting customer reply — {PLAUSIBLE — reasoning: standard in ticketing workflows; not stated} - Awaiting manager review — {HIGHLY LIKELY — evidence: "Managers review escalations and unresolved tickets"} **EXCEPTIONS** - Refund/account/high-impact requests — {CONFIRMED — evidence: explicit constraint} - Duplicate tickets, multi-issue tickets, tickets with missing info — UNKNOWN — evidence needed: whether/how these occur and are handled **OUTPUTS** Customer reply, updated status, escalation record, manager-reviewed resolution — {HIGHLY LIKELY — evidence: derived from listed actions} **HUMAN APPROVALS** - Refunds, account access, high-impact customer decisions — {CONFIRMED — evidence: "without giving AI uncontrolled authority over refunds, account access, or high-impact customer decisions"} - Approval requirements for routine replies and status updates — UNKNOWN — evidence needed: current QA/review policy for ordinary answers --- # 2. FRICTION & OPPORTUNITY MAP **F1 — Repetitive doc lookup and answer drafting for common questions** - Who: support agents - Cause: common questions require re-searching and re-composing known answers - Consequence: agent time spent on repeat work - Evidence: {CONFIRMED — evidence: goal "Reduce repetitive agent work"; agents "search documentation, answer common questions"} - Frequency/volume: UNKNOWN — evidence needed: share of tickets that are common questions - Agentic potential: low-to-moderate; mostly single-step retrieval and drafting **F2 — Manual classification and routing** - Who: support agents - Cause: classification is a manual agent step - Consequence: agent time and possible inconsistent labeling - Evidence: {CONFIRMED — evidence: "Support agents classify issues"} - Misclassification rate: UNKNOWN — evidence needed: current rework/reroute data - Agentic potential: low; classification is a bounded single decision **F3 — Escalation packaging: gathering context for engineering** - Who: support agents, and engineers who receive incomplete escalations - Cause: agent must collect ticket history, repro details, related engineering notes, and prior similar cases by hand - Consequence: slow escalation; possible engineer back-and-forth - Evidence: {HIGHLY LIKELY — evidence: goal "slow escalations" plus "escalate technical problems" and "internal engineering notes" as a separate system} - Actual quality of current escalations: UNKNOWN — evidence needed: how often engineering asks for more info - Agentic potential: high; multi-source gathering, normalization, and routing **F4 — Escalation follow-up and stall detection** - Who: support agents, managers - Cause: agents "sometimes follow up with engineering" (manual, dependent on memory); managers review unresolved tickets after the fact - Consequence: escalated tickets can sit without movement, discovered late - Evidence: {HIGHLY LIKELY — evidence: "slow escalations" and "sometimes follow up with engineering," which implies follow-up is inconsistent} - Stall frequency/duration: UNKNOWN — evidence needed: aging data on escalated tickets - Agentic potential: high; requires monitoring, timed intervention, and re-escalation across systems **F5 — Manager review of escalations and unresolved tickets** - Who: managers - Cause: review requires opening tickets and reconstructing status - Consequence: review time spent on state reconstruction instead of decisions - Evidence: {HIGHLY LIKELY — evidence: "Managers review escalations and unresolved tickets"; reconstruction burden inferred} - Agentic potential: moderate; decision preparation **F6 — Fragmented knowledge (docs vs. engineering notes vs. Slack)** - Who: agents and managers - Cause: answers may live across documentation, engineering notes, and Slack threads - Consequence: slower resolution; risk of stale or conflicting answers - Evidence: {PLAUSIBLE — reasoning: four separate systems are listed and cross-system fragmentation is common; no input text says information is scattered} - Agentic potential: moderate; feeds F1 and F3 rather than standing alone **Not carried forward as friction:** ticket status updates (a single deterministic action, {CONFIRMED — evidence: "update ticket status"} but no stated pain) and customer-facing reply delivery (no stated friction). --- # 3. AGENT SUITABILITY MATRIX Gate criteria (numbered 1-12 as in the gate definition): Y = yes, P = partial/depends, ? = UNKNOWN. | Opportunity | 1 Recur | 2 Outcome obs. | 3 Trigger | 4 State obs. | 5 Tools | 6 Measurable | 7 Adapts | 8 >Single action | 9 Autonomy valuable | 10 Gates | 11 Detect fail | 12 Recover | Class | |---|---|---|---|---|---|---|---|---|---|---|---|---|---| | F1 Doc lookup + draft | Y | Y | Y | Y | ? (Zendesk write/API) | Y | P | N | P | Y | Y | Y | **COPILOT** | | F2 Classification/routing | Y | Y | Y | Y | ? | Y | N | N | N | Y | Y | Y | **WORKFLOW AUTOMATION** | | F3 Escalation packaging | Y | Y | Y | P (needs cross-system read) | ? | Y | Y | Y | Y | Y | Y | Y | **AGENT-WORTHY** | | F4 Escalation follow-up/stall | Y | Y | Y (timer/state change) | P | ? (Slack/Zendesk write) | Y | Y | Y | Y | Y | Y | Y | **AGENT-WORTHY** | | F5 Manager review prep | Y | Y | Y | Y | ? | P | P | P | P | Y | Y | Y | **COPILOT** | | F6 Cross-source knowledge | Y | P | P | P | ? | P | Y | P | P | Y | P | Y | **COPILOT** (as a capability inside F1/F3, not standalone) | Explanations: - **F1 = COPILOT.** {evidence: retrieval-and-draft is a single-pass task with a human sending the reply; autonomy adds little}. It is not agent-worthy: it is closer to a chatbot with retrieval. - **F2 = WORKFLOW AUTOMATION.** A classifier or rules with confidence-based routing is simpler and more reliable than an agent. There is no cross-step adaptation. - **F3 and F4 = AGENT-WORTHY.** Both need observe → decide → act → verify loops across Zendesk, engineering notes, and Slack, with time-based triggers and adaptive re-escalation. Every criterion is Y or P *except tool access, which is UNKNOWN* (see Section 8). - **F5 = COPILOT.** Summarization for decision preparation; the human decides. - **F6 = COPILOT capability**, folded into F1/F3 (see consolidation). **Consolidation (complexity budget).** Four opportunities survive as AGENT-WORTHY or COPILOT (F1, F3, F4, F5, plus F6 = five). Five is under the cap of 6, but F6 shares trigger, system, and actor with F1 and F3. Consolidation applied: - F6 merged into F1 and F3 as a retrieval capability, not carried as a separate concept. - F1 and F5 both survive as COPILOT and stay as separate concepts (different actors: agent vs. manager). - F2 set aside: WORKFLOW AUTOMATION, out of scope for agent design. **Carried into Stage 4: F1, F3, F4, F5** (four concepts). --- # 4. PRIORITIZED OPPORTUNITIES | Opportunity | Classification | Driving axes | |---|---|---| | F3 Escalation packaging | **HIGH-LEVERAGE** | Coordination burden (multi-source context gathering across systems); Business relevance ("slow escalations" is a stated goal) | | F4 Escalation follow-up/stall | **HIGH-LEVERAGE** | Follow-up failure / dependency on human memory ("sometimes follow up"); Measurability (time-to-response on escalations is observable) | | F5 Manager review prep | **PROMISING** | Decision complexity (reconstructing state before deciding); Human oversight feasibility (managers already in the loop) | | F1 Doc lookup + draft | **CONDITIONAL** | Frequency/recurrence (volume UNKNOWN, the value hinges on it); Actionability (depends on Zendesk write access, UNKNOWN) | Implementation dependency is the shared caveat on all four: tool access is UNKNOWN. F3 and F4 are classified HIGH-LEVERAGE on workflow fit, not on validated value. --- # 5. INNOVATION TRANSFORMATIONS **F3 — Escalation packaging** - **HANDOFF COMPRESSION:** the agent gathers ticket history, related notes, and prior similar cases and normalizes them into one escalation package, so the support agent stops assembling it by hand and engineering stops asking follow-up questions. - **DECISION PREPARATION:** the agent assembles the evidence and a suggested routing; the support agent approves the escalation. - Multi-agent split not used: no distinct evidence boundary justifies it. **F4 — Escalation follow-up/stall** - **CLOSED-LOOP AGENT:** observe escalation state → detect stall against an agreed threshold → nudge engineering → verify a response arrived → re-escalate or notify the manager. - **PROACTIVE SHIFT:** monitoring replaces after-the-fact discovery during manager review. - **MEMORY-ASSISTED CONTINUITY:** used only for per-escalation state (last nudge, who was pinged), which the loop needs; no broader persistent memory. **F5 — Manager review prep** - **DECISION PREPARATION:** an agent-generated digest of each escalated or unresolved ticket (status, age, blockers, last action) so managers decide rather than reconstruct. **F1 — Doc lookup + draft** - **EXCEPTION-FIRST AGENT** considered and rejected as a distinct concept: the "exception path" is just the escalation flow already covered by F3. F1 stays a copilot. **Design note:** F3 and F4 can share state (the escalation record). This is one shared data object, not two agents needing coordination. --- # 6. AGENT CONCEPT ARCHITECTURES ## Concept A — Escalation Packager | Field | Definition | |---|---| | AGENT NAME | Escalation Packager | | PRIMARY USER | Support agents (secondary: engineers receiving escalations) | | PROBLEM | Escalations require manual context gathering; incomplete escalations slow engineering response ({HIGHLY LIKELY — evidence: "slow escalations" goal}) | | TRIGGER | Support agent flags a ticket for escalation (or agent accepts the packager's suggestion that escalation is warranted) | | GOAL | Produce a complete, normalized escalation package and route it to the right engineering channel | | INPUTS | Ticket thread, customer/account reference, product area | | OBSERVABLE STATE | Ticket content and history (Zendesk); related engineering notes; prior similar escalations; documentation coverage | | DECISIONS | Which context is relevant; whether required information is missing; which team/channel to route to; suggested severity | | TOOLS | Zendesk (read, write internal note), engineering notes (read), documentation (read), Slack (post) | | DATA SOURCES | Zendesk, engineering notes, documentation, Slack history | | ACTIONS | Assemble package; request missing info from the support agent; post the approved package to the engineering destination; write an internal note on the ticket | | MEMORY NEED | Per-escalation record only (package, destination, timestamp) | | OUTPUTS | Escalation package (summary, repro/context, related notes, prior cases, suggested severity/route) | | HUMAN APPROVAL POINTS | Support agent approves the package before it leaves Zendesk for engineering (MVP default) | | ESCALATION CONDITIONS | Missing critical info the agent cannot obtain; conflicting engineering notes; anything touching refunds/account access/high-impact decisions → human-only | | COMPLETION CONDITION | Package accepted by engineering (engineering acknowledges) or rejected with stated reason | ## Concept B — Escalation Watchdog | Field | Definition | |---|---| | AGENT NAME | Escalation Watchdog | | PRIMARY USER | Support agents and support managers | | PROBLEM | Escalated tickets can stall; follow-up depends on agent memory ({HIGHLY LIKELY — evidence: "sometimes follow up with engineering"}) | | TRIGGER | An escalated ticket ages past a threshold without a response or state change. The threshold is UNKNOWN and must be set by the workflow owner | | GOAL | Keep escalations moving: detect stalls, nudge, verify, escalate to a human owner | | INPUTS | Escalation record and timestamps; ticket status; Slack thread activity | | OBSERVABLE STATE | Time since last engineering response; ticket state; whether the nudge was acknowledged | | DECISIONS | Whether the stall is real (vs. waiting on the customer); who to nudge; whether to notify the manager | | TOOLS | Zendesk (read, write internal note), Slack (read, post) | | DATA SOURCES | Zendesk ticket/escalation state; Slack threads | | ACTIONS | Post nudge in the engineering thread; add internal note; notify the support agent/manager of a stall | | MEMORY NEED | Per-escalation nudge history to avoid duplicate nudges | | OUTPUTS | Nudge, stall notice, updated escalation state | | HUMAN APPROVAL POINTS | Nudges to engineering: autonomous within limits (see Section 7); manager notification: autonomous; anything customer-facing: human | | ESCALATION CONDITIONS | No engineering response after N nudges (N = UNKNOWN, set by owner); ambiguity about ownership; stall on a ticket flagged high-impact | | COMPLETION CONDITION | Engineering responds or the ticket is closed/reassigned by a human | ## Concept C — Review Digest | Field | Definition | |---|---| | AGENT NAME | Review Digest | | PRIMARY USER | Support managers | | PROBLEM | Managers reconstruct state on escalated/unresolved tickets before deciding ({HIGHLY LIKELY — evidence: "Managers review escalations and unresolved tickets"}) | | TRIGGER | Scheduled or on-demand before manager review (cadence UNKNOWN) | | GOAL | Decision-ready digest per ticket | | INPUTS | Ticket state, escalation records, Slack activity | | OBSERVABLE STATE | Age, status, last action, blockers, whether escalation stalled | | DECISIONS | Which tickets to surface first; how to summarize; what the likely blocker is | | TOOLS | Zendesk (read), Slack (read) | | DATA SOURCES | Zendesk, Slack, escalation records (from Concepts A/B if built) | | ACTIONS | Generate digest (read-only) | | MEMORY NEED | None beyond current state | | OUTPUTS | Ranked digest with evidence per ticket | | HUMAN APPROVAL POINTS | Not applicable (read-only, no actions) | | ESCALATION CONDITIONS | None; it surfaces, humans act | | COMPLETION CONDITION | Digest delivered | ## Concept D — Answer Drafter (Copilot) | Field | Definition | |---|---| | AGENT NAME | Answer Drafter | | PRIMARY USER | Support agents | | PROBLEM | Repetitive doc search and reply composition ({CONFIRMED — evidence: goal "Reduce repetitive agent work"}) | | TRIGGER | New ticket classified as a common question | | GOAL | Draft a documentation-grounded reply with citations for agent approval | | INPUTS | Ticket text | | OBSERVABLE STATE | Documentation match confidence | | DECISIONS | Whether a doc answer exists; which sections apply | | TOOLS | Documentation (read), Zendesk (read; draft insertion only) | | DATA SOURCES | Product documentation | | ACTIONS | Insert a draft reply for the agent to edit/send | | MEMORY NEED | None | | OUTPUTS | Draft reply with doc citations | | HUMAN APPROVAL POINTS | Every reply is sent by a human agent | | ESCALATION CONDITIONS | No confident doc match; question touches refunds/account/high-impact → route to human, no draft | | COMPLETION CONDITION | Agent sends or discards the draft | --- # 7. AUTONOMY & HUMAN-GATE MATRIX The input states that refunds, account access, and high-impact customer decisions must not be under uncontrolled AI authority. Under the classification-conflict override rule, that requirement outranks any concept-level assessment. | Action | Concept | Classification | Rule | |---|---|---|---| | Read tickets, docs, notes, Slack | A, B, C, D | READ-ONLY | Autonomous. Evidence: no state change | | Assemble escalation package | A | LOW-IMPACT ACTION | Autonomous (draft only, not sent) | | Write internal Zendesk note | A, B | LOW-IMPACT ACTION | Autonomous. Evidence: internal-facing, editable by staff; note visibility settings UNKNOWN and must be verified as internal-only | | Post escalation package to engineering | A | REVERSIBLE ACTION | Requires support agent approval in MVP; autonomy can be widened later on evidence | | Nudge engineering in an existing Slack thread | B | REVERSIBLE ACTION | Autonomous within rate limits (limit UNKNOWN, owner-set). Evidence: internal audience; a message can be followed by a correction, but it cannot be unsent from people's attention | | Notify manager/agent of a stall | B | LOW-IMPACT ACTION | Autonomous | | Insert draft reply (not sent) | D | LOW-IMPACT ACTION | Autonomous | | Send any customer-facing reply | D / all | CONSEQUENTIAL ACTION | Human only. Input authority: the input names "high-impact customer decisions" as human-gated; routine reply approval policy is UNKNOWN, so the conservative default applies until the owner confirms | | Change ticket status or priority | A, B | UNKNOWN band | Input silent on status changes. Concept assessment: REVERSIBLE (status can be reset; evidence: Zendesk statuses are editable). Held human-approved in MVP until the owner confirms | | Refunds | all | IRREVERSIBLE / HUMAN-ONLY | See conflict statement below | | Account access / account changes | all | IRREVERSIBLE / HUMAN-ONLY | See conflict statement below | | Any high-impact customer decision | all | CONSEQUENTIAL or HUMAN-ONLY | See conflict statement below | **CLASSIFICATION CONFLICT:** Refunds — concept assessment: not applicable (no concept proposes it); input-stated requirement: human control required. Resolved per input authority: **HUMAN-ONLY**. **CLASSIFICATION CONFLICT:** Account access and account changes — concept assessment: not applicable; input-stated requirement: human control required. Resolved per input authority: **HUMAN-ONLY**. **CLASSIFICATION CONFLICT:** High-impact customer decisions (including status changes or nudges on tickets tagged high-impact) — concept assessment: REVERSIBLE for status/nudge actions; input-stated requirement: no uncontrolled AI authority. Resolved per input authority: **CONSEQUENTIAL, human-approved**. How "high-impact" is defined is UNKNOWN and must come from the workflow owner. **What agents may do autonomously:** read across systems; assemble packages and digests; write internal-only notes; nudge engineering in-thread within rate limits; notify humans of stalls; insert unsent drafts. **What requires approval:** posting escalation packages (MVP), any customer-facing send, ticket status/priority changes, and anything on a high-impact ticket. **Never without explicit authority:** refunds, account access or changes, contractual or entitlement commitments to customers, deleting or closing tickets, and any action outside the concept's declared tool list. --- # 8. TOOL / DATA READINESS | Concept | System | Data | Action | R/W | Availability | Dependency / Blocker | |---|---|---|---|---|---|---| | A, B, C, D | Zendesk | Tickets, threads, status | Read | R | CONFIRMED that Zendesk exists ({evidence: "Existing systems include Zendesk"}); API/read permission UNKNOWN | Verify API access and scopes | | A, B | Zendesk | Internal notes | Write | W | UNKNOWN | Verify note-write permission and internal-only visibility | | A | Zendesk | Escalation flag/field | Read | R | UNKNOWN | Need to know how "escalated" is represented (tag, field, group, external ticket) | | A, C | Engineering notes | Notes/known issues | Read | R | CONFIRMED that they exist ({evidence: "internal engineering notes"}); format, location, and access UNKNOWN | Blocker if notes are unstructured or access-restricted; retrieval quality untested | | D, A | Product documentation | Docs | Read | R | CONFIRMED that it exists ({evidence: "product documentation"}); accessibility (public/indexable/API) UNKNOWN | Verify format and freshness | | A, B | Slack | Channel/thread history | Read | R | CONFIRMED that Slack exists ({evidence: "Slack"}); workspace/bot permissions UNKNOWN | Verify app approval and channel scope | | A, B | Slack | Posting | Write | W | UNKNOWN | Requires workspace admin approval; determine which channels receive escalations | | B | Escalation destination (Jira/Linear/other) | Engineering-side ticket state | Read | R | UNKNOWN. The input does not name an engineering tracker | Critical: Watchdog needs to see engineering-side responses. If they occur only in Slack DMs or meetings, stall detection cannot work | | B, C | Timestamps/aging | Last-activity times | Read | R | HIGHLY LIKELY via Zendesk ({evidence: standard ticket metadata; not confirmed}) | Verify available fields | | All | Customer/account data | Plan, account state | Read | R | UNKNOWN | Needed only if severity depends on account tier; no evidence it is accessible to support | **Feasibility dependencies:** (1) Zendesk API access and scopes; (2) how escalations are represented and where engineering responds; (3) Slack posting permission; (4) engineering notes access and structure. Concept B is the most exposed: if engineering-side state is not machine-visible, its core loop cannot run. --- # 9. FAILURE & RECOVERY MAP ## Concept A — Escalation Packager | Agent action | Failure | Detection | Impact | Recovery | Escalation | |---|---|---|---|---|---| | Retrieve related notes | Stale or wrong engineering note included | Source timestamp and citation shown per item; engineer feedback flag | Engineer misled | Package shows citations/dates; engineer marks "irrelevant" | Repeated flags → pause retrieval source, notify owner | | Assemble context | Missing context, package looks complete but is not | Required-field checklist; missing fields listed explicitly | Engineering back-and-forth | Agent asks support agent for the missing field before send | Cannot fill → route to human | | Route to destination | Misrouting to wrong team/channel | Engineering reroute or "wrong team" reply | Delay | Re-route with correction note | Repeated misroutes → drop auto-suggested routing | | Post package | Duplicate posting | Check for existing package on the ticket before post | Noise | Delete or reply "duplicate," idempotency key per ticket | Repeats → halt posting | | Any step | Tool/permission failure | Error response | Package not delivered | Retry once, then surface to the support agent | Human handles manually | | Classification of severity | Unsupported severity call | Severity shown as suggestion with its basis | Wrong priority | Human sets severity | High-impact tickets → human only | ## Concept B — Escalation Watchdog | Agent action | Failure | Detection | Impact | Recovery | Escalation | |---|---|---|---|---|---| | Detect stall | Stale state: response happened in a place the agent cannot see | Compare with human-reported outcomes during the pilot | False nudges, annoyed engineers | Add source; suppress nudges when visibility is uncertain | Persistent false positives → suspend concept | | Nudge | Duplicate or excess nudges (looping) | Per-escalation nudge counter; hard cap | Spam, trust loss | Hard cap and cooldown | Cap reached → notify human owner, stop | | Nudge | Nudges the wrong person/thread | Ownership check before posting; thread linkage | Misdirected noise | Correct with follow-up; log | Ambiguous ownership → notify manager, do not post | | Stall on high-impact ticket | Over-autonomy | Ticket flag check | Consequential delay mishandled | Human-owned path only | Always escalate to manager | | Follow-up | Failed follow-up (no verification that the nudge landed) | Verify acknowledgement/state change after the interval | Stall persists silently | Re-check; escalate on no change | Notify manager | ## Concept C — Review Digest | Agent action | Failure | Detection | Impact | Recovery | Escalation | |---|---|---|---|---|---| | Summarize ticket | Unsupported summary (inaccurate) | Each claim linked to a source ticket event | Manager decides on bad info | Show source links; manager can open ticket | Repeated errors → revert to raw list | | Rank tickets | Wrong prioritization | Manager overrides logged | Wrong order of review | Ranking rationale shown | Persistent → drop ranking, keep summary | | Data fetch | Incomplete data (missed tickets) | Reconcile count against a Zendesk view | Tickets missed | Show coverage statement ("N of N reviewed") | Coverage gap → banner warning | ## Concept D — Answer Drafter | Agent action | Failure | Detection | Impact | Recovery | Escalation | |---|---|---|---|---|---| | Draft answer | Bad source data (outdated docs) | Doc last-updated shown; agent edits | Wrong answer if sent unedited | Human reviews every draft | Feedback flag on doc | | Draft answer | Unsupported decision (answers beyond docs) | Every claim requires a citation; no citation, no draft | Wrong customer info | Suppress draft | Route to human | | Draft answer | Touches refunds/account/high-impact | Keyword/category gate plus human review | Consequential misstep | No draft is generated | Human-only | --- # 10. DIFFERENTIATION TEST **Concept A — Escalation Packager** - Just a chatbot? No: it acts on systems (reads several, writes a note, posts). - Just a single automation? Partly: a templated escalation form with auto-filled fields captures some value. The agentic part is judging relevance across unstructured notes and prior cases and detecting missing information. - Requires agentic behavior: cross-source relevance judgment and gap detection. - Closed loop: partial: package → engineering response → completion check. - Burden removed: context assembly. - Harder to replace with a generic assistant because of: access to Zendesk history, engineering notes, and escalation records, which a generic assistant lacks. **Advantage is conditional on tool access (UNKNOWN).** - Verdict: differentiated **if** cross-system read access exists; otherwise it collapses to a template. **Concept B — Escalation Watchdog** - Chatbot? No. - Single automation? Partly: "if an escalation is unanswered for X hours, post a reminder" is deterministic, and a Zendesk trigger or Slack workflow may do it. **This is the strongest challenge to the concept.** The agentic residue is judgment: distinguishing a real stall from waiting on the customer, choosing whom to nudge, reading unstructured Slack replies, and deciding when to escalate to a manager. - Closed loop: yes (observe → nudge → verify → escalate). - Verdict: **differentiation is moderate and hinges on whether a plain timer rule covers most of the value.** The MVP must test this directly: compare against a deterministic reminder baseline. **Concept C — Review Digest** - Chatbot? Close: a read-only summarizer with no action loop. - Single automation? Largely: a saved Zendesk view plus an LLM summary field. - Closed loop: none. - Verdict: **weak as an agent; retained as a COPILOT feature** (best delivered as an output of Concept B rather than a standalone agent). Downgraded to a component. **Concept D — Answer Drafter** - Chatbot? Essentially yes (retrieval-augmented drafting). - Closed loop: none. - Verdict: **not an agent.** Legitimate as a copilot feature, and Zendesk may already offer comparable native tooling (UNKNOWN whether it is licensed or in use). Downgraded; not pursued as an agent concept. --- # 11. MVP EXPERIMENTS ## Concept A — Escalation Packager - **Hypothesis:** A pre-assembled package reduces engineering clarification requests and support-agent assembly effort compared to current escalations. - **Smallest test:** For a limited set of real escalations, produce packages in parallel (shadow mode) without sending them; support agents compare against what they wrote. - **Manual/concierge version:** A human (or a single LLM prompt run by the pilot owner) assembles the package from the ticket plus copied engineering notes; agents rate it. - **Minimum tool access:** Read-only Zendesk export and read access to relevant notes; no writes. - **Minimum data:** A sample of past escalations with their outcomes (clarification requests, resolution time). Availability of that history: UNKNOWN. - **Success signal:** Agents rate the shadow package as at least as complete as their own; it would have prevented clarification requests seen in past escalations. - **Failure signal:** Packages routinely miss information engineers later requested; agents rewrite most packages. - **Learning objective:** Is cross-source retrieval good enough, and what fields do engineers actually need? - **Test duration:** Until sufficient sample is observed. - **Next decision:** Proceed to a write-enabled pilot with approval, or downgrade to a template. ## Concept B — Escalation Watchdog - **Hypothesis:** Escalations stall often enough, and long enough, that judgment-based follow-up beats a plain timer reminder. - **Smallest test:** Observe-only. Analyze existing escalated tickets for stalls (retrospective), then run the detector in shadow mode, logging when it *would* have nudged. - **Manual/concierge version:** A pilot owner scans the escalation queue daily and sends manual nudges, logging what worked and where a timer rule would have sufficed. - **Minimum tool access:** Read-only on Zendesk and the relevant Slack channels; no posting. - **Minimum data:** Timestamps of escalations and engineering responses. Whether that history is retrievable: UNKNOWN. - **Success signal:** Retrospective data shows meaningful stall time, AND the shadow detector's would-be nudges are judged correct by humans more often than a fixed-timer baseline. - **Failure signal:** Stalls are rare, or a simple timer rule matches the detector's judgment; or engineering-side responses are not machine-visible. - **Learning objective:** Does the stall problem exist, and does the agent add value over a deterministic rule? - **Test duration:** Until sufficient sample is observed. - **Next decision:** If a timer suffices, build the timer (workflow automation) and drop the agent. If judgment adds value, pilot with limited posting. **Concept C** and **Concept D** are downgraded to components and receive no standalone MVP. Concept C's digest is tested as an output of the Concept B pilot; Concept D is evaluated only against whatever native Zendesk tooling exists. --- # 12. BUILD / TEST / REJECT DECISIONS | Concept | Status | Basis | |---|---|---| | A — Escalation Packager | **TEST FIRST** | Workflow fit is clear; value is plausible; tool access, note structure, and current escalation quality are unknown; success is measurable via shadow mode | | B — Escalation Watchdog | **TEST FIRST** | Stated problem ("slow escalations") maps directly, but value over a deterministic timer is unproven and engineering-side visibility is unknown | | C — Review Digest | **REWORK** | Agent boundary is wrong as a standalone; fold into B as an output | | D — Answer Drafter | **REJECT** as an agent | Single-pass retrieval and drafting; a copilot or native Zendesk feature is sufficient; no closed loop | No concept reaches BUILD: none meets all four BUILD conditions, because data/action feasibility is not established ({UNKNOWN — evidence needed: Zendesk/Slack API access, escalation representation}). --- # 13. AGENT OPPORTUNITY PORTFOLIO ### AGENT CONCEPT — Escalation Packager Assembles a complete, normalized escalation package from ticket history, engineering notes, and prior cases. **PROBLEM:** Escalating a technical problem requires manual context gathering, which slows escalation. The evidence is the stated goal of reducing slow escalations; current package quality is UNKNOWN. **WHY AGENTIC:** Requires relevance judgment across unstructured sources, missing-information detection, and routing, beyond a fixed template. This is conditional on cross-system read access. **USER:** Support agents (and receiving engineers). **TRIGGER:** Support agent flags a ticket for escalation. **OBSERVE:** Ticket thread, related engineering notes, docs, prior similar escalations. **DECIDE:** Which context is relevant; what is missing; route and suggested severity. **ACT:** Draft the package; ask for missing fields; (after approval) post to the engineering destination; write an internal note. **TOOLS:** Zendesk (R/W internal note), engineering notes (R), docs (R), Slack (W). Availability UNKNOWN for all but existence. **AUTONOMY:** Read, assemble, and draft; write internal note. **HUMAN GATES:** Posting to engineering (MVP); any customer-facing message; refunds/account/high-impact: human-only. **FAILURE BOUNDARY:** Primary risk is stale or wrong context misleading engineering. Containment: cited sources with dates, human approval before send, engineer feedback flag. **MVP:** Shadow-mode packages on real escalations, read-only. **SUCCESS SIGNAL:** Agents rate packages at least as complete as their own, and they would have prevented past clarification requests. **KILL SIGNAL:** Packages routinely miss what engineers later ask for; agents rewrite most of them. **NEXT ACTION:** Confirm read access to a sample of past escalations and the engineering notes; pick the pilot sample. **STATUS:** TEST FIRST ### AGENT CONCEPT — Escalation Watchdog Monitors escalated tickets for stalls, nudges engineering, verifies movement, and escalates to a human owner. **PROBLEM:** Escalations can stall; follow-up depends on agent memory and is discovered late. Evidence: "sometimes follow up with engineering," and "slow escalations." Stall frequency is UNKNOWN. **WHY AGENTIC:** Time-based monitoring across Zendesk and Slack with judgment on real stalls vs. waiting on the customer and on whom to nudge. **Caveat:** a deterministic timer may capture most of the value; the MVP tests this. **USER:** Support agents; support managers. **TRIGGER:** Escalation ages past an owner-set threshold (threshold UNKNOWN). **OBSERVE:** Escalation timestamps, ticket state, Slack thread activity. **DECIDE:** Is the stall real; whom to nudge; whether to notify a manager. **ACT:** Nudge in-thread; add an internal note; notify the agent/manager. **TOOLS:** Zendesk (R, W internal note), Slack (R, W), engineering tracker (R, UNKNOWN whether one exists). **AUTONOMY:** Nudge within rate limits; notify humans; write internal notes. **HUMAN GATES:** Anything customer-facing; status changes; any high-impact ticket; refunds/account: human-only. **FAILURE BOUNDARY:** Primary risk is false or repeated nudges (stale state, looping). Containment: hard cap and cooldown per escalation, ownership check, stop-and-notify on ambiguity. **MVP:** Observe-only retrospective analysis plus shadow detection; compare with a fixed-timer baseline. **SUCCESS SIGNAL:** Material stall time observed, and detector judgment beats the timer baseline. **KILL SIGNAL:** Stalls are rare, a timer suffices, or engineering-side responses are invisible to the agent. **NEXT ACTION:** Pull aging data on past escalated tickets and identify where engineering responds. **STATUS:** TEST FIRST ### AGENT CONCEPT — Review Digest (folded component) Decision-ready digest of escalated/unresolved tickets for managers. **PROBLEM:** Managers reconstruct ticket state before deciding. Evidence: "Managers review escalations and unresolved tickets"; reconstruction effort is UNKNOWN. **WHY AGENTIC:** Weak. Read-only summarization with no action loop; retained as an output of the Watchdog. **USER:** Support managers. **TRIGGER:** Scheduled or on-demand (cadence UNKNOWN). **OBSERVE:** Ticket state, escalation records, Slack activity. **DECIDE:** Ordering and summary content. **ACT:** Generate digest (read-only). **TOOLS:** Zendesk (R), Slack (R). **AUTONOMY:** Read-only, fully autonomous. **HUMAN GATES:** None needed (no actions). **FAILURE BOUNDARY:** Unsupported summaries or missed tickets. Containment: every claim links to its source event; coverage statement shown. **MVP:** Delivered as part of the Watchdog pilot. **SUCCESS SIGNAL:** Managers report shorter review prep. **KILL SIGNAL:** Managers keep reconstructing state anyway. **NEXT ACTION:** Fold into the Watchdog design; no separate build. **STATUS:** REWORK ### AGENT CONCEPT — Answer Drafter (rejected as an agent) Docs-grounded reply drafting for common questions. **PROBLEM:** Repetitive doc search and reply composition. Evidence: goal "Reduce repetitive agent work." **WHY AGENTIC:** It is not; single-pass retrieval and drafting. **USER:** Support agents. **TRIGGER:** Ticket classified as a common question. **OBSERVE:** Ticket text; documentation. **DECIDE:** Whether the docs answer the question. **ACT:** Insert an unsent draft. **TOOLS:** Documentation (R), Zendesk (R, draft insertion). **AUTONOMY:** Draft only. **HUMAN GATES:** Every send; refunds/account/high-impact: no draft, human-only. **FAILURE BOUNDARY:** Wrong or outdated answer sent. Containment: citation required for every claim; human sends. **MVP:** None as an agent; evaluate against native Zendesk tooling if any. **SUCCESS SIGNAL:** Not applicable. **KILL SIGNAL:** Not applicable. **NEXT ACTION:** Check what native Zendesk AI/copilot features are already licensed. **STATUS:** REJECT --- # 14. MACHINE-READABLE PORTFOLIO The schema below is followed exactly, with `null` for empty values, though the JSON must use standard array/object syntax rather than the doubled braces shown in the template. ```json [ { "agent_name": "Escalation Packager", "one_line_purpose": "Assemble a complete, normalized escalation package from ticket history, engineering notes, and prior cases.", "problem": "Escalating technical problems requires manual context gathering, which slows escalation; current package quality is UNKNOWN.", "why_agentic": "Needs cross-source relevance judgment, missing-information detection, and routing beyond a fixed template; conditional on cross-system read access.", "primary_user": "Support agents (secondary: receiving engineers)", "trigger": "Support agent flags a ticket for escalation", "observe": { "sources": ["Zendesk ticket thread and history", "Engineering notes", "Product documentation", "Prior similar escalations"] }, "decide": { "decisions": ["Which context is relevant", "What information is missing", "Routing destination", "Suggested severity"] }, "act": { "actions": ["Draft escalation package", "Request missing fields from support agent", "Post approved package to engineering destination", "Write internal Zendesk note"] }, "tools_required": [ {"system": "Zendesk", "read_write": "read + write internal note", "availability": "UNKNOWN"}, {"system": "Engineering notes", "read_write": "read", "availability": "UNKNOWN"}, {"system": "Product documentation", "read_write": "read", "availability": "UNKNOWN"}, {"system": "Slack", "read_write": "write", "availability": "UNKNOWN"} ], "autonomy": { "autonomous": ["Read across systems", "Assemble draft package", "Write internal-only Zendesk note"], "human_approval_required": ["Post package to engineering (MVP)", "Any customer-facing message", "Ticket status or priority changes"], "never_without_explicit_authority": ["Refunds", "Account access or account changes", "High-impact customer decisions", "Actions outside the declared tool list"], "classification_conflicts": [ {"action": "Refunds", "concept_assessment": "not applicable (not proposed)", "input_requirement": "human control required", "resolved_as": "IRREVERSIBLE / HUMAN-ONLY"}, {"action": "Account access / account changes", "concept_assessment": "not applicable (not proposed)", "input_requirement": "human control required", "resolved_as": "IRREVERSIBLE / HUMAN-ONLY"}, {"action": "High-impact customer decisions", "concept_assessment": "REVERSIBLE for status/notes", "input_requirement": "no uncontrolled AI authority", "resolved_as": "CONSEQUENTIAL, human-approved"} ] }, "failure_boundary": { "primary_risk": "Stale or wrong context misleads engineering.", "containment": "Cited, dated sources; human approval before send; engineer feedback flag; idempotency check against duplicate posts." }, "mvp": { "hypothesis": "Pre-assembled packages reduce engineering clarification requests and support-agent assembly effort.", "smallest_test": "Shadow-mode packages on real escalations, read-only, compared against agent-written escalations.", "success_signal": "Agents rate packages at least as complete as their own; packages would have prevented past clarification requests.", "kill_signal": "Packages routinely miss information engineers later request; agents rewrite most packages.", "test_duration": "until sufficient sample is observed" }, "next_action": "Confirm read access to past escalations and engineering notes; select the pilot sample.", "status": "TEST_FIRST" }, { "agent_name": "Escalation Watchdog", "one_line_purpose": "Monitor escalated tickets for stalls, nudge engineering, verify movement, and escalate to a human owner.", "problem": "Escalations can stall and follow-up depends on agent memory; stall frequency is UNKNOWN.", "why_agentic": "Time-based monitoring across Zendesk and Slack with judgment on real stalls and on whom to nudge; a deterministic timer may capture most of the value, which the MVP tests.", "primary_user": "Support agents and support managers", "trigger": "Escalation ages past an owner-set threshold (threshold UNKNOWN)", "observe": { "sources": ["Escalation timestamps", "Ticket state", "Slack thread activity", "Engineering tracker state (existence UNKNOWN)"] }, "decide": { "decisions": ["Whether the stall is real versus waiting on the customer", "Whom to nudge", "Whether to notify a manager"] }, "act": { "actions": ["Post nudge in the engineering thread", "Write internal Zendesk note", "Notify agent or manager of a stall"] }, "tools_required": [ {"system": "Zendesk", "read_write": "read + write internal note", "availability": "UNKNOWN"}, {"system": "Slack", "read_write": "read + write", "availability": "UNKNOWN"}, {"system": "Engineering tracker", "read_write": "read", "availability": "UNKNOWN"} ], "autonomy": { "autonomous": ["Nudge within rate limits (limit UNKNOWN, owner-set)", "Notify humans of stalls", "Write internal-only notes"], "human_approval_required": ["Any customer-facing message", "Ticket status changes", "Any action on high-impact tickets"], "never_without_explicit_authority": ["Refunds", "Account access or account changes", "High-impact customer decisions", "Closing or deleting tickets"], "classification_conflicts": [ {"action": "Refunds", "concept_assessment": "not applicable (not proposed)", "input_requirement": "human control required", "resolved_as": "IRREVERSIBLE / HUMAN-ONLY"}, {"action": "Account access / account changes", "concept_assessment": "not applicable (not proposed)", "input_requirement": "human control required", "resolved_as": "IRREVERSIBLE / HUMAN-ONLY"}, {"action": "Nudges and status changes on high-impact tickets", "concept_assessment": "REVERSIBLE", "input_requirement": "no uncontrolled AI authority over high-impact customer decisions", "resolved_as": "CONSEQUENTIAL, human-approved"} ] }, "failure_boundary": { "primary_risk": "False or repeated nudges caused by stale state or looping.", "containment": "Hard cap and cooldown per escalation; ownership check before posting; stop and notify a human on ambiguity or cap reached." }, "mvp": { "hypothesis": "Escalations stall often enough, and long enough, that judgment-based follow-up outperforms a plain timer reminder.", "smallest_test": "Observe-only retrospective aging analysis plus shadow detection compared with a fixed-timer baseline.", "success_signal": "Material stall time is observed and the detector's would-be nudges are judged correct more often than the timer baseline.", "kill_signal": "Stalls are rare, a timer rule suffices, or engineering-side responses are not machine-visible.", "test_duration": "until sufficient sample is observed" }, "next_action": "Pull aging data on past escalated tickets and identify where engineering responds.", "status": "TEST_FIRST" }, { "agent_name": "Review Digest", "one_line_purpose": "Produce a decision-ready digest of escalated and unresolved tickets for managers (folded into the Watchdog).", "problem": "Managers reconstruct ticket state before deciding; reconstruction effort is UNKNOWN.", "why_agentic": "Weak: read-only summarization with no action loop; retained as an output of the Watchdog.", "primary_user": "Support managers", "trigger": "Scheduled or on-demand before manager review (cadence UNKNOWN)", "observe": { "sources": ["Ticket state", "Escalation records", "Slack activity"] }, "decide": { "decisions": ["Ordering of tickets", "Summary content per ticket"] }, "act": { "actions": ["Generate read-only digest"] }, "tools_required": [ {"system": "Zendesk", "read_write": "read", "availability": "UNKNOWN"}, {"system": "Slack", "read_write": "read", "availability": "UNKNOWN"} ], "autonomy": { "autonomous": ["Read and summarize"], "human_approval_required": [], "never_without_explicit_authority": ["Any write action", "Refunds", "Account access or account changes"], "classification_conflicts": [] }, "failure_boundary": { "primary_risk": "Unsupported summaries or missed tickets lead to poor manager decisions.", "containment": "Every claim links to its source ticket event; coverage statement shown; manager can open the raw ticket." }, "mvp": { "hypothesis": "A digest shortens manager review preparation.", "smallest_test": "Delivered as an output of the Watchdog pilot; no standalone test.", "success_signal": "Managers report shorter review prep.", "kill_signal": "Managers keep reconstructing state despite the digest.", "test_duration": "until sufficient sample is observed" }, "next_action": "Fold into the Watchdog design; no separate build.", "status": "REWORK" }, { "agent_name": "Answer Drafter", "one_line_purpose": "Draft documentation-grounded replies to common questions for agent approval.", "problem": "Repetitive doc search and reply composition (goal: reduce repetitive agent work); volume is UNKNOWN.", "why_agentic": "Not agentic: single-pass retrieval and drafting with no closed loop; a copilot or native Zendesk feature suffices.", "primary_user": "Support agents", "trigger": "Ticket classified as a common question", "observe": { "sources": ["Ticket text", "Product documentation"] }, "decide": { "decisions": ["Whether the docs answer the question", "Which sections apply"] }, "act": { "actions": ["Insert unsent draft reply with citations"] }, "tools_required": [ {"system": "Product documentation", "read_write": "read", "availability": "UNKNOWN"}, {"system": "Zendesk", "read_write": "read + draft insertion", "availability": "UNKNOWN"} ], "autonomy": { "autonomous": ["Retrieve and draft (unsent)"], "human_approval_required": ["Every customer-facing send"], "never_without_explicit_authority": ["Sending replies", "Refunds", "Account access or account changes", "High-impact customer decisions"], "classification_conflicts": [ {"action": "Customer-facing reply send", "concept_assessment": "REVERSIBLE (a follow-up can correct it)", "input_requirement": "high-impact customer decisions must stay human-controlled; routine reply policy UNKNOWN", "resolved_as": "CONSEQUENTIAL, human-only send"} ] }, "failure_boundary": { "primary_risk": "Wrong or outdated answer sent to the customer.", "containment": "Citation required for every claim; no citation means no draft; a human reviews and sends every reply." }, "mvp": { "hypothesis": null, "smallest_test": null, "success_signal": null, "kill_signal": null, "test_duration": null }, "next_action": "Check which native Zendesk AI/copilot features are already licensed.", "status": "REJECT" } ] ``` --- # FINAL PORTFOLIO DECISION **BEST OPPORTUNITY TO TEST FIRST** Escalation Watchdog (Concept B), run as an observe-only retrospective analysis. **WHY THIS ONE** It maps most directly to the stated goal of slow escalations, is the cheapest to test (read-only, no customer-facing exposure, no consequential actions), and carries the sharpest open question: whether an agent beats a plain timer rule. A negative result there is also valuable, since it redirects effort to a simple automation. The Packager is close behind and can be tested in parallel if its inputs are easy to get, but the Watchdog experiment needs less access. **EVIDENCE SUPPORTING IT** - {CONFIRMED — evidence: "Reduce repetitive agent work and slow escalations"} - {HIGHLY LIKELY — evidence: agents "sometimes follow up with engineering," implying follow-up is inconsistent} - {CONFIRMED — evidence: "Managers review escalations and unresolved tickets," indicating unresolved-ticket visibility is a manual, after-the-fact process} - No quantified evidence of stall frequency, duration, or business impact was supplied. **BIGGEST UNKNOWN** Where engineering responds and whether those responses are machine-visible (Zendesk field, Slack thread, separate tracker, or DMs and meetings). If they are not, the Watchdog's core loop cannot run. Close behind: how often escalations actually stall, which no input quantifies. **FIRST EXPERIMENT** 1. Identify how escalations are represented in Zendesk and where engineering responds. 2. Export aging data (escalation time, first engineering response, resolution) for a sample of past escalated tickets. 3. Measure stall frequency and duration; classify which stalls a fixed timer would have caught. 4. If stalls are material and the timer misses meaningful cases, run the detector in shadow mode (no posting) and have humans grade each would-be nudge. **DO NOT BUILD YET** - Any write-enabled Slack or Zendesk behavior - Any customer-facing generation or sending - The Answer Drafter as an agent - A standalone Review Digest agent - Any multi-agent architecture - Anything touching refunds, account access, or high-impact customer decisions **WHAT WOULD CHANGE THE DECISION** - Stalls are rare, or a deterministic timer captures most of the value: build the timer as a workflow automation and drop the Watchdog agent. - Engineering responses are invisible to machines: rework the escalation process first, or switch priority to the Packager. - Escalation packages are the real bottleneck (frequent clarification requests): promote the Packager to first test. - Zendesk or Slack API access is blocked: nothing beyond manual concierge tests is feasible. - Native Zendesk AI features already cover the Answer Drafter and digest needs: confirms their rejection and downgrade. **PORTFOLIO STATUS** **PARTIALLY READY.** The workflow fit is clear and the risk boundaries are defined, but tool access, escalation representation, and the frequency and cost of the underlying friction are all unknown. No demand, ROI, integration, or business value has been validated by the evidence supplied.