Red Hat AI quickstarts are ready-to-run industry-specific use cases for your Red Hat AI environment. Each quickstart is designed to be simple to deploy, explore, and extend. They give you and your team a fast, hands-on way to see how AI can power solutions on enterprise-ready, open source infrastructure. You can read more about AI quickstarts in AI quickstarts: An easy and practical way to get started with Red Hat AI.
Many businesses rely on ticket management systems to track support requests, meet a service level agreement (SLA), and build a history of common issues and resolutions. However, support teams still spend significant time triaging requests, gathering missing information, answering repetitive questions, and resolving common issues manually. This increases the cost of handling each ticket and limits the time available to focus on more complex work. AI can help reduce some of that effort, but rather than introducing a separate AI chatbot that sits outside the existing support process, you can integrate AI directly into your organization's ticketing workflows, where it can assist users and IT teams throughout the lifecycle of a request.
The speeding-up-ticket-resolution quickstart demonstrates this approach using Red Hat OpenShift AI. Built on OpenShift, Red Hat OpenShift AI provides the capabilities needed to develop, deploy, observe, and operate AI applications on a trusted enterprise Kubernetes platform. These include model serving with high-performance inference servers such as vLLM, agents and MCP servers, as well as evaluation, tracing, guardrails, observability, and more.
The speeding-up-ticket-resolution quickstart
The speeding-up-ticket-resolution quickstart puts those capabilities into practice through an agentic ticket management system. It shows how AI agents can work with an existing enterprise application, use knowledge bases and tools, maintain conversation state, and safely resolve or escalate requests. It also demonstrates how evaluation, tracing, and session-level observability can help you understand agent behavior, follow requests across components, and investigate multi-turn conversations.
By bringing these capabilities directly into the ticketing workflow, agentic AI can reduce manual effort, accelerate resolution, and provide more consistent support. The benefits extend across requesters, IT teams, and the business. Benefits include:
For customers or employees submitting requests
- Faster, higher-quality submissions: The agent helps end-users understand available options and required fields before they submit, reducing back-and-forth and eliminating rejections caused by missing or incorrect information.
- Continuous availability: End-users receive immediate responses and progress updates outside business hours, without degrading service levels.
For IT teams resolving requests
- Reduced first-touch effort: The agent handles triage, categorization, and routing automatically, and can gather missing information from the requester before a human ever opens the ticket.
- Shorter time to close: Common requests can be resolved end-to-end by the agent without human handoff.
For the business
- Consistent answers: Agents apply the same policies and knowledge base every time, eliminating variability caused by human error or knowledge gaps.
- Cost savings: Automating high-volume, repetitive requests reduces the staff time required to close tickets, lowering overall support costs.
- Reduced ticket backlog: Faster resolution times mean fewer tickets accumulate, keeping the backlog manageable and SLAs on track.
- Improved customer satisfaction: Consistent, timely resolutions build confidence in the IT function and improve the overall service experience.
Realizing these benefits requires the underlying agentic system to be integrated reliably into existing enterprise workflows. The speeding-up-ticket-resolution quickstart provides a working implementation that brings together ticket routing, specialist agents, knowledge bases, enterprise integrations, conversation state, evaluation, guardrails, tracing, and observability.
The following sections walk through how the quickstart is structured, how a ticket moves through the system, and how you can deploy and explore it yourself.
Architecture overview
This quickstart provides a reusable framework for implementing an agentic ticket management system. It includes request routing, agent services, knowledge bases, an integration dispatcher and an evaluation framework that you can apply across multiple IT processes. While the quickstart implements a laptop specialist agent and a general knowledge base agent as a concrete working example, the same components can be adapted to cover other structured IT workflows, providing a proven starting point for understanding the patterns and adapting them to the processes most critical to your organization.
It builds on the existing it-self-service-agent quickstart, extending the existing architecture by integrating the Zammad ticketing system and new AI agents that can interact with users and manage requests directly (Figure 1).
The core components of the quickstart include:
Ticket system
This quickstart uses Zammad, an open source ticket management platform. End-users submit requests by creating tickets in Zammad, and interact with agents through ticket comments. Ticket creation, comments, and status changes drive interactions with the request manager. The underlying framework also supports other channels, including Slack, email, the command line, and a website or chatbot.
Request manager
The request manager is the central entry point for every request, regardless of which channel it arrived through. It normalizes incoming requests into a common internal format, retrieves any existing conversation state, and hands the request off to the router agent. It also routes agent responses back to Zammad.
Router agent
The router agent performs triage on each incoming request, determining which specialist agent is best suited to handle it. For example, it can distinguish between a laptop refresh request and a general IT question, then route the request to the appropriate specialist. This keeps each specialist agent focused on a specific type of request and makes it easier to add support for new request types by introducing additional specialist agents rather than expanding a single monolithic agent.
Agent
Each specialist agent (the laptop refresh agent and general support agent) owns the conversation with the user once it's been routed to it. Built as a LangGraph state machine, each agent is responsible for understanding what the user needs, deciding when to consult a knowledge base or call a tool, and driving the conversation to a resolution. Depending on the request, this may mean closing the ticket, escalating it, or handing it off for approval.
Prompt
The prompt defines an agent's instructions, persona, and conversational logic. The quickstart demonstrates 2 approaches: A single, comprehensive prompt that gives a capable model the information and instructions it needs in one step, and a multi-step prompt built with LangGraph that breaks the conversation into smaller, more constrained steps. The latter approach can make complex workflows more reliable when using smaller models.
Model
The model is the LLM that provides the reasoning and language capabilities for an agent. It interprets user requests, decides which tools to invoke, whether to retrieve information from a knowledge base, and generates responses. The quickstart has been tested with Llama 4 Scout 17B and Llama 3 70B, with different prompt strategies recommended depending on which model you use.
Knowledge base
Each agent can be backed by a retrieval augmented generation (RAG) based knowledge base containing policy documents and process guidelines, such as laptop refresh policies and regional laptop offerings, or general IT support articles. The agent queries the knowledge base to align its answers with your organization's authoritative policies and procedures, rather than relying solely on the model's general knowledge.
Tools
Tools are model context protocol (MCP) actions that enable an agent to interact with external systems. Examples include looking up a user's current laptop details, closing a ticket, escalating a ticket to a human-managed group, assigning a ticket to a manager for approval, or applying labels for ticket reporting. Exposing actions as MCP tools enables agents to interact with external systems through a standard interface rather than embedding system-specific API logic directly in the agent.
Long-term memory/session memory
This component persists conversation state across turns and requests, allowing a user to leave a conversation and resume it later or continue the conversation through a different message on the same ticket without losing context. This enables a single ticket to support an extended, multi-turn conversation rather than treating every message as a one-off request.
Here's what the end to end process looks like for a single submitted ticket:
- A user creates a ticket in Zammad.
- The user's ticket comments are routed to the request manager, which normalizes the request and retrieves any existing conversation state.
- The request manager routes the request to the router agent.
- The router agent determines whether the ticket is a laptop refresh or a general question and hands the session to the appropriate specialist agent.
- The specialist agent processes the request, consulting the knowledge base and calling tools as needed. The request manager then routes the response back to the ticket.
- The conversation continues across multiple turns in the same ticket until the request is resolved (Figure 2).
- The ticket ends when the agent closes it, escalates it to a human-managed group, or assigns it to another user, such as the requester's manager, for approval.
The quickstart also provides useful operational visibility, making it easier to understand how tickets are being handled and where human intervention is still required. The application tags every ticket an agent touches with labels such as agent-managed-laptop-refresh
, escalated-human-review
, pending-manager-review
, and closed-by-ai-agent
, then surfaces those labels as overviews inside Zammad so you can see at a glance how many tickets were closed automatically, escalated to a human, or routed to a manager for approval.
Deploying the quickstart
To deploy the quickstart, you need:
- Red Hat OpenShift 4.17 cluster
- Red Hat OpenShift AI 3.4
- External Model: Llama-4-Scout-17B-16E
- External Model to run evaluations (optional): Meta-Llama-3-70B
Read the full setup guide for instructions.
What the quickstart covers
The quickstart takes you through:
- Deploying the agentic system to Red Hat OpenShift AI.
- Interacting with the general agent through the Zammad ticketing system UI to see how general IT questions are handled, with tickets either being escalated or closed by the agent.
- Interacting with the laptop refresh specialist through the Zammad ticketing system UI to see how the agent gathers required information, verifies the requested laptop against available options, and either resolves the request or escalates it to the employee's manager for approval.
- Reviewing the statistics to see how many tickets were closed, escalated, or sent to a manager for approval.
- Running multi-turn evaluations using the open source DeepEval framework to validate business requirements such as policy compliance and catch regressions.
- Setting up NeMo Guardrails with TrustyAI in OpenShift AI.
- Using OpenTelemetry to review traces and understand the flow within the deployed system.
- Exploring session-level observability using the OpenShift AI MLflow integration to be able to dig into the specific multi-turn conversations that your users had with the general and laptop specialist agents.
Building production-ready AI agents is deceptively complex. Beyond the large language model (LLM) integration, you need conversation state management across multiple turns, robust evaluation frameworks for non-deterministic systems, reliable enterprise integrations, distributed tracing across asynchronous components, and safety guardrails—all while keeping infrastructure costs reasonable. This orchestration layer can take weeks to build before you write your first line of business logic. This quickstart provides these foundational capabilities out of the box, giving you a working architecture that you can explore, extend, and adapt to your own ticket management processes.
Evaluations get their own dedicated step because agentic systems are difficult to validate with traditional testing approaches. Generative AI agents are non-deterministic, meaning the same input can produce different, equally valid responses across conversations. Manual testing and simple assertions are therefore not enough to catch regressions when you change a prompt or swap a model. The evaluation framework addresses this by combining predefined conversation flows with AI-generated scenarios and scoring them against business-specific metrics, such as whether the agent closes or escalates a ticket at the appropriate time.
Observability presents a similar challenge. With a routing agent, specialist agents, knowledge bases, and MCP servers all interacting on a single request, it can be difficult to understand what happened and where problems occurred without distributed tracing. The quickstart's OpenTelemetry integration traces each request end-to-end across these components. MLflow, which is fully integrated and supported in OpenShift AI, builds on this by grouping traces by session so you can follow and investigate multi-turn conversations.
Each step in the quickstart is meant to help you quickly deploy and explore that topic. If you want to dig deeper into the technical details behind the quickstart's components, the following blog posts cover them in more depth, in the context of the it-self-service-agent quickstart on which the speeding up ticket resolution quickstart was built.
- Part 2: AI meets you where you are: Slack, email & ServiceNow
- Part 3: Prompt engineering: Big vs. small prompts for AI agents
- Part 4: Automate AI agents with the Responses API in Llama Stack
- Part 5: Eval-driven development: Build and evaluate reliable AI agents
- Part 6: Distributed tracing for agentic workflows with OpenTelemetry
- Part 7: 3 lessons for building reliable ServiceNow AI integrations
- Part 8: Guardrails: Enterprise safety shields with Llama Stack
- Part 9: Deploy with confidence: Continuous integration and continuous delivery for agentic AI
To learn more
If this blog post has sparked your interest in the speeding up ticket resolution quickstart, here are additional resources:
Explore more quickstarts
Browse the AI Quickstarts catalog for other production-ready use cases including fraud detection, document processing and customer service automation.
Related quickstarts
- it-self-service-agent — the reusable core components (agent service, request manager, evaluation framework) that this quickstart extends
- lls-observability — observability quickstart with OpenTelemetry and Tempo
- ai-architecture-charts — Helm charts for deploying LLM services on OpenShift AI
Learn more about the tech stack
- Zammad ticketing system
- Model Context Protocol (MCP) specification
- LangGraph — state machine framework for agents
- DeepEval — LLM evaluation framework
- MLflow — AI engineering platform
- OpenTelemetry
- OGX — agentic API server
- Red Hat OpenShift AI documentation
- TrustyAI / NeMo Guardrails
Next steps
Try it yourself: Run through the quickstart (60-90 minutes) to deploy a working multi-agent system.
Time savings: Rather than spending 2-3 weeks building agent orchestration, evaluation frameworks and enterprise integrations from scratch, you'll have a working system in under 90 minutes. Start in testing mode (simplified setup, mock eventing) to explore quickly, then switch to production mode (Knative Eventing + Kafka) when ready to scale.
What you'll learn: Production patterns for AI agent systems that apply beyond IT automation—how to test non-deterministic systems, implement distributed tracing for async AI workflows, integrate LLMs with enterprise systems safely and design for scale. These patterns transfer to any agentic AI project.
Customization path: The laptop refresh agent is just one example. The same framework supports Privacy Impact Assessments, RFP generation, access requests, software licensing, or your own custom IT processes. Swap the specialist agent, add your own MCP servers, customize the knowledge base, and define your own evaluation metrics.
Questions or issues? Open a discussion on the GitHub repository or file an issue.