Skip to content

Article: Building a truly cybernetic Jira support assistant that can independently navigate our knowledge base#141

Open
lehmamic wants to merge 3 commits into
Zuehlke:mainfrom
lehmamic:main
Open

Article: Building a truly cybernetic Jira support assistant that can independently navigate our knowledge base#141
lehmamic wants to merge 3 commits into
Zuehlke:mainfrom
lehmamic:main

Conversation

@lehmamic
Copy link
Copy Markdown
Contributor

I wrote a new article for our blog: Building a truly cybernetic Jira support assistant that can independently navigate our knowledge base

@lehmamic lehmamic requested a review from culas January 14, 2026 15:44
Copy link
Copy Markdown

@kunman93 kunman93 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The article is written very well overall. I reviewed your PR with the help of AI. The next time, let AI review your article and then create a PR.

P.S. I like your Monkey D. Luffy profile picture.❤️

tags:
- ai
- tools
- semantik kernel
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- semantik kernel
- semantic kernel

- tools
- semantik kernel
shortDescription: >-
I built a cybernetic AI tool that streamlines the entire JIRA support workflow. This eliminates repetitive troubleshooting and helps teams resolve issues significantly faster.
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
I built a cybernetic AI tool that streamlines the entire JIRA support workflow. This eliminates repetitive troubleshooting and helps teams resolve issues significantly faster.
I built a cybernetic AI-powered tool that streamlines the entire Jira support workflow. This eliminates repetitive troubleshooting and helps teams resolve issues significantly faster.

---
title: 'Building a truly cybernetic Jira support assistant that can independently navigate our knowledge base'
description: >-
In DevOps, resolving JIRA tickets efficiently is critical, yet teams often waste time on issues that first-level support could have solved or on recurring problems that are hard to find due to JIRA’s exact-match search. To address this, I built a cybernetic AI tool. By indexing all JIRA support tickets in a vector database and combining it with an AI-driven chat interface, the tool retrieves similar past cases, suggests solutions, and streamlines the entire support workflow.
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
In DevOps, resolving JIRA tickets efficiently is critical, yet teams often waste time on issues that first-level support could have solved or on recurring problems that are hard to find due to JIRA’s exact-match search. To address this, I built a cybernetic AI tool. By indexing all JIRA support tickets in a vector database and combining it with an AI-driven chat interface, the tool retrieves similar past cases, suggests solutions, and streamlines the entire support workflow.
In DevOps, resolving Jira tickets efficiently is critical, yet teams often waste time on issues that first-level support could have resolved or on recurring problems that are hard to find due to Jira’s exact-match search. To address this, I built a cybernetic AI-powered tool. By indexing all Jira support tickets in a vector database and combining this with an AI-driven chat interface, the tool retrieves similar past cases, suggests solutions, and streamlines the entire support workflow.

I built a cybernetic AI tool that streamlines the entire JIRA support workflow. This eliminates repetitive troubleshooting and helps teams resolve issues significantly faster.
---

During the project, I noticed that many support tickets were escalated to the development team even though they could have been resolved by first-level support. The necessary knowledge is usually well documented or already captured in previously solved tickets. At the same time, the business often submits the same types of requests repeatedly, even though the answers already exist in their own historical tickets. Yet even for us developers, finding the relevant information in older JIRA issues can be surprisingly difficult and time-consuming.
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
During the project, I noticed that many support tickets were escalated to the development team even though they could have been resolved by first-level support. The necessary knowledge is usually well documented or already captured in previously solved tickets. At the same time, the business often submits the same types of requests repeatedly, even though the answers already exist in their own historical tickets. Yet even for us developers, finding the relevant information in older JIRA issues can be surprisingly difficult and time-consuming.
During the project, I noticed that many support tickets were escalated to the development team, even though they could have been resolved by first-level support. In most cases, the necessary knowledge was already well documented or captured in previously resolved tickets. At the same time, the business often submitted the same types of requests repeatedly, even though the answers already existed in their historical tickets. Yet even for developers, finding relevant information in older Jira issues can be surprisingly difficult and time-consuming.


During the project, I noticed that many support tickets were escalated to the development team even though they could have been resolved by first-level support. The necessary knowledge is usually well documented or already captured in previously solved tickets. At the same time, the business often submits the same types of requests repeatedly, even though the answers already exist in their own historical tickets. Yet even for us developers, finding the relevant information in older JIRA issues can be surprisingly difficult and time-consuming.

