Mainframe Modernization Agents
★ Selected for AWS Summit São Paulo 2026
Architecture & engineering · Bradesco Seguros
Early in 2026, AWS brought in a dedicated AWS ProServe team to help drive the migration.
Douglas Ramos led the AWS ProServe team on this migration, on the mainframe and backend side. AWS Transform handled converting the Mainframe backend to Java, and I was in charge of the Micro Frontend part: three AI agents that learn the actual Mainframe screen patterns well enough to rebuild them as modern UI.
Doing this migration by hand, one Mainframe screen at a time, wasn't realistic at Bradesco Seguros' scale. So I started with a loop, and at the beginning I was part of it myself: writing a component, checking it against the real screen, and manually feeding corrections back in. As I refined that process, the manual checking turned into a fully automated loop instead.
That's the loop the three agents run today. An orchestrator agent starts the process by validating the business rules it reads from the screenshot with a person: me, another developer, or even a business analyst. Once that's confirmed, the loop begins. A translator agent reads the Mainframe screenshot, including the business rules baked into it, and writes a first version of the React/TypeScript component. A reviewer agent then checks that component against the design system and the other Micro Frontends; if it doesn't hold up, it sends the issue back, the translator rewrites, and the cycle repeats until the component actually conforms, not just looks close.
Manages the loop between the two agents below until the review passes.
- Orchestration rules: when to end the loop, when to keep going
- Drafts a business-logic plan from the screenshot
Writes the component, then rewrites it whenever the reviewer sends back an issue.
- General front-end code-pattern steering file
- A skill file for each component in the UI library
Checks the code and the rendered UI against the other Micro Frontends and every reference screenshot of Portal Gestor.
- Playwright MCP: sees what's actually rendered
- Same code-pattern files, to catch what the translator missed
The output is a Micro Frontend meant to be appended directly to Portal Gestor, with every screen translated to the modern UI library. The project was selected to be showcased at AWS Summit São Paulo 2026.
→ Session memory
Every time an agent is called, it starts from a brand-new context: on its own, the reviewer wouldn't know which pass of the loop it's on, what it flagged last time, or whether that got fixed. Each call forgets the one before it.
The review-history file is what carries that across calls: the reviewer writes to it every pass, and folds what it learns back into the translator's steering, so the system remembers even though no single agent call does.
Same reviewer, brand-new context every time.
→ Infinite loop
Nothing guarantees the reviewer approves on the first, or the fifth, attempt. Left alone, the translator/reviewer loop could keep running forever if the review never passes. To bound it, there's a hard cap of 5 passes: if the reviewer still hasn't approved by then, the orchestrator stops the loop and asks for your intervention.
→ Resources used