Winning the GameDay for AWS Top Engineers with Kiro Also Joining as a Team Member
This page has been translated by machine translation. View original
In February 2026, I took part in AWS GameDay "Microservice Magic," held for Japan AWS Top Engineers, and won first place out of 13 teams (450,585 pts).
Our team consisted of three members: two AWS Top Engineers from different companies, plus one young IT specialist representing the next generation. In this team, I was mainly responsible for directing and controlling the AI agents.
In this article, while complying with the NDA (non-disclosure agreement) for Unicorn Rental, I will share the strategy behind the scenes: "how we fought alongside AI" on a battlefield where top engineers gather, and "why such a large gap opened up."
Final Scores and Rankings
| Rank | Team Name | Score |
|---|---|---|
| 1 | Amazing13 | 450,585 |
| 2 | The Four Heavenly Kings | 339,659 |
| 3 | The Multi-Cloud Security Textbook | 336,546 |
| 4 | Team EHA | 305,584 |
| 5 | We love Dr.Werner | 295,773 |
What Is GameDay?
It is a team-versus-team cloud operations competition hosted by AWS. The theme and format differ each time: some test your ability to build, some test your operational skills, and some focus on security.
This time the theme was "Microservice Magic." It involved working with microservices on a provided AWS environment, and it was a round that tested operational skills.
There were 13 participating teams. The time limit was about three and a half hours.
Using an AI Agent (Kiro)
In this GameDay, Kiro, Amazon's AI coding assistant, was officially provided. It was preinstalled on VSCode Server and ready to use just by authenticating the license through SSO login. Use on personal devices was also permitted, and it was an environment where even the top-tier model, Opus 4.6, could be used freely without worrying about pay-as-you-go charges.
I also used Kiro in "Security Battle Royale," which I participated in at the end of last year, but at that time the top-tier model Opus was not yet available.
What truly showed its value in this GameDay was, without a doubt, Kiro's Opus 4.6. In every situation, whether grasping the situation, estimating causes, or devising countermeasures, I felt performance on a different level from earlier models.
The individual responses themselves are by no means fast. However, they were more than compensated for by the depth of reasoning and the high precision of hitting the right answer in one shot. Because the number of trial-and-error attempts dropped dramatically, I feel the speed to problem resolution was overwhelmingly boosted as a result.
Towards the end, the model's responses frequently timed out, and there were moments when I switched to Sonnet 4.6. However, by that point the main work was almost complete, so there was no major impact. All in all, I think it was a competition where we were able to draw out Opus's potential to the fullest.
What We Had It Do
- Building infrastructure and changing configurations
- Investigating causes and responding when anomalies occurred
- Designing, implementing, and improving countermeasures
- Devising ways to share context between agents
Why I Chose the CLI Version
Kiro also had an IDE-integrated version, but this time I chose the CLI version.
The IDE-integrated version excels at interactive assistance, but for high-density parallel work like this, the CLI version's "portability of the execution environment" and "ease of multiplexing" were major advantages. When treating AI not as a mere tool but as an independent execution unit, I feel the CLI offers overwhelmingly greater freedom of control.
Running Multiple Agents in Parallel
I wasn't aiming for massive parallelism from the start. In the early stages, I handed a task to one agent, and while waiting for it to process, it felt like I was enjoying the coffee and snacks the organizers had prepared.
(GameDay is a warmly hospitable event with plenty of drinks and light meals, and the organizers themselves encourage taking breaks.)
However, as the waiting time for the agents' background processing grew, a flow emerged naturally: the human, back from a break, adds a terminal, launches a new Kiro, shares context, and sends it into the fray.
In general, "piecemeal commitment of forces" is considered a bad move, but with AI agents it worked. This is because the cost of sharing context with a new agent was very low.
The operating cycle was as follows:
- Instruct an agent with a task, and move on to another agent or other work while it processes
- Ask the agents that have finished for a status report
- Have agents whose context has built up run Compact (context compression) and take a rest
- After Compact completes, check progress and then resume work
We devised ways to share context between agents so that each agent could grasp the situation autonomously.
Parallelizing the work greatly improved our response speed. When problems occurred, we were able to split the basics of incident response, "temporary countermeasures" and "root cause investigation," between agents, which led to improved response capability in a short time. On the other hand, there were cases where operations conflicted between agents, so there remained room for improvement in the coordination mechanism.
Redundancy of the Work Environment
In a work style that relies on AI, the work environment itself can become a SPOF (single point of failure). This time, having prepared alternatives meant there were moments when we avoided having to stop work. I came to feel that "redundancy of the work environment" is essential in the age of AI usage.
The Human Role — Information Hub and Decision-Making
Was it a case of leaving everything to the AI agents? Not at all. There was clearly "work that only humans can do."
First, during the initial startup phase until the AI ran stably, the team members built the foundation through manual operations. I was able to concentrate on preparing the AI because the members supported the early stage. Even after the AI stabilized, the members continued to function as sensors, so to speak, detecting anomalies and doing patrol-like monitoring. The human side was not a solo effort.
On top of that, there were two human roles in coordinating with the AI agents.
AI agents excel at completing the task in front of them, but while they are good at looking at the "past" (existing code and configuration), they are weak at integrating the "present" (real-time changes in the situation) and the "future" (what is likely to happen next). There is also the constraint that CLI-based agents cannot directly access information in the browser.
One role is the "information hub" that digests and conveys information the AI cannot access. The other is decision-making that redefines priorities in response to changes in the situation, saying "focus on this now."
AI carries out given tasks astonishingly quickly and accurately, but humans had to decide "what to show, when to show it, and which tasks to drop." I think one of the keys to our victory was that, on top of the foundation the members built, this "human decision-making" and the "execution power of AI" meshed well.
Reflections
The experience of giving instructions to Kiro and having it carry out the work is close to having several excellent engineers on hand. However, I also realized that coordination between AI agents is harder than in a human team. Not everything went smoothly, and there were moments when "obvious things" that I skipped in the rush of the competition led to lost points.
Even so, the form in which a human acts as an orchestrator binding AI agents together was a major advantage in a team battle. I feel we have entered an era where the "proficiency of the user" in mastering AI at an advanced level is what is tested.
What is required differs from one GameDay to another, but I feel that using AI agents will become increasingly important going forward. If you get the chance, please do participate.
