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: falseAllowed and forbidden actions
| Allowed actions | Forbidden actions |
|---|---|
| Read the ticket | Send the email directly |
| Summarize history | Modify or close the ticket without validation |
| Search the knowledge base | Promise a refund |
| Check known incidents | Promise an unconfirmed deadline |
| Propose a response | Admit legal responsibility |
| Recommend escalation | Invent 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
- Define agent contract.
- Implement Context Builder.
- Version runtime skills.
- Add typed validation.
- Add business validators.
- Create draft UI with human validation.
- Log runs.
- Test invalid outputs.