Elegance AI Enterprise Lab
When one enterprise agent needs an answer from another
A buyer’s procurement agent asks a supplier’s fulfillment agent for the latest purchase order status through the A2A protocol. Neither company exposes its internal ERP system or agent implementation.
Google ADKGeminiA2A ProtocolSAP ScenarioSynthetic Data
Why A2A is needed
Without A2A
- Emails
- Phone calls
- Supplier portals
- Point-to-point custom integrations
- Direct system access
- A different integration pattern for every agent
With A2A
- Discover the supplier agent
- Understand its capabilities
- Send a standard agent request
- Receive a structured response
- Preserve organizational and system boundaries
The buyer does not need to know whether the supplier agent uses Google ADK, LangGraph, Java, Python, SAP, Oracle or a custom ERP. It needs a trusted A2A-compatible interface.
Interactive lab
Ask the Buyer Procurement Agent
Buyer Company
Buyer Procurement Agent
SAP S/4HANA · simulated
Ask about a purchase order, or click a suggestion below.
Buyer Agent
→A2A Request→
Supplier Agent
→A2A Request→
Supplier Agent
Buyer Agent
←A2A Response←
Supplier Agent
←A2A Response←
Supplier Agent
Supplier Company
Supplier Fulfillment Agent
Supplier ERP · simulated
Agent statusChecking…
Agent Card availabilityNot reachable
Exposed skill
get_purchase_order_status
A2A endpoint
—
Architecture
Buyer Enterprise
User
↓
Buyer Procurement Agent
↓
Buyer SAP Tool
↓
Simulated SAP Data
A2A Protocol
Supplier Enterprise
Supplier Fulfillment Agent
↓
Supplier ERP Tool
↓
Simulated Supplier ERP Data
- Separate ownership, separate deployment, separate data — no shared database.
- No direct buyer access to the supplier’s ERP.
- A2A is the only agent-to-agent boundary between the two enterprises.
Inspect the Agent Card
An Agent Card is the machine-readable description of what an agent can do and how another agent can communicate with it. This is fetched live from the deployed Supplier Fulfillment Agent — never hardcoded.
Fetching the live Agent Card…
A2A versus API, MCP and local sub-agents
| Pattern | Primary purpose | Typical boundary |
|---|---|---|
| API | Application invokes a defined system function | System to system |
| MCP | An agent accesses tools, data or enterprise systems | Agent to tool |
| Local sub-agent | Agents collaborate inside one controlled application | Same team or codebase |
| A2A | Independently built agents discover and communicate | Cross-team or cross-company |
A2A still runs over standard network technologies. Its value is the common agent interaction model, not the elimination of APIs.
Build it end to end
1
Define the enterprise boundary
Model the buyer and supplier as separately owned systems and services, from the start — this is what the whole exercise is about.
2
Create synthetic buyer SAP data
A JSON file of purchase orders (PO number, supplier, material, quantity, requested delivery date) plus a get_buyer_purchase_order_context() tool that reads only it.
3
Create synthetic supplier ERP data
A separate JSON file of fulfillment records (acknowledgment, confirmed quantity, ship date, ETA, carrier, tracking) plus a get_purchase_order_status() tool.
4
Build the Supplier Fulfillment Agent
A Google ADK LlmAgent with the ERP tool and an instruction that forbids inventing values the tool didn't return — data minimization is enforced here, not downstream.
5
Expose the supplier agent through A2A
to_a2a(root_agent, port=8001) wraps the agent in a Starlette app that auto-generates and serves its Agent Card, and mounts the A2A JSON-RPC routes.
6
Run the supplier service
uvicorn server:a2a_app --host localhost --port 8001 — a real, separate process the buyer never touches directly.
7
Inspect the Agent Card
Fetch /.well-known/agent-card.json (path may vary by SDK version) and confirm name, skills, protocol version, and service URL before consuming it.
8
Create the remote supplier proxy
RemoteA2aAgent(name=..., agent_card=<card_url>) resolves the card and speaks A2A on the buyer's behalf.
9
Build the Buyer Procurement Agent
Its own LlmAgent with the buyer SAP tool plus a plain tool function that drives the RemoteA2aAgent through its own Runner, catching A2A failures explicitly.
10
Execute the buyer agent
InMemorySessionService + Runner + run_async(), same as any ADK agent — the remote call is just another tool call from here.
11
Add the streaming web experience
A FastAPI POST /query/stream endpoint emits each step as a Server-Sent Event as it happens, so the browser can render a live trace instead of a single blob after the fact.
12
Run everything locally
Two Python services plus this Next.js app, three processes, no Docker required for local dev — see the lab's README for exact commands.
13
Deploy the services
Supplier and buyer each become their own Cloud Run service; the buyer is configured with the supplier's live Cloud Run URL as SUPPLIER_AGENT_CARD_URL.
14
Validate the real boundary
Stop the supplier service and confirm the buyer returns a controlled 'unavailable' response instead of silently fabricating one — that's the whole point.
Enterprise considerations
- Identity & authorization — service-to-service identity (OAuth2, mTLS, or workload identity), declared in the Agent Card and enforced by the supplier.
- Data minimization — the supplier agent should only ever return data for purchase orders the calling buyer is entitled to see.
- Agent discovery — how a buyer first learns a trusted supplier agent exists and where its Agent Card lives.
- Contract & schema versioning — the A2A message schema and skill definitions need a versioning and deprecation policy.
- Network security — private networking instead of a public endpoint, where the relationship allows it.
- Auditability — every A2A call logged with a request ID, timing, and outcome.
- Observability — trace visibility into buyer-tool calls, A2A calls, and failures, without exposing hidden model reasoning.
- Timeouts & bounded retries — so a slow or struggling supplier degrades gracefully instead of hanging the buyer.
- Rate limits — both to protect the supplier and to keep a public demo from being abused.
- Human escalation — what happens, and who is notified, when a supplier agent is degraded for an extended period.
- Service-level expectations — agreed availability and response-time targets between buyer and supplier.
- Supplier onboarding & offboarding — how a new supplier agent gets trusted, and how that trust gets revoked.
Elegance AI Lab — Practical learning for applied and agentic AI. Built with synthetic data. Not connected to a production SAP system.