# AI Customer-Support Escalation Agent: Architecture Analysis & Blueprint --- ## 1. AGENT OPPORTUNITY RECONSTRUCTION **Core problem** Support agents and leads currently decide, largely by hand, whether an unresolved Zendesk ticket needs engineering involvement, and if so, they must gather evidence, determine the right team, file a Jira issue, notify the team in Slack, and track it to resolution. This is inconsistent, easy to skip under load, and hard to audit. The core problem is inconsistent, unaudited, and slow escalation decision-making and follow-through — not a lack of raw information, and not a lack of execution capability once a decision is made. **Primary users and stakeholders** - Primary users: support agents and support leads (they benefit from correct, evidence-backed escalations and reduced manual triage work). - Downstream recipients: engineering teams (receive Jira issues and Slack notifications; must trust that what arrives is real, deduplicated, and well-evidenced). - Indirect stakeholders: customers (affected by resolution speed and by privacy of their data moving through the pipeline). **Trigger** CONFIRMED trigger class: unresolved support tickets in Zendesk. The exact triggering mechanism (webhook on ticket update, scheduled poll, SLA-breach event, manual "escalate" tag) is UNKNOWN and material — it determines whether this is event-driven or a recurring/scheduled workflow. This is treated as a key unknown below, and the architecture is designed to tolerate either. **Desired outcome** Every ticket that genuinely needs engineering gets an accurate, evidence-backed, correctly routed Jira issue, engineering is notified once, duplicates are prevented, and the escalation is tracked to resolution with a full audit trail — without the agent making customer-facing commitments, refunds, account changes, or production changes on its own. **Inputs and information** - Zendesk ticket content: description, comments, tags, customer metadata, prior agent notes. - Internal knowledge base: documentation, known issues, runbooks, past resolutions. - Historical Jira issues (for duplicate detection) — CONDITIONAL on read access being confirmed. - Team-to-issue-type routing rules or ownership metadata — ASSUMED to exist somewhere (Jira components, a routing table, or KB metadata); exact source is UNKNOWN and must be confirmed before build. **Observable state** - Ticket status/history in Zendesk. - Existing Jira issues linked to a ticket (or lack thereof). - Prior escalation decisions and their outcomes, if persisted. - Workflow state in the PostgreSQL store (this is the system's own memory of what it has already done). **Decisions** 1. Does this ticket require engineering involvement (escalate: yes/no)? 2. If yes, which engineering team owns it? 3. Is this a duplicate of an existing open escalation? 4. Is the evidence sufficient, or is more information needed (and from whom)? 5. When is the escalation considered resolved and closeable? **Actions** - Read ticket and KB content (read-only). - Query for existing/duplicate Jira issues (read-only). - Create a Jira issue (write, consequential but reversible). - Post a Slack notification (write, low-impact). - Write/update workflow state and audit records in PostgreSQL (write, internal only). - Update the Zendesk ticket with a link/status note (write, low-impact) — CONDITIONAL on this being desired; not stated explicitly in requirements, flagged as ASSUMED-useful. - Poll or listen for Jira status changes to track resolution (read, recurring). **Tools and systems** CONFIRMED (named explicitly): Zendesk, internal knowledge base, Jira, Slack, PostgreSQL. No other tools should be assumed. Anything beyond these five requires new justification and explicit confirmation. **Human participants and approvals** - Support agents/leads: implicit reviewers, and likely the escalation point when the agent cannot decide confidently (UNKNOWN exact human review point — assumed to be "support lead" for ambiguous cases based on stated stakeholder list). - Engineering teams: recipients, not approvers, of the created issue. - Human approval is explicitly required for anything customer-facing (commitments) — this is a hard constraint, not a design choice. **Time horizon** Long-running per escalation: from detection through to Jira resolution, which could span hours to weeks. This is fundamentally a durable, resumable, multi-day workflow, not a single-shot request/response. **Completion conditions** An escalation instance completes when: (a) the agent decides no escalation is needed (terminal, no Jira issue created), or (b) the linked Jira issue reaches a resolved/closed state and the outcome is recorded back to the ticket and audit log, or (c) the escalation is manually closed/overridden by a human. **High-impact or irreversible actions** None of the core actions (Jira creation, Slack post) are truly irreversible — they can be corrected, closed, or retracted. The genuinely irreversible/prohibited category is explicitly out of scope: refunds, account changes, production changes, and customer-facing commitments. This matters: it means the agent's own actions are all LOW-IMPACT/REVERSIBLE, which is a strong argument against heavy human-in-the-loop gating on every step, while the excluded actions must be hard-blocked at the tool-access layer, not just at the prompt layer. **Explicit exclusions and boundaries** - No autonomous refunds or account changes. - No autonomous production changes. - No autonomous customer-facing commitments (human approval required). - Bounded retries only. - Least-privilege tool access. - Reliability and traceability prioritized over autonomy. **Key unknowns** - Exact trigger mechanism (webhook vs. poll vs. tag-based). - Source of truth for team-routing rules. - Whether Zendesk write access is authorized (to post status back to the ticket). - Whether Jira search/read access exists for duplicate detection. - Expected ticket volume (affects whether batching/queueing is needed). - Whether a human lead must approve every escalation, or only low-confidence ones. - What "resolution" means precisely — Jira status change alone, or also requiring the original ticket to close. These unknowns are treated as ASSUMED-conservative defaults throughout (favoring human review and least privilege) and are flagged for confirmation before implementation. **Solution classification** This is a **hybrid architecture**: deterministic workflow/state-machine orchestration for control flow, durability, retries, and audit, combined with a **single tool-using agent** (one LLM-driven reasoning component) for the genuinely judgment-heavy steps — escalation decision, evidence synthesis, and team routing when rules are ambiguous. It is explicitly **not**: - A single model call — the task spans multiple systems, requires durable state, and outlives a single request/response cycle. - Pure deterministic automation — deciding "does this need engineering" and "which team" from unstructured ticket text and KB content requires language understanding and judgment that fixed rules cannot fully capture, though rules should handle what they can (e.g., exact keyword/component matches). - A copilot — the workflow must run without a human driving every step in real time; humans are gated at specific checkpoints, not steering the whole process. - A multi-agent system — there is one class of judgment task (interpret ticket → decide → route), performed by one reasoning component per ticket. Splitting this into multiple communicating agents (e.g., a "triage agent" talking to a "routing agent" talking to a "evidence agent") adds coordination overhead, failure surface, and cost with no corresponding capability gain — a single agent with well-scoped tools and a structured output can do all three judgment steps in one reasoning pass per ticket. - A long-running autonomous system in the "keeps planning and acting indefinitely" sense — each escalation has a bounded, well-defined lifecycle (open → track → resolve/close) governed by a state machine, not open-ended autonomous goal pursuit. The "long-running" property here is about **state durability and external wait states** (waiting on Jira status, waiting on human approval), which is a workflow-orchestration concern, not a reason to make the agent itself autonomous and open-ended. --- ## 2. WORKFLOW & CONTROL-FLOW ANALYSIS **Trigger** An unresolved Zendesk ticket enters the system, either via event (webhook) or scheduled scan (poll). The workflow instance is keyed by ticket ID to guarantee idempotency — re-triggering on the same ticket must not create a second workflow instance. **Observe** The system checks durable state: does a workflow instance already exist for this ticket ID? If yes and it is active, no new instance is created (duplicate-trigger protection at the entry point, distinct from duplicate-issue protection later). If yes and terminal, only re-open if explicitly instructed. If no, create a new instance in PostgreSQL with status "observed." **Retrieve** Deterministic retrieval step (not LLM-driven): pull the full ticket content and history from Zendesk, and run a knowledge-base lookup (keyword/semantic search) for related documentation or known issues. This is retrieval-augmented context assembly, executed by code, not by agent reasoning — the agent should receive already-fetched evidence, not decide on its own whether to call the KB. **Interpret** The LLM-driven agent reasoning step. Given the ticket content and retrieved KB context, the agent produces a structured judgment: escalation-needed (yes/no), confidence level, candidate team, and a rationale referencing the specific evidence used. This is where genuine ambiguity resolution happens. **Decide** Deterministic control logic consumes the agent's structured output: - If escalation-needed = no and confidence is high → mark ticket workflow complete, no Jira issue, log rationale. - If escalation-needed = no but confidence is low → route to human review queue (support lead) rather than auto-closing. - If escalation-needed = yes → proceed to duplicate check. - Duplicate check (deterministic query against Jira/PostgreSQL by ticket ID or fingerprint) → if duplicate found, link to existing issue and skip creation; if not, proceed. - Team routing: attempt deterministic match against known routing rules first (e.g., KB tags → team mapping); only fall back to the agent's suggested team when no deterministic rule applies, and flag those cases for lower-confidence handling. **Plan** Explicitly minimal: the "plan" is a fixed, short sequence (gather evidence → decide → route → create issue → notify → track), not an open-ended planning loop. No dynamic multi-step planning is required because the action space is small and well-known in advance. **Act** Deterministic tool calls, gated by the decisions above: - Create Jira issue with the evidence brief, ticket link, and routing. - Post Slack notification to the routed team's channel. - Write back a status note/link on the Zendesk ticket (if write access confirmed). - Persist all of the above as audit records in PostgreSQL, including timestamps, decision rationale, and evidence snapshot. **Verify** After each write action, a deterministic verification check confirms the action succeeded (e.g., Jira returns a valid issue key; Slack returns a 200 with message timestamp) before marking that step complete in state. If verification fails, the step is retried within bounds, not silently assumed successful. **Continue (tracking / recurring)** Once the Jira issue is created, the workflow enters a "tracking" state. This is a recurring/long-running wait state: on a schedule (e.g., periodic poll of Jira issue status, or webhook if Jira supports it) the system checks whether the issue has moved to resolved/closed. Each check is a lightweight deterministic operation, not a fresh agent reasoning pass, unless the ticket's own state has materially changed (e.g., customer replied again), in which case a bounded re-interpretation may be warranted. **Complete** The workflow reaches a terminal state when: the Jira issue is resolved and the Zendesk ticket is updated/closed accordingly, or when a human explicitly closes the escalation, or when the "no escalation needed" path is taken. All terminal states are recorded with full rationale and timestamps. **Escalate (to a human)** Distinct from "escalate to engineering" — this is escalation of the *workflow itself* to a human when: agent confidence is low, evidence is insufficient or conflicting, no routing rule matches, a tool call fails repeatedly beyond retry bounds, or the ticket contains a customer-facing commitment need. These route to a human review queue, not to a dead end. **Sequential vs. parallel work** Sequential: observe → retrieve → interpret → decide → route → create issue → notify. Retrieval sub-steps (Zendesk fetch and KB lookup) can run in parallel since they are independent reads. Duplicate-check query can also run in parallel with KB retrieval since both only need the ticket ID/content, not each other's output. **Long-running and recurring processes** The tracking phase is inherently long-running (days to weeks) and recurring (periodic status checks). This is the primary reason durable state is REQUIRED rather than optional. **External wait states** Waiting on Jira resolution; waiting on human approval/review in the escalation queue; waiting on additional customer information if evidence is insufficient (this last one implies the workflow may need to pause and resume when the Zendesk ticket gets a new customer reply — an event-driven resume path). **Exceptions, retries, recovery points** Each tool call (Zendesk read/write, KB query, Jira create/query, Slack post) is a discrete, retryable unit with bounded attempts (e.g., 3 retries with backoff) and a defined failure state that surfaces to human review rather than looping indefinitely. Recovery points are the persisted state after each successfully verified step, so a crash mid-workflow resumes from the last confirmed step rather than restarting or duplicating actions. **Human gates** Low-confidence escalation decisions; no matching routing team; any customer-facing commitment language detected in evidence; repeated tool failures beyond retry bounds; explicit "no escalation needed" decisions below a confidence threshold (to catch missed escalations). **Completion states and termination conditions** Terminal states: "resolved-via-engineering" (Jira closed, ticket updated), "no-escalation-needed" (logged, no issue created), "closed-by-human" (manual override), "abandoned-after-max-retries-pending-human" (only after human review, never a silent drop). **Persistent-state requirements** Every workflow instance's current stage, decision rationale, evidence snapshot, tool-call outcomes, and timestamps must be durably persisted (PostgreSQL) so the system can resume after interruption, prevent duplicate actions, and provide a complete audit trail. This is REQUIRED, not optional, because of the multi-day time horizon and the auditability requirement. --- ## 3. ARCHITECTURAL FORCES **State duration** Evidence: tracking phase spans until Jira resolution, potentially days to weeks; audit records must persist indefinitely for compliance. Consequence: durable, queryable state store is mandatory (PostgreSQL, as specified) rather than in-memory or ephemeral context. Confidence: CONFIRMED (explicitly stated requirement). If false: irrelevant — this is a given constraint, not an inference. **Decision complexity** Evidence: "requires engineering" and "which team" are judgments over unstructured ticket text plus KB context, with no fully deterministic rule set known to exist. Consequence: a single LLM reasoning step is justified for interpretation, but should be constrained to structured output and cross-checked against whatever deterministic routing rules do exist. Confidence: HIGHLY LIKELY. If false (i.e., if routing turns out to be fully deterministic, e.g., ticket category directly maps to team): the LLM step could be narrowed to just the escalate/no-escalate judgment, with routing handled entirely by rules — this would simplify the architecture further and should be re-evaluated once routing rules are confirmed. **Tool/integration complexity** Evidence: five distinct systems (Zendesk, KB, Jira, Slack, PostgreSQL), each with its own API semantics, auth, and failure modes. Consequence: a tool-gateway/adapter layer per integration is warranted to isolate failure handling and permissions, but this does not require a multi-agent split — one orchestrator can call multiple tool adapters. Confidence: CONFIRMED (systems are named explicitly). **Action consequences** Evidence: explicit exclusions (no refunds, no account changes, no production changes, no autonomous customer commitments) plus explicit inclusion of Jira/Slack/DB writes as the agent's actual action set. Consequence: the agent's writable action surface is inherently bounded to low/medium-impact, reversible actions; the highest-consequence actions are structurally excluded from tool access entirely, not merely discouraged by prompting. Confidence: CONFIRMED. **Reliability and traceability** Evidence: explicitly stated as taking priority over autonomy; success criteria include "complete auditability." Consequence: every decision and action must be logged with rationale and evidence references; verification steps follow every write; deterministic control flow is preferred over open-ended agent looping wherever possible. Confidence: CONFIRMED — this is the single most important force shaping the whole design. **Specialization and parallelism** Evidence: the judgment tasks (interpret, decide, route) are cognitively related and operate on the same evidence bundle; there's no indication of needing genuinely independent specialist expertise (e.g., a distinct "legal specialist" vs. "billing specialist" agent). Consequence: one agent role suffices; parallelism is limited to independent read operations (retrieval), not to splitting reasoning across agents. Confidence: HIGHLY LIKELY. If false (e.g., if engineering teams are highly specialized enough that routing truly requires domain-specific sub-reasoning per team): a router-plus-specialist pattern could be reconsidered, but this is not evidenced by the current requirements. **Human oversight** Evidence: explicit requirement for human approval on customer-facing commitments, plus general "reliability over autonomy" mandate. Consequence: defined human gates at low-confidence decisions and at any customer-facing-commitment detection; human review queue is a first-class component, not an afterthought. Confidence: CONFIRMED for commitments; HIGHLY LIKELY (but UNKNOWN in exact threshold) for low-confidence escalation gating. **Recovery** Evidence: multi-day time horizon, external system dependencies prone to transient failure. Consequence: state machine with persisted checkpoints after each verified step; bounded retries; clear failure-to-human-review path. Confidence: CONFIRMED as a requirement (bounded retries explicitly stated). **Latency** Evidence: nothing suggests sub-second response requirements; this is a background support-operations workflow, not a live chat. Consequence: batching, polling intervals, and asynchronous processing are all acceptable; no need for low-latency streaming architecture. Confidence: HIGHLY LIKELY, based on the nature of ticket escalation work. If false (e.g., if support leads expect near-real-time escalation for urgent tickets): trigger mechanism should favor webhook/event-driven over polling, but the rest of the architecture is largely latency-insensitive regardless. **Data sensitivity** Evidence: explicit "respecting customer-data privacy" requirement; customer PII will flow through ticket content into Jira issues and Slack messages. Consequence: evidence briefs sent to engineering should be scrubbed/minimized to what's necessary (least-data-exposure), and access to raw ticket content should be limited to what each tool/component needs. Confidence: CONFIRMED as a stated constraint; exact scrubbing rules are UNKNOWN and must be defined with privacy/legal input. **Scale/workload** UNKNOWN — ticket volume is not stated. This matters for whether polling-based tracking and duplicate-checking need to be batched/queued versus handled per-ticket synchronously. ASSUMED moderate volume (typical B2B/B2C support team scale) pending confirmation; if volume is very high, a queue-based worker pool becomes necessary rather than optional. **Consistency** Evidence: duplicate prevention is an explicit success criterion. Consequence: the workflow-instance-per-ticket-ID model plus a duplicate-issue check before Jira creation are both required; the system must treat "has this already been escalated" as a strongly consistent read against durable state, not an eventually-consistent guess. Confidence: CONFIRMED. **Change frequency** UNKNOWN how often routing rules, team ownership, or KB structure change. ASSUMED moderate — routing rules should be stored as configurable data (a table or KB-derived mapping), not hardcoded in agent prompts, so they can change without redeploying the agent. **Operational complexity** Evidence: five integrations plus a durable store plus human review queue. Consequence: this is a real production system requiring observability (logging, metrics, alerting on stuck workflows) — but still within the bounds of a single orchestrated workflow, not a distributed multi-agent operations burden. Confidence: HIGHLY LIKELY to be manageable at moderate scale; would need re-evaluation only if scale/workload turns out to be very high (UNKNOWN, noted above). --- ## 4. MINIMUM REQUIRED ARCHITECTURE - **Single agent (one LLM reasoning role)** — REQUIRED. One judgment role (interpret evidence, decide escalation, suggest routing) is sufficient; no second agent role is evidenced. - **Multiple agents** — NOT REQUIRED. No distinct specialist domains or independent goal-pursuing entities are evidenced. - **Router** — CONDITIONAL. A deterministic routing rule-matcher is required if/when routing rules exist as structured data; the agent's judgment is a fallback, not the primary router. This is a lightweight rules component, not a full "router agent" pattern. - **Planner (dynamic, open-ended)** — NOT REQUIRED. The action sequence is fixed and short; no dynamic multi-step plan generation is needed. - **Supervisor (agent overseeing other agents)** — NOT REQUIRED. There is only one agent role; a supervisor pattern implies multi-agent coordination that doesn't exist here. - **Specialized workers** — NOT REQUIRED. No evidence of needing parallel specialist sub-agents. - **Retrieval** — REQUIRED. Knowledge-base lookup for supporting evidence is explicitly part of the workflow and directly supports the "evidence-backed briefs" success criterion. - **Tool gateway** — REQUIRED. Five distinct external systems each need a controlled, permissioned, retryable adapter layer; this is basic integration hygiene, not over-engineering. - **Memory (long-term, cross-ticket, learned preferences)** — NOT REQUIRED. Nothing in the requirements calls for the agent to "learn" across tickets or maintain persistent conversational memory. Durable *workflow state* is required, but that is distinct from agent memory (see Section 10). - **Durable state** — REQUIRED. Multi-day tracking horizon, duplicate prevention, and auditability all depend on it directly. - **Event triggers** — CONDITIONAL. Required if the actual trigger mechanism is webhook-based (UNKNOWN); if polling is used instead, a scheduler substitutes for this. - **Queues** — CONDITIONAL. Justified if ticket volume is high enough to require decoupling ingestion from processing (UNKNOWN scale); at moderate volume, direct synchronous processing per ticket with a scheduler for tracking is sufficient. - **Verification** — REQUIRED. Explicit success criteria (accurate decisions, correct routing, duplicate prevention) demand post-action verification, not "fire and forget" tool calls. - **Human approval** — REQUIRED. Explicitly mandated for customer-facing commitments; CONDITIONAL (recommended, pending confirmation of threshold) for low-confidence escalation/routing decisions. - **Long-running orchestration** — REQUIRED. The tracking-until-resolution requirement is inherently long-running and cannot be handled by a single request/response call. - **Scheduling** — REQUIRED (at minimum for the tracking/polling phase, even if the initial trigger turns out to be event-driven). - **Observability** — REQUIRED. Reliability-over-autonomy mandate demands visibility into stuck workflows, failure rates, and decision quality. - **Audit logging** — REQUIRED. Explicitly named success criterion ("complete auditability"). --- ## 5. AGENT PATTERN ANALYSIS **Deterministic workflow/state machine (control/orchestration)** Problem: coordinate a multi-step, multi-day process reliably. Requirement: durable, resumable, auditable control flow. Evidence: multi-day tracking, duplicate prevention, audit requirements. Benefit: predictable, debuggable, resumable execution. Complexity: moderate (need a state store and defined transitions). Failure modes: state/tool drift if not reconciled carefully. Prerequisites: PostgreSQL schema for workflow state. Fit: STRONG FIT. **Single tool-using agent (for interpretation/decision)** Problem: judge escalation need and team from unstructured evidence. Requirement: decision complexity force. Evidence: no fully deterministic rule set for "does this need engineering." Benefit: handles ambiguity and unstructured text well. Complexity: low-moderate — one well-scoped LLM call with structured output per ticket (plus possible re-invocation on new evidence). Failure modes: hallucinated rationale, overconfidence, inconsistent decisions across similar tickets. Prerequisites: constrained output schema, evidence grounding, confidence scoring. Fit: STRONG FIT. **Retrieval-augmented generation (KB retrieval)** Problem: ground the agent's decision and the eventual Jira brief in real documentation rather than invented claims. Requirement: "evidence-backed briefs" success criterion. Evidence: explicit KB integration named. Benefit: reduces hallucination, supports the brief's credibility to engineering. Complexity: low (existing KB search capability, assumed to exist). Failure modes: irrelevant or stale KB hits leading to misleading evidence. Prerequisites: KB search API access (ASSUMED to exist; exact capabilities UNKNOWN). Fit: STRONG FIT. **Router (rules-first, agent-fallback)** Problem: assign the correct engineering team. Requirement: correct routing success criterion. Evidence: teams are a known, presumably finite set; some routing signals (component tags, product area) are likely structured. Benefit: deterministic routing where possible is more auditable and consistent than pure LLM judgment. Complexity: low, assuming routing metadata exists. Failure modes: stale or incomplete routing tables causing fallback overuse. Prerequisites: a routing table or equivalent structured mapping (UNKNOWN if it exists; must be confirmed). Fit: CONDITIONAL FIT — strong if routing metadata exists, otherwise the agent's own judgment must carry more weight and be more heavily gated by human review. **Multi-agent supervisor/worker system** Problem it would solve: splitting escalation judgment, evidence gathering, and routing into separate cooperating agents. Requirement it maps to: none directly evidenced — the tasks are cohesive and can be done in one reasoning pass. Evidence against: no distinct specialist domains, no need for independent parallel goal pursuit, added coordination and cost with no corresponding capability gain. Fit: REJECTED. **Open-ended planning agent** Problem it would solve: dynamically decide what steps to take next. Requirement: none — the step sequence is fixed and well understood in advance (retrieve → interpret → decide → route → act → track). Fit: REJECTED. **Unbounded reflection/self-critique loops** Problem it would solve: improving output quality via iterative self-review. Requirement: bounded, traceable reasoning is preferred over recursive reasoning that's hard to audit and can loop indefinitely. A single bounded verification pass (e.g., "does this decision cite evidence?") is useful; open-ended reflection is not. Fit: WEAK FIT for unbounded form; a single bounded self-check is CONDITIONAL FIT. **Long-term cross-ticket memory** Problem it would solve: learning patterns across many tickets over time. Requirement: not evidenced; success criteria are about correctness and auditability per-ticket, not adaptive learning. Risk: memory of past customer data raises privacy concerns without clear benefit. Fit: REJECTED (for now — see Section 6 revisit conditions). **Human-in-the-loop gate (approval queue)** Problem it would solve: preventing autonomous customer commitments and catching low-confidence decisions. Requirement: explicitly mandated. Evidence: stated constraint. Benefit: directly satisfies the "human approval for customer-facing commitments" and "reliability over autonomy" requirements. Complexity: low (a queue/table plus a review UI or existing ticketing mechanism — UNKNOWN what review interface exists, likely just a flagged Zendesk/Slack notification to a lead). Fit: STRONG FIT. **Bounded retry with circuit-breaker-style failure escalation** Problem it would solve: transient tool failures without infinite loops. Requirement: "bounded retries" explicitly stated. Fit: STRONG FIT. **Idempotent action design / deduplication key** Problem it would solve: duplicate prevention. Requirement: explicit success criterion. Evidence: ticket ID as natural dedup key; Jira issue search before creation. Fit: STRONG FIT. **Event-driven trigger + recurring scheduler (hybrid)** Problem it would solve: initiating on new unresolved tickets and periodically checking long-running Jira status. Requirement: trigger and tracking needs. Evidence: both an initiating trigger and a recurring check are needed regardless of which mechanism initiates. Fit: STRONG FIT. --- ## 6. PATTERN SELECTION & REJECTION **Selected: deterministic state machine as the orchestration backbone.** Necessary because the workflow spans days, must be resumable, and must be auditable. It lives at the top level, owning all control-flow decisions (what step comes next, whether to retry, whether to gate to a human), while delegating only the interpretation step to the LLM agent. Trade-off: requires upfront schema and state design work, but this cost is unavoidable given the durability and audit requirements regardless of architecture style. **Selected: single tool-using agent for interpretation and decision-support.** Necessary because unstructured ticket/KB text requires language understanding that fixed rules can't fully capture. It sits inside the "Interpret" stage only, receiving pre-fetched evidence and returning a structured judgment (escalate: yes/no, confidence, suggested team, rationale with evidence citations). It does not itself decide what tools to call next or control the overall workflow — that stays deterministic. Trade-off: introduces some non-determinism and cost per ticket, justified because the alternative (rigid rules) cannot handle the classification task described. **Selected: rules-first router with agent fallback.** Necessary if a routing table/mapping exists (to be confirmed); belongs between "decide escalation" and "create issue." Responsibility: match structured signals (component, product area, tags) to a team before ever trusting the agent's own suggestion. Trade-off: needs a maintained routing table, but this is far more auditable and consistent than letting the LLM pick teams freely every time. **Selected: retrieval as a deterministic pre-step, not an agent-invoked tool call.** Necessary to ground the agent's reasoning and keep the "evidence-backed" requirement enforceable and inspectable. It belongs before the interpretation step, not inside a tool-calling loop, which avoids unnecessary agent-directed tool-use non-determinism for a step that should happen every time anyway. **Selected: human approval gate.** Necessary and explicitly mandated. Sits at three points: (1) any ticket with a detected customer-facing-commitment need, (2) low-confidence escalate/no-escalate decisions, (3) cases where routing cannot be determined even by the agent's fallback judgment. Trade-off: adds latency for the gated subset of tickets, acceptable given the reliability-over-autonomy mandate. **Selected: bounded retry with escalation-to-human on exhaustion.** Necessary for every external tool call. Trade-off: none significant; this is baseline production hygiene. **Selected: deduplication via ticket-ID-keyed workflow instances plus pre-creation Jira search.** Necessary and directly required by the stated success criteria. **Rejected: multi-agent supervisor/worker architecture.** Unjustified because there is one cohesive judgment task, not multiple independent specialist domains. It would introduce agent-to-agent messaging, coordination failure modes, higher cost, and harder auditability (whose decision was authoritative?) without any corresponding capability benefit. Revisit condition: if engineering team routing genuinely requires deep domain-specific reasoning per team (e.g., a security-team classifier needs fundamentally different evidence-handling than a billing-team classifier) such that a single generalist judgment consistently underperforms, a router-plus-specialist pattern could be reconsidered — but this must be evidenced by actual decision-quality data, not assumed upfront. **Rejected: open-ended planning loop.** Unjustified because the action sequence is fixed and small. Introducing dynamic planning would add unpredictability and undermine the traceability requirement. Revisit condition: only if the action space grows substantially more varied and conditional than currently described (not evidenced). **Rejected: unbounded reflection/self-critique.** Unjustified — a single bounded verification check (e.g., "cite at least one evidence source, or flag low confidence") captures nearly all the benefit without the cost and risk of open-ended recursive reasoning loops that are hard to audit and bound. Revisit condition: only if a bounded single-pass check is empirically shown insufficient to catch a specific class of errors. **Rejected: long-term cross-ticket agent memory.** Unjustified given current requirements and a real cost given privacy sensitivity of customer data. Revisit condition: if a future requirement explicitly calls for learning from past escalation outcomes (e.g., adjusting confidence calibration based on historical accuracy) — this would need its own privacy review and explicit scope, and should be a separate, deliberate addition, not a default. **Rejected: excessive LLM calls per ticket.** The design should use one primary agent reasoning call per ticket for interpretation (plus, at most, a second bounded call if new evidence arrives during tracking, e.g., a customer reply). Anything beyond this (e.g., separate LLM calls for "gather evidence," "decide," "write brief," "pick team") is unjustified fragmentation — one structured-output call can produce all of these fields together. **Rejected: redundant Zendesk/Jira write paths or agent-controlled tool selection for routine reads.** Retrieval and duplicate-checking are deterministic and should not be delegated to agent judgment about "should I search now" — they always happen, every time, before interpretation. --- ## 7. OVERENGINEERING & ANTI-PATTERN REVIEW - **Multiple agents/supervisor structure** — REJECTED. No evidenced need; adds coordination failure surface. - **Open-ended planning** — REJECTED. Fixed sequence suffices. - **Unbounded reflection loops** — REJECTED. Replaced with a single bounded verification check. - **Long-term learned memory** — DEFERRED. Not justified now; privacy-sensitive; revisit only with explicit future requirement. - **Excess LLM calls (separate calls per sub-decision)** — SIMPLIFIED. Consolidated into one structured-output interpretation call per ticket (plus bounded re-invocation on new evidence). - **Unbounded retries** — BOUNDED. Fixed retry count with backoff, escalating to human review on exhaustion. - **Broad tool access ("agent can call anything")** — SIMPLIFIED/BOUNDED via least-privilege tool gateway: the agent receives read-only access to pre-fetched evidence and a constrained "propose decision" output schema; it does not directly hold write credentials to Jira/Slack/Zendesk. Deterministic code performs the actual writes after the decision passes control-flow checks. This structurally enforces "no autonomous refunds/account/production changes" since those tools are never exposed at all. - **Agent-controlled retrieval decisions** — SIMPLIFIED. Retrieval happens deterministically every time, not at the agent's discretion, to guarantee "evidence-backed" consistently. - **Verification via additional LLM self-review calls** — BOUNDED. A single deterministic check (does structured output include required fields and at least one evidence citation) substitutes for a second LLM "review" call, avoiding doubling cost without losing meaningful safety. - **State complexity (many overlapping state stores)** — SIMPLIFIED. One canonical state store (PostgreSQL) for workflow status, decisions, evidence snapshots, and audit trail — not separate systems for each. - **Coupling between agent reasoning and orchestration logic** — SIMPLIFIED/BOUNDED. Agent is a pure function: evidence in, structured judgment out. All control-flow (retries, gating, routing rule precedence) lives outside the agent, making the system easier to test and audit. - **Duplicate responsibility between rules-router and agent routing suggestion** — BOUNDED. Rules always take precedence when they match; agent suggestion is used only as a fallback and is always flagged as lower-confidence in the audit record, preventing ambiguity about which source made the routing call. - **Hidden failure points: polling/tracking silently stalling** — RETAINED as an explicit risk requiring observability (Section 13) rather than "solved" architecturally; monitoring/alerting on stuck workflows is necessary and called out. --- ## 8. FINAL PATTERN STACK 1. **Event/scheduled trigger** — initiates a new workflow instance per unresolved ticket; also drives periodic tracking checks. Satisfies: trigger and long-running-tracking requirements. 2. **Durable state machine (PostgreSQL-backed)** — owns all control flow, checkpointing, and status; the backbone everything else plugs into. Satisfies: reliability, traceability, duplicate prevention, resumability. 3. **Deterministic retrieval step** — fetches Zendesk ticket content and queries the KB before interpretation. Satisfies: evidence-backed decisions. 4. **Deterministic duplicate-check step** — queries Jira/state for existing escalations tied to the ticket before allowing creation. Satisfies: duplicate prevention. 5. **Single tool-using agent (interpretation/decision)** — consumes retrieved evidence, returns structured escalate/no-escalate judgment, confidence, suggested team, and cited rationale. Satisfies: decision-complexity handling. 6. **Rules-first router with agent fallback** — resolves team assignment, preferring structured rules over agent suggestion. Satisfies: correct routing, auditability of routing source. 7. **Bounded verification step** — deterministic check that the agent's output is well-formed and evidence-grounded before it's trusted. Satisfies: hallucination containment. 8. **Human approval gate** — intercepts low-confidence decisions, unmatched routing, and any customer-facing-commitment signal. Satisfies: human oversight mandate. 9. **Tool gateway (least-privilege adapters)** — isolated adapters for Jira create/query, Slack post, Zendesk read/write, each with bounded retry and verification. Satisfies: least-privilege access, reliability. 10. **Audit/log writer** — records every decision, evidence snapshot, tool call, and outcome to PostgreSQL. Satisfies: complete auditability. 11. **Tracking scheduler** — recurring check of Jira issue status until resolution, feeding back into the state machine. Satisfies: reliable follow-up. Relationship: 1 feeds 2; 2 orchestrates 3→4→5→6→7→8→9 in sequence per ticket, with 10 recording at every step; 11 re-enters the state machine (2) periodically for open escalations until completion. --- ## 9. COMPOSED AGENT ARCHITECTURE **Component: Trigger Handler** - Purpose: detect new unresolved tickets and initiate workflow instances. - Responsibilities: receive webhook or run scheduled scan; deduplicate at the trigger level (ignore if active instance exists for ticket ID). - Dependencies: Zendesk (read), PostgreSQL (state check). - Inputs: ticket-updated event or scan result. Outputs: new or resumed workflow instance record. - State: writes initial "observed" state row. - Tools: Zendesk read API. - Decision responsibility: none beyond dedup check (deterministic). - Failure/retry: on Zendesk API failure, bounded retry, then log and alert (do not silently drop). - Human interaction: none at this stage. - Verification: confirms state row written before returning. - Completion condition: workflow instance exists in "observed" or "resumed" state. **Component: Evidence Retriever** - Purpose: assemble the evidence bundle for interpretation. - Responsibilities: fetch full ticket content/history; query KB for related docs. - Dependencies: Zendesk, KB. - Inputs: ticket ID. Outputs: structured evidence bundle (ticket text, KB snippets with sources). - State: writes evidence snapshot to state store (for audit and reproducibility). - Tools: Zendesk read, KB search. - Decision responsibility: none (deterministic fetch). - Failure/retry: bounded retries per API; on persistent KB failure, proceed with ticket-only evidence but flag reduced-confidence downstream. - Human interaction: none. - Verification: confirms non-empty ticket content retrieved; KB failure is tolerated but logged. - Completion condition: evidence bundle persisted. **Component: Duplicate Checker** - Purpose: prevent redundant escalations. - Responsibilities: query existing Jira issues and internal state for prior escalation tied to this ticket or a matching fingerprint (e.g., same underlying bug signature). - Dependencies: Jira (read), PostgreSQL. - Inputs: ticket ID, evidence bundle. Outputs: duplicate/not-duplicate verdict, linked issue key if duplicate. - State: reads/writes duplicate-check result. - Tools: Jira search API. - Decision responsibility: deterministic (exact/fingerprint match); does not use LLM judgment for this step, to keep dedup logic auditable and predictable. - Failure/retry: bounded retry on Jira API failure; on repeated failure, escalate to human rather than guess. - Human interaction: only on tool failure. - Verification: confirms query executed and returned a definitive result. - Completion condition: duplicate status recorded. **Component: Interpretation Agent (the single LLM reasoning role)** - Purpose: judge whether engineering involvement is needed and suggest a team, grounded in evidence. - Responsibilities: analyze ticket + KB evidence; output structured judgment: escalate (yes/no), confidence (numeric or categorical), suggested team, rationale with explicit evidence references, flag if customer-facing-commitment language is present. - Dependencies: Evidence Retriever output; routing rule metadata (for context, not as something it directly edits). - Inputs: evidence bundle. Outputs: structured JSON judgment. - State: writes its judgment and rationale to the audit log; does not itself read/write Zendesk/Jira/Slack. - Tools: none directly — it operates purely on the evidence handed to it (no autonomous tool-calling), which keeps its action surface at zero write capability. - Decision responsibility: the substantive judgment on escalation need and suggested routing; final control-flow decisions remain with deterministic code. - Failure/retry: if output fails schema validation, bounded retry with corrective re-prompt; on repeated failure, route to human review. - Human interaction: none directly; its low-confidence or commitment-flagged outputs trigger the Human Approval Gate downstream. - Verification: schema validation plus the bounded evidence-citation check (Component: Verification Checker, below). - Completion condition: valid structured judgment persisted. **Component: Verification Checker** - Purpose: catch unsupported or malformed agent output before it drives real actions. - Responsibilities: confirm the judgment cites at least one specific evidence element for its escalate/no-escalate call; confirm confidence and team fields are present and well-formed. - Dependencies: Interpretation Agent output. - Tools: none (pure deterministic check, possibly a lightweight rule-based text check, not another LLM call). - Decision responsibility: pass/fail gate only. - Failure handling: fail → bounded re-prompt of the agent once; second failure → human review. - Completion condition: judgment marked "verified" or routed to human. **Component: Router** - Purpose: finalize team assignment. - Responsibilities: check deterministic routing table first (e.g., by product component/tag); use agent's suggested team only if no rule matches; mark routing source (rule vs. agent) in the audit record. - Dependencies: routing rule table (source UNKNOWN, to be confirmed), Interpretation Agent output. - Decision responsibility: deterministic when a rule exists; agent-assisted fallback otherwise, flagged as lower confidence. - Failure handling: if no rule and agent suggestion is also low-confidence, route to human review for manual team assignment rather than guessing. - Completion condition: team assigned and recorded. **Component: Human Approval Gate** - Purpose: enforce human oversight where required. - Responsibilities: surface low-confidence escalation decisions, unresolved routing, and any customer-facing-commitment flags to a support lead (via Slack or Zendesk, mechanism UNKNOWN, ASSUMED Slack given it's already an integration) for confirm/override before proceeding. - Dependencies: Interpretation Agent output, Verification Checker result. - Tools: Slack (notify), Zendesk/PostgreSQL (record human decision). - Decision responsibility: human makes the final call; system executes it. - Failure handling: approval timeout → defined escalation (e.g., re-notify after a set period, then escalate to a broader lead group; never silently proceed or silently drop). - Completion condition: human decision recorded, workflow resumes accordingly. **Component: Action Executor** - Purpose: perform the actual writes. - Responsibilities: create Jira issue with evidence brief, ticket link, and team; post Slack notification to the routed team channel; write status back to the Zendesk ticket (if authorized). - Dependencies: Router output, Human Approval Gate (if triggered). - Tools: Jira write, Slack write, Zendesk write (each via least-privilege adapter). - Decision responsibility: none — purely executes the already-approved decision. - Failure/retry: bounded retries per tool with idempotency keys (e.g., don't create a second Jira issue if a retry occurs after a partial success — check for existing issue by ticket-ID tag first). - Human interaction: none at this stage (approval already happened upstream if needed). - Verification: confirms Jira issue key returned, Slack message timestamp returned, before marking step complete. - Completion condition: all required writes verified and recorded. **Component: Tracking Scheduler** - Purpose: follow the escalation to resolution. - Responsibilities: periodically check Jira issue status; on status change to resolved/closed, update Zendesk ticket and mark workflow terminal; on new customer activity on the original ticket, optionally trigger a bounded re-interpretation pass. - Dependencies: Jira (read), Zendesk (write), state store. - Tools: Jira read, Zendesk write. - Decision responsibility: deterministic status-mapping; re-interpretation trigger decision is deterministic (based on "new customer message" event), not agent-initiated. - Failure/retry: bounded retries; persistent failure surfaces to observability/alerting, not to the customer. - Human interaction: only if re-interpretation flags something needing approval. - Verification: confirms Zendesk update succeeded before marking terminal. - Completion condition: workflow reaches a terminal state as defined in Section 2. **Component: Audit Logger** - Purpose: record everything for compliance and debugging. - Responsibilities: append-only log of every decision, evidence snapshot, tool call, verification result, and human action, keyed to workflow instance and ticket ID. - Dependencies: all other components write to it. - Tools: PostgreSQL. - Decision responsibility: none. - Completion condition: continuous; never "completes," persists for the life of the record per data-retention policy (UNKNOWN retention period — to be defined with compliance). --- ## 10. STATE, MEMORY & CONTEXT MODEL **Ephemeral working context** What: the evidence bundle assembled for a single interpretation call (ticket text, KB snippets). Why: needed only for that reasoning pass. Lifetime: duration of the call, but a snapshot of it is persisted to the audit log for traceability — the ephemeral copy in the agent's context is not itself the system of record. Access: Interpretation Agent only. Modification: not modified, only consumed. Stale-state risk: if the ticket changes between retrieval and interpretation, the evidence could be stale — mitigated by re-fetching close to the interpretation call rather than caching for long periods. **Retrieved knowledge (KB content)** What: documentation/known-issue snippets relevant to the ticket. Why: grounds the decision. Lifetime: fetched fresh per interpretation; a reference (not necessarily full text) is persisted in the audit snapshot for reproducibility. Access: read-only, no modification by the agent. Stale-state risk: KB content changes over time; audit records should store what was retrieved at decision time, not a live pointer that could later show different content. **Execution state** What: current stage of the workflow instance (observed, retrieving, interpreting, routing, awaiting-approval, acting, tracking, complete). Why: enables resumability and prevents duplicate actions. Lifetime: for the life of the workflow instance, retained afterward as part of the audit trail. Access: read/write by the state machine only; agent does not write to this directly. Reconciliation: on resume after interruption, the system re-verifies the last recorded step's actual external state (e.g., "did the Jira issue actually get created?") before assuming the persisted state is accurate — this guards against crashes between action and state-write. **Durable workflow state** Same store as execution state (PostgreSQL) — not a separate system. Covers ticket ID, workflow status, decisions made, routing outcome, tool-call results, timestamps. **Short-term memory** Not a distinct component here — the "short-term" scope is exactly the ephemeral working context above, scoped to one interpretation call. There is no need for a separate short-term memory store beyond what's already captured in execution state and the evidence snapshot. **Long-term memory** Explicitly NOT included. No requirement calls for the agent to learn or adapt across tickets, and introducing it would add privacy risk (retaining customer data indefinitely for model "learning" purposes) without a stated benefit. If a future need arises (e.g., calibrating confidence thresholds based on historical outcomes), this should be a deliberate, separately-scoped addition — likely implemented as aggregate/statistical analysis over the audit log by a human or a separate offline process, not as agent memory the interpretation agent reads at inference time. **Audit history** What: full record of every decision, tool call, verification, and human action, tied to ticket ID. Why: explicit success criterion. Lifetime: per data retention policy (UNKNOWN, must be defined — likely governed by the same policy as Zendesk/Jira data retention). Access: read access for support leads/compliance; write is append-only by the system, never edited retroactively. **User preferences** Not evidenced as a requirement (e.g., no mention of per-agent or per-lead customizable behavior). NOT REQUIRED at this stage. If support leads later want configurable confidence thresholds or notification preferences, this would be a small, separate configuration store, not "memory" in the AI sense. **System configuration** What: routing rules/table, confidence thresholds, retry limits, Slack channel mappings. Why: needs to change without redeploying the agent (change-frequency force from Section 3). Lifetime: persistent, versioned. Access: modifiable by engineering/ops, read by the Router and state machine. **What should not be stored** - Full customer PII beyond what's necessary for the evidence brief and ticket linkage — the Jira brief and Slack notification should reference the Zendesk ticket rather than duplicating full customer PII into engineering-facing systems where it isn't needed. - No long-term agent memory of individual customers or their history beyond the current ticket's workflow instance. - No raw model "chain-of-thought" persisted as if it were a verified fact — only the structured rationale/citations that passed verification should be treated as authoritative in the audit record. --- ## 11. TOOL & INTEGRATION ARCHITECTURE **Zendesk** - Purpose: source of ticket content; destination for status updates. - Read/write: read (ticket content, history) CONFIRMED as needed; write (status/link back to ticket) ASSUMED desirable but not explicitly confirmed as an authorized capability — must be verified before build. - Inputs/outputs: ticket ID in, ticket content out (read); ticket ID + note/link in, confirmation out (write). - Failure modes: rate limits, transient API errors, permission errors. - Retry strategy: bounded exponential backoff, small fixed cap (e.g., 3 attempts). - Idempotency: writing the same status note twice should be safe (check-then-write or use a fixed identifiable note format to detect prior writes) to avoid duplicate ticket comments. - Approval requirements: none for read; write is low-impact and doesn't require per-instance human approval, but the write must never include customer-facing commitment language without prior human approval. - Post-action verification: confirm API returns success/updated-ticket confirmation. - Permissions: least-privilege — read scope for content, narrow write scope limited to internal notes/tags if that's what's authorized (not full ticket edit rights). - Availability: ASSUMED standard SaaS uptime; not confirmed. **Internal Knowledge Base** - Purpose: supporting evidence for decisions and briefs. - Read/write: read-only. - Inputs/outputs: query in, relevant documents/snippets out. - Failure modes: no results, stale content, search API failure. - Retry strategy: bounded retry; on failure, proceed with reduced evidence and flag lower confidence rather than blocking the whole workflow. - Idempotency: not applicable (read-only). - Approval requirements: none. - Post-action verification: not applicable (read). - Permissions: read-only, scoped to whatever content is appropriate for support/engineering visibility (should not surface anything support agents themselves couldn't see). - Availability: UNKNOWN. **Jira** - Purpose: destination for engineering issues; source for duplicate-checking and resolution tracking. - Read/write: both. Read for search/duplicate-check and status polling; write for issue creation (and possibly comments/links). - Inputs/outputs: search query in, matching issues out; issue fields (summary, evidence brief, ticket link, team/component) in, issue key out. - Failure modes: rate limits, validation errors (e.g., invalid component/team field), auth failures. - Retry strategy: bounded retry; validation errors should not be blindly retried (they'll fail again) — route to human review instead. - Idempotency: creation must include a check for an existing issue tagged with the same ticket ID before creating a new one, and/or use a client-provided idempotency key if Jira's API supports it, to prevent duplicate issues on retry. - Approval requirements: none for creation itself (it's the core authorized action), but low-confidence/no-rule-match cases route to human approval before creation per Section 12. - Post-action verification: confirm a valid issue key is returned and the issue is queryable immediately after creation. - Permissions: least-privilege — create/read/comment scope; explicitly no permissions to modify unrelated issues, delete issues, or take production-affecting actions (if Jira is also used for deployment tracking, that scope must be excluded). - Availability: ASSUMED standard SaaS uptime; not confirmed. **Slack** - Purpose: notify engineering teams; notify support leads for approval gates. - Read/write: write (post messages) is the primary need; read may be needed only if approval responses are captured via Slack interactions (UNKNOWN if this is in scope; ASSUMED a simple notification-only pattern unless confirmed otherwise). - Inputs/outputs: channel + message content in, message timestamp/confirmation out. - Failure modes: rate limits, invalid channel, auth failure. - Retry strategy: bounded retry. - Idempotency: avoid re-posting the same notification on retry by checking whether a message was already confirmed sent for this workflow step. - Approval requirements: none to post; if using Slack for approval capture, that response itself is a human-authority action. - Post-action verification: confirm message timestamp returned. - Permissions: least-privilege — post to specific known channels only, not workspace-wide posting rights. - Availability: ASSUMED standard SaaS uptime; not confirmed. **PostgreSQL** - Purpose: durable workflow state and audit records. - Read/write: both, extensively, by the state machine and audit logger. - Inputs/outputs: workflow instance records, decision records, evidence snapshots. - Failure modes: connection failures, transaction conflicts, disk/capacity issues. - Retry strategy: bounded retry with transactional integrity (writes should be atomic per step to avoid partial/corrupt state). - Idempotency: writes are keyed by workflow instance ID and step, so retries overwrite/no-op rather than duplicate. - Approval requirements: none (internal system of record). - Post-action verification: transaction commit confirmation. - Permissions: application-level access only; least-privilege database roles per component if the deployment environment supports it. - Availability: CONFIRMED as the durable backbone — its availability is foundational; if it's down, no workflow progress should be silently assumed, and reconciliation on recovery is required. **General note on assumptions**: nothing beyond these five systems should be introduced without new evidence. Any capability not explicitly confirmed (e.g., Zendesk write access, Jira duplicate-search capability, a routing-rule data source, Slack interactive approval buttons) is marked UNKNOWN above and must be verified during implementation before the corresponding component is finalized. --- ## 12. AUTONOMY & HUMAN OVERSIGHT - **Read ticket/KB content** — READ-ONLY. Fully autonomous; no approval needed. - **Query Jira for duplicates/status** — READ-ONLY. Fully autonomous. - **Interpretation judgment (escalate/route)** — REVERSIBLE (it's an internal decision, not yet an external action). Autonomous generation is fine; but low-confidence outputs must gate to human approval before triggering external actions. - **Create Jira issue** — REVERSIBLE/LOW-IMPACT (issue can be closed/edited later). Autonomous when confidence is high and routing is rule-matched; requires human approval when confidence is low or routing is agent-fallback-only. - **Post Slack notification** — LOW-IMPACT, easily correctable (can post a follow-up correction). Autonomous once the Jira issue is confirmed created — should not fire ahead of a verified Jira creation. - **Write status/link back to Zendesk ticket (internal note)** — LOW-IMPACT/REVERSIBLE. Autonomous, provided the content contains no customer-facing commitment. - **Any customer-facing commitment (timelines, compensation, resolution promises)** — HUMAN-ONLY. Never generated or sent autonomously; if the interpretation agent's evidence suggests such language is needed, it must flag this explicitly and route to a human, who drafts/approves the actual customer-facing message (which itself may be entirely outside this agent's scope). - **Refunds / account changes** — HUMAN-ONLY, explicitly excluded from this agent's tool access entirely (not merely gated by approval — the credentials/tools for these actions should not be reachable by this system at all). - **Production changes** — HUMAN-ONLY, same treatment as above; this agent has no deployment or infrastructure tool access whatsoever. - **Closing/resolving the workflow based on Jira status** — REVERSIBLE/LOW-IMPACT. Autonomous, since it's just reflecting an already-human-driven engineering resolution, not making a new judgment call. **General boundary statement**: the agent may autonomously read, synthesize evidence, and take low-impact/reversible internal actions (Jira issue creation under high confidence, Slack notification, internal ticket notes) but may never autonomously touch money, customer accounts, production systems, or make commitments to customers. These are structural exclusions enforced at the tool-access layer, not behavioral requests made to the model. --- ## 13. FAILURE & RECOVERY ARCHITECTURE **Tool/API failures (Zendesk/Jira/Slack/KB)** Detection: non-2xx response or exception from adapter. Containment: fail the current step only, not the whole workflow. Retry: bounded (e.g., 3 attempts, exponential backoff). Recovery: on exhaustion, mark step "failed-pending-review" and alert observability/human queue. Resulting state: workflow paused at last known-good checkpoint, never silently marked complete. **Timeouts and rate limits** Detection: explicit timeout or 429-style response. Containment: backoff before retry; if rate-limited broadly, throttle the scheduler's batch size. Recovery: same bounded-retry-then-human-review path as general tool failures. **Missing information (insufficient evidence to decide confidently)** Detection: Interpretation Agent returns low confidence or explicitly flags insufficient evidence. Containment: do not force a decision; route to human review with the evidence gathered so far, or request more customer information via the normal support workflow (not this agent's job to contact the customer directly, per commitment restrictions). Resulting state: "awaiting-more-information" or "human-review" status. **Bad retrieval (irrelevant/stale KB hits)** Detection: the Verification Checker step (does the cited evidence actually support the claim) can catch clearly mismatched citations; harder cases require human review sampling. Containment: if verification fails, one bounded re-prompt with instruction to disregard weak evidence; second failure routes to human review. Recovery: log for KB-quality feedback (not for agent "learning," but for a human to fix the KB). **Hallucinations or unsupported claims** Detection: Verification Checker requires explicit evidence citation for the escalate/no-escalate call; missing or vague citations fail verification. Containment: reject unverified output, bounded re-prompt, then human review. Resulting state: nothing unverified is ever passed to Action Executor. **Stale state** Detection: on workflow resume after interruption, reconcile persisted state against actual external system state (e.g., check if Jira issue already exists before assuming it doesn't) before taking further action. Containment: reconciliation step before every resumed action. Recovery: correct state record to match reality, log the discrepancy. **Duplicates** Detection: Duplicate Checker step before any Jira creation; also dedupe at the trigger level by ticket ID. Containment: never create a second issue for the same escalation; link instead. Recovery: none needed if detection works; if a duplicate slips through (e.g., race condition), a periodic reconciliation job should be able to detect and merge/flag it — this is a real residual risk and should be monitored, not assumed away. **Wrong routing** Detection: engineering team can flag misrouted issues (feedback loop, likely manual — e.g., a Slack reaction or Jira reassignment triggers reconciliation). Containment: initial mitigation is rules-first routing plus human gate on agent-fallback routing. Recovery: misrouted issues get reassigned by humans; the event should be logged so patterns of routing failure become visible to whoever maintains the routing table (again, this is operational feedback, not automated agent learning). **Partial completion** Detection: crash or failure between two verified steps (e.g., Jira issue created but Slack notification not yet sent). Containment: state machine resumes from last verified checkpoint, checking whether the next action was actually completed (idempotency check) before re-attempting. Recovery: complete only the missing step, not repeat completed ones. **Human non-response / approval timeout** Detection: approval request has a defined SLA/timeout. Containment: on timeout, escalate to a broader review group or a backup approver, never silently proceed as if approved, and never silently drop. Recovery: workflow remains in "awaiting-approval" state with escalating notifications until resolved. **System outages (PostgreSQL or a core dependency down)** Detection: connection/health-check failures. Containment: workflow processing pauses entirely rather than proceeding with unpersisted state (since durable state is foundational, no action should be taken that can't be recorded). Recovery: resume processing once the outage clears, reconciling any in-flight external actions against actual system state. **Conflicting state** Detection: e.g., two processes attempt to act on the same workflow instance concurrently (race condition). Containment: use database-level locking/transactions keyed by workflow instance ID to serialize actions per ticket. Recovery: the losing process backs off and re-checks state rather than proceeding blindly. **Invalid tool parameters** Detection: schema/field validation before calling Jira/Slack/Zendesk APIs (e.g., required Jira fields missing). Containment: fail fast with a clear validation error rather than sending malformed requests; route to human review since blind retry won't fix a validation error. Recovery: human corrects the missing configuration/mapping (e.g., adds a routing rule), then the workflow can be resumed. **Workflow interruption (process crash, deployment restart)** Detection: workflow instance left in a non-terminal state with a stale "last updated" timestamp. Containment: a periodic sweep identifies stalled instances beyond an expected duration for their current stage. Recovery: reconcile against external systems, resume or route to human review if reconciliation is ambiguous. **Model failure (LLM API error or malformed/empty output)** Detection: API error or schema validation failure on the Interpretation Agent's output. Containment: bounded retry of the model call; on repeated failure, route the ticket to human review rather than defaulting to either "escalate" or "no escalate" — an undecided ticket should never be silently treated as resolved. All retry loops above share the same shape: bounded attempts, clear terminal failure state, and a guaranteed path to human visibility on exhaustion — nothing fails silently, and nothing loops indefinitely. --- ## 14. ARCHITECTURE DECISION RECORD **Decision: Single agent vs. multi-agent** Driving requirement: decision-complexity and specialization forces. Selected approach: single tool-using agent for interpretation, embedded in a deterministic workflow. Alternative: multi-agent (separate triage/evidence/routing agents). Reason: the judgment tasks are cohesive and don't require independent specialist reasoning; multi-agent would add coordination cost without capability benefit. Trade-off: a single agent's output quality is the sole point of judgment failure — mitigated by verification and human gating rather than by adding more agents. Revisit condition: evidenced need for genuinely independent specialist reasoning per engineering team. **Decision: Deterministic vs. open-ended planning** Driving requirement: reliability/traceability force. Selected approach: fixed, deterministic step sequence. Alternative: dynamic planning agent. Reason: the action space is small and well-understood; open-ended planning would reduce predictability and auditability for no benefit. Trade-off: less flexible if genuinely novel workflow branches emerge in the future. Revisit condition: if the workflow needs to handle a meaningfully expanding variety of conditional paths not covered by the current fixed sequence. **Decision: Temporary vs. durable state** Driving requirement: state-duration and reliability forces. Selected approach: durable PostgreSQL-backed state machine for every workflow instance. Alternative: in-memory/ephemeral processing per trigger. Reason: multi-day tracking horizon and audit requirements make ephemeral state untenable. Trade-off: requires schema design and operational care (locking, reconciliation) but this is unavoidable given requirements. Revisit condition: none foreseeable — this is a hard requirement, not a judgment call. **Decision: Rules vs. LLM judgment for routing** Driving requirement: reliability and consistency forces, balanced against decision-complexity. Selected approach: rules-first with LLM fallback, fallback always flagged lower-confidence. Alternative: pure LLM routing for every ticket. Reason: deterministic rules are more auditable and consistent when available; LLM judgment fills genuine gaps. Trade-off: requires a maintained routing table (operational overhead) but improves consistency and traceability substantially. Revisit condition: confirmation of whether such a routing table/source actually exists — if it does not and cannot be created, the LLM-fallback share of decisions grows and human-gate thresholds should be tightened accordingly. **Decision: Bounded verification vs. reflection loops** Driving requirement: reliability over autonomy. Selected approach: single deterministic evidence-citation check plus schema validation. Alternative: iterative LLM self-critique loop. Reason: bounded checks are cheaper, more predictable, and sufficiently effective for catching unsupported claims; unbounded reflection adds cost and unpredictable termination. Trade-off: may miss subtler reasoning errors that deeper reflection could catch. Revisit condition: if post-deployment error analysis shows the single-pass check missing a specific, recurring class of unsupported claims. **Decision: Autonomy vs. human approval** Driving requirement: explicit constraints (no autonomous commitments, refunds, account/production changes) plus reliability-over-autonomy mandate. Selected approach: tiered gating — full autonomy for read operations and high-confidence low-impact writes; mandatory human approval for low-confidence decisions, unmatched routing, and anything commitment-adjacent; structural tool-access exclusion for refunds/accounts/production. Alternative: full autonomy with post-hoc audit only, or full human approval on every action. Reason: full autonomy risks the explicitly prohibited outcomes; full manual gating defeats the purpose of automation. Trade-off: tiered gating requires careful confidence-threshold calibration (currently UNKNOWN exact thresholds — must be set collaboratively with support leads and tuned post-launch). Revisit condition: after initial production data shows actual false-positive/false-negative rates at given thresholds. **Decision: Simple vs. dedicated routing component** Driving requirement: tool/integration complexity and change-frequency forces. Selected approach: a lightweight rules-matching component plus agent fallback, not a dedicated "routing agent" or service. Alternative: a full dedicated routing microservice/agent. Reason: the routing logic, once the data source is confirmed, is simple enough not to warrant its own agent or service boundary. Trade-off: if routing logic grows significantly more complex later (e.g., many interacting rules, weighted scoring), a dedicated component might become justified. Revisit condition: routing rule complexity growing beyond simple table lookups. **Decision: Temporary context vs. persistent memory** Driving requirement: privacy sensitivity and absence of an evidenced learning requirement. Selected approach: no long-term agent memory; durable workflow/audit state only. Alternative: persistent cross-ticket memory for the agent. Reason: no stated requirement for adaptive learning; retaining customer data for memory purposes increases privacy risk without benefit. Trade-off: the system won't automatically improve its calibration over time without separate, deliberate analysis work. Revisit condition: an explicit future requirement for adaptive learning, with its own privacy review. --- ## 15. IMPLEMENTATION BLUEPRINT **Component: PostgreSQL schema and state machine** What to build: tables for workflow instances, decisions/evidence snapshots, tool-call audit log, human-approval records; state-transition logic with locking. Responsibility: durable backbone. Dependencies: none (foundational). Inputs/outputs: workflow instance CRUD. Failure handling: transactional writes, reconciliation-on-resume logic. Human involvement: none directly; supports audit access for leads. Definition of success: a workflow instance can be created, progressed through all defined stages, interrupted, and resumed correctly without duplication. **Component: Tool adapters (Zendesk, Jira, Slack, KB)** What to build: least-privilege, bounded-retry, verified adapters for each system's required operations (as scoped in Section 11). Responsibility: isolate integration failure handling. Dependencies: confirmed credentials/permissions for each system (several UNKNOWN items must be resolved first — see below). Definition of success: each adapter reliably performs its scoped operation, fails predictably and bounded, and verifies outcomes. **Component: Evidence Retriever + Duplicate Checker** What to build: deterministic fetch-and-assemble logic, plus Jira/state duplicate query logic. Dependencies: Zendesk and KB read adapters; Jira read adapter. Definition of success: given a ticket ID, produces a complete evidence bundle and an accurate duplicate verdict. **Component: Interpretation Agent** What to build: a single structured-output LLM call taking the evidence bundle and returning escalate/no-escalate, confidence, suggested team, rationale with citations, and commitment-language flag. Dependencies: Evidence Retriever output; a defined output schema. Definition of success: outputs consistently validate against schema and, on a labeled test set, match human-expert escalation judgments at an acceptable rate (rate to be defined with support leads, not invented here). **Component: Verification Checker + Router** What to build: deterministic checks (citation presence, schema validity) and rules-first routing logic against the (to-be-confirmed) routing data source. Dependencies: Interpretation Agent output; routing table. Definition of success: no ungrounded decision reaches the Action Executor; routing matches known correct team assignments on historical test cases. **Component: Human Approval Gate** What to build: notification and response-capture mechanism (likely Slack-based) for flagged decisions, with timeout/escalation logic. Dependencies: Slack adapter; defined confidence thresholds. Definition of success: flagged cases reliably reach a human, and the workflow correctly resumes based on their decision, with no silent proceeding on timeout. **Component: Action Executor** What to build: the actual Jira-create, Slack-post, Zendesk-update logic, idempotent and verified. Dependencies: all upstream components; tool adapters. Definition of success: exactly one Jira issue and one Slack notification per genuine escalation, verified as created, with no duplicates even under retry. **Component: Tracking Scheduler** What to build: periodic Jira-status-check job, resolution handling, optional re-interpretation trigger on new ticket activity. Dependencies: Jira read adapter, state machine. Definition of success: escalations reliably reach a terminal state without manual polling by support staff. **Component: Observability/Audit access** What to build: logging, metrics (decision accuracy proxies, stuck-workflow alerts, tool failure rates), and a way for support leads/compliance to inspect the audit trail. Dependencies: all components emit to the audit log. Definition of success: any escalation's full history can be reconstructed on demand, and stalled workflows are detected proactively rather than discovered by customer complaint. **Implementation sequence (highest-risk assumptions and highest-value decisions first)** 1. **Resolve key unknowns before writing code**: confirm trigger mechanism, Zendesk write authorization, Jira duplicate-search capability, and — most importantly — whether a structured routing-rule data source exists. These four facts materially change component design and should be confirmed first, not assumed. 2. **Prototype the Interpretation Agent against real historical tickets** (offline, no live actions) to validate that escalate/no-escalate judgment quality is viable before investing in the full orchestration build. This is the highest-uncertainty, highest-value component to validate early, since if it performs poorly, the whole approach needs rethinking regardless of how well the orchestration is built. 3. **Build the durable state machine and audit schema** next, since every other component depends on it and it embodies the reliability/traceability priority. 4. **Build tool adapters one at a time**, starting with read-only ones (Zendesk read, KB read, Jira read) since they carry no risk of unwanted external effects, before building write adapters (Jira create, Slack post, Zendesk write). 5. **Wire up Evidence Retriever → Duplicate Checker → Interpretation Agent → Verification Checker → Router** as a read-only, non-acting pipeline first (produces decisions and logs them, but does not create Jira issues or post Slack messages) — this allows real-world validation of decision quality and routing accuracy with zero external-action risk. 6. **Add the Human Approval Gate and Action Executor** only after the decision pipeline has demonstrated acceptable accuracy in the read-only phase, since enabling real writes is the point where mistakes become externally visible. 7. **Add the Tracking Scheduler** last, since it depends on issues actually existing in Jira, and its correctness can only be meaningfully tested once real issues are being created. --- ## 16. EVALUATION & VALIDATION PLAN **Task success**: Behavior tested — did the correct end-to-end outcome occur (issue created and eventually resolved, or correctly no-escalated)? Success: matches human-expert-labeled outcome on a held-out ticket set. Failure: mismatch rate above an agreed threshold. If it fails: revisit the Interpretation Agent's prompting/evidence quality before adding more orchestration complexity. **Decision quality (escalate/no-escalate)**: Tested via a labeled historical ticket set reviewed by support leads. Success: acceptable agreement rate with human judgment (rate to be defined by the team, not invented here). Failure: high false-negative rate (missed escalations) is especially critical given the stated goal of reducing missed escalations. If it fails: tighten confidence thresholds so more borderline cases route to human review rather than auto-deciding. **Routing accuracy**: Tested against historical tickets with known-correct team assignment. Success: rules-matched cases are essentially always correct (since they're deterministic); agent-fallback cases meet an agreed accuracy bar. Failure: fallback routing frequently wrong. If it fails: expand/improve the routing rule table rather than relying more heavily on agent judgment. **Tool selection and execution**: Since tool use is deterministic (not agent-directed), this reduces to adapter correctness testing — does each adapter call the right API with the right parameters and handle documented error responses correctly? Success: adapters pass integration tests against sandbox/staging instances of each system. Failure: malformed calls or unhandled error codes. If it fails: harden adapter validation before any live write access is granted. **Evidence grounding**: Tested by sampling agent outputs and checking whether cited evidence genuinely supports the stated rationale. Success: citations are accurate and relevant in the large majority of sampled cases. Failure: frequent unsupported or misattributed citations. If it fails: strengthen the Verification Checker's citation-matching logic and/or improve evidence retrieval quality (e.g., better KB search ranking). **State continuity**: Tested by deliberately interrupting a workflow instance mid-process (simulated crash) and verifying it resumes correctly without duplicating actions or losing progress. Success: resumes at the correct step, no duplicate Jira issues or Slack posts. Failure: duplication or lost state. If it fails: revisit checkpointing granularity and reconciliation logic. **Memory correctness**: Not applicable in the traditional sense since no long-term agent memory exists; instead, test that the audit trail accurately and completely reflects what happened for a given workflow instance. Success: audit record fully reconstructs the decision path. Failure: gaps or inconsistencies in the log. If it fails: identify which component is failing to log and fix at the source. **Duplicate prevention**: Tested by triggering the same ticket twice (including concurrent triggers) and verifying only one workflow instance and one Jira issue result. Success: no duplicates under normal and race-condition scenarios. Failure: duplicate instance or issue created. If it fails: strengthen locking/idempotency keys at the trigger and Action Executor levels. **Human approval**: Tested by forcing low-confidence and commitment-flagged scenarios and verifying the gate correctly intercepts them, notifies the right person, and correctly resumes based on the human's response (including timeout behavior). Success: gate reliably intercepts and resumes correctly. Failure: gate is bypassed, or timeout leads to silent auto-proceeding. If it fails: this is a serious defect given explicit constraints — halt rollout until fixed. **Failure recovery**: Tested by simulating each failure mode in Section 13 (API errors, timeouts, outages) in a staging environment. Success: system behaves exactly as designed for each case (bounded retry, then defined terminal/human-review state). Failure: infinite retry, silent failure, or incorrect state. If it fails: revisit the specific failure-handling logic for that case. **Retry boundaries**: Tested by forcing persistent tool failures and confirming retries stop at the configured bound and escalate to human review rather than looping. Success: retries terminate as configured every time. Failure: unbounded or silently-abandoned retries. If it fails: this is a hard requirement violation — fix immediately. **Security boundaries**: Tested by attempting (in a controlled test) to have the system perform an out-of-scope action (e.g., simulate a prompt/evidence trying to induce a refund-like action) and confirming it's structurally impossible because the tool isn't exposed, not merely discouraged. Success: out-of-scope actions are impossible, not just unlikely. Failure: any path exists to a prohibited action. If it fails: this is critical — the tool-access layer, not the prompt, must be fixed. **End-to-end completion**: Tested by running full realistic tickets through the entire pipeline (interpretation → routing → creation → notification → tracking → resolution) in staging. Success: correct terminal state reached with full audit trail. Failure: any stage hangs, errors silently, or produces an incorrect terminal state. If it fails: isolate which stage failed using the audit log and fix that component specifically. **Observability**: Tested by verifying that stuck workflows, elevated failure rates, and approval-gate backlogs actually surface as alerts/dashboards a human would notice. Success: a deliberately stalled test workflow is detected and surfaced within the expected monitoring window. Failure: stalls go unnoticed. If it fails: add or fix the relevant monitoring hooks before production rollout. **Auditability**: Tested by picking a random completed workflow instance and confirming a reviewer can reconstruct exactly what evidence was used, what was decided, why, by whom (system or human), and what actions resulted — without needing to consult anything outside the audit log. Success: full reconstruction possible. Failure: gaps requiring guesswork. If it fails: this directly undermines the stated top priority (reliability/traceability over autonomy) and should block launch until resolved. --- ## 17. FINAL AGENT ARCHITECTURE BLUEPRINT **ARCHITECTURE SUMMARY** This system is a durable, deterministic workflow orchestrator with a single embedded LLM reasoning role. The orchestrator owns all control flow, state persistence, retries, and audit logging. The agent's sole job is to interpret unstructured ticket and knowledge-base evidence into a structured escalation judgment and suggested routing, grounded in citable evidence. Deterministic logic handles retrieval, duplicate detection, rules-based routing where possible, verification of the agent's output, and all actual writes to Jira, Slack, and Zendesk. Human approval gates intercept low-confidence decisions, unresolved routing, and anything touching customer-facing commitments. A recurring scheduler tracks each escalation from creation through Jira resolution, closing the loop back to the originating ticket. **PRIMARY ARCHITECTURAL PATTERN** A durable state-machine-orchestrated workflow with a single embedded tool-using agent performing bounded, evidence-grounded interpretation at one well-defined stage of an otherwise deterministic pipeline. **SUPPORTING PATTERNS** Deterministic retrieval-before-reasoning; rules-first routing with agent fallback; bounded output verification; human-in-the-loop approval gating; least-privilege tool adapters with bounded retry and idempotency; append-only audit logging; event/scheduled triggering combined with recurring status polling for long-running tracking. **WHY THIS ARCHITECTURE FITS** The dominant force is reliability/traceability taking priority over autonomy — this directly argues for deterministic orchestration wherever possible and a narrowly scoped agent role rather than broad agentic autonomy. The dominant complexity is in language understanding of unstructured ticket/KB content (decision complexity), which is exactly the kind of task a single well-grounded LLM call handles well, without needing multiple agents or open-ended planning. The multi-day tracking horizon and explicit duplicate-prevention/auditability success criteria directly demand durable state and verified, idempotent actions rather than ephemeral, fire-and-forget automation. **REJECTED COMPLEXITY** Multi-agent/supervisor architectures (no evidenced specialist domains), open-ended planning (fixed, small action space), unbounded reflection loops (a single bounded verification check suffices), long-term cross-ticket agent memory (no learning requirement, real privacy cost), and broad/unscoped tool access (structurally excluded to enforce the no-refunds/no-account-changes/no-production-changes/no-autonomous-commitments constraints). **CONTROL MODEL** A ticket triggers a new workflow instance (or resumes an existing one). The system deterministically retrieves evidence and checks for duplicates, then invokes the interpretation agent once to produce a structured, evidence-cited judgment. A deterministic verification check and rules-first router refine that judgment. Low-confidence or commitment-flagged cases pause for human approval; otherwise the system proceeds to create the Jira issue, notify the team via Slack, and update the ticket, verifying each write. The workflow then enters a recurring tracking state until the Jira issue resolves, at which point the ticket is updated and the instance reaches a terminal, fully audited state. **STATE MODEL** Temporary: the evidence bundle assembled for a single interpretation call. Persistent: workflow instance status, all decisions and their rationale/evidence citations, tool-call outcomes, human-approval records, and the full audit trail — all in PostgreSQL, retained per a to-be-defined retention policy. Prohibited: long-term cross-ticket agent memory, retention of full customer PII beyond what evidence briefs require, and treating unverified model output as authoritative fact in the audit record. **TOOL MODEL** Zendesk (read ticket content; write internal status notes, no customer-facing commitments) — Internal KB (read-only evidence source) — Jira (read for duplicate-check/status tracking; write for issue creation) — Slack (write for team/lead notifications) — PostgreSQL (read/write for all durable state and audit records). No tools beyond these five are introduced; no tool grants access to refunds, account changes, or production systems. **AUTONOMY BOUNDARY** The agent may autonomously read and synthesize evidence, and the system may autonomously execute low-impact, reversible writes (Jira creation under high confidence with rule-matched routing, Slack notification, internal Zendesk notes) once verified. Autonomy stops at: low-confidence escalation/routing decisions, any hint of a needed customer-facing commitment, and anything touching refunds, account changes, or production systems — the last three are structurally unreachable by this system's tools, not merely policy-restricted. **HUMAN GATES** Low-confidence escalate/no-escalate decisions; unmatched or low-confidence team routing; any detected need for a customer-facing commitment; repeated tool failures beyond bounded retry; approval-timeout escalations; any workflow reconciliation ambiguity that automated logic cannot resolve confidently. **PRIMARY FAILURE RISK** The most important failure to address first is an inaccurate or ungrounded interpretation judgment (false negatives that miss real escalations, or hallucinated/unsupported rationale) since this sits upstream of every other component and directly undermines the stated goal of reducing missed or poorly routed escalations. This is why the implementation sequence prioritizes offline validation of the Interpretation Agent before building the full acting pipeline. **FIRST COMPONENT TO PROTOTYPE** The Interpretation Agent, run offline against a historical, human-labeled set of tickets, with no live tool-write access — this validates the highest-uncertainty, highest-value assumption (that an LLM can reliably judge escalation need and team from available evidence) before investing in orchestration, gating, and integration work. **FIRST EVALUATION** Decision quality on a labeled historical ticket set, specifically measuring false-negative rate (missed escalations), since the stated goal explicitly centers on reducing missed escalations and this metric most directly tests whether the core premise of the system is sound before any other component is built out. **DO NOT BUILD YET** Long-term cross-ticket agent memory or adaptive learning from past decisions; multi-agent/specialist-per-team architectures; open-ended planning or dynamic tool-selection by the agent; queue-based scaling infrastructure (unless/until ticket volume is confirmed to require it); any Slack-interactive approval-capture mechanism beyond simple notification (unless confirmed to be needed/available); anything touching refunds, account changes, or production systems. **REVISIT CONDITIONS** Confirm the four key unknowns (trigger mechanism, Zendesk write authorization, Jira duplicate-search capability, routing-rule data source) — their answers may shift specific component designs, though not the overall architecture shape. Revisit multi-agent/specialist routing if evidence emerges that a single-agent judgment consistently underperforms for certain engineering teams. Revisit long-term memory only if an explicit, separately-scoped learning/calibration requirement emerges, with its own privacy review. Revisit queueing/scaling infrastructure if actual ticket volume proves much higher than assumed. Revisit human-gate confidence thresholds after real production data on false-positive/false-negative rates is available. **FINAL STATUS** **READY WITH OPEN DECISIONS.** The overall architecture shape (durable orchestrator plus single bounded interpretation agent, deterministic execution, tiered human oversight) is well justified by the stated requirements and success criteria. However, several material facts remain UNKNOWN — the trigger mechanism, Zendesk write authorization, Jira duplicate-search capability, and especially the existence of a structured routing-rule data source — and these must be confirmed before final component-level design and implementation proceed, since they materially affect the Router and Trigger Handler designs specifically. .....0