Support Triage Agent¶
Thinklio Built-in Agent Specification Version 0.1 | March 2026
1. Purpose and Problem Statement¶
The Support Triage Agent is the first responder for inbound support requests. It receives Items from the Enquiry Agent, attempts to resolve them autonomously using the knowledge base and known issue library, and only escalates to a human when it cannot resolve or when the nature of the request warrants human involvement.
The distinction from the Enquiry Agent is important: the Enquiry Agent handles intake — receiving, classifying, and routing inbound contacts. The Support Triage Agent handles resolution — attempting to close the loop before a human needs to get involved.
Together, Enquiry → Support Triage forms the complete inbound support pipeline.
The problem it addresses is support volume. Most support requests are either answerable from existing documentation, answerable from the known issue register, or are variations of previously resolved cases. Human agents should spend their time on the requests that genuinely need them — complex problems, emotional conversations, novel issues. The Support Triage Agent handles the rest autonomously, or at least prepares everything a human needs to resolve the remainder quickly.
2. Position in the Pipeline¶
Inbound channel → Enquiry Agent (intake) → [Support Triage Agent]
↓
Resolved autonomously
OR
Prepared + escalated to human
The Support Triage Agent operates on Items created by the Enquiry Agent. It can also be invoked directly by a human support agent who wants the agent to research and draft a response.
3. UI Structure¶
Chat Tab¶
Used by human support agents to interact with the triage agent: - "Look up what we know about the error code 5023 issue" - "Draft a response to Item #482 — the client is asking about invoice reconciliation" - "What's the resolution rate this week?" - "Has this type of issue been reported before?"
Queue Tab¶
The support queue view — identical in structure to the Enquiry Agent's Queue tab, but filtered to Items in the triage agent's scope. Shows autonomous resolution status alongside standard Item fields: - Items the agent has resolved autonomously (green) - Items the agent has prepared a draft response for, awaiting human approval (amber) - Items the agent could not resolve and has escalated with context (red) - Items the agent is currently working on (processing indicator)
Knowledge Tab¶
Access to the support knowledge sources the agent draws from: - Known issue register (maintained by the support team) - FAQ library - Product or service documentation - Past resolved cases (anonymised, for pattern matching)
Admin controls for updating the known issue register and FAQ library directly from this tab.
Analytics Tab¶
Support performance metrics: - Autonomous resolution rate (percentage of Items closed without human intervention) - Average time to first response (agent and human) - Average time to resolution - Volume by Item type, channel, and priority - Most common issue types - Escalation reasons (why the agent escalated — useful for improving the knowledge base)
4. Configuration¶
4.1 Admin Configuration¶
| Setting | Description |
|---|---|
| Library assignments | Which knowledge libraries the agent draws from for resolution |
| Known issue register | A structured registry of known issues with symptoms, root causes, and resolution steps |
| Autonomous resolution scope | Which Item types the agent may resolve without human approval |
| Confidence threshold | Minimum confidence required for autonomous resolution; below this, the agent prepares a draft and escalates |
| Response tone | Professional / friendly / technical — applied to agent-drafted responses |
| Escalation rules | Conditions that always trigger human escalation regardless of confidence (e.g. complaints, legal mentions, named individuals) |
| Human approval required | Whether any autonomous response requires human approval before sending |
| SLA integration | Whether the triage agent is aware of and factors in SLA deadlines |
4.2 Escalation Triggers¶
Certain conditions always route to a human regardless of the agent's confidence:
| Trigger | Reason |
|---|---|
| Item type: complaint | Requires empathy and relationship management |
| Content contains legal language | Potential liability — must not respond autonomously |
| Contact is a VIP (tagged in Rolodex) | Strategic relationship requiring personal attention |
| Repeated Item from same contact | Pattern suggesting a systemic problem |
| Sentiment analysis: highly negative | Distressed contact needs a human |
| No response match above threshold | Agent genuinely doesn't know — honest escalation is better than a poor autonomous response |
5. Resolution Flow¶
For each Item received from the Enquiry Agent:
1. Retrieve contact history from Rolodex
→ Has this contact had this issue before?
→ Are there open related Items?
2. Check known issue register
→ Does this match a known issue?
→ If yes: is there a confirmed resolution?
3. Search knowledge base
→ Can the question be answered from documentation?
→ Confidence score for best match
4. Check past resolved cases
→ Has a similar issue been resolved before?
→ What was the resolution?
5. Evaluate escalation triggers
→ Does any trigger condition apply?
→ If yes: escalate with context bundle
6. Autonomous resolution (if confidence ≥ threshold and no triggers)
→ Draft response citing resolution source
→ Send (if autonomous send permitted) or queue for approval
→ Close Item with resolution note
7. Assisted resolution (if confidence < threshold and no hard triggers)
→ Draft response with agent confidence note
→ Queue for human review with full context bundle:
contact history, matched knowledge, confidence score, suggested next steps
6. The Context Bundle¶
When the Support Triage Agent escalates to a human, it provides a structured context bundle that prepares the human to resolve the Item without re-researching:
ContextBundle
├── item_summary string (one-paragraph summary of the issue)
├── contact_history InteractionSummary (recent interactions with this contact)
├── related_items Item[] (open or recently resolved Items from same contact)
├── knowledge_matches KnowledgeMatch[] (what the agent found, with confidence scores)
├── known_issue_match KnownIssue | null (if matched)
├── draft_response string | null (agent's best draft, for human to edit)
├── suggested_actions string[] (what the agent recommends, even if not acting on it)
├── escalation_reason string (why the agent didn't resolve autonomously)
└── confidence_score float
This bundle is shown in the Item detail panel when a human picks up an escalated Item. The human should be able to resolve most escalated Items in under two minutes using this context.
7. Known Issue Register¶
The known issue register is a structured record of recurring issues maintained by the support team:
KnownIssue
├── issue_id UUID
├── title string
├── symptoms string[] (patterns that indicate this issue)
├── root_cause string | null
├── status enum (investigating | confirmed | resolved | monitoring)
├── resolution_steps string (what to tell the contact)
├── internal_notes string | null (not shown in agent responses)
├── affected_versions string[] | null (for product issues)
├── workaround string | null
├── created_at timestamp
├── updated_at timestamp
└── resolved_at timestamp | null
The agent matches incoming Items against the known issue register using both keyword and semantic matching on the symptoms field. A match above a configurable threshold routes the Item through the known issue resolution path.
8. Agent Capabilities¶
| Capability | Description |
|---|---|
| Triage item | Execute the full resolution flow for an Item |
| Look up known issue | Search the known issue register by symptom or keyword |
| Draft response | Compose a response for human review |
| Retrieve contact history | Pull interaction history and related Items for a contact |
| Search knowledge base | Query the knowledge library for relevant content |
| Update known issue | Add or update a known issue record (admin or support lead) |
| Report | Produce an analytics summary for a time period |
| Batch triage | Process a queue of unaddressed Items |
9. Inter-Agent Behaviour¶
- Enquiry Agent creates Items that the Support Triage Agent processes
- Knowledge Base Agent is queried for resolution content
- Rolodex is queried for contact history and VIP status
- Mail Agent sends autonomous responses (governed by permission level)
- Messenger Agent sends autonomous responses via messaging channels
- Taskmaster creates follow-up tasks for Items that require human action after initial response
10. Use Cases¶
UC-1: Autonomous resolution¶
A contact emails asking "how do I reset my password?" The Enquiry Agent creates an Item. The Support Triage Agent matches it to a known issue (password reset) with a confirmed resolution path, confidence 0.94. No escalation triggers apply. The agent drafts and sends a response with the reset instructions, citing the help article, and closes the Item. Total time: under 60 seconds. No human involved.
UC-2: Assisted resolution¶
A contact submits a complex billing query. The agent finds partial matches in the knowledge base (billing policy) but confidence is 0.61 — below threshold. It drafts a response that addresses the policy dimension but cannot confirm the specific account detail. It escalates to a human with the context bundle: contact history, draft response, the specific billing policy sections it found, and a note explaining what information the human needs to check in the billing system to complete the response.
UC-3: Complaint escalation¶
A contact sends an angry message about a service failure. Sentiment analysis flags it as highly negative and the content includes a complaint. The escalation trigger fires immediately. The agent does not attempt resolution — it classifies, prepares the context bundle (including the contact's history and any related previous Items), marks the Item as high priority, and notifies the support lead.
UC-4: Known issue spike¶
Five Items arrive within two hours with similar symptoms matching a known issue currently in "investigating" status. The agent resolves the first four autonomously (using the current workaround from the register) and alerts the support lead: "5 Items today matching known issue #143. You may want to update the status and resolution."
11. Open Questions¶
- Sentiment analysis as an escalation trigger requires an NLP capability. Should this be a built-in processor or an optional integration?
- Past resolved cases as a knowledge source raises privacy questions if the cases contain contact information. Anonymisation should happen at the point of ingestion, not at retrieval. How is this enforced?
- Autonomous response with no human approval is a significant trust decision. Should this be off by default, requiring an explicit admin opt-in to enable?
- The known issue register is manually maintained. Could the agent contribute to it — suggesting new entries when it encounters issue patterns without a match? This would be a useful feedback loop but requires admin approval before new entries are published.
Previous: Knowledge Base Agent | Next: Coordinator Agents