Configuring Agent integration and Agent Step

A single Agent might not have all the knowledge or capabilities required to complete a business objective. A Pega Agent might need to delegate part of its work to a specialized external agent. An external agent might also need to invoke a governed Agent that is implemented in Pega. 

The A2A protocol provides a common communication model through which Agents can: 

• Discover one another by using Agent cards 
• Identify the capabilities and endpoints that another Agent exposes 
• Delegate goal-oriented tasks 
• Exchange context and results 
• Collaborate without exposing internal implementation logic 

Pega Platform 26 supports A2A protocol version 0.3.0. 

The Agent Rule includes settings for exposing a Pega Agent to external A2A-compatible Agents. 

External access 

The Enable external access option determines whether external agents can communicate with the Pega Agent. This option is disabled by default. 

When you enable external access, the Agent Rule displays an Agent card URL that you can copy and provide to the external agent. The URL enables the external agent to retrieve the Pega Agent card and obtain the information required to communicate with the Pega Agent. 

Agent card URLs typically end with the following path: .well-known/agent-card.json 

Agent version 

After you enable external access, you can optionally enter an Agent version. This value communicates the version of the Agent implementation to external systems.  

As a best practice, update the Agent version whenever the Agent implementation changes to include new skills or features. This update communicates the implementation change and helps maintain compatibility between the Agent and external systems. 

Types of versioning 

A2A integration involves two distinct types of versioning. 

A2A protocol version 

The A2A protocol version identifies the version of the A2A technical specification that the platform supports. Pega Platform 26 supports A2A protocol version 0.3.0. 

The protocol version identifies the A2A specification used for communication between participating Agents. 

Agent implementation version 

The Agent implementation version is the value in the version field of the Pega Agent Rule. It communicates a change in the Pega Agent implementation to external systems. 

For example: 

• A2A protocol version: 0.3.0 
• Agent implementation version: 2.1.0 

In this example, the Agent communicates by using version 0.3.0 of the A2A specification. Version 2.1.0 identifies the business-facing implementation of the Agent.

A Pega Agent Rule resides in an application Ruleset and Ruleset version. However, the Agent implementation version serves a different purpose: 

• The Ruleset version supports rule storage, resolution, packaging, and application deployment. 
• The Agent implementation version communicates the externally visible implementation version to A2A consumers. 
• The A2A protocol version identifies the communication specification that the platform supports. 

You maintain the Ruleset version and Agent version separately. Update the Agent version field to communicate  Agent implementation changes  to external systems. 

An Agent card provides the information required to discover an Agent and invoke the features that the Agent exposes. 

An Agent card separates the Agent’s public contract from its internal implementation. An external agent needs information about what the Pega Agent can do and how to communicate with it. The Agent card exposes the information required for A2A interaction without requiring the configuration of the external agent with the internal Pega implementation. 

This separation supports interoperability while preserving implementation boundaries. 

Update the Agent version when you introduce new skills or features to communicate the implementation change and maintain compatibility with external systems. The version format is organization-defined because Pega Platform does not prescribe a specific versioning convention.

Authentication Profiles store the information that a Pega Agent needs to access and invoke an external agent. A Connect Agent Rule can use separate Authentication Profiles to retrieve the Agent card and invoke the external agent’s capabilities. 

Use Application Settings when Agent card URLs or Authentication Profiles differ between development, testing, staging, and production environments. Application Settings prevent you from embedding environment-specific endpoints or credentials directly in the rule. 

Consider authentication separately for the following operations: 

• Discovery: Permission to retrieve the external agent card. 
• Execution: Permission to invoke the external agent’s capabilities. 
• Inbound access: Permission for an external agent to invoke the Pega Agent. 
• Environment promotion: Mapping the appropriate endpoints and credentials in each environment.  

Pega Agentic Process Fabric™ uses A2A to orchestrate collaboration with registered Agents across the enterprise. The Intelligent Registry supports the registration and discovery of Agents and workflows across connected Pega applications. The Fabric Control Agent identifies an appropriate Agent and delegates work to that Agent. 

The following components support this model: 

