Cas d'étude : agent support technique

Ce cas présente un agent support client technique. L'objectif n'est pas un chatbot généraliste, mais un composant applicatif limité, testable et observable.

Résumé exécutif

L'agent analyse un ticket technique, consolide les informations utiles et prépare un brouillon d'e-mail pour validation humaine.

Il ne peut pas envoyer l'e-mail directement.

Pourquoi ce cas est représentatif

Il combine :

données hybrides ;
documentation incomplète ;
incident connu ;
risque de promesse non autorisée ;
besoin d'escalade ;
validation humaine ;
traçabilité.

Fiche de spécification

agent:
  agent_key: technical-support-reply-agent
  label: Technical Support Reply Agent
  purpose: Analyser un ticket client technique et préparer un brouillon d'e-mail clair, prudent et actionnable.
  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

Actions autorisées et interdites

Actions autorisées	Actions interdites
Lire le ticket	Envoyer l'e-mail directement
Résumer l'historique	Modifier ou fermer le ticket sans validation
Rechercher dans la base de connaissances	Promettre un remboursement
Consulter les incidents connus	Promettre un délai non confirmé
Proposer une réponse	Reconnaître une responsabilité juridique
Recommander une escalade	Inventer une cause technique

Validation humaine obligatoire

Avant tout envoi au client.
Si le niveau de confiance est faible.
Si le ticket concerne sécurité, facturation ou données personnelles.
Si le client mentionne SLA, contrat, menace juridique ou mise en demeure.
Si la documentation est absente, contradictoire ou insuffisante.

Données hybrides

Le Context Builder assemble :

message client ;
données structurées du ticket ;
historique ;
documentation ;
incident connu ;
règles internes.

Un fait confirmé doit toujours pouvoir être rattaché à une source.

Exemple de structure de contexte

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[]
}

Runtime SR

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
}

Contrat de sortie

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 }>
}

Plan de tests

sortie valide ;
JSON malformé ;
champ obligatoire absent ;
type incorrect ;
enum invalide ;
champ inattendu si contrat fermé ;
sortie partielle ;
action critique interdite si sortie invalide ;
incident connu avec message public autorisé ;
ticket avec données sensibles ;
escalade obligatoire ;
faible confiance.

Roadmap V1

Définir le contrat d'agent.
Implémenter le Context Builder.
Versionner les skills runtime.
Ajouter validation typée.
Ajouter validateurs métier.
Créer UI de brouillon avec validation humaine.
Journaliser les runs.
Tester les sorties invalides.

Cas d'étude : agent support technique

On this page