In this blog post, we will go into some more detail about how the process works and what benefits this approach gives us when used with our CICS Transaction Server agents for Z.
Didn't know that CICS TS has AI agents? Click here to read a 60 second summary!
It is safe to say that generative AI has taken the world by storm. A more recent application of Generative AI is in agents, systems that can make decisions and attempt to get to a goal or provide an answer, often using tools along the way. With CICS TS 6.3, we introduced our Model Context Protocol (MCP) server, which acts as a standardised way of providing our agents with tools to access CICS data. In this blog post, we will go into some more detail about how the process works and what benefits this approach gives us.
SME Interviews
This whole process actually began with a relatively low-tech process: interviewing key members of the Hursley CICS lab to hoover up as much of the data in their minds about CICS as possible. This data would prove invaluable as we move towards use cases where documentation alone can struggle to provide LLMs with all the context required to generate a full, accurate answer. These interviews were just the beginning, and we are still doing them even as we GA our new agents. We believe giving our agents SME insights via this process is going to help our agents stand apart, as we know our middleware best - we build it after all!
Our three agents: CICS Topology, Problem Determination and Routing
When you select the IBM CICS Transaction Server agents for Z, you are actually talking to the first layer: our routing agent! This agent, native to the watsonx Orchestrate platform, takes requests and determines how to handle them. It has two collaborators, the CICS Topology and Problem Determination (PD) agents, and with prompting, understands when a request should be routed to one of them.
The topology agent is the simpler to understand, so we can start there; this agent takes a user request and first searches zRAG for relevant IBM documentation and SME data - we actually conducted interviews with members of the CICS department to provide the agent with an even richer dataset to pull from when answering questions. This data is then ranked, summarised, and used to prompt an LLM to provide a human-readable answer to the original query.
The Problem Determination agent is a little more complex. This agent is designed to help users identify the root cause of an error and implement a solution as quickly as possible. This agent understands DFHAC error messages in CICS, so in order to get the best response, provide the agent with the error code and transaction details - and it will do the rest! For example, when you say to it "I am getting DFHAC2016 on my transaction, TXN1" the agent starts by extracting key data from the query and the specific error code. It then finds the relevant IBM documentation for that error code, and simultaneously reaches out to CICS’ MCP Server to gather the tools available. It reads over these tools and selects the appropriate ones for the task at hand, and by running these, it gathers contextual data about the system. This data is then combined with zRAG Docs data, and all parsed into a prompt fine-tuned to answer the query in a very specific way, so you get answers that are easily digestible.
In the architecture of watsonx Assistant for Z, these two collaborators are actually running as external containers, running inside an Openshift cluster, and it can even all be running on-prem.
Wait… it talks to Z? Is this secure?
Yes! We didn’t want to reinvent the wheel. Z has long-standing authentication mechanisms in place, and reusing them made the most sense. When an admin makes a user a watsonx Assistant for Z account, they link an email address to them. This email is mapped using RACF to the User ID that person uses to sign into Z. When a user then asks a question to the CICS agents, we go through a process which ends with a single use pass ticket being generated.
This allows us to use the strong foundations built into the platform to keep security as a pillar of the product.
Why is MCP important?
Without data from CICS, it is impossible for us to make relevant and system-specific recommendations or observations. We can use documentation to give an idea of what could be the problem, but we cannot be sure. By adding an MCP server, we allow the LLM to make read-only tool requests to CICS, providing key contextual information about transaction and program data.
What about IBM Documentation?
A shared service is used among all the watsonx Assistant for Z agents. We call it zRAG (Retrieval Augmented Generation). It contains all of the IBM Documentation for Z products, and allows us to search using vectors, to gather chunks of official content. We then use that data in our answers, to provide a baseline understanding of Z - LLMs are trained on huge datasets, and we find that they can sometimes struggle with Z-based questions due to limited data on Z in those datasets.
Putting it altogether
By putting these three agents, zRAG, MCP, and watsonx Assistant together, we were able to build out a robust product, with scope for growth in the future. Each of these components has required out-of-the-box thinking, skilling up in entirely new subject areas for many of us, and a lot of thought, time, care, and attention to ensure we are building the right products for all of our Z customers.
What is planned for the future?
We are thrilled to have you on this journey with us. The fact that the mainframe, a technology that dates back all the way to the 1960s, is, with the new Spyre AI Accelerator cards, able to run the latest LLMs entirely on-premise is a monumental achievement, and we have ambitious plans for where we want to head next. We hope you’re as excited as we are!