SR Method
SR Method EN

Case study: technical support agent

Technical Support Reply Agent designed with the SR Agent Method.

Case study: technical support agent

This case presents a technical customer support agent. The goal is not a generic chatbot, but a limited, testable and observable application component.

Executive summary

The agent analyzes a technical ticket, consolidates useful information and prepares an email draft for human validation.

It cannot send the email directly.

Why this case is representative

It combines:

  • hybrid data;
  • incomplete documentation;
  • known incident;
  • risk of unauthorized promise;
  • escalation need;
  • human validation;
  • traceability.

Specification sheet

agent:
  agent_key: technical-support-reply-agent
  label: Technical Support Reply Agent
  purpose: Analyze a technical customer ticket and prepare a clear, careful and actionable email draft.
  business_function_key: support
  model_provider: configurable
  model: configured_by_environment
  temperature: 0.2
  execution_mode: draft_with_approval
  system_prompt: controlled_support_system_prompt
  user_prompt_template: support_reply_request
  input_schema: SupportAgentInput
  output_schema: SupportAgentOutput
  input_model: SupportAgentInputModel
  output_model: SupportAgentOutputModel
  json_schema_source: generated_from_output_model
  output_validation_mode: pydantic_strict_or_typed_validator_strict
  invalid_output_policy: retry_once_then_human_review
  validation_error_trace: safe_agent_validation_log
  sql_context_bindings: read_only_ticket_context
  nexus_context_bindings: optional_support_kb
  required_runtime_skills:
    - technical-diagnosis
    - support-email-writing
    - support-escalation
    - quality-review
  ui_placement: ticket_reply_panel
  test_cases: support_agent_core_cases
  typed_output_tests: support_agent_typed_output_cases
  risk_notes: no direct send, no legal acceptance, no unverified promise
  human_validation_required: true
  validation_status: draft
  is_active: false

Allowed and forbidden actions

Allowed actionsForbidden actions
Read the ticketSend the email directly
Summarize historyModify or close the ticket without validation
Search the knowledge basePromise a refund
Check known incidentsPromise an unconfirmed deadline
Propose a responseAdmit legal responsibility
Recommend escalationInvent a technical cause

Mandatory human validation

  • Before sending anything to the customer.
  • If confidence is low.
  • If the ticket concerns security, billing or personal data.
  • If the customer mentions SLA, contract, legal threat or formal notice.
  • If documentation is absent, contradictory or insufficient.

Hybrid data

The Context Builder assembles:

  • customer message;
  • structured ticket data;
  • history;
  • documentation;
  • known incident;
  • internal rules.

A confirmed fact must always be linked to a source.

Context structure example

type SupportContext = {
  ticket: {
    id: string
    product: string
    productVersion: string
    customerPlan: string
    priority: string
  }
  customerMessage: string
  ticketHistorySummary: string
  confirmedFacts: Array<{ fact: string; source: string }>
  relevantKnowledgeBase: Array<{ id: string; title: string; excerpt: string }>
  knownIncidents: Array<{ id: string; status: string; impact: string; publicMessageAllowed: boolean }>
  supportRules: string[]
  redactionWarnings: string[]
}

SR runtime

async function runSupportReplyAgent(ticketId: string): Promise<SupportAgentOutput> {
  const spec = await loadAgentSpec("technical-support-reply-agent", "1.0.0")
  const skills = await loadSkills([
    "technical-diagnosis@1.0.0",
    "support-email-writing@1.0.0",
    "support-escalation@1.0.0",
    "quality-review@1.0.0"
  ])
  const context = await buildSupportContext(ticketId)
  const rawResponse = await callModel({
    system: buildSystemPrompt(spec, skills),
    input: {
      context,
      userRequest: "Prepare a support email draft for human review."
    },
    jsonSchema: buildJsonSchemaFromOutputModel(spec.output_model),
    tools: {
      searchKnowledgeBase,
      getKnownIncidents,
      getTicketHistory
    }
  })
  const structured = await validateTypedOutput(rawResponse, {
    outputModel: spec.output_model,
    mode: spec.output_validation_mode,
    invalidOutputPolicy: spec.invalid_output_policy
  })
  const reviewed = runBusinessValidators(structured, context)
  await writeAgentRunLog(ticketId, spec, skills, context, reviewed)
  return reviewed
}

Output contract

type SupportAgentOutput = {
  problem_summary: string
  confirmed_facts: string[]
  hypotheses: string[]
  missing_information: string[]
  confidence: "low" | "medium" | "high"
  escalation_required: boolean
  escalation_reason?: string
  draft_email: string
  quality_warnings: string[]
  source_references: Array<{ claim: string; source: string }>
}

Test plan

  • valid output;
  • malformed JSON;
  • missing required field;
  • wrong type;
  • invalid enum;
  • unexpected field when contract is closed;
  • partial output;
  • critical action forbidden when output is invalid;
  • known incident with public message allowed;
  • ticket with sensitive data;
  • mandatory escalation;
  • low confidence.

V1 roadmap

  1. Define agent contract.
  2. Implement Context Builder.
  3. Version runtime skills.
  4. Add typed validation.
  5. Add business validators.
  6. Create draft UI with human validation.
  7. Log runs.
  8. Test invalid outputs.

On this page