Every good redemption arc starts with a loss.
Mine was at the London Summit. I walked in confident - maybe a little too confident, following the beta event the AWS Community Builders program had laid on for us. I topped the Round 1 leaderboard, and then the finale happened. Josh and Tomasz in the finale were faster, sharper, and better prepared for the unexpected moment. I left the summit bruised, and somewhat annoyed. The kind of annoyed that turns into a training montage.
This is the story of what I did next, and how the AWS AI League EMEA Virtual became my redemption arc. Las Vegas awaits… let’s hope redemption continues all the way to the big dance and the $30k top prize!
The loss that lit the fuse
If you’ve not played, the AWS AI League Agentic Challenge is deceptively simple to describe and difficult to master. You build an agent that navigates a dungeon-style grid, find a path from the start to the treasure, and along the way solve challenges scattered across the map - safety guardrails, structured-data problems, web lookups, quick factual questions, and a lethal door that punishes a wrong answer. You score for challenges solved, coins collected, treasure reached, and lives remaining. Then there’s the twist that decides everything: a token bonus and/or model fine-tuning bonus (note - for the virtual rounds in APJ and EMEA, and I assume the rest of the competition, the fine tuning option is disabled).
In London I had a strong agent. What I didn’t have was a strong agent under finale conditions. Round 1 is a known map you can tune against for hours. The finale throws brand-new maps at you, live, with the clock running - and all the little assumptions you baked in during practice come due at the worst possible moment.
I lost the finale comfortably - from 1st in round 1 to 3rd out of 3 in the finale! I congratulated the winner (who was so excited he forgot to take his MacBook when he left!) and on the train home I started sketching what “getting it right” would actually take.
The building blocks (and where you’d use them for real)
Before the redemption montage, it’s worth pausing on what you actually build with - because the same stack that powers a dungeon-crawling agent is the stack you’d reach for to build a serious production agent at work. The game is a fun wrapper around a genuinely real-world architecture.
Amazon Bedrock gives you managed access to foundation models behind a single API, with no infrastructure to run. In the League it’s the brain making the decisions. In the real world it’s the same thing you’d use to add a language model to a product - a support assistant, a document summariser, a classification pipeline - without standing up your own GPUs or committing to a single provider. You pick a model, call the API, and switch models later if a better or cheaper one appears.
Amazon Bedrock AgentCore is the runtime that hosts the agent - it manages sessions, memory, tool invocation and identity, and runs the agent as a managed service. In the League it keeps my agent alive across a game and lets it call tools. At work, AgentCore is how you take an agent from “clever demo on my laptop” to “always-on service my colleagues and customers can actually use” - with the session handling, memory and secure tool access already solved for you rather than hand-rolled.
The Strands Agents SDK is the framework for defining the agent itself - its instructions, the tools it can call, and how a supervisor agent delegates to specialists. In the League I use it to wire up specialist tools. In a business setting it’s how you’d model something like a claims-processing agent that hands structured-data work to one tool, a lookup to another, and keeps a supervisor coordinating the whole flow - the exact multi-agent pattern the game rewards.
AWS Lambda runs the individual tools - small, single-purpose functions the agent calls on demand. In the League those tools do things like compute a route or compute a complex maths problem. Everywhere else, Lambda is the workhorse for exactly this - run a bit of code in response to an event, pay only for what you use, and scale from zero to thousands of concurrent calls automatically. It’s the natural home for the deterministic, testable pieces of any agent - the parts you don’t want a language model guessing at.
The point I want to land: none of this is game-only. If you learn to build a competitive League agent, you’ve learned to build a real Bedrock + AgentCore + Strands + Lambda application. The maze is just a very fun set of unit tests.
Instead of hoarding things to myself, I open-sourced them
Here’s the part I’m most proud of, and it happened before I’d won anything.
The single biggest gap between practice and finale is that you can’t practise the finale. So I built a community edition of the game - an open-source practice platform anyone can run, with the real challenge types, an approximation of the scoring model, and a map builder so you can design and test against arbitrary layouts. I put it out for the whole community to use.
Was giving away a practice platform to my future competitors a strange move? Maybe. But the community is the whole point of these events, and a rising tide lifts all agents. It also, selfishly, forced me to formalise my own thinking - you can’t build a faithful practice sandbox without deeply understanding what actually gets scored.
Token economics: the game within the game
Let’s talk about the thing that quietly decides round 1 of these competitions: tokens.
Once you’ve solved every challenge, collected the coins, banked the treasure and kept enough lives, your raw score hits a ceiling - a “perfect” run that many strong competitors reach, especially over the 3 day format of the virtual league, where sadly the model fine tuning differentiator is disabled. At that point everyone is tied on the visible stuff, and the tie-breaker is the token bonus - the fewer output tokens your agent generates to get the job done, the higher your bonus. Ranking among the best runs comes down almost entirely to this.
So the real competition isn’t “can you solve the maze”, it’s “can you solve the maze while saying as little as possible”. Every unnecessary word your model emits is points left on the table. I spent an enormous amount of effort trimming my agent’s output down to the essentials - being economical about what the model says, and pushing the heavy lifting to places that don’t cost you. I’ll stay deliberately vague on the specifics, but the mindset is: treat every token as if it costs you a spot in the finale, because it does.
A word on the disqualifications
Token economics has a dark side. When the tie-breaker is “generate fewer tokens”, there’s an obvious and illegitimate shortcut: don’t let the model actually do the work. Hardcode the answers, hardcode the path, and your agent produces almost no tokens at all - an artificially perfect token bonus. For those trying to get to the finale and seeing token usage less that theirs it must be tempting.
In both the APJ and EMEA virtual rounds, several of the top raw-leaderboard finishers weren’t allowed to compete in the finale - some were disqualified. We can’t see their code, but a really low token count with a perfect score is the signature of an agent that isn’t solving anything - it’s reciting. It’s worth saying plainly: the honest, harder path - an agent that genuinely computes its path and reasons through each challenge - is the one that wins and the one that’s still standing when the AWS review happens, and it’s the one that can perform against unknown maps and challenges in the finale. I built mine to actually play the game, and that’s exactly why it survived scrutiny.
Regression testing: winning on maps you’ve never seen
Here’s the lesson London beat into me: an agent that’s perfect on the round 1 map can fall apart on a map it’s never seen.
The finale maps aren’t the round 1 map. Different dimensions. Different timers. Different start and treasure positions. Coins and traps in different places. A door and key that have moved. Sometimes fewer lives. Sometimes a huge number of challenges and coins to test how long your pathfinding takes. If your agent has quietly overfitted to the round 1 map, or the time allowed to pathfind during, say a relaxed 5 minutes, or you assumed pathfinding and challenges take a fixed amount of time regardless of complexity, the finale is where that bill comes due - publicly, with a clock running.
So this time I treated my agent like production software. Every change went through regression testing against a whole battery of maps in the community edition of the game - different sizes, different layouts, the corner cases we could dream up - to make sure an optimisation that worked for the round 1 map didn’t silently break another. If it didn’t work everywhere, it didn’t ship (well until the last 30 minutes when I had to ship some changes to keep up with those later disqualified!). That discipline is unglamorous and slow, and it’s the single biggest reason the EMEA finale went the way it did. I wasn’t hoping my agent would generalise; I’d (mostly!) verified it. Someone in the EMEA finale anonymously posted they thought the finale was ‘a fix’ - it wasn’t, I was just infinitely more prepared than I suspect anyone else taking part was, and I’d done it in the open with the Community Game available to all on GitHub.
Different challenges, different prompts
One subtlety that catches people out: the finale rounds each use a different map, and the only thing you’re allowed to change between rounds is the short prompt you give your agent - not its code, not its setup. But the maps vary wildly. A tight, tiny map on a brutal timer wants a very different approach than a big, sprawling maze with a generous clock. The mix of challenges crossed on the optimal route changes too - sometimes you’re threading past guardrails and a web lookup, sometimes it’s structured-data problems and the door.
So part of the prep was building the judgement to read a fresh finale map quickly and reach for the right route for that map - knowing which route trades a couple of tiles for a lot more points, and when to be greedy versus safe. Same agent, tuned intent, per round.
The finale, and the pain that only shows up when it’s live
Because of the disqualifications above, the finale field shifted. I made it through, alongside Jochem and Edward.
The finale is where everything gets real. And it’s where Jochem ran into almost exactly the wall I hit in London - which was painful to watch, because I understood it intimately, and Jochem figured it out in finale 1 but was a passenger unable to alter his code for the finale 2 or finale 3 maps.
Jochem’s pathfinding spent too long calculating. On the practice map that’s invisible: you’ve got time to spare, so a heavy, thorough route computation feels free. But in the finale, on a tighter clock, the seconds your agent burns thinking are seconds it isn’t moving and scoring. The route it eventually produced may well have been excellent - but by the time it committed, there wasn’t enough clock left to collect what the map was offering. That failure mode is essentially undetectable in practice and merciless in the finale. It’s the exact trap that got me in London, and seeing it again was a reminder that finale performance is as much about how much time you have as it is about total correctness.
Edward, meanwhile, had the most dramatic excuse imaginable - his wife went into labour about an hour before the finale. His agent ran on default prompts, no per-round tuning at all, and still put in a respectable showing, coming in 2nd place! Priorities, correctly ordered. Congratulations, Edward, on the much bigger win that day, the birth of a son!
As for us, the montage paid off. Across the three finale rounds our agent did what we’d built and tested it to do - read each map, pick the right intent, compute a fast route, solve the challenges cleanly, and keep its mouth shut to protect the token bonus. Round after round, it held up. We finished the finale comfortably clear.
What redemption actually taught us
The win is nice. The lessons are better, and they generalise well beyond a dungeon game: -
Optimise for the metric that actually decides it. In the game that was token economy. At work it’s usually cost and latency: every token a production agent generates is money on your AWS bill and milliseconds a user waits. The same discipline that wins the League - say only what’s needed, push deterministic work to cheap tools instead of the model - is exactly what keeps a real Bedrock application fast and affordable at scale.
Test for the conditions you’ll be judged in, not the ones that are convenient. Round 1 maps are the happy path; the finale is the unknown. Real agents are the same - they behave beautifully on the inputs you thought of and fall over on the ones your users actually send. Build an evaluation set of adversarial and edge-case inputs and run every prompt or model change against it, the way I regression-tested against a battery of maps. If it doesn’t hold up on the inputs you didn’t design for, it isn’t ready for production.
Watch your time budget, not just your correctness. The best answer delivered too late is a loss - in a 45-second finale round and in a customer-facing app where a slow response is a lost user. A “correct” agent that reasons for too long, calls too many tools, or spins up expensive computation on every request will time out or rack up cost in production. Measure and budget latency as a first-class requirement, not an afterthought you discover live.
Play the game honestly. The shortcuts that look brilliant on the leaderboard - hardcoding answers to fake a perfect score - are the ones that get you disqualified. The professional version: don’t ship an agent that fakes the work (hardcoded responses, benchmarks gamed, evaluations quietly skipped). It looks great in the demo and collapses the moment it meets a real, unseen input. Build the thing that genuinely does the job.
Give something back. Open-sourcing the practice platform made the whole community stronger, and made me stronger too - you can’t build a faithful sandbox without deeply understanding the real system. Sharing your tools, your evals, and your hard-won lessons with your team or the wider community isn’t charity; it forces the rigour that makes your own work better, and it compounds.
London bruised, EMEA Virtual healed. If you want to build your own story, the community edition is out there waiting for you - go break it, learn from it, submit PRs to us, and come find us on the leaderboard in your region’s virtual competitions.
See you in the maze.
- Mark Ross, Atos