MRH Trowe gives 400 employees governed access to self-service AI agents
MRH Trowe deployed secure AI agents for about 400 employees using AWS and open-source tools, showing how regulated firms can scale governed self-service.
Germany’s MRH Trowe has put a governed self-service AI platform into production for approximately 400 employees, using AWS infrastructure and open-source software to address the security and data-residency demands of financial services.
The commercial and industrial insurance broker’s first production agent turns Microsoft Teams meetings into structured minutes. Employees can ask in German for a recent meeting with a participant, after which the agent finds the calendar entry, retrieves the transcript, and produces a summary covering participants, agenda items, discussion topics, and follow-up actions.
AWS described the deployment in a Machine Learning Blog case study. The account is therefore vendor-controlled, and its adoption, cost, and projected savings figures should be treated as reported by AWS rather than independently verified market data. Still, the implementation offers a concrete example of how a regulated company is moving beyond general-purpose chat toward centrally managed AI agents connected to internal systems.
From isolated experiments to a governed platform
MRH Trowe operates mainly in Germany, Switzerland, and Austria and has grown through organic expansion and acquisitions, according to AWS. The company was among the first German insurance brokers to run exclusively on cloud-based IT infrastructure, with AWS serving as its preferred cloud partner.
As employee demand for generative AI increased, individual teams began experimenting with tools independently. AWS says this created a risk of fragmented deployments and potential exposure of sensitive client and insurance information. The company wanted employees to create and use AI agents without requiring every team to build its own technical stack.
That requirement goes beyond a conventional chat interface. MRH Trowe needed responses grounded in internal information, agents capable of multi-step work, secure connections to company systems, and centralized oversight of access and spending. Its stated goal is for routine questions to be answered by AI before human intervention and for repetitive work to be automated by the employees who previously performed it.
The resulting platform combines three components. Builders use Strands Agents, an open-source software development kit for creating agent workflows. Amazon Bedrock AgentCore provides the production environment for connecting, operating, and scaling agents. LibreChat supplies the employee-facing interface, with authentication, conversation management, branding, token budgets, and support for multiple models.
Identity, residency, and infrastructure controls
The meeting-minutes workflow is designed around the identity of the employee making the request. LibreChat authenticates users through Microsoft Entra ID and passes that identity to the agent server-side. The identity cannot be supplied or altered through the chat prompt, and the agent is limited to the user’s own calendar and meeting transcript access.
AWS says the agents, models, and data operate in the AWS Europe (Frankfurt) Region, also known as eu-central-1. That regional placement is intended to keep meeting and client data in Germany, although AWS notes that service and model availability varies by region.
The deployment runs in a single AWS account inside a virtual private cloud. Employees connect from the corporate network through a transit gateway and a zero-trust provider, rather than sending traffic over the public internet. An internal Application Load Balancer routes requests to the application tier in a private subnet.
AWS identifies session isolation as a key reason MRH Trowe selected Amazon Bedrock AgentCore. The service isolates agent sessions at the compute and filesystem levels and supports open-source frameworks such as Strands Agents. For a regulated broker, that combination is intended to preserve developer flexibility while reducing the risk that one agent session can access another’s data.
What the evidence shows—and what it does not
AWS reports that the rollout reached approximately 400 employees during its first month of production. It also reports an initial cost of about $14 per seat in that month, with a projected path to reduce infrastructure costs by roughly 40% through right-sizing and scheduled scaling.
Those figures are useful indicators of the deployment’s reported economics, but they are not an independent benchmark. AWS does not provide, in the supplied case study, a detailed breakdown of usage by employee, model consumption, agent execution volume, or the precise basis for the projected reduction. The evidence also does not establish whether all 400 employees use the system regularly or how the meeting-minutes agent performs against manual work in accuracy, latency, or error rates.
The case study does establish the technical design choices MRH Trowe says it made: a private network path, regional processing, identity-bound requests, token budgets, and an open interface supporting multiple models. It also shows that the first production use case is relatively bounded. Meeting retrieval and summarization can offer immediate value while limiting the agent’s authority compared with workflows that modify records, send external communications, or make business decisions.
Why the deployment matters for AI teams
For builders, MRH Trowe’s approach highlights the importance of treating identity and infrastructure as part of the agent design rather than as features added after development. Passing the authenticated user context from the interface to the agent server can make access control explicit, while session isolation addresses a separate layer of risk in multi-user deployments.
The architecture also separates experimentation from production operations. Developers can use Strands Agents to build workflows without implementing all the underlying infrastructure themselves, while AgentCore provides a managed runtime and consumption-based model. LibreChat gives the business a familiar front end without requiring the broker to adopt a commercial chat product as its only interface.
For enterprise buyers, the use of multiple models may reduce dependence on one model provider and allow teams to match models to specific tasks. Token budgets provide a basic cost-control mechanism, but they do not replace monitoring of quality, latency, data access, and agent failures. Those operational questions will become more important as agents move from summarization to actions across insurance systems.
The deployment also illustrates a practical path for enterprise AI in regulated environments: begin with a workflow that is useful, internally bounded, and auditable; enforce user-level permissions; keep processing in an approved region; and scale access through a central platform instead of unmanaged team-by-team tools.
What to watch next
The next signals will be whether MRH Trowe expands beyond meeting minutes into workflows that retrieve or update insurance and client records. Such use cases would test whether the platform’s identity controls and session isolation remain sufficient when agents can take consequential actions.
Adoption quality will matter as much as the reported employee count. Follow-up evidence on active usage, task completion rates, human review, error handling, and employee time saved would provide a clearer picture of business value than first-month access alone.
Cost reporting is another area to monitor. The promised reduction of about 40% depends on right-sizing and scheduled scaling, so actual spend after optimization would help buyers assess whether consumption-based infrastructure remains predictable as usage grows. More detail on model selection and regional availability would also clarify how portable the architecture is across workloads and jurisdictions.
Creati.ai perspective
MRH Trowe’s deployment is notable less because it puts a chatbot in front of employees than because it treats self-service AI as a governed internal platform. The combination of employee-bound permissions, private connectivity, regional processing, and controlled agent execution addresses several reasons regulated organizations hesitate to move from experimentation to production.
The evidence remains a vendor case study, so its adoption and cost claims require independent validation. Even with that caveat, the design points to a sensible near-term pattern for financial-services AI: narrow, auditable agents first, with broader automation dependent on demonstrated reliability, clear authorization boundaries, and operating costs that enterprises can measure.
