Article: Building a truly cybernetic Jira support assistant that can independently navigate our knowledge base#141
Article: Building a truly cybernetic Jira support assistant that can independently navigate our knowledge base#141lehmamic wants to merge 3 commits into
Conversation
kunman93
left a comment
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
| - 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. |
There was a problem hiding this comment.
| 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. |
There was a problem hiding this comment.
| 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. |
There was a problem hiding this comment.
| 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. |
There was a problem hiding this comment.
| 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. |
There was a problem hiding this comment.
| 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. |
There was a problem hiding this comment.
| 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. |
There was a problem hiding this comment.
| 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. |
There was a problem hiding this comment.
| 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. |
There was a problem hiding this comment.
| 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. |
kunman93
left a comment
There was a problem hiding this comment.
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.❤️
I wrote a new article for our blog: Building a truly cybernetic Jira support assistant that can independently navigate our knowledge base