A Field Journal on AI Agents in the SAP Stack
Agents with SAP
Issue 001 · N° 002 · PrimerJAN 01, 2026 · 5 min

A first agent on Vertex AI, talking to SAP over A2A

An introduction to Google Cloud's Vertex AI Agent Builder and the open Agent-to-Agent protocol, framed around the simplest useful task: asking for the status of a purchase order.

Google CloudVertex AIA2AAgentsSAP

Picture the most boring question a procurement manager asks all day: "What's the status of PO 4500001234?" It's the kind of question that should never reach a human. The data is structured, the answer is one row in a table, and the asker doesn't care which system holds it. They just want a number and a date.

This dispatch walks through how that question gets answered when the asker lives in Google Workspace, the answer lives in SAP, and neither system was built to know the other exists. The bridge is a pair of agents, a managed runtime called Vertex AI Agent Builder, and an open protocol called A2A.

Why this is harder than it looks

The classic answer is a point-to-point integration: a Cloud Function with hard-coded SAP credentials, an OData call, a Slack bot wrapper. It works, but every new question — "who is the vendor on that PO?", "what's our spend with them this year?" — produces another bespoke endpoint. After eighteen months you have a graveyard of half-maintained glue.

The agent version of the same problem is more interesting. You don't write an endpoint per question. You expose capabilities, and let the model on the other side figure out which to call. But that only scales if the agents can discover and address each other without a human wiring them together each time. That's the gap A2A is meant to close.

What Vertex AI Agent Builder gives you

Strip away the marketing and Agent Builder is three things stitched together:

  1. A Gemini-powered runtime that hosts your agent and handles the LLM loop.
  2. A tool registry where your agent's capabilities are declared — typed inputs, typed outputs, the same idea as Anthropic's tool use.
  3. An A2A endpoint that's mounted automatically, so any A2A-compatible client can call your agent without knowing it lives on Google Cloud.

That last point is the one most people miss. You don't bolt A2A on; the runtime speaks it natively. You write the agent, deploy it, and a well-known URL like https://your-agent.run.app/.well-known/agent.json starts answering.

The A2A protocol, in one minute

A2A is HTTP plus a small contract. Two pieces matter for an introduction:

  • An AgentCard is a JSON document published at /.well-known/agent.json. It says who the agent is, what it can do, where to send tasks, and how to authenticate.
  • A Task is a unit of work. The caller POSTs a task with a user message; the callee streams back messages and, when finished, an artifact (a structured result, a file, whatever).

Here's the AgentCard for our SAP-side agent, trimmed for clarity:

{
  "name": "sap-procurement-agent",
  "description": "Answers questions about purchase orders, vendors, and goods receipts in S/4HANA.",
  "url": "https://sap-procurement.run.app/a2a",
  "version": "0.2.0",
  "capabilities": { "streaming": true },
  "skills": [
    {
      "id": "lookup_purchase_order",
      "description": "Returns the header status, vendor, and delivery progress of a purchase order by number.",
      "inputModes": ["text"],
      "outputModes": ["text", "data"]
    }
  ],
  "authentication": { "schemes": ["bearer"] }
}

A few things to notice. The skills aren't tool definitions in the LLM sense — they're a menu for other agents. The Vertex side doesn't need to know how OData works, or which entity set holds delivery progress. It just needs to know that something downstream can answer "lookup_purchase_order" given a number.

The flow, end to end

The procurement manager types into a Workspace chat: "What's the status of PO 4500001234?" The Vertex agent, which has been told about the SAP agent's URL at deploy time, does roughly this:

  1. Fetches the SAP agent's AgentCard (cached after the first call).
  2. Sees a lookup_purchase_order skill that matches the intent.
  3. POSTs a task to the SAP agent's A2A endpoint with the PO number as the message.
  4. Waits for the artifact: { status: "Partially delivered", deliveredPct: 80, vendor: "Contoso GmbH" }.
  5. Renders it back to the user as a sentence.

The Python on the calling side is almost embarrassingly small, because the SDK does the protocol dance for you:

from google.cloud.aiplatform.agents import A2AClient
 
sap = A2AClient.from_card("https://sap-procurement.run.app/.well-known/agent.json")
 
artifact = sap.run_task(
    skill="lookup_purchase_order",
    message="4500001234",
)
 
print(artifact["status"], artifact["deliveredPct"])

The SAP agent on the other side is the same pattern we covered last issue — a thin OData client, a tightly scoped tool, an allowlist the model can't edit. A2A doesn't change how that agent is built. It just gives it a public-facing front door that any other A2A speaker can knock on.

What this actually unlocks

Three things, in order of how much they matter:

  • Vendor neutrality. The Vertex side could be swapped for an Anthropic-hosted agent, a Bedrock agent, or a homegrown one. As long as it speaks A2A, the SAP agent doesn't notice the difference.
  • Capability composition. Add a calendar agent, an email agent, a CRM agent — each with its own AgentCard. A planner agent can discover and chain them without you writing an N-by-N integration matrix.
  • Auditability. Tasks and artifacts are addressable, persistable units of work. "Why did the system place this order?" becomes a question with an answer in a log, not a question that requires re-running an LLM with the same prompt and hoping.

What's still rough

A2A is young. The SDKs are moving weekly, the spec has open issues around long-running tasks and partial failure semantics, and the discovery story beyond a known URL — agent registries, capability search — is still being written. None of that is a reason to wait. It is a reason to keep your A2A surface narrow and your fallbacks boring.

The boring half of agent infrastructure — protocols, contracts, allowlists — is the half that will still be load-bearing in three years.

For an introductory project, pick a single question, expose a single skill, and let two agents talk through it end to end. The PO status example above takes an afternoon and demonstrates every concept that matters. Everything more ambitious is the same shape, repeated.

Coming up next

A closer look at authentication across A2A boundaries — service accounts, propagated user identity, and what to do when the downstream agent needs to know who is asking, not just what.

⟵ Back to the index