Back to projects

Prototype

Support Copilot

A locally running AI assistant built around real troubleshooting workflows, not around producing an answer.

technical / knowledge / AI / troubleshooting

SC
PythonFastAPISQLitesentence-transformersllama.cppRAG

Why I built it

Support Copilot came out of working with support cases where the useful knowledge already exists. It's just scattered across historical tickets, troubleshooting notes, previous investigations and escalation information.

Instead of asking an AI to magically produce an answer, the goal is to help the support engineer make the next decision. That distinction matters: the useful part of AI support tooling is not the answer, it is reducing the next decision.

Privacy was a deliberate constraint from the start, not something added later. The system is built around local inference, local data and controlled knowledge ingestion, with read-only behaviour and human approval built into the parts of the workflow that actually matter.

What it does

Support Copilot combines retrieval over historical support knowledge with a local LLM to suggest troubleshooting steps, while keeping a human engineer in control of every consequential action.

Key features

Retrieval (RAG)

  • Sentence-transformer embeddings (paraphrase-multilingual-MiniLM-L12-v2)
  • Retrieval over historical support knowledge

Local LLM

  • Served through llama.cpp behind an OpenAI-compatible local endpoint
  • Qwen3 4B GGUF used during development

Knowledge ingestion

  • Ingests Jira ticket exports (XML), JSON and CSV
  • Extracts roles, escalation structure, troubleshooting context, error codes and resolutions

Troubleshooting engine

  • Troubleshooting sessions with suggested actions and session events
  • Approve / reject actions
  • Surfaces knowledge candidates discovered during live cases

How it works

  1. 1Jira exports
  2. 2Parser / extractor
  3. 3Sanitized structured ticket data
  4. 4Verified knowledge
  5. 5Embeddings / retrieval
  6. 6Local LLM
  7. 7Troubleshooting suggestions
  8. 8Human approval

Nothing reaches an engineer as a suggestion without passing through retrieval and the local model first

Architecture notes

Ticket exports go through a parser/extractor that turns raw Jira XML, JSON or CSV into sanitized, structured ticket data. The ingestion step can identify useful structure: ticket roles, escalation paths, references to logs and investigations, error codes and resolution information.

That structured data becomes verified knowledge, which is embedded and made retrievable. When a new case comes in, retrieval feeds relevant historical context to the local LLM, which proposes troubleshooting suggestions, but nothing acts on its own. Every consequential step waits on human approval.

Tech stack

Backend

FastAPISQLite

RAG

sentence-transformersparaphrase-multilingual-MiniLM-L12-v2

Local LLM

llama.cppOpenAI-compatible local endpointQwen3 4B GGUF

Knowledge sources

Jira XML exportsJSONCSV

Interesting technical details

Detail

Local-first, read-only where it matters

Local inference, local data and controlled knowledge ingestion, with read-only behaviour by default and human approval for consequential troubleshooting actions. Not a formal compliance claim, just a design decision about where control should sit.

Detail

Human approval is architectural, not a UI afterthought

Suggested actions and session events flow through an explicit approve/reject step. The AI proposes; the engineer decides. That boundary is part of the troubleshooting session model itself, not just a confirmation dialog.

Detail

Development dataset

A Jira XML export containing hundreds of recent support tickets has been used during development. The broader historical dataset available is substantially larger. Ticket contents and customer information are never exposed.

Detail

Structured API surface

The backend exposes structured endpoints for concepts like health/status, RAG search, ticket analysis, ticket troubleshooting, ingestion, and troubleshooting sessions.

Challenges & decisions

Decision

The answer isn't the point

It's tempting to optimize an AI support tool for giving a correct final answer. The more useful framing turned out to be narrower: reduce the engineer's next decision, and let them stay in control of the ones that matter.

Decision

Small hardware, real workloads

The system has also been used to experiment with running useful AI workloads on relatively limited hardware, which makes model size, quantization, inference speed and retrieval quality practical, everyday engineering considerations rather than abstract ones.

Current status

Prototype, in active development.

  • RAG pipeline, ingestion and troubleshooting session model are working end-to-end
  • Development so far centers on a Jira XML export of hundreds of recent tickets
  • No formal compliance certifications; privacy is a design decision, not a certified claim
  • Backend API surface (search, analysis, troubleshooting, ingestion) is functional and evolving

What's next

Support teams repeatedly solve similar problems, and the knowledge to solve them faster usually already exists somewhere in past work. This project is really an exploration of how to make that existing knowledge useful at the exact moment a new issue arrives, without pretending the model should be the one making the call.

Broaden ingestion beyond the current ticket datasetImprove retrieval quality and session toolingKeep experimenting with model size vs. hardware constraints