How to create an Agent using VertexAI and call from Pega case using A2A

This article explains how to build a basic Vertex AI agent that provides city weather information and shows how to call it from a Pega case using A2A. The agent uses the ‘Google Search’ tool, offering an alternative way to integrate Google Search into your Pega flows.

Step1: Build External Agent

Prerequisites

1. In console.google.com, create Google Cloud Project. Make sure billing is enabled for this cloud project

2. Install Google CLI on your laptop. Follow instructions on below page. https://docs.cloud.google.com/sdk/docs/install-sdk. For initialising Google Console, please use the account and project details from Step 1.

3. Enable Vertex AI APIs using below command.

gcloud services enable cloudresourcemanager.googleapis.com \

    servicenetworking.googleapis.com \

    run.googleapis.com \

    cloudbuild.googleapis.com \

    artifactregistry.googleapis.com \

    aiplatform.googleapis.com \

compute.googleapis.com   

Create agent in VS Code

1. Create a virtual environment

python3 -m venv .venv

2. Activate virtual environment and install adk packages

source .venv/bin/activate    

pip install google-adk

3. Easy steps to create agent using Google’s Agent Development Kit can be followed here

https://adk.dev/get-started/python/#create-an-agent-project

4. Below are the instructions that you can follow to create an agent hosted on Google Cloud to fetch weather of a given city.

adk create simple_weather_agent

5. Above command creates the folder structure and the python files needed for this agent e.g. init, agent

6. Navigate to ‘Agent Designer’ on google console to create the code for the weather agent.

7. Create an agent and click on ‘Get Code’ to view the code for this agent.

8. Copy the python code and paste it in the agent.py file in the VS code project.

Test your agent

1. Run below command to test your code. (Note: Make sure you in a parent folder of the agent folder)

adk web

2. A localhost link will be crated for this agent as seen in below screenshot

3. Click/Open this link browser to test your agent and you can chat with this agent and test if it is working.

Make this agent A2A Compatible

1. Create agent skill as show below for this agent. You could also use github copilot/vibe coding to add the agent skill. However, adk libraries are changing frequently hence some of the vibe coding tools may not give you the latest code that can run on vertex AI, hence refer to the Google documentation here. https://docs.cloud.google.com/agent-builder/agent-engine/quickstart-adk

# A2A Agent Skill definition

skill = AgentSkill(

    id='get_weather_info',

    name='Weather Information Tool',

    description='Helps with fetching weather information for a given location',

    tags=['weather', 'forecast', 'temperature'],

    examples=['What is the weather in New York?'],

)

2. Create agent card referring to agent skill here

# A2A Agent Card definition

agent_card = AgentCard(

    name='Weather Agent',

    description='Helps with fetching weather information for a given location',

    url=SERVICE_URL,  # Replace with your service URL

    version='1.0.0',

    default_input_modes=["text"],

    default_output_modes=["text"],

    capabilities=AgentCapabilities(streaming=True),

    skills=[skill],

)

3. Add below line to agent.py

# Make the agent A2A-compatible

a2a_app = to_a2a(root_agent, agent_card=agent_card)

4. You will also need to install ADK a2a packages

pip install a2a-sdk

5. Also, you need to add Dockerfile and _main_.py file to the folder structure to deploy this agent on CloudRun. Refer to this github project for dockerfile sample

https://github.com/google/adk-python/blob/main/tests/remote/triggers/test_agent/Dockerfile

6. Create requirements.txt file for the project by following below command. (Note: you could also use uv instead of pip)

pip freeze > requirements.txt

Deploy to CloudRun

1. Sample command to deploy this agent to the CloudRun is as below. (Please note we are creating a simple agent without any authentication. Please do not use unauthenticated agents in Production. I will be sharing another article to add security to the agents. Google agents need ID tokens as opposed to Access Tokens hence you need to create a service account and keystore to create JWT bearer tokens)

gcloud run deploy weather-agent \              

    --port=8080 \

    --source=. \

    --allow-unauthenticated \

    --clear-base-image \

    --memory "1Gi" \

    --region="us-central1" \

    --project= <your_project_name> \

    --set-env-vars=GOOGLE_GENAI_USE_VERTEXAI=true,\

GOOGLE_CLOUD_PROJECT="your_project_name ",\

GOOGLE_CLOUD_LOCATION="us-central1",\

APP_URL="TEMPORARY_URL"

2. Above command gives the APP URL in this format

https://weather-agent-xxxxxxxxxxxx.us-central1.run.app

Run below commands to update the APP_URL and the SERVICE_URL

3. Run below commands to update the APP_URL and the SERVICE_URL

gcloud run services update weather-agent \
  --project="<your_project_name>" \
  --region="us-central1" \
  --update-env-vars=APP_URL="https://weather-agent-xxxxxxxxxxxx.us-central1.run.app"


gcloud run services update weather-agent \
  --project="<your_project_name>" \
  --region="us-central1" \
  --update-env-vars=SERVICE_URL="https://weather-agent-xxxxxxxxxxxx.us-central1.run.app" 



4. You could access agent card using below URL

https://weather-agent-xxxxxxxxxxxx.us-central1.run.app/.well-known/agent-card.json


5. Below is the json format for the agent card that can be viewed in the browser.

Step 2: Call this agent from Pega Case

1. Add a Step ‘CheckWeather’ to the Case as we can see in below screenshot

2. You could specify instructions as shown here

3. In external Tools tab for this agent add the Google Agent instance

4. Create GoogleWeatherReportAgent with details as shown here

Test Workflow

1. Run the workflow locally and enter the Location of your travel

2. View the weather forecast

3 Likes

Great info, this is awesome!

1 Like

Very well written. Will surely give it a try.

Regards

JC

Good to see this implementation. Thanks for sharing Kajal. I am interested to know if you used 2 auth profiles? one for agent card and other for external agent execution?

Hi Murali, for this particular example I did not have to create any auth profiles as I deployed this agent with ‘–allow-unauthenticated’ option. However, if you want to add security, you need to create a service account on google and deploy this agent with below option -

–no-allow-unauthenticated \

–service-account <your_service_account_name> \

Also, you just need one profile for both - agent card and the execution of the agent.

Another issue is - VertexAI agents need ID tokens and Pega’s OOTB OAuth rule only creates Access Tokens. Hence you need a custom java code to create ID Token from Service Account Key file (json) that can be passed to the external agent. Hope this makes sense.

1 Like

Yea makes sense. Either Pega needs to support ID tokens or Vertex Agents needs to support Access tokens. Thanks for sharing.

Thank you for putting together such a detailed walkthrough and for sharing a concrete example of integrating an external Vertex AI agent with Pega using A2A.

Articles like this are valuable because they help practitioners understand how agent to agent orchestration works beyond theory.

From a Predictable and Enterprise ready AI perspective, the key point to emphasize is the separation of concerns you are demonstrating: the external agent focuses on a narrow capability, while Pega remains the system of record and orchestration layer that governs when and how that capability is invoked.

It is also important that you call out authentication, token handling, and the fact that unauthenticated deployments are not appropriate for production use.

That reinforces the message that integration success is not just about making the call work, but about doing so in a way that is secure, auditable, and supportable over time.

I would encourage others who have implemented similar external agent integrations to share what additional controls or patterns they applied when moving from a demo setup to a production environment, especially around identity, observability, and failure handling?

1 Like

Really cool @kaspk, to not only know that this is possible, but to see practical steps on making this work. Thanks!