Live
Self‑Hosted Void Platform Lets Teams Govern AI‑Built Apps on CloudflareRethinking Agent Evaluation: Practical Lessons from the Google Cloud Developer PluginTaming Semantic and Embedding Drift in Production Agentic SystemsLLM autonomous hacking exposes gaps in model sandboxing and credential handlingGitHub Actions GA Xcode 27 Runner on Apple SiliconSeparating Orchestration and Compute for GPU‑Intensive Biotech AgentsAgent Quality Evaluation at Scale with Amazon Bedrock AgentCoreAI agents on Kubernetes: handling 20‑fold request spikes and new runtime optionsSelf‑Hosted Void Platform Lets Teams Govern AI‑Built Apps on CloudflareRethinking Agent Evaluation: Practical Lessons from the Google Cloud Developer PluginTaming Semantic and Embedding Drift in Production Agentic SystemsLLM autonomous hacking exposes gaps in model sandboxing and credential handlingGitHub Actions GA Xcode 27 Runner on Apple SiliconSeparating Orchestration and Compute for GPU‑Intensive Biotech AgentsAgent Quality Evaluation at Scale with Amazon Bedrock AgentCoreAI agents on Kubernetes: handling 20‑fold request spikes and new runtime options
AWS

Running an Agentic AI League to Upskill Engineers on AWS Services

AI SummaryPowered by AI

Atos replaced theory‑only training with a three‑day, hands‑on agentic AI league that forced 400 engineers to build multi‑agent systems using native AWS services. This shift gives practitioners concrete experience with service integration, observability, and security considerations that are essential for production deployments.

Atos transformed a theoretical AI curriculum into a three‑day, hands‑on agentic AI league that moved 400 engineers from basic awareness to building multi‑agent systems on AWS. Practitioners care because the format forces real‑world integration of services such as Amazon Bedrock, Bedrock AgentCore, AWS Lambda, Kiro and Amazon SageMaker, exposing the operational and security nuances of deploying autonomous agents at scale.

Why a Competitive Lab Beats Traditional Training

The league replaced passive lectures with a live leaderboard that scored functional completeness and efficiency. This approach delivered three concrete benefits:

  • Immediate application: Engineers produced a working agent that navigated a maze, solved challenges, and managed resources, rather than only reading about concepts.
  • Motivation through competition: The public scoring encouraged rapid iteration and peer learning.
  • Service‑level exposure: Every solution was built with native AWS services, giving participants a realistic view of provisioning, IAM configuration, and cost considerations.

Event Structure and Service Usage

Setup leveraged the AWS Workshop Studio and required only a few coordination calls with AWS. The schedule consisted of:

  • Kick‑off workshop (2 hours) – introduced the challenge, the AWS services, and the scoring model.
  • Daily office‑hours call (1 hour) – provided troubleshooting and idea exchange.
  • Finale showdown (1 hour) – crowned the top three solutions.

Outside these slots, engineers worked independently, fitting the lab around existing responsibilities. Participant skill distribution was:

  • 5 % with no prior agentic AI knowledge.
  • 25 % with basic awareness.
  • 50 % understood the theory but lacked hands‑on experience.
  • 20 % already had practical exposure.

The core challenge required an autonomous agent to traverse a 10×10 dungeon, collect coins, avoid traps, and reach a treasure within a time limit and limited lives. Scoring rewarded correct challenge answers, coin collection, map completion, and remaining lives.

Architectural and Operational Takeaways

Building the league highlighted several practical considerations for teams adopting agentic AI on AWS:

  • Service integration patterns: Combining Bedrock for foundation models, AgentCore for orchestration, Lambda for event‑driven logic, and SageMaker for fine‑tuning creates a modular stack, but each component introduces its own IAM policies and monitoring requirements.
  • Observability: Multi‑agent runs generate logs from Lambda invocations, Bedrock inference calls, and SageMaker training jobs. Centralizing these streams in CloudWatch or a dedicated observability pipeline is essential for debugging and performance tuning.
  • Cost awareness: On‑demand usage of Bedrock and SageMaker can grow quickly during iterative development. Tagging resources and setting budget alerts helps prevent surprise spend.
  • Security posture: Agents that invoke external APIs or access data stores must be scoped with least‑privilege IAM roles. The league’s sandbox environment demonstrated the need for separate execution roles per team to avoid cross‑team privilege leakage.

Related CloudNinjas coverage: AWS.

What This Means For Practitioners

Running a short, competitive lab is an effective way to surface real‑world integration challenges that pure theory hides. Teams should consider adopting a similar format when introducing new AI services: define a concrete, measurable task, use native AWS services, and provide a shared scoreboard to drive rapid iteration. Prior to launch, map out IAM boundaries, set up centralized logging, and enable cost‑tracking tags. After the event, capture the top solutions as reference implementations for future client deliveries.

Originally published atAWS Machine Learning Blog