How Deutsche Bahn's Vision of 1 Million AI Agents Will Be Realized with Amazon Bedrock AgentCore - AWS Summit Hamburg 2026 Attendance Report
This page has been translated by machine translation. View original
This is Konishi from the Berlin office.
On May 20, 2026, I attended AWS Summit Hamburg, held in Hamburg, Germany.
From sessions to booths, everything was AI. What left the strongest impression on me was a session by Deutsche Bahn (hereinafter DB, German Rail) on AI agent adoption.
The session title was "AI Agents at Deutsche Bahn: Best Practices for Amazon Bedrock AgentCore."
The first half featured Simon from AWS introducing best practices for Bedrock AgentCore, while the second half covered real-world case studies from DB.
Since many of our company's blog posts already cover AgentCore (reference), this article will focus mainly on how Deutsche Bahn implemented Bedrock AgentCore.
What is Deutsche Bahn (German Rail)?
Deutsche Bahn is Germany's state-owned railway company, and one of Europe's largest rail operators with 230,000 employees and over 880 subsidiaries.
The presenter at this session was René Schneider (pictured above) from DB Systel (DB Group's IT services subsidiary), who oversees infrastructure operations across the entire DB Group as Senior Vice President, Infrastructure.
Challenges Facing Deutsche Bahn
First, a bit of context on DB's current situation.
DB has been facing a serious decline in service quality in recent years.
The on-time rate for long-distance trains in 2025 was 60.1%, the worst on record. Looking at the numbers again, it's quite stark. In fact, living in Germany, train delays and cancellations are an everyday occurrence...
The causes include aging infrastructure, deferred maintenance and investment, and speed restrictions and line closures due to large-scale renovation works.
With infrastructure problems only multiplying and no easy way to increase manpower, streamlining operations became urgent — and that became the driving force behind the adoption of AI agents.
Background on the AI Agent Initiative
According to Schneider, DB began exploring agentic AI in November 2025, when the Group CIO posed the challenge: "Think about how we can govern one million agents in the future."
A PoC started in January 2026, and production deployment was achieved approximately two months later — an remarkably fast timeline.
Production Use Case: Automated Patch Management for the Central Operations Control System
Target System
The PoC targeted DB's central operations control and orchestration system, which manages train operations across all of Germany. It is DB's core system, covering over 34,000 km of track, more than 5,400 stations, and over 20,000 trains per day. As Schneider put it, "If you want to tackle this area seriously, there's no point starting with a small system."
The Challenge
The system is supported by over 2,500 servers. Security and functional patches need to be applied almost daily, but doing so manually across that many servers — while accounting for complex interfaces and dependencies — requires an enormous amount of effort.
Agent Architecture
DB adopted the "agents-as-tools" pattern.
The architecture is as follows:
- Orchestrator Agent: Receives patch request tasks via Amazon SQS and controls the overall flow
- Triage Agent: Analyzes the scope and scale of patches and creates a summary
- Human-in-the-loop: Based on the Triage Agent's summary, a human decides whether to apply patches automatically or handle them manually
- Patching Agent: After approval, applies patches to EC2 instances via an MCP Server. Unlike humans, it can process all 2,500 servers simultaneously in parallel
Rather than full automation, a Human-in-the-loop is incorporated. The division of roles — where agents analyze the impact and humans make the final call — has reportedly been working well.
The framework adopted is Strands Agents, AWS's open-source framework. The choice was made to "avoid vendor lock-in by selecting an open-source framework, considering the possibility of migrating from AWS to a different provider in the future."
For more on Strands Agents, please also see our company's article:
Design Philosophy for the AI Agent Ecosystem
Building on this success, DB is moving forward with constructing an ecosystem to operate AI agents across the entire group. The goal is to establish a foundation capable of running one million agents in the future. While the AWS side of the session also recommended a "central registry" and "investment in platform teams," DB is working to put this into practice at an enterprise-wide scale.
The Mental Model of "Digital Office Workers"
One particularly interesting concept from the session was treating AI agents as "digital office workers."
Just like human employees, agents are said to have the following lifecycle:
- Hiring: Creating an agent. Defining skills and roles
- Onboarding: Connecting to environments, granting permissions
- Collaboration: Interacting with employees via Microsoft Teams and Amazon Q
- Feedback: Evaluating and improving performance
The vision described was one where 230,000 employees would hire, train, and promote agents as needed through Teams to get their work done.
Two Types of Agents
DB classifies agents into two types.
1. On-behalf Agent
These agents operate using the user's own identity and permissions. They handle tasks such as composing emails, managing calendars, and creating meeting minutes. When the user shuts down their PC, these agents also stop. They are positioned as the user's "alter ego."
2. Enterprise Agent
These agents have their own identity and permissions and are subject to identity management and access control just like employees. They operate continuously without depending on user actions, autonomously executing enterprise-level tasks such as the patch management for the operations control system described earlier.
This classification makes it clear "whose authority the agent acts under" and "when it stops."
Security and Governance
Operating one million agents raises significant challenges around security and governance.
Zero Trust Principles
Following the zero trust principle of "treating every agent as if it has already been compromised," DB has established six layers of safety nets, covering not only technical security (authentication and authorization, encryption, network isolation) but also functional guardrails (data privacy, regulatory compliance).
Agent Cards
Each agent is issued something like an ID card called an "Agent Card." Based on Google's A2A protocol's Agent Card, it explicitly lists the owner (responsible person).
If an agent causes a problem, it is not the agent that is held responsible, but the human owner. Even with one million agents, the principle that accountability always traces back to one individual human being is simple yet crucial.
Network Isolation
Agents have no access rights at the time of creation. They start in a state where they cannot communicate with any system within DB, and access to tools and other agents is granted incrementally. This is similar to how new human employees start with limited permissions.
Autonomy Level Model
DB applies the same level-based thinking used in autonomous driving to its agents.
Agents start at a level where they only provide assistance, and as they earn trust, their permissions and autonomy are gradually expanded.
- Start by assisting humans as an assistant
- "The last 20 responses were all accurate" → grant more responsibility
- Ultimately, agents make decisions and take action autonomously
Schneider noted, "Just like autonomous driving, you don't jump straight to Level 5."
Corporate Governance Hierarchy
Governance is managed in a three-tier structure:
- Corporate Level: Rules applied across the entire DB Group
- Business Unit Level: Regulatory compliance for each of the 880 subsidiaries
- Department Level: Department-specific guardrails
Since agent cards contain information about the business unit they belong to, agents automatically fall under the applicable guardrails. It applies to agents the same mechanism by which human employees follow the rules of their own department.
Traceability
DB's traceability is built on four pillars:
- Task: A record of the tasks an agent received — from whom, and what was requested
- Process: How it was processed — the basis for decisions, the status of guardrail application, whether escalation occurred
- Result: The final output
- Next Step: Handoffs to downstream agents or triggers for Human-in-the-loop
Trace information from all agents is aggregated, and the status of the workforce is visualized on a dashboard. It sounds something like "attendance management for AI agents."
Future Outlook
Schneider reflected: "Six months ago, nobody at DB was talking about AI agents. And now the ecosystem is up and running."
The next goal, he said, is to migrate the more than 2,500 use cases DB currently operates to AI agents within 12 months.
Closing Thoughts
It was a packed session with a lot of ground covered in a short time. In fact, this session was extremely popular, with people waiting to get in.
In reality, there are surely still many challenges ahead, but given that there is already a track record with a core system, it doesn't sound like mere idealism. As a user, I'm also hoping to see DB's continued improvements.
