Dynamic Connect Gen AI Rule Configuration

This article shares a Proof of Concept (PoC) and some practical experience with Pega GenAI capabilities. Initially, I planned to share only a summarization use case, but I decided to enhance the solution and present a more flexible framework that can be used for a variety of GenAI scenarios.

The PoC demonstrates how a Pega case type can invoke a Large Language Model (LLM) using a Connect GenAI rule. We applied a similar approach in one of our projects to summarize information from existing and previously completed cases.

Important Disclaimer:
This solution is not production-ready. It is intended as a starting point for experimentation, learning, and building your own GenAI use cases.


Solution Overview

The PoC consists of a dedicated case type responsible for orchestrating GenAI interactions and storing execution details.

Key Advantages

:white_check_mark: Generated with Pega Blueprint

The initial application was generated using Pega Blueprint, allowing rapid development and experimentation.

:white_check_mark: Independent Architecture

The solution is designed to be independent of a specific source system.

  • It can be triggered from both Pega and non-Pega applications.
  • It maintains its own data model for storing request and response information.
  • The architecture can be adapted to integrate with multiple source systems.

:white_check_mark: Auditable and Extensible

The solution can be configured to capture and persist a variety of execution details, including:

  • User prompts
  • System prompts
  • Model information
  • Generated responses
  • LLM usage statistics
  • Token consumption
  • Execution timestamps
  • Additional audit information

This provides a strong foundation for governance, monitoring, and future enhancements.

Case Type Overview

Document Operations stage does not related for this artice. Ignore it.

Prompt Management

The PoC currently stores prompts in a dedicated Pega data object. However, the architecture is flexible and supports alternative approaches:

  • External data sources
  • Configuration files
  • User-provided prompts
  • System-generated prompts
  • Dynamic prompt composition during case processing

This enables teams to adapt prompt management to their specific governance and operational requirements.

Prompt Configuration

Data Object

Connect Gen AI Rule Configuration :

System Prompt :

User Prompt

Data Model

The initial data model was generated using Pega Blueprint and then extended to support the requirements of this PoC.

The model stores:

  • Request information
  • Prompt configuration
  • LLM execution details
  • Response data

This provides a reusable foundation for building GenAI-powered applications within Pega.

LLM Statistics and Monitoring

The solution captures execution information returned by the Connect GenAI rule.

This implementation was inspired by an approach described in another article, which allows organizations to gather valuable operational insights such as:

  • Model used
  • Token consumption
  • Request metrics
  • Response metrics
  • Execution details

Additional details can be found in the related post: GenAI Activity Logging

Execution :

Create a case with context :

Result :

Execution Details :

Same context with summary prompt :

JSON Output prompt :

1 Like

Hi, thanks for sharing practical and well-structured approach on how to wrap genai connect rule with case type for better auditing and governance.

I have one question, how does. the word counting works with GenAI, I believe this is task better suited for deterministic code rather than for LLM.

1 Like

Yes agreed. example is only for demostrating different type of prompts like word count is an html format, but other is JSON. We should not trust LLM for any kind of calculation like you said.

1 Like