From theory to delivery: How Atos gave 400 engineers hands-on agentic AI experience

Atos wanted to move a large group of engineers beyond an academic understanding of agentic AI and into practical delivery. Its answer was a 2026 AWS AI League event in which 400 participants spent three days building autonomous, multi-agent systems and competing on a live leaderboard.

The exercise addressed a common weakness in enterprise AI training. Courses and classroom sessions can establish concepts, but they do not necessarily provide experience with the architectural decisions, operational constraints and debugging work involved in making an agentic system function. Atos and AWS therefore used a challenge in which success depended on working software, not just familiarity with terminology.

The cohort was deliberately broad. Some participants were developers who already knew AWS, while others were first-time AWS users or worked as product owners and project managers. Before the event, 5% reported no knowledge of agentic AI, 25% had basic awareness, 50% understood the subject but lacked hands-on experience, and 20% already had practical experience with agentic AI services.

Why the AWS AI League?

Atos selected the AI League as part of its strategic focus on agentic AI, which includes developing Sovereign Agentic AI Studios in multiple locations. The company had also previously used AWS DeepRacer for reinforcement-learning upskilling and an AI League program for model fine-tuning in 2025.

The league format combined four elements that Atos considered important:

• Practical application: participants had to produce functioning agentic systems instead of only studying examples.
• Competitive motivation: a live leaderboard gave teams an immediate reason to iterate and improve.
• Relevant infrastructure: the work used AWS services that engineers could encounter in client delivery.
• Measurable performance: scores reflected both functional results and solution efficiency.

The competition simulated some of the pressures found in delivery work—limited time, consequences for poor decisions and trade-offs between quality and cost—while remaining a training environment rather than a client production project.

Time commitment and format

The event was delivered through AWS Workshop Studio. Although the platform supported formats lasting from one to three days, Atos chose three days to give participants room to work around their existing commitments.

The scheduled program began with a two-hour kickoff covering the league, its challenges and the AWS services involved. A one-hour office-hours call was offered each day for assistance and idea sharing. The program ended with a one-hour finale for the top three participants and the selection of the 2026 champion. Engineers could continue refining their systems outside those sessions.

According to the source, setup required only a small number of planning calls with AWS to settle logistics and event details, along with an internal process for promotion and registration. That description reflects this specific event and should not be treated as a universal estimate of the preparation every organization would require.

The AI League challenge

Participants built an autonomous agent to navigate a dungeon maze. Within a time limit and with a limited number of lives, the agent needed to plan a route, answer challenges placed on tiles, avoid traps and reach a treasure.

The scoring rules created competing objectives. Correct challenge answers earned points, whereas mistakes consumed lives. Coins were risk-free and took no additional collection time. Reaching the treasure before time expired produced a completion bonus, and unused lives added to the final score. Concise answers beat unnecessarily long responses, while specialist small language models created through fine-tuning could earn bonus points.

Eight named challenge types distributed the work across different engineering skills:

• Violent Violet tested safety and content filtering with Amazon Bedrock Guardrails.
• Blue Brain tested code generation and execution through AWS Lambda and AgentCore Code Interpreter.
• Memento tested context retention using AgentCore memory.
• Dark Prophet used Lambda and AgentCore Code Interpreter for retrieval from web sources.
• Bonehead tested general knowledge and token efficiency through Amazon Bedrock prompt engineering.
• Healthcare API tested structured-data extraction through prompt engineering in Amazon Bedrock.
• Keys & Doors required AgentCore memory to preserve context between interactions.
• Spikes & Coins focused on route planning and risk assessment with AWS Lambda.

Amazon Bedrock

Amazon Bedrock supplied access to the models behind the agents’ reasoning. Engineers selected models for different jobs, designed system prompts that could answer directly or delegate to specialist agents and tools, and managed token use and cost. The workflow began with an established model and could later direct inference to a participant’s fine-tuned model. Model availability could vary by AWS Region, making regional support a planning consideration.

Amazon Bedrock AgentCore

AgentCore provided the main orchestration layer for the multi-agent systems. AgentCore Runtime hosted the containers that processed challenge tiles and returned scored answers within the allotted time. AgentCore Gateway routed tool requests through the Model Context Protocol to Lambda functions handling tasks such as pathfinding, scraping and code execution.

AgentCore memory preserved facts between interactions, including whether an agent had collected a key or completed an earlier challenge. AgentCore Code Interpreter provided an isolated sandbox in which agents could safely run code for computational tasks. Together, these capabilities let participants separate language-model reasoning from state, execution and deterministic tools.

Amazon Bedrock Guardrails

Participants configured Guardrails to filter potentially harmful inputs and outputs. Their controls included denied topics, filtering thresholds for hate, violence and misconduct, and custom messages for blocked inputs or outputs. The challenge was not merely to enable filtering, but to tune it accurately enough to reject unwanted material without preventing valid requests.

AWS Lambda

Lambda functions handled operations that a language model could not be expected to perform reliably by itself. These included route calculation, computational code execution, and fetching and parsing web pages for retrieval challenges. For navigation, engineers could implement deterministic techniques such as Breadth-First Search rather than asking a model to improvise every movement.

