At AWS Summit Amsterdam 2026, the breakout session “Transforming from SaaS to multi-tenant agentic SaaS” (Level 300, Floor 1 Breakout 9) delivered one of the deepest technical dives of the event. Speakers Adrian Congiu (VP, Product Management at Mambu) and Danny Kuiper (Product Manager AI at Mambu) shared how they are transforming their cloud banking platform into an agentic SaaS — using Amazon Bedrock AgentCore as the foundation.

The Case Study: Mambu

Mambu is a cloud-native, pure SaaS banking platform covering Lending, Deposits, Payments, and Islamic Banking. Their mission: make more possible in people’s lives by removing monolithic barriers to financial access. The platform runs on a multi-cloud foundation with composability tools (RESTful APIs, Config as Code, Notifications, Streaming APIs, Custom Fields) serving both shared and dedicated environments.
Their challenge — and the session’s central question — was: How do you introduce AI agents into an existing multi-tenant banking system while maintaining the security and compliance posture that financial regulators demand?
Mambu’s Intelligent Core

Mambu’s strategy stacks three AI capabilities on top of their existing composable architecture and cloud-native core:
- Mambu Data Lake — centralized financial data for AI consumption
- MCP Solution — Model Context Protocol integration for tool access
- Agentic Layer — the new intelligence tier
The Agentic Layer

The Agentic Layer delivers three capabilities to financial institutions:
- AI-Powered Insights — agents that run automatically on banking data to identify opportunities and risks, providing context-specific guidance across portfolios
- Conversational AI — natural-language access to customer data, product portfolios, and transactional records (“query your loan book as easy as chatting with your favourite model”)
- Copilots and Agents — intelligence embedded in the platform that works alongside teams for product configuration, streamlined daily processes, and automated back-office operations
The answer to making this work in a regulated, multi-tenant environment: Amazon Bedrock AgentCore.
Mambu’s Agentic Architecture on AWS

The full deployment architecture maps Mambu’s agentic capabilities onto AWS services across four layers:
External — Admin (Config Portal) and User (Chat Widget) interfaces
Application Layer:
- Amazon EKS — Config Control Plane + Mambu MCP
- Amazon API Gateway — HTTP Endpoint + TLS Termination
- AWS Lambda — AgentCore Proxy
AI/ML Runtime:
- Amazon Bedrock — Models, Inference, Monitoring, AgentCore, Knowledge Bases
Data and Events:
- Amazon RDS (PostgreSQL) — Config Data and Metadata
- Amazon S3 — Knowledge Base Docs
- Amazon EventBridge — Event Bus + Bedrock KB Ingestion

The AgentCore Architecture
The architecture diagram reveals a comprehensive platform for production-ready agents:
AgentCore Runtime
The core execution environment where your agent lives:
- Framework support — works with LangChain, CrewAI, AutoGen, and custom frameworks
- Agent instruction — define agent behavior and system prompts
- Agent local tools — register tools the agent can call
- Agent context — manage conversation and task context
AgentCore Gateway (via MCP)
The Runtime connects to external services through MCP (Model Context Protocol):
- AgentCore Gateway — the central routing layer for all external tool calls
- AgentCore Browser — gives agents the ability to browse the web
- AgentCore Code Interpreter — sandboxed code execution for agents
AgentCore Runtime: Securely Run Agents at Scale

The deep-dive into Runtime revealed the full request flow for a production CRM agent:
- Tenant user connects via Amazon CloudFront
- Request hits Amazon API Gateway with JWT authentication
- JWT proxy (Lambda) validates tokens via Amazon Cognito
- Static assets served from Amazon S3
- AgentCore Runtime executes the CRM agent (with tools like
create_lead(),create_task(),get_reports()) - Agent invokes LLMs via Amazon Bedrock through AgentCore Identity
This is the full-stack pattern — from CDN edge to agent execution to model inference, with authentication at every layer.
Agents Need Identity

A key insight from the session: agents are not just code — they are actors that need their own identity. The AgentCore Runtime wraps each agent (like the CRM agent shown) with proper credential delegation, ensuring agents can only access what they are authorized to access.
The identity formula: Incoming access token + Agent identity = Workload access token
Tool Access and Multi-Tenant Identity

When agents need additional tool access, every request flows through AgentCore Identity for validation. The CRM agent calls create_lead(), create_task(), and get_reports() — each tool call is authorized against the agent’s identity before reaching Amazon Bedrock.

