Support triage with explicit human escalation

The problem and my role

A support workflow needs a useful stopping condition. If an order cannot be found, billing evidence is ambiguous, or a customer asks for a person, continuing to improvise is the wrong behavior. I wanted a small implementation where those decisions could be inspected.

I kept final approval over scope and publish readiness. Claude handled the spec, review, and workflow guardrails; Codex handled implementation. The public repository records that division of work. This project applies the AI Operator System approach to a bounded support use case.

How the workflow works

The first version supports three issue types: an order not received, a duplicate charge, and a cancellation request. A FastAPI endpoint accepts the message and optional follow-up state; a single-page frontend displays the reply and structured result.

1. Classify the message using keyword rules and extract identifiers.
2. Check for an explicit human request or escalation language.
3. Ask for a required missing field, at most once.
4. Call a mock customer, order, or ticket tool when enough information is available.
5. Return a resolution or escalation with the relevant context.

Each completed session includes the issue type, collected fields, tool result, customer response, and escalation details. The separate follow-up response carries the question and state needed for the next turn.

When should the workflow escalate?

The implementation routes to a human when classification confidence is low, a customer requests a person, a tool fails, required information remains missing after one follow-up, or the available record cannot support a decision. It also checks for legal, threat, and frustration language.

Keep the follow-up limit in code

If a customer says their order has not arrived without an order ID, the workflow asks for that ID. If the next message still lacks it, the workflow escalates. A counter in the follow-up state controls this branch; it does not depend on a model remembering a prompt instruction.

Preserve uncertainty in billing cases

A report of being charged twice does not establish a duplicate. The mock lookup checks recent charges for matching amount and date. Incomplete or ambiguous evidence routes to billing. Even a plausible match creates a ticket for manual review; it does not issue a refund.

Define what “resolved” means

In this reference, a resolved cancellation path means a support ticket was created. It does not mean a subscription was canceled. The output status describes completion of the triage step, which is an important distinction for any downstream integration.

Evidence and implementation limits

The repository includes focused tests for the order-status path, cancellation ticket creation, ambiguous billing, an explicit human request, an unknown order, and escalation after the follow-up allowance is exhausted. These are inspectable examples of the intended behavior, rather than a production reliability claim.

Backend tools use local fixtures. Ticket creation and human routing are simulated. There is no live support platform integration and no provider call in this version. Keyword classification also limits the language the workflow can recognize.

For a production implementation, I would add authenticated integrations, server-owned session state, stronger input handling, operational monitoring, and evaluation against representative customer messages before expanding the workflow.

Inspect the project

• Project scope and build roles
• Triage rules and escalation implementation
• Behavioral test cases
• Try the support triage demo with fictional customer details.