- Product
- Agent Knowledge Base
- Provider
- linked-planet
- Scope
- Incident handling for infrastructure operators
- Source
- Jira incident reports
- Document
- LP-AKB · 2026-10
Resolved incidents become knowledge for the next decision
Summary
The Agent Knowledge Base makes documented incident experience from your Jira incident reports retrievable. Teams and AI agents get comparable cases for the right vendor, each linked to its source issue.
| Match | Fault pattern | Documented remediation | Reference cases | Relevance |
|---|---|---|---|---|
| 1 | Connector lock stays in an intermediate position after the cable is pulled. |
1 more remediation documented | 12 past incidents
| 0.86 |
| 2 | Cable is not released after the session ends. |
| 4 past incidents
| 0.67 |
| Match | Fault pattern | Documented remediation | Reference cases | Relevance |
|---|---|---|---|---|
| 1 | Vehicle handshake drops after authorisation. |
1 more remediation documented | 5 past incidents
| 0.78 |
| Match | Fault pattern | Documented remediation | Reference cases | Relevance |
|---|---|---|---|---|
No sufficiently relevant match. No fault pattern for Vendor C scores above the minimum. The team knows the catalogue has no reliable answer here and escalates the case for expert review. | ||||
Relevance measures fit to the query, not the likelihood that a remediation works. More on evidenceMinimum score 0.60
An asset fails. The experience to fix it is scattered.
Engineers look for similar cases, work out possible fixes and prepare the next site visit. Often someone on the team has solved the problem before. The answer then sits buried in vendor docs, a ticket thread, a comment or one person’s head. Finding it again takes time while the incident keeps tying up capacity.
- 1.1Scattered
- Clues sit in issue descriptions, comments, vendor documents and the memory of individual staff.
- 1.2Repeated
- The same research ties up capacity in the operations team and in field preparation.
- 1.3Risky
- The wrong fix on the wrong charge-point model leads to a wasted visit and a longer outage. In charging parks with many hardware variants, picking the right remediation is the critical step.
- 1.4Duplicated
- Rewriting issue findings as knowledge articles takes time. A gap remains between a solved case and a usable instruction.
The Agent Knowledge Base turns fault patterns and remediations from suitable Jira issues into condensed entries. Every new query gets comparable cases with the documented fix and a link to the source issue, or a clear statement that no sufficient match exists.
New suitable cases are added automatically. The goal is less research, better-prepared remediation and more consistent handling of recurring problems.
Less searching, better-prepared site visits
| Area | Value | Possible operational metric |
|---|---|---|
| Operations | Documented experience is available across teams and sites. It stays accessible when the person who solved the case is unavailable or has left. | Research effort per incident |
| Service | Comparable incidents are handled on the same basis. New staff learn known fixes. Escalations arrive with matching reference cases. | Time to an accepted remediation proposal |
| Field | Known fault patterns, past remediations and their references prepare the visit and improve the handover to field technicians. | Follow-up questions and repeat visits |
NoteSupport teams use the results for first triage and the handover to the expert team. The expert team checks whether a remediation fits the specific asset. Which procedure becomes the binding standard is the operator’s decision.
From the current incident to a reasoned remediation proposal
A charge point will not start a session. The issue names the vendor, an error message and first observations from support. The team asks the question every support team knows:
“Which similar cases do we know, and how were they fixed?”
If the Knowledge Base finds matching fault patterns for that vendor, it returns the documented remediation steps, alternative fixes and links to past issues. Where notes on vendor-specific error codes exist, they complete the answer.
Vendor A shows the fault pattern “Connector lock stays in an intermediate position after the cable is pulled.” It was fixed in two ways: path 1, Restart, check actuator, replace if it recurs; path 2, Readjust the limit switch. Reference cases DEMO-1041, DEMO-0977, DEMO-0932, DEMO-0811 and more support the vendor, the fault pattern and both remediations.
The principle is called GraphRAG. Search recognises symptoms described in different words and uses the stored relationships between vendor, fault pattern, remediation and reference case. Distillation happens before the query: teams read condensed entries, not raw ticket threads.
- 3.1Vendor
- The boundary of every comparison. A similar symptom at another vendor may need a different fix.
- 3.2Fault pattern
- A condensed description of a problem. Different wordings of the same problem become one entry.
- 3.3Remediation
- The documented fix. If a fault pattern was solved in several ways, every way stays visible.
- 3.4Reference case
- The source issue behind an entry. Every proposal can be traced back to it.
Note 1If there is no sufficiently relevant match, the Knowledge Base says so instead of constructing an answer.
Note 2Queries start from a Jira issue or a free-text symptom description plus the vendor.
Note 3EV charging is one application area. The approach fits wherever incidents and their remediations are documented well enough. The expert team decides whether a remediation suits the model and operating situation.
Solved issues become knowledge, no extra articles
Your teams write no extra knowledge articles. A scheduled run picks up new suitable issues.
- 4.1
Selection
A Jira filter defines which issues serve as sources, for example closed incidents with a documented fix.
- 4.2
Check
Quality gateIs the vendor unambiguous? Are problem and solution described clearly enough?
- 4.3
Distillation
Fault pattern and remediation are extracted from the description and comments. An early guess corrected later is not kept as a valid solution.
- 4.4
Merge
Identical knowledge is merged within the vendor. More cases strengthen existing entries, new findings extend the catalogue.
- 4.5
Availability
The entry is retrievable with its references, for people and for agents.
Not ingested (4.2)
Missing or ambiguous vendor, unclear problem, unclear solution. These issues are logged as documentation gaps and show where better incident records would help.
We set up the schedule during integration. Existing incident issues are ingested. Issues already in the catalogue are recognised and skipped.
Maintenance stays a defined task
Note 1Later corrections to ingested issues need a targeted re-run.
Note 2Conflicting remediations and outdated content need expert review.
Note 3Supplementary vendor notes, such as error-code hints, are maintained separately.
Note 4Feedback from use: did a recommendation help, and what information was missing?
How well is a recommendation supported?
Final remediation decisions need a clear basis. The Knowledge Base gives no blanket score. It provides the facts the expert team needs to judge whether a remediation fits.
| # | The expert team asks | The Knowledge Base provides |
|---|---|---|
| 1 | How well does the fault pattern fit the report? | A relevance score per match. Matches below a set minimum score are not returned. |
| 2 | How many past cases support the remediation? | The number of incidents that document exactly this problem and solution pair, with a link to each issue. |
| 3 | Which alternatives are known? | Other documented fixes for the same fault pattern, visible side by side. |
Relevance is not a probability of success.
A high relevance score describes the fit to the current query, not a measured chance that a remediation works. Even a frequently documented fix must suit the specific asset and operating situation.
Confidence rating Possible extension
The available facts can be combined into a plain-language rating with a stated reason. We define the criteria with your experts and validate them on real cases.
- well supported
- partly supported
- insufficiently supported
A checked and connected catalogue of traceable knowledge
The Knowledge Base is not a chatbot on top of a ticket export. It builds a checked, connected catalogue in advance and answers queries from that catalogue.
| # | Characteristic | Specification |
|---|---|---|
| 6.1 | Knowledge model | A graph of vendor, fault pattern, remediation and reference case (GraphRAG). Relationships are stored, not guessed again at query time. |
| 6.2 | Search | Semantic vector search finds symptoms described in different words. A reranking model re-scores the candidates, and a minimum score filters weak matches. |
| 6.3 | Vendor isolation | Search, merging and evidence stay strictly within one vendor. Similar-sounding faults from different vendors never mix. |
| 6.4 | Deduplication | Two stages: an exact match first, then semantic matching with reranking. Identical knowledge becomes one entry, and evidence accumulates. |
| 6.5 | Quality gate | Issues without an unambiguous vendor, or with an unclear problem or solution, are not ingested. They are logged instead. |
| 6.6 | Traceability | Every entry links to its source issues and records which model and prompt version produced it. |
| 6.7 | Model choice | Language, embedding and reranking models are chosen per task, including through OpenAI-compatible APIs, for example for self-hosted models. Switching models runs as a controlled re-computation of the catalogue. |
| 6.8 | Operational safety | Before every run, the system checks its prerequisites, such as model availability and search readiness. Transient transport errors are retried automatically; issues already ingested are skipped. |
| 6.9 | Agent access | Read-only access via MCP (Model Context Protocol). Agents receive matches with references and cannot change the catalogue. |
NoteWe walk through architecture, data storage and the operating model in a conversation.
From recommendation to automation
Beyond the single incident, the knowledge catalogue shows where common procedures or better documentation pay off. Reports built on it answer questions like these:
- Which fault topics are documented most often for a vendor?
- Which remediations are used again and again?
- Where do variants or knowledge gaps appear?
- Where does ingestion fail because of unclear documentation?
| Level | What happens | Status | |
|---|---|---|---|
| 1 | Assemble a proposal | Matching remediations and evidence are compiled automatically for review. The expert team decides on execution. | First use case |
| 2 | Route further handling | If the evidence is strong enough and the information complete, a defined checklist is provided. Otherwise the case goes to the expert team with everything available. | By your criteria |
| 3 | Trigger an approved routine | Where knowledge, rules and mandate allow, approved routine actions follow. Figure 3 shows a possible rule. | Outlook |
Autonomous agents need a decision basis they can check Outlook
An AI agent that is meant to decide on its own needs knowledge whose quality it can verify. The Knowledge Base supplies the vendor scope, a relevance score per match, the number of supporting cases, known alternatives and a clear signal when nothing fits well enough. That turns when an agent may act alone into a rule you can check.
Conditions, all met
- Match within the vendor scope, above the minimum score
- Minimum number of reference cases for the remediation reached; you set the value
- No conflicting remediations for the fault pattern
- Remediation is on your approved list
- Required issue information is complete
All conditions met
The agent triggers the approved routine and records the reference cases in the issue.
A condition is open
The agent hands over to the expert team, with matches, evidence and the missing information.
No sufficient match
The agent does not decide. The case goes straight to the expert team.
Note 1The Knowledge Base is connected read-only and makes no decision itself. We set up rules, approvals and actions such as issue changes or dispatch within the agreed integration scope.
Note 2Every autonomous decision stays traceable because it points to named reference cases. Where the basis is not enough, a person decides.
You set the mandate
You decide which information is required, which actions are permitted and when a person decides. Issue changes, dispatch or actions on assets need additional integrations.
Impact is measured in operation
Research effort, time to an accepted remediation proposal and the share of helpful recommendations show the effect. Availability, time to restore and handling cost remain the top-level measures.
Connect to agents and applications
The Knowledge Base connects to AI agents and applications. Knowledge reaches your teams where they triage cases, review remediations and prepare site visits. Further assistants use the same catalogue without preparing the experience again.
| Channel | Description |
|---|---|
| MCP | Standard connection for existing AI agents through the Model Context Protocol. |
| Custom assistant | An agent or application built for your workflows. |
| Atlassian Rovooptional | Where teams already use Rovo, a configured Rovo agent can query the same Knowledge Base. |
Example agent tasks
- Triage
- Pulls similar fault patterns, prepares the first assessment and names missing information.
- Remediation
- Explains documented fixes with their reference cases and shows alternatives to the expert team.
- Field preparation
- Turns the matches into a structured handover for field technicians.
NoteThe Knowledge Base supplies information; the agent combines it with its task. We tailor which tasks an agent takes on to your workflows. Atlassian: tools for Rovo agents
Start small with one vendor and your issues
- 9.1
Distillation
linked-planet turns suitable Jira issues from your operation into reusable incident knowledge: condensed entries, vendor-scoped merging, reference cases and ongoing intake of new cases.
- 9.2
Integration
From MCP for existing agents to a custom assistant. Together we define tasks, knowledge sources and extensions. Responsibility for operation and maintenance is set out in the specific offer.
- 9.3
Getting started
One vendor or infrastructure segment with recurring, well-documented incidents. Plus a clear usage path, such as technical triage or field preparation, and the target level of automation.
PrerequisiteIncidents and remediations are documented well enough in Jira, and the vendor is identifiable. Knowledge extraction is based on Jira issues today. Further source systems can be agreed as an extension.
OutlookAdditional asset and operational data could enable finer classification. Failure prediction or spare-parts planning require additional data and their own expert validation.
Bring one recurring incident to the conversation.
Talk to us about the incident-handling problems that keep tying up your operation.
In the conversation we clarify
- What knowledge already sits in your issues?
- Who needs it: support team, expert team, field technicians?
- How does it reach the workflow, through an agent or an application?
- Which scope and next steps fit?