Amazon SageMaker

SageMaker supported the model-customization portion of the event. Participants used Reinforcement Learning from Verifiable Rewards, or RLVR. SageMaker Studio supplied an integrated development environment with AI development tools; serverless fine-tuning trained custom models on datasets created by participants; and the resulting models were deployed to inference endpoints to handle traffic.

What our engineers learned

The exercise exposed practical lessons about prompt design, system architecture, safety, routing, observability and AI-assisted development. The central theme was that a working first attempt was only a starting point. Competitors also needed to improve speed, reliability and token efficiency.

Prompt engineering under constraints

Verbose prompts and answers carried a direct scoring penalty, while unnecessary tool calls consumed time and reduced scores. Participants therefore had to strip away instructions that did not improve results and decide when a model should answer on its own or invoke another component. That made prompt engineering part of a broader optimization problem rather than an isolated writing exercise.

Multi-agent architecture decisions

Engineers experimented with specialist agents equipped with narrow tools as well as more multifunctional agents. Neither pattern removed the need for trade-offs. Adding specialist components could improve task focus, but orchestration could also increase token use and latency. Consolidating behavior could reduce handoffs while affecting reliability. The leaderboard made those architectural consequences visible through performance and efficiency scores.

Guardrail configuration

The Violent Violet task illustrated the balance required in safety controls. Overly strict settings could block acceptable prompts and cause failures elsewhere in the maze. Settings that were too permissive could fail the safety challenge. The lesson was that guardrails need task-aware testing and calibration; simply switching them on is insufficient.

Pathfinding algorithm design

Navigation required more than finding any valid route. Engineers weighed speed against score maximization, assessed hazards and managed the remaining time. Spikes reduced lives, while hitting walls ended the game. Routes also had dependencies: an agent might need to collect a key before approaching a door. Teams had to choose whether to visit every challenge and collect more points or take a shorter route to the treasure.

The value of observability

Participants who reviewed Amazon CloudWatch Logs between runs appeared to improve faster than those who tried to infer failures without evidence. Logs from Lambda functions exposed inputs, map coordinates, execution details and other diagnostic information. The observation supports a familiar engineering practice: instrument a system, inspect what happened and then make a targeted change.

Using AI to build agentic AI solutions

Engineers also used AI development tools such as Kiro while constructing their systems. According to the source, those who supplied these tools with fuller challenge context tended to make progress more quickly. The reported pattern suggests that AI coding assistance was most useful when grounded in the actual constraints and artifacts of the problem.

Results and outcomes

Registration data indicated that 400 engineers gained hands-on agentic AI experience. The technologies practiced included Amazon Bedrock, Amazon Bedrock AgentCore, Amazon Bedrock Guardrails, AWS Lambda, Amazon SageMaker and Kiro. Atos also reported that internal champions emerged with greater confidence for client engagements and that the competitive format encouraged knowledge sharing across teams.

The leading entries combined custom route strategies, tuned safety controls, persistent memory and fine-tuned models intended to reduce token use. James Ponter finished first, followed in the top three by Adam Różewicki and Eduard-Cosmin Socol. The displayed finale leaderboard recorded 14,040 points for JPonter, 12,896 for adro and 5,944 for EdwardSS.

Ponter, identified as Head of Hyperscalers – UKI Cloud and Infrastructure, described the event as a way to put academic learning under time and performance pressure. Chris Byrne, Atos’s Global Head of AWS Alliance, similarly presented the gamified environment as a less daunting place to acquire experience before facing the pressures of a real project.

These outcomes are reported by Atos and AWS rather than established through an independent assessment. The source provides registration totals and leaderboard results, but it does not report a controlled comparison, pre- and post-event competency scores, long-term retention measures, production deployment results or business return on investment. Claims about greater confidence, faster improvement and cross-team benefits should therefore be read as event observations.

Getting started

The source said AWS AI League was available for enterprise events throughout 2026, as well as at selected AWS Summits and virtual events. Formats ranged from half-day workshops to multi-day hackathons, with AWS providing infrastructure, accounts and facilitation support. Organizations interested in a private event were directed to the AWS AI League page or their AWS account team, while the AWS AI League Builder Space and AI Community offered announcement and discussion channels.

For enterprises considering a similar program, the Atos event highlights several design questions: how much scheduled time participants can commit, how mixed skill levels will be supported, which tasks can be scored objectively, and whether the scoring model rewards the same qualities the organization values in delivery. Teams should also plan for regional model availability, logging, guardrail testing, tool isolation, cost and token controls, and a path from competition prototypes to production-grade engineering.

About the authors

The source article was written by Rajesh Babu Nuvvula, a Senior Solutions Architect in AWS’s Worldwide Public Sector team; Ruchi Bhatia, an AWS Technical Product Marketing Manager whose work includes SageMaker model customization and the AWS AI League; and Mark Ross, Atos’s Chief Architect for AWS within its Cloud and Modern Infrastructure engineering function.

Source attribution: This article synthesizes reporting published by the AWS Machine Learning Blog.

Definition. The AWS AI League was a practical engineering competition in which Atos participants built autonomous agents while balancing accuracy, safety, speed, token use and cost.