| # Product Requirements Document (PRD): Support Ticket Environment for OpenEnv |
|
|
| ## 1. Introduction and Objectives |
| The **Support Ticket Environment** aims to test Large Language Models (LLMs) and agentic frameworks in a highly realistic, consequence-driven enterprise setting. Customer support resolution requires strict adherence to internal policies, information verification, and multi-step reasoning before taking terminal actions (e.g., refunds or escalations). |
|
|
| **Objective**: Provide an OpenEnv-compliant simulation where an agent assumes the role of a support professional. The environment acts as an adversarial and deterministic evaluator to cleanly quantify an agent's ability to gather state, read contextual rules, and execute appropriate API actions. |
|
|
| ## 2. Real-World Utility |
| Most AI evaluations focus on static benchmarks (MMLU) or gamified environments (Minecraft). However, the most immediate commercial application of agentic AI is customer support automation. |
|
|
| ### The Problem |
| Companies lose millions to unchecked LLM agents hallucinating policies, issuing improper refunds, or frustrating high-tier enterprise clients. |
|
|
| ### The Solution |
| This environment models the actual complexity of a ticketing system. It enforces that agents must securely verify `UserData`, correctly attribute `IssueType` to a `Policy`, and avoid taking destructive actions (like rejecting an enterprise client abruptly) under pressure or when faced with confusing queries. |
|
|
| ## 3. Environment Architecture |
|
|
| ### State Boundaries |
| - Each task begins with a newly opened ticket. |
| - The episode terminates either when the agent explicitly uses a terminal action (`close_ticket`, `escalate`) or after reaching the hard threshold of $N=10$ steps. |
|
|
| ### Action Constraints |
| - Intermediate actions (`fetch_user_data`, `check_policy`) do not alter the external ticket state but provide critical context. |
| - Terminal actions irreversibly mutate the state and trigger evaluation. |
|
|
| ### Grading and Reward Shaping |
| - Graders are strictly deterministic. |
| - Fractional rewards are yielded for necessary intermediate contextualization steps (promoting chain-of-thought grounding). |
| - Sharp penalties are applied for protocol violations (e.g., escalating a simple refund directly to billing Tier 2). |
|
|
| ## 4. Required Agent Capabilities |
| To succeed on hard tasks, an agent must demonstrate: |
| - **State Management**: Remembering the constraints of the `policy` retrieved earlier in the episode. |
| - **Self-Correction**: Adapting if `fetch_user_data` returns constraints (e.g., the user is not a premium member). |
| - **Nuanced Execution**: Apologizing organically when generating the `reply_to_customer` response during a high-stakes failure ticket. |
|
|
| ## 5. Evaluation Criteria |
|
|
| ### Core Metrics |
| - **Task Completion Rate**: Fraction of tasks completed successfully. |
| - **Protocol Adherence**: Fraction of steps that align with the defined policy. |
| - **Efficiency**: Average number of steps taken to complete a task. |
|
|
| ### Grader Outputs |
| Grader outputs are JSON objects with the following fields: |
| ```json |
| { |
| "task_id": "task_hard_1", |
| "score": 0.8, |
| "violations": ["policy_violation", "premature_closure"] |
| } |
| ``` |
|
|
| ### Constraints |
| - Agents must not exceed the step limit. |
| - Agents must avoid terminal actions unless confident of the resolution. |
|
|
| ## 6. Future Extensions |
| - **Multi-Agent Collaboration**: Introduce scenarios where multiple agents must collaborate to resolve a ticket. |
| - **Dynamic Policies**: Add tasks where policies change mid-episode, requiring agents to adapt. |
| - **Realistic User Simulation**: Enhance the environment with stochastic user behavior to test robustness. |
|
|