• Agent Rule: Defines the Pega Agent’s objective, behavior, tools, external accessibility, and implementation version. 
• Connect Agent Rule: Defines how a Pega Agent connects to and invokes a specific external Agent.
• A2A protocol: Supports communication and task delegation between Agents.
• Intelligent Registry: Provides visibility into available Agents and workflows across connected Pega applications. 
• Fabric Control Agent: Selects an appropriate registered Agent and delegates work through A2A. 
• Pega Agentic Process Fabric: Provides orchestration, governance, traceability, and operational visibility. 

Pega Agentic Process Fabric uses A2A and Model Context Protocol (MCP) as complementary standards. A2A supports Agent-to-Agent collaboration. MCP provides controlled access to tools, data, APIs, and enterprise functions.

An Agent Step is an automated Case Lifecycle step that invokes a configured Agent to perform agentic work at a defined point in Case processing. When the Case reaches the step, the Agent uses the supplied instructions, relevant Case context, and permitted tools to reason and produce an output that supports continued Case processing. 

Use an Agent Step for work that requires contextual reasoning or the dynamic selection of permitted actions. Use deterministic automation for fixed, predictable tasks.  

Agent Steps support the following types of work: 

• Summarizing Case information or submitted documents 
• Identifying gaps, discrepancies, or risk indicators 
• Comparing Case details with policies or business criteria 
• Retrieving supporting information from approved sources 
• Preparing recommendations, assessments, or draft responses 
• Delegating specialized work to another configured Agent 
• Writing structured results to the Case for human review 

Use an Agent Step when intelligent analysis must occur at a predictable point in a business process instead of through an open-ended user conversation. 

A published Agent Step example performs an audit assessment by examining findings, document summaries, audit objectives, and internal rules. The Agent then obtains remediation suggestions from an external agent

When a Case reaches an Agent Step, the configured Agent receives the input message and relevant Case context. The Agent applies its instructions and guardrails and uses permitted knowledge sources and tools to complete the objective. 

The application stores the response in the configured Case field. The Case then continues through its defined processing, review, decision, or exception path.

An Agent Step runs a configured Pega Agent, which can delegate work to an external Agent when required. The appropriate option depends on where you govern the capability , which context and tools it requires, and how the workflow uses the result. 

Pega Agent 

The Pega application defines and governs a Pega Agent. Its configuration controls the information that the Agent can access and the actions that it can perform through referenced Tool Rules. 

Use a Pega Agent in the following situations: 

• The Pega application owns the Agent. 
• The Agent requires Pega Case context or Pega-defined tools. 
• The application must govern the Agent instructions, knowledge sources, and actions. 
• The Agent must retrieve Data Page information, perform an automated action, run an eligible User Action, start a Case, or invoke another Agent.  

External Agent 

An external agent runs outside a Pega application and provides specialized functionality during Case processing. When the Case reaches an Agent Step, the configured Pega Agent determines whether it requires the external functionality and delegates the work through A2A  integration. The Pega Agent uses the returned result to continue processing the Agent Step. 

Use an external agent in the following situations: 

• An enterprise or third-party Agent platform provides the required functionality. 
• Specialized reasoning or domain expertise is available outside the Pega application. 
• The external agent participates in a controlled Pega Case workflow. 
• The workflow reviews, stores, or uses the result to guide subsequent Case processing. 

In the external-Agent pattern, the runtime path is: 

Case Flow → Agent Step → Pega Agent → A2A → external agent → Pega Agent → Case Flow 

This pattern introduces an external trust boundary. Share only the Case context that the external agent requires, and explicitly govern authentication, authorization, returned results, and integration failures. 

An Agent Step and a Model Context Protocol (MCP) Step represent different processing patterns: 

Agent Step: Invokes an Agent to reason about an objective, context, knowledge, and permitted capabilities. 

MCP Connect Step: Directly invokes a capability exposed through the Model Context Protocol when the workflow requires a deterministic tool-level interaction. 

Use an Agent Step when the work requires interpretation, semantic analysis, planning, or selection among permitted tools. 

Use a MCP Connect Step when the workflow already identifies the external capability to invoke and does not require an Agent to determine how to complete the objective. 
 
For more information on configuring Agent step, see Adding an Agent to a workflow

Check your knowledge with the following interaction: