TriageAgent: a fully local AI that triages support tickets for my dev team(HALF BAKED)

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

My dev team's biggest time-sink isn't writing code — it's triaging support tickets. Every morning someone reads a wall of messages, figures out which tickets we've already solved and which need a real engineer, and routes them.

TriageAgent does that automatically. You paste in our support chat log — no strict format, just messages that mention a ticket ID like #123 — and it:

• groups messages into ticket threads by their ticket ID,
• builds a local index of every past thread and of each developer's past work,
• for a new ticket, either writes a short internal note to the support team (when a similar resolved thread exists) or routes it to the right dev based on whose past responses it most resembles,
• and prints case-based reports: open tickets per dev, critical cases, and a full case list.

No cloud, no API keys, nothing leaves the machine.

Demo

It runs as a CLI and a small web UI. Two real examples from the sample data:

$ python cli.py triage "#999 the login page crashes on Safari"
action: note
note: "Duplicate of #101. Fix applied: Safari-specific JS bug in login
       handler fixed in v2.3.1. Handled by: alice."

$ python cli.py triage "#999 our webhook receiver is returning 500s"
action: route
assigned_dev: carol
reason: "A very similar ticket already exists (#108) but is still open,
         so I routed to 'carol' — their past work is closest."

Code

The whole thing is on GitHub:

karan-2004 / triage-agent

TriageAgent

A local, open-source support-ticket triage agent for a dev team. Point it at a chat log; it groups messages into ticket threads, builds an index, then for any new ticket it either writes a short internal note to the support team (when a similar resolved thread exists) or routes it to the developer whose past responses it most resembles. It also prints case-based reports (open tickets per dev, critical cases, and a full case list).

Built with local AI at its core (Ollama + open models). No data leaves your machine.

How it works

1. Ingest — parse a free-form chat log, group messages by ticket ID embed each thread (nomic-embed-text), store in a local vector index. It also builds one "profile" embedding per developer from every message they wrote.
2. Triage — embed the new ticket and search
   • if a past resolved thread is similar enough (≥ threshold)…

View on GitHub

How I Built It

The open-source AI is the point, so everything runs locally:

• Ollama serving two open-weight models:
  • nomic-embed-text — embeddings for similarity search,
  • llama3.2:1b — writes the internal notes.
• Python glue: a tiny numpy vector store (cosine similarity), a free-form chat-log parser that groups messages by ticket ID, and a simple RAG flow.
• Streamlit for the browser UI.

The flow: parse the chat log → embed each thread and each developer's profile → store locally. For a new ticket, embed it and search. If the best resolved match clears a similarity threshold, the LLM drafts the note from that thread's resolution; otherwise it routes to the dev whose profile is closest.

One detail I'm proud of: it only auto-notes from resolved threads. An open duplicate gets routed instead of answered with a hallucinated fix — that alone cut the wrong answers to near zero. The suite of 26 pytest tests covers the parser, reports, store, and triage decisions.

Why Does Open Innovation Matter?

Support tickets are full of things you don't want on someone else's server: customer emails, login problems, billing details. Because Ollama and the models are open-weight, this all runs on a laptop with the Wi-Fi off — the tickets never leave the machine.

That's what a closed API wouldn't let us do. A hosted model means shipping every ticket thread to a vendor. An open stack let us:

• keep the data local — no upload, no retention policy to worry about;
• swap models freely — if we outgrow llama3.2:1b, point TRIAGE_CHAT_MODEL at a bigger model, no code change;
• run it for free — no per-token bill for triaging our own backlog.

Open innovation isn't a nice-to-have here; it's the reason the tool is safe to point at real tickets. Hope we devs really needs to keeps the bugs not to fly onto third party server exposing its source.

Also Context of tickets need to be shared between the devs so that anyone can respond to it at the earliest. This agent acts as the context manager with autonomous response generator.

Honestly it is still half baked and untested in the real environment. Need to involve in several iterations to make it helpful for my friends. So let it be outside rewarding category.

Credits: Opencode with Deepseek 4(helped to convert my idea into code)