Skip to main content

Amazon Quick Integration with Joule Agents

Last updated on by kay-schmitteckert

Disclaimer

Some components and capabilities of this reference architecture are not yet generally available (GA) — the current architecture reflects a transitional state that highlights the relevant building blocks for an agentic architecture based on SAP Business AI Platform. In particular, the Agent Gateway is not yet GA. The pattern outlined here shows how the integration between AWS and SAP can be done today and will evolve as those capabilities are released.

Amazon Quick gives users a natural-language chat interface inside AWS. This page describes the inbound direction — an Amazon Quick agent consuming agents running on SAP Business AI Platform, with the actual agent delegation handled by AWS AgentCore.

The integration uses AWS AgentCore as the bridge: Quick reaches AgentCore via a connector, and AgentCore handles the communication with the Agent Gateway. The SAP side, running on SAP Business AI Platform, exposes Joule Agents, Assistants, and Custom Agents (built with Joule Studio) through the Agent Gateway. Identity flows end-to-end — from the user's Cognito session all the way to the agent running on SAP Business AI Platform — without any additional sign-in step.

A user working in Amazon Quick can hand an SAP-specific task to a Joule Agent, Assistant, or Custom Agent and receive the answer in the flow of work. Because every delegation runs under the signed-in user's identity, the SAP authorizations already in place in the downstream system continue to govern what the agent can do, with full end-to-end traceability.

Architecture​

image of solution diagram
Copy to clipboard
Solution Diagram Resources
You can download the Solution Diagram as a .drawio file for offline use. Alternatively, you may view and edit the Solution Diagram directly on draw.io.
Please note that any changes made online will need to be saved locally if you wish to keep them.
DownloadEdit

Core Components​

  • Amazon Quick: The chat interface inside AWS. Quick does not natively speak A2A, so it reaches AgentCore through an MCP connector. Hosts the connector and its Cognito OAuth session, and sends a Cognito access token as the Bearer credential on every message to the AgentCore Runtime.
  • AWS AgentCore Runtime: The managed compute layer hosting the custom MCP server. Its own inbound JWT authorizer validates the incoming Cognito token, mints the WorkloadAccessToken, runs the model (via Amazon Bedrock) to select the right agent running on SAP Business AI Platform, and orchestrates the A2A call to SAP Business AI Platform.
  • AWS AgentCore Identity: The identity bridge between AWS and SAP. Performs the on-behalf-of (OBO) token exchange — exchanges the WorkloadAccessToken for a SAP Cloud Identity Services token scoped to the Agent Gateway, authenticating itself to SAP Cloud Identity Services with a private_key_jwt client assertion, without any user interaction.
  • Amazon Cognito → SAP Cloud Identity Services: The identity chain. Cognito authenticates the user and issues the access token; SAP Cloud Identity Services resolves the user by a user identifier (email, in this setup) and issues the gateway-scoped token.
  • Agent Gateway: The single inbound hub for agent traffic on the SAP side. Routes to the SAP-managed runtimes where the Joule Agents, Assistants, and Custom Agents are deployed.

Identity and principal propagation​

Secure, user-context-aware access is the key design principle — the signed-in user is the principal, their identity established once at the Cognito login and then carried forward automatically across every layer.

The chain has three tokens, each issued by a different authority and used for a different hop:

  • Cognito access token — the user authenticates via Cognito (OAuth 2.0 authorization code + PKCE) when the connector is first used. The resulting access token carries the user's identifier (email, in this setup) and is the Bearer credential Quick sends to the AgentCore Runtime on every message. A Cognito access token does not include email by default, so a pre-token-generation Lambda on the app client adds it — it is the claim SAP Cloud Identity Services later uses to resolve the user. Quick silently refreshes the token using a cached refresh token, so this login happens only once per connector session.
  • WorkloadAccessToken (WAT) — once the Cognito access token passes the Runtime's inbound JWT authorizer, the AgentCore Runtime hosting layer mints a WAT from it. The WAT binds the Runtime's own workload identity together with the user identity from the access token, and is injected as a request header before the application code runs.
  • SAP Cloud Identity Services access token — when the Runtime needs to call an agent running on SAP Business AI Platform, it passes the WAT to AgentCore Identity, which performs the on-behalf-of (OBO) exchange with SAP Cloud Identity Services. SAP Cloud Identity Services resolves the user by the same identifier present in the Cognito access token — email, in this setup — and issues a token scoped to the Agent Gateway with that identifier as its sub. No user interaction; no separate SAP login.

The OBO exchange carries two independent proofs that SAP Cloud Identity Services validates before it issues the gateway-scoped token: who the user is, from the WAT, and who the client is, from a private_key_jwt client assertion (RFC 7523). AgentCore Identity signs that assertion with a private key held in AWS KMS — the key never leaves AWS and no shared secret is exchanged — while the matching public key is published at a JWKS URL that SAP Cloud Identity Services trusts. Key rotation is a matter of publishing a new JWKS entry, with no secret to leak.

Because the user's identifier threads through all three tokens, the Agent Gateway receives a token whose sub is the known SAP identity of the signed-in user. SAP applies its own authorization policies against that identity, just as if the user had authenticated directly at the SAP system.

Integration approach​

Amazon Quick does not natively speak A2A, so MCP is the connector layer: it bridges Quick to AgentCore, and AgentCore then handles the A2A communication with the Agent Gateway. Connecting the two comes down to three pieces of setup:

  1. An MCP connector in Amazon Quick backed by a Cognito user pool — Quick opens a Cognito login popup on first use and silently refreshes the token on every subsequent conversation. The connector calls the AgentCore Runtime MCP endpoint with the Cognito access token.
  2. An AWS AgentCore Runtime hosting the MCP server — the Runtime validates the incoming token, mints the WAT, runs the model (via Amazon Bedrock) to select the right agent running on SAP Business AI Platform, calls AgentCore Identity for the OBO exchange, and then issues the A2A call (message/send) to the Agent Gateway with the gateway-scoped SAP Cloud Identity Services token.
  3. An AgentCore Identity credential provider pre-configured with the SAP Cloud Identity Services OAuth endpoints, the Agent Gateway resource URN, and a private_key_jwt key held in AWS KMS (with its public half published to a JWKS URL SAP Cloud Identity Services trusts) — AgentCore Identity performs the OBO exchange with SAP Cloud Identity Services on the Runtime's behalf, so the Runtime never calls SAP Cloud Identity Services directly and never builds the client assertion.
Agent Interoperability Cookbook for Integrating Joule Agents into Amazon Quick

Step-by-step setup — Cognito user pool, AgentCore Runtime configuration, AgentCore Identity credential provider, and the Amazon Quick connector — lives in the cookbook: AWS Integration - Amazon Quick in SAP-samples/agent-interoperability.