An AI agent for IT support tickets investigates each ticket the way a senior engineer would: it searches application logs, runs read-only database queries, reviews recent code changes and checks scheduled jobs, then writes a structured report with evidence and a probable root cause. An engineer reviews the report and approves any fix. We run one on our own support desk.
This is part 1 of our series on what we have built, deployed and learned running AI agents in our own operations.
Key takeaways
- Most support time goes on investigation. Automate the detective work first and leave fixes to engineers.
- Put the agent where engineers already work. Ours lives in Microsoft Teams.
- A person reviews every recommendation before anything changes, permanently, by design.
- Stored investigation history becomes a searchable knowledge base that speeds up repeat issues.
- Start with one ticket category, prove it, then expand.
Why do support tickets take so long to investigate?
A ticket arrives: "The report isn't showing data for the last three days." To investigate, someone checks application logs, queries the database, reviews recent code changes, verifies API endpoints, checks scheduled jobs and cross-references configuration. Two hours later they find the cause: a scheduled job failed silently after a dependency update.
We lived this running our own products. The cost lands on the most expensive resource, senior engineers, doing detective work instead of building. Most AI in support today classifies and routes tickets. Genuine investigation, which means reading logs, querying data and connecting evidence, has stayed manual.
What does an AI investigation agent actually do?
We built an internal agent for our own support operations. It lives inside Microsoft Teams and uses a large language model (Anthropic's Claude) for reasoning.
- Ticket arrivesReported via Teams or the helpdesk
- InvestigationAgent searches logs, databases and code
- EvidenceCollects relevant data points and traces
- ReportStructured findings with probable root cause
- Engineer reviewsChecks evidence and recommendation
- ResolutionApproved fix applied by the team
When someone reports "data not loading", the agent:
- Searches application logs for errors, warnings and anomalies in the relevant window.
- Queries the database (read-only) to check data integrity, recent changes and gaps.
- Reviews code changes for commits that may have introduced the issue.
- Cross-references configuration, scheduled tasks and external dependencies.
- Writes a structured report with evidence, probable root cause and recommended steps.
- Stores the investigation so similar issues resolve faster next time.
The critical design decision is that a person approves. The agent recommends; an engineer reviews and approves before any fix is applied.
Why integrate the agent with Microsoft Teams?
One early lesson: if the AI does not live where your team already works, nobody uses it. We built it as a Teams bot instead of a separate dashboard.
- No context switching. Engineers ask and receive reports in the tool they already use.
- Plain English. No query syntax. Describe the issue.
- Follow-up questions. Ask it to dig into a specific area or a different time window.
- Shared visibility. Reports are visible to the team, building shared knowledge.
- Mobile access. On-call engineers get results on their phones.
This matches the wider direction. Gartner predicted in August 2025 that 40 per cent of enterprise applications will feature task-specific AI agents by the end of 2026, up from less than 5 per cent in 2025.
What changed after deploying the agent?
We have run the agent in production on our own support operations. The changes we care about:
| Manual investigation | With the AI agent | Impact | |
|---|---|---|---|
| Time to first findings | Hours of an engineer's time | Minutes, then engineer review | Much faster |
| Evidence completeness | Depends on the engineer | Same checklist every time | Consistent |
| Root cause | Often needs escalation | Probable cause proposed with evidence | Fewer escalations |
| Documentation | Often minimal | Structured report every time | Documented |
| Knowledge retention | In one engineer's head | Stored and searchable | Shared memory |
| After-hours tickets | Wait until morning | Report ready for whoever picks it up | Earlier start |
Speed is the headline. Three other gains matter more:
Consistency. An experienced engineer on a good day investigates thoroughly. Someone covering on a Friday afternoon might miss things. The agent follows the same process every time.
Documentation. Every investigation produces an evidence-backed report, which matters for audit, compliance and handover.
A learning loop. The agent draws on past investigations when similar issues appear, so value compounds.
How do you work out the return on an investigation agent?
Use your own numbers. These are the lines that drive the case.
- Tickets per week needing deep investigationYour helpdesk data
- Average engineer hours per investigationYour time study
- Loaded hourly cost of those engineersYour payroll
- Escalations to senior staff per monthYour helpdesk data
- Engineer hours returned to product workMeasured after the pilot
Value scales with ticket volume and system complexity. Teams handling dozens of deep investigations a week see the largest effect. Our build vs buy AI TCO guide covers the cost side.
What did we learn building an AI support agent?
1. Start with investigation before resolution
Our first instinct was an agent that fixes issues automatically. That was wrong. Understanding what happened and why is where most of the time goes, and fixes are usually straightforward once the cause is known. Focusing on investigation built trust: engineers could see the reasoning, verify the evidence and learn from it.
2. The conversational interface matters
We first tried a form: ticket number, system, severity. Nobody used it. Switching to plain-English conversation in Teams changed adoption. Engineers want to type "Why is the reporting dashboard showing stale data since Tuesday?"
3. Human review is a feature
For support investigations, the review step catches recommendations that need adjustment, builds engineers' understanding of the systems, keeps accountability with a person, and improves the agent when engineers correct it. As multi-agent systems become more capable, this matters more.
4. Investigation history is an asset
Every investigation is stored with symptoms, evidence, root cause and resolution. After a few months, new team members can search past investigations, the agent resolves repeats faster, and you have a documented trail for audits.
5. Scope it tightly at first
We started with one class of ticket: data integrity issues in our reporting system. Once that was reliable, we added API errors, then authentication, then performance. The build vs buy decision framework makes the same point: start narrow.
Is an AI investigation agent right for your organisation?
What describes your support situation?
- Ten or more tickets a week needing deep investigationStrong candidate for an investigation agent
- High volume but mostly routine questionsA knowledge base assistant is a better fit
- Complex systems with logs, databases and code to searchStrong candidate for an investigation agent
- Simple product with little to investigateBetter documentation may be enough
- Regulated industry needing audit trailsAgent with human review adds compliance value
- Few tickets, low complexityFocus on other automation first
The best fit is an organisation with complex systems, meaningful ticket volume and a need for consistent, documented investigations. That includes internal IT teams running ERPs and line-of-business apps across several sites, as well as software companies.
How do you deploy your own AI investigation agent?
- Week 1-2Audit and scopeMap investigation workflows, pick the highest-value ticket category, list data sources the agent needs
- Week 3-4Core buildSet up the model, connect read-only to logs, database and code repository
- Week 5-6Integration and testingDeploy into Teams or your chat tool, test against historical tickets
- Week 7-8Run alongside the teamProduction with close human oversight, tune based on feedback
- Week 9-12ExpandAdd ticket categories, refine accuracy, build the history
Choose the model carefully. Investigations can mean reading hundreds of log lines, so you need strong reasoning, long context and structured output.
Connect real data, read-only. At minimum: logging, the database (read-only queries) and version control. Each extra source makes the agent more capable. Keep credentials scoped and logged.
Design the report. Ours has fixed sections: Summary, Evidence, Probable Root Cause, Recommended Resolution and Confidence. Consistency makes review fast.
Plan the learning loop. Store every investigation and tag the outcome (correct, partly correct, needed adjustment) to improve over time.
Keep it inside your environment. Logs and databases often contain personal and commercial data. Run the agent on your own infrastructure in Australia with access through your identity provider.
What came out of this deployment?
What we learned building this agent became RootCauseAI, our own AI investigation product. It runs on premises, inside a client's own boundary, connects to ticketing, code and databases, and produces evidence-backed investigation reports for an engineer to review. It is the same pattern described above.
The rest of this series covers other agents in our operations: where to start across seven business functions, a Xero reconciliation agent, an HR agent for policy and leave, an email agent for brand-voice replies, a client-facing knowledge GPT, a BI agent for plain-English dashboards, agent ecosystem architecture and agent governance.
How Solve8 can help
Our engineers build investigation agents that run inside your environment and hand your team evidence-backed reports, and we can walk you through how RootCauseAI works. See our custom AI development and managed AI services, or talk to us.