At NDC Oslo 2024, I was particularly inspired by a talk on practical AI: [“How to add genuinely useful AI to your webapp (not just chatbots)” by Steve Sanderson](https://www.youtube.com/watch?v=TSNAvFJoP4M&list=PL03Lrmd9CiGdnMlwisvEjKClATrAooE2U&index=125&t=2327s). Two years later, during one of our Innovation Sprints, I finally sat down and built a small tool based on the ideas presented in that talk. The solution works in a very similar way to Sanderson’s example and focuses on adding AI where it actually creates value—by helping teams discover and reuse existing knowledge instead of reinventing it for every ticket.
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
At NDC Oslo 2024, I was particularly inspired by a talk on practical AI: [“How to add genuinely useful AI to your webapp (not just chatbots)” by Steve Sanderson](https://www.youtube.com/watch?v=TSNAvFJoP4M&list=PL03Lrmd9CiGdnMlwisvEjKClATrAooE2U&index=125&t=2327s). Two years later, during one of our Innovation Sprints, I finally sat down and built a small tool based on the ideas presented in that talk. The solution works in a very similar way to Sanderson’s example and focuses on adding AI where it actually creates value—by helping teams discover and reuse existing knowledge instead of reinventing it for every ticket.
At NDC Oslo 2024, I was particularly inspired by a talk on practical AI: [“How to add genuinely useful AI to your webapp (not just chatbots)” by Steve Sanderson](https://www.youtube.com/watch?v=TSNAvFJoP4M&list=PL03Lrmd9CiGdnMlwisvEjKClATrAooE2U&index=125&t=2327s). Two years later, during one of our innovation sprints, I finally sat down and built a small tool based on the ideas presented in that talk. The solution works in a very similar way to Sanderson’s example and focuses on adding AI where it actually creates value—by helping teams discover and reuse existing knowledge rather than reinventing it for every ticket.

- `SearchResult` → collects the JIRA keys and IDs so the UI can render clickable links.
- `AnswerChunk` → appends text to the assistant message and parses `<cite …>` tags to map citations back to the corresponding search results.

In the rendered bubble I strip the `<cite>` tags from the main text and show the citations as a separate list of “Search results”, each linking directly to the matching JIRA issue. This keeps the answer readable while still making the underlying tickets fully transparent to the support agent.
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
In the rendered bubble I strip the `<cite>` tags from the main text and show the citations as a separate list of “Search results”, each linking directly to the matching JIRA issue. This keeps the answer readable while still making the underlying tickets fully transparent to the support agent.
In the rendered bubble, I strip the `<cite>` tags from the main text and show the citations as a separate list of “Search results”, with each item linking directly to the corresponding Jira issue. This keeps the answer readable while still making the underlying tickets fully transparent to the support agent

1. The user describes their problem in the chat UI in natural language.
2. The backend forwards the full conversation (plus the system prompt) to the model and registers the `searchJiraIssue` tool in auto mode.
3. The model decides to call the tool, passing the user’s text as the `searchPhrase`.
4. The tool performs a semantic search in **Qdrant**, resolves the matching JIRA issues (including comments), and returns them as structured JSON.
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
4. The tool performs a semantic search in **Qdrant**, resolves the matching JIRA issues (including comments), and returns them as structured JSON.
4. The tool performs a semantic search in **Qdrant**, resolves the matching Jira issues (including comments), and returns them as structured JSON.

3. The model decides to call the tool, passing the user’s text as the `searchPhrase`.
4. The tool performs a semantic search in **Qdrant**, resolves the matching JIRA issues (including comments), and returns them as structured JSON.
5. The model reads these results, formulates an answer grounded in the existing tickets, and ends its reply with a `<cite …>` element that references one of the `SearchResultId` values.
6. The UI renders both the answer and the corresponding JIRA links, so support agents can immediately jump to the original issue if needed.
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
6. The UI renders both the answer and the corresponding JIRA links, so support agents can immediately jump to the original issue if needed.
6. The UI renders both the answer and the corresponding Jira links, so support agents can immediately jump to the original issue if needed.


By the time you read this, it’s worth noting that this experiment is already a bit “old” in AI years. The ecosystem around LLMs, tooling, and integration patterns is moving incredibly fast. If I were to build the same assistant again today, I would probably not wire up the tools manually in the backend anymore.

Instead, I would likely expose the JIRA search and vector database as tools via an MCP (Model Context Protocol) server. That would make the integration more modular and reusable: different clients could plug into the same capabilities, and the assistant could discover and use these tools without as much custom glue code. The core idea, however, would stay the same: let AI augment human support work by making existing knowledge easier to find and reuse.
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Instead, I would likely expose the JIRA search and vector database as tools via an MCP (Model Context Protocol) server. That would make the integration more modular and reusable: different clients could plug into the same capabilities, and the assistant could discover and use these tools without as much custom glue code. The core idea, however, would stay the same: let AI augment human support work by making existing knowledge easier to find and reuse.
Instead, I would likely expose the Jira search and vector database as tools via an MCP (Model Context Protocol) server. That would make the integration more modular and reusable: different clients could plug into the same capabilities, and the assistant could discover and use these tools without as much custom glue code. The core idea, however, would stay the same: let AI augment human support work by making existing knowledge easier to find and reuse.


By the time you read this, it’s worth noting that this experiment is already a bit “old” in AI years. The ecosystem around LLMs, tooling, and integration patterns is moving incredibly fast. If I were to build the same assistant again today, I would probably not wire up the tools manually in the backend anymore.

Instead, I would likely expose the JIRA search and vector database as tools via an MCP (Model Context Protocol) server. That would make the integration more modular and reusable: different clients could plug into the same capabilities, and the assistant could discover and use these tools without as much custom glue code. The core idea, however, would stay the same: let AI augment human support work by making existing knowledge easier to find and reuse.
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Instead, I would likely expose the JIRA search and vector database as tools via an MCP (Model Context Protocol) server. That would make the integration more modular and reusable: different clients could plug into the same capabilities, and the assistant could discover and use these tools without as much custom glue code. The core idea, however, would stay the same: let AI augment human support work by making existing knowledge easier to find and reuse.
Instead, I would likely expose Jira search and the vector database as tools via a Model Context Protocol (MCP) server. That would make the integration more modular and reusable: different clients could plug into the same capabilities, and the assistant could discover and use these tools without as much custom glue code. The core idea, however, would remain the same: letting AI augment human support work by making existing knowledge easier to find and reuse.

Copy link
Copy Markdown

@kunman93 kunman93 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The article is written very well overall. I reviewed your PR with the help of AI. The next time, let AI review your article and then create a PR.

P.S. I like your Monkey D. Luffy profile picture.❤️

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants