A state-of-the-art intelligent routing and answering engine built natively on STACKIT infrastructure to drastically reduce ticket resolution times.
Five swimlanes across STACKIT SKE. Every component aligned to a 5-column grid so data flows read cleanly top-to-bottom. The green path is the live query route · cyan is AI processing · orange is nightly ingestion.
Orchestration paths for converting unstructured inputs (PDF runbooks, raw scripts, resolved Jira tickets, or custom Markdown drafts) into standardized runbooks, ending in a git Pull Request.
Raw Jira tickets and Confluence runbooks undergo processing before entering the vector space, ensuring high semantic density.
Ingests Jira tickets resolved/closed in last 25 hours (ORDER BY updated DESC).
Syncs new/updated markdown files and runbooks from STACKIT Git Knowledge Repo.
Runs manually using BACKFILL=true to ingest historical tickets (ORDER BY created DESC).
Support agent enters a ticket number (SSD-XXXX or SSD3RD-XXXX) in the Agent Panel. The frontend normalizes dashes (including Unicode variants), uppercases the input, strips whitespace, and validates format before sending to the backend.
n8n fetches the complete Jira ticket via Bearer token. Extracts: summary, description, resolution, priority, labels, STACKIT custom fields (Org, Project, Product, Region, Service Hours, Resolution Category), attachments, issue links, and up to 15 comments (1,500 chars/comment). HTTP 401/403/404 error codes return specific user-facing error messages.
A dedicated Llama 3.3 70B call extracts a precise real_problem_summary (e.g. "PostgreSQL Flex Control Plane API returning 503 under heavy clone workload") and 4–5 STACKIT-specific search_keywords. This focused summary is used for embedding — not the raw ticket text — dramatically improving vector search relevance.
The extracted problem summary is vectorized to 1,536 dimensions via e5-mistral-7b on STACKIT model serving. Two parallel HNSW cosine similarity searches run concurrently: (1) ticket_embeddings — top 5 similar past resolved tickets (score ≥ 0.65); (2) kb_chunks — top 3 KB runbook excerpts of 1,000 chars each (score ≥ 0.70).
n8n merges both parallel PostgreSQL results via a Merge node. The combined result set (similar past tickets + KB runbook chunks) is passed together as retrieval context into the main LLM prompt — ensuring the model has access to both historical resolutions and official documentation simultaneously.
n8n assembles the full structured prompt: ticket metadata, STACKIT custom fields, full description, similar past tickets with their resolutions, and KB runbook excerpts. The system prompt instructs the LLM to produce strict JSON output (routing, confidence, missing info, troubleshooting, draft reply) grounded only in provided context — preventing hallucinations.
The structured prompt is sent to Llama 3.3 70B on STACKIT model serving (temperature: 0.3, max_tokens: 1,536). The model returns a strict JSON response with: sag_routing, confidence_score, missing_information, troubleshooting_steps, and draft_reply. The LLM is sole authority on missing information — no programmatic regex overrides this except an empty description guard.
n8n parses the JSON response and applies weighted multi-signal STACKIT Product routing (STACKIT Product match 20% + semantic similarity 80%). Resolved/closed tickets automatically get empty missing_information. The finalized brief is returned to the frontend — rendered in the AI Ticket Analysis tab, with Reply Drafter, RCA Generator, Ticket Builder, and Follow-up Chat available as separate tabs/panels.
How the frontend, backend n8n automation instances, and secure databases are architected inside the sovereign Kubernetes cluster.
• ai-service Namespace: Hosts the static nginx web servers running the Agent Panel (helpdesk-frontend-pr-X).
• n8n-team Namespace: Hosts the shared n8n production instances, database connection agents, and webhook listener worker pods.
• Isolated Namespaces: n8n-dev, n8n-kos, and n8n-kev provide sandboxed playgrounds for team development.
• Egress Isolation: Restrictive Kubernetes NetworkPolicy rules block all pod outbound traffic to the open internet.
• Acl Whitelist: Pods can connect ONLY to CoreDNS (port 53), Redis (port 6379), STACKIT Managed PostgreSQL Flex (port 5432), and the STACKIT AI model-serving gateway (port 443).
• Ingress TLS: nginx-ingress terminations enforce TLS 1.3 using certificates auto-renewed by cert-manager.
• Forgejo Actions: Push events trigger automatic syntax validation (Terraform fmt, tfsec) and n8n schema checks (n8nac validate).
• Preview Deployment: Pull Requests spin up isolated preview urls. Workflows are renamed with -pr-${PR_NUMBER} suffixes to prevent collisions.
• Teardown: Merging or closing a PR triggers cleanup_pr_preview.js, deactivating active webhook hooks in database memory before wiping cluster resources.
Deep-dive into the embedding dimension generation, pgvector similarity scoring, and dynamic ranking boosts.
When a query is submitted, the workflow generates a 1,536-dimension vector embedding array. It computes similarity by executing a cosine distance calculation against all indexed runbooks and tickets:
SELECT chunk_text, source, url, (1 - (embedding <=> '[query_embedding]'::vector)) * CASE WHEN source ILIKE '%[product_path_hint]%' THEN 1.35 ELSE 1.0 END AS score FROM kb_chunks ORDER BY (embedding <=> '[query_embedding]'::vector) LIMIT 12;
• Path Boost: If the ticket description refers to a specific product (e.g. Postgres Flex), the search query applies a 1.35x multiplier to all KB chunks originating from that directory path.
• Keyword Boost: If similar resolved tickets share matching keywords in their summary or resolution fields, they receive a flat +0.35 relevance score boost.
LLM is instructed to cite only retrieved evidence — no hallucination by design.
Every answer shows ticket keys, resolution dates, and KB article URLs inline.
Similarity score <70% → auto-escalate to L2. Score shown to agent for transparency.
Shows other open tickets with the same root cause — enabling proactive batch resolution.
Windows update KB5034441 resets the Winsock split-tunnel routing table, breaking VPN profiles that rely on static routes.
Related open: SSD-4798, SSD-4812 — same root cause.
A panel-by-panel breakdown of every active section in the Agent Dashboard — covering data retrieval, AI pipeline involvement, models, transformations, and orchestration logic as implemented in the live codebase.
The core intelligence panel. Fetches a Jira ticket by key and produces a full structured brief: STACKIT Product routing, missing info, troubleshooting steps, and a draft customer reply — all grounded in the vector knowledge base.
Webhook: /webhook/ai-ticket-brief
Data Retrieval: Fetches full Jira ticket via Bearer token REST API — summary, description, labels, resolution, priority, custom STACKIT fields (Org, Project, Product, Region), attachments, comments (up to 15, truncated to 1,500 chars each), and issue links.
Orchestration: Full RAG Pipeline. Pre-processor LLM extracts a precise real_problem_summary and STACKIT-specific keywords. These feed an e5-mistral-7b embedding to run dual pgvector HNSW searches: similar past tickets (score ≥ 0.65, top 5) and KB runbook chunks (score ≥ 0.70, top 3, 1,000 chars per excerpt).
AI Involvement: Two LLM calls — Stage 1: Llama 3.3 70B (pre-processor) extracts problem summary and search keywords as JSON. Stage 2: Llama 3.3 70B (main brief) generates the full structured JSON response (routing, troubleshooting, draft reply).
Transformations: n8n applies weighted multi-signal STACKIT Product routing (STACKIT Product 20% + semantic 80%). Programmatic missing-info is minimal (only empty description guard); LLM is sole authority. Resolved/closed tickets force empty missing_information and generate closure-style replies. Follow-up Chat 👇 enables iterative refinement post-analysis.
Drafts a professional, empathetic customer reply fully personalized with the ticket's STACKIT metadata, resolution status, attachment context, and the complete comment thread.
Webhook: /webhook/ai-reply-draft
Data Retrieval: Fetches Jira ticket via Bearer API. Extracts summary, description, resolution, priority, STACKIT metadata (Org, Project, Product, Region, Service Hours), attachments list, issue links, and comments (up to 15 recent, 1,500 chars/comment).
Orchestration: Direct n8n → STACKIT AI (Flowise not used). No vector search is performed. The full enriched ticket context is passed directly to the LLM in a single structured prompt.
AI Involvement: Llama 3.3 70B on STACKIT model serving. System prompt enforces 14 strict rules including: reference specific logs/error codes, no "we will investigate" placeholders, 150–400 word length, tone selectable (friendly/formal/empathetic), closure confirmation for resolved tickets, and personalized with Org/Project names from metadata. Temperature: 0.3, max_tokens: 1,024.
Transformations: Frontend renders the draft reply as plain text in an editable textarea. UI shows orange warning banner if ticket is already resolved. Agent can select tone, copy to clipboard, and add the reply as a Jira comment directly from the panel.
Generates a complete, structured Root Cause Analysis markdown document with incident summary, annotated timeline, deep technical root cause analysis, impact assessment, corrective actions, and specific preventive measures.
Webhook: /webhook/ai-rca-generate
Data Retrieval: Fetches Jira ticket via Bearer API. Extracts key, summary, type, priority, resolution, STACKIT metadata (Org, Project, Product team, Region), full description, attachment list, related issues/links, and full comment thread (15 comments × 1,500 chars).
Orchestration: Direct n8n → STACKIT AI (Flowise not used). Features an inline dashboard guard: if the ticket is unresolved and force=false, the backend returns an unresolved: true flag and the frontend shows an inline orange warning card — no browser popup. Agent can "Generate Anyway" to override.
AI Involvement: Llama 3.3 70B on STACKIT model serving. System prompt enforces 6-section RCA structure. Key rules: analyze log snippets technically (e.g. EXT4-fs shutdown vs platform failure), derive timeline from comment timestamps, provide 3–5 specific preventive measures referencing actual STACKIT components. Temperature: 0.2, max_tokens: 2,048.
Transformations: Frontend renders the markdown RCA via a live marked.js renderer into a rich preview pane. Agent can copy raw markdown, copy rich-text preview (for Jira/Confluence paste), or download as .md file.
Transforms an agent's raw shorthand notes, bullet points, or keywords into a professional, structured Jira ticket description — saving time during incident escalation.
Webhook: /webhook/ai-ticket-expand
Data Retrieval: Accepts freeform text input (shorthand notes), an optional service area group, and an optional priority level. No Jira API call required — pure text generation from raw input.
Orchestration: Direct n8n → STACKIT AI (Flowise not used). The simplest pipeline: one webhook → one LLM call → response delivered directly.
AI Involvement: Llama 3.3 70B on STACKIT model serving. System prompt instructs the model to expand shorthand into a professional structured markdown description with sections: Overview, Technical Details, Steps to Reproduce, Expected vs Actual Behavior. Output in English.
Transformations: Frontend renders the expanded description in a markdown preview pane. Agent can copy the output for direct pasting into a new Jira ticket.
An inline chat assistant embedded within the Ticket Analysis panel. Allows agents to ask follow-up questions, request a shorter reply, or refine the analysis after the initial brief is generated — without re-fetching Jira.
Webhook: /webhook/ai-chat-followup
Data Retrieval: Receives the agent's follow-up question text, the ticket key, and the full prior context (previous draft reply + routing analysis) serialized from the active panel state — no new Jira fetch needed.
Orchestration: Direct n8n → STACKIT AI (Flowise not used). Lightweight single-turn chat model call with injected panel context.
AI Involvement: Meta-Llama 3.1 8B FP8 on STACKIT model serving (lighter model for fast chat responses). System prompt: professional CE support chat, use prior context, handle German language shortcuts like "kürzer" (shorter). Temperature: 0.3, max_tokens: 1,024.
Transformations: Messages rendered as chat bubbles in the UI. Agent sees conversation history. Thumb up/down feedback per response is persisted separately via the Feedback webhook.
Validates a ticket key, retrieves the full ticket details and comments from Jira, and uses Llama-3.3-70B to generate a structured JSON summary document with timeline.
Webhook: /webhook/ai-ticket-summary
Data Retrieval: Fetches Jira ticket via Bearer API. Extracts key, summary, description, and full comment thread.
Orchestration: Direct n8n → STACKIT AI. No vector search is performed. Uses the ticket's structured contents to summarize the technical details and timeline chronologically.
AI Involvement: Llama 3.3 70B on STACKIT model serving. System prompt instructs the model to produce a strict JSON output with an incident summary, technical explanation, and a chronological table of events from comment timestamps. Temperature: 0.2, max_tokens: 1,536.
Transformations: Frontend renders the JSON timeline as a readable list/table for the agent to quickly catch up on days of comment history.
A lightweight thumbs up/down rating system built into the Ticket Analysis panel. Every helpfulness vote is persisted to PostgreSQL for ongoing quality monitoring and future fine-tuning.
Webhook: /webhook/ai-feedback
Data Retrieval: Receives ticket key, feedback direction (up/down), and ISO timestamp from the frontend. No LLM involved — pure data logging.
Orchestration: Pure n8n data pipeline (no AI). Webhook → PostgreSQL INSERT → respond OK. The simplest workflow in the system.
AI Involvement: None. This is a pure data persistence layer.
Transformations: Data stored in feedback_log(ticket_key, feedback_direction) table on the isolated STACKIT PostgreSQL Flex Instance. Designed for future LLM fine-tuning and weekly quality review workflows.
Converts PDF runbooks and documentation files into clean Markdown format, ready for chunking and ingestion into the KB vector store. Preserves document structure including headings, lists, and code blocks.
Trigger: Agent drag-and-drops or selects a .pdf file via the browser file picker in the dashboard.
Data Retrieval: PDF file is read client-side and sent as a base64 payload to the n8n KB PDF-to-MD workflow for server-side processing.
AI Involvement: Llama 3.3 70B on STACKIT model serving assists in cleaning and structuring extracted text. Adds STACKIT-standard frontmatter metadata fields (domain, product, category).
Output: Renders the converted Markdown in the preview pane. Agent can review, edit frontmatter, and trigger direct KB ingestion from the same panel — closing the loop from document to searchable knowledge.
Generalizes any raw input — resolved ticket data, shell scripts, runbook notes — into a clean, sovereign KB runbook article stripped of all customer PII before ingesting into the vector store.
Trigger: Agent pastes raw text (ticket resolution, script, manual notes) or selects source type from the tool panel.
Data Retrieval: Accepts freeform raw text. The n8n script-to-KB workflow processes it server-side through the full ingestion pipeline.
AI Involvement: Llama 3.3 70B on STACKIT model serving extracts the problem/resolution, generalizes it into a reusable runbook pattern, and scrubs all customer-specific data (IPs, server names, organization names, UUIDs). Adds structured frontmatter.
Transformations: Generalized runbook is chunked into 512-token segments with 50-token overlap → e5-mistral-7b embeddings → upserted into kb_chunks table on the isolated STACKIT PostgreSQL Flex Instance.
A live Markdown editor and previewer for KB runbook files. Parses YAML frontmatter automatically and offers AI-assisted metadata detection for empty fields — ensuring consistent KB article quality before ingestion.
Trigger: Agent pastes raw Markdown or uploads a .md file. Rendering is immediate and debounced (no submit needed).
Data Retrieval: Pure client-side parsing — no backend call required. YAML frontmatter is extracted and mapped to form fields (domain, product, category, language).
AI Involvement: When a metadata field is set to "AI decides", Llama 3.3 70B is called to predict the correct category, service domain, or product classification based on article content — preventing mislabeled KB articles.
Transformations: Live debounced markdown rendering with syntax highlighting for code blocks, heading hierarchy structuring, and sanitized HTML output. Agent can trigger KB ingestion directly from this panel once satisfied with the content.
Queries ownership, billing, membership, and folder structure details for multiple STACKIT project IDs at once using an ADM token.
Webhook: /webhook/project-info-proxy
Data Retrieval: Accepts project IDs input (comma-separated or file upload). Queries STACKIT Resource Manager API (metadata, billing, folder) and STACKIT Authorization API (members list).
Orchestration: Pure n8n workflow proxy (no AI/LLM). Executes a sequential parsing and mapping loop: ParseProjectRequest → GetProjectDetails → GetProjectMembers → FormatProjectResults → RespondProjectInfo.
AI Involvement: None. This is a pure API-driven metadata retrieval tool.
Transformations: Automatically filters duplicate project IDs to prevent redundant API queries. Formats results into a clean text brief listing Owner, Editors, Billing Reference, and Organization folder hierarchy (with direct folder fallbacks for unresolved resource names).
VECTOR(1536) — The database embedding schema size must match the exact output dimensions of the STACKIT embedding model serving. Probe the API before deploying the schema.
512-token chunks with 50-token overlap. Each chunk embedded and stored separately in the isolated STACKIT PostgreSQL Flex Instance. A 5,000-word incident as one vector loses critical detail.
Flowise requires runAsUser: 0. Agent Panel uses nginx-unprivileged (non-root). All services have dedicated namespaces with NetworkPolicy egress control.
Strict GDPR Compliance: All support tickets, vector search indices, and LLM text generation reside exclusively in the European Union (EU) on STACKIT sovereign cloud infrastructure. The isolated STACKIT PostgreSQL Flex Instance is encrypted at rest using local keys.
Store thumbs-up/down in a response_feedback table. Weekly review of negative ratings reveals knowledge gaps and triggers targeted re-ingestion.
Protect helpdesk + Flowise with STACKIT IdP OIDC via oauth2-proxy at Ingress layer. Two roles: admin (Flowise + Panel) and user (Panel only). Zero app changes needed.
Implemented daily Jira ingestion cron, historical DESC backfill, pgvector HNSW search, pre-processor LLM for precise keyword extraction, enriched Reply Drafter (15 comments, metadata, attachments, issue links), deep RCA prompt engineering with log analysis and specific preventive measures, and automatic resolved-ticket detection with orange UI warning banners.
• SSO via oauth2-proxy: Protect helpdesk + Flowise with STACKIT IdP OIDC at Ingress layer. Two roles: admin (Flowise + Panel) and user (Panel only).
• Jira Comment Integration: Post the drafted reply directly as a Jira comment from the panel — full ticket lifecycle in one tool.
• Ingestion Failure Alerts: Email/Google Chat notifications if the nightly Jira or KB cron fails.
• KB Duplicate Detection: Query vector store before KB creation and warn agents of near-duplicate articles.
Implement image OCR and vision model APIs for screenshot diagnostics. Extract attachments, system log files, and support Confluence workspace ingestion.
Please review these critical configurations required for the next phase of the STACKIT CE support engine rollout.
Define the list of runbooks, APIs, or Confluence documentation spaces to index into the STACKIT Git Knowledge Repo for automated nightly ingestion.
Confirm whether the minimum relevance scores (similar past tickets ≥ 0.35, KB matches ≥ 0.30) are appropriate, or if they should be raised to filter out more noise.
Determine if the default customer email reply draft should default to formal or friendly, and if there are specific signature parameters to enforce for the CE team.