The multi-tenant challenge: “What happens when there are multiple users?” Each tenant gets their own inbound access token, which combines with the agent identity to produce a unique workload access token. Tenant 1 and Tenant 2 share the same CRM agent but get completely isolated data access — solving the hardest problem in enterprise AI agents.
Infrastructure Level Isolation

AgentCore offers two isolation tiers for multi-tenant deployments:
- Basic tier — shared AgentCore Runtime and Gateway, with identity-based logical isolation via AgentCore Identity and Amazon Cognito
- Premium tier — dedicated AgentCore Runtime and Gateway per tenant, full infrastructure-level isolation
Both tiers share the same frontend stack (CloudFront → API Gateway → proxy → Cognito), but the Premium tier gives each tenant their own compute plane — critical for regulated industries where data isolation is a compliance requirement.
AgentCore Gateway: Securely Discover and Connect with Tools

The AgentCore Gateway is the tool discovery and routing layer. It supports four target types:
- API Gateway Target — route to existing REST APIs (Tool 1, Tool 2)
- OpenAPI Target — auto-discover tools from OpenAPI specs (Tool 3, Tool 4)
- AWS Lambda Target — invoke serverless functions directly (Tool 5, Tool 6)
- MCP Server Target — connect to any MCP-compatible tool server
All tool access is validated through AgentCore Identity with Amazon Cognito, ensuring agents can only call tools they are authorized to use.
AgentCore Memory

AgentCore Memory provides persistent memory across sessions — agents that remember past interactions, user preferences, and conversation history. The architecture has two layers:
- Short-term memory — synchronized from agent events (Messages + Agent State), scoped per session
- Long-term memory — persistent knowledge retrieved via “List Events” and “Retrieve Memory records” calls
- Automatic Memory Extraction Module — asynchronously promotes important short-term memories to long-term storage
Tenant Isolation in AgentCore Memory

Multi-tenant memory isolation follows a clear chain:
- Extract TenantID from incoming JWT
- Map it to IAM Session Tag
- Call AssumeRole to assume ABAC IAM role
- Call AgentCore Memory API with tenant-scoped credentials
The result: short-term memory is scoped per actorId (e.g., “TenantA/UserA”, “TenantB/UserB”) and long-term memory uses namespace isolation (“TenantA”, “TenantB”). No tenant can ever access another tenant’s memory — enforced at the IAM level.
AgentCore Observability

Full tracing and monitoring of agent behavior from four signal sources:
- Agent deployed on AgentCore Runtime — execution traces and latency
- Agent memory using AgentCore Memory — memory read/write patterns
- Tools from AgentCore Gateway — tool call success rates and response times
- Agents from Third Party Integrations — external agent frameworks
All signals flow into Amazon Bedrock AgentCore Observability, with OTEL logs export to third-party observability dashboards (Datadog, Grafana, etc.) for unified monitoring.
Phase 4: Operations — Scaling and Monitoring

The session outlined a phased approach to agentic SaaS adoption. Phase 4 covers operational scaling with SaaS Context — a JSON object that travels with every request:
{
"feature": "1",
"tier": "standard",
"tenantId": "...",
"region": "us-east-1",
"agent": "agent_1212"
}This enables tier-based routing — Standard tenants share Agent 1 (pooled), while Enterprise tenants get dedicated Agent 3 instances with full isolation.
Key Takeaways

The speakers closed with five critical takeaways:
- Agentic SaaS is a business and technology strategy — not just a feature
- There is no one-size-fits-all agentic SaaS experience — customization is key
- Prioritize multi-tenancy from the outset of your adoption
- Do not underestimate the impact of multi-agent systems — complexity compounds
- Agents are likely to disrupt and transform the SaaS domain — this is existential for SaaS providers
Why This Matters

The agent ecosystem has been fragmented — everyone building their own scaffolding around LLM calls. AgentCore provides the managed infrastructure layer that handles the undifferentiated heavy lifting:
- No more DIY agent infrastructure — memory, identity, and observability are built in
- MCP-native — first-class support for the Model Context Protocol standard
- Framework-agnostic — bring your own agent framework (LangChain, CrewAI, etc.)
- Enterprise-grade — identity management, audit trails, and cost controls from day one
For teams already building on Amazon Bedrock, AgentCore is the natural next step from single-model inference to multi-step agentic workflows.
Key Takeaways
- Agents need more than an LLM — the Runtime + Gateway + Memory + Identity + Observability stack is what makes agents production-ready
- MCP is the glue — AWS is betting on MCP as the standard protocol for agent-to-tool communication
- Observability is not optional — you cannot run agents in production without full tracing
- Identity is the hardest problem — agents acting on behalf of users need proper credential delegation

