01
Common requests resolve themselves
The requests that arrive dozens of times a week already have documented answers. Agents match against your knowledge base and draft the resolution.
2 live information technology agents across 2 processes — service desk triage and incident summarisation.
Turn rough incident notes into a blameless postmortem with a timeline, contributing factors, and action items someone actually owns.
Classify an IT ticket, set its priority against your SLA, and draft either a fix or a routing note for approval. Nothing is sent.
IT service work has a volume problem at the front and a learning problem at the back. At the front, tickets arrive unclassified and unprioritised, so the queue is worked in the order it was filled rather than by impact, and the first response — which is mostly classification plus a routing decision — consumes the time of whoever is on duty. At the back, incidents get resolved and then not written up. The postmortem is genuinely valuable and always the lowest priority in the week after an outage, so it gets deferred until the detail has gone, and the contributing factors that would have prevented the next one are never recorded.
The two agents here take the mechanical half of each. Triage classifies against your own SLA and drafts either a fix or a routing note, and sends nothing — the judgement about whether the classification is right stays with a person, which matters because a misprioritised P1 is worse than an unprioritised ticket. The postmortem agent turns rough notes into a blameless writeup with a timeline, contributing factors and action items that have owners. Blameless is not a tone preference: a postmortem that identifies a person rather than a system produces silence at the next incident, and silence is what makes an organisation repeat itself.
Incident Management
Service Desk
What this changes
In plain terms, without the engineering detail. The individual agent pages carry the technical specifics.
01
The requests that arrive dozens of times a week already have documented answers. Agents match against your knowledge base and draft the resolution.
02
The timeline, affected systems and actions taken are assembled as the incident unfolds, so the post-mortem is not reconstructed from memory a week later.
03
Anything that alters permissions or infrastructure state requires explicit approval, scoped per action. Convenience does not get to override that.
Start with triage and resolution drafting on your top five ticket types. Your knowledge base is the input, so the setup cost is mostly finding out which articles are actually current.
Next Step
These run as-is, and most engagements adapt one to the way your process actually works — different source systems, different tolerances, a different approval path. The first call establishes which base agent fits and what has to change.