Automating IoT firmware update orchestration with an AI agent on AWS

Automating Internet of Things (IoT) firmware update orchestration with an AI agent helps fleet operators deploy updates confidently at scale. Firmware updates require careful sequencing: the right devices first, at the right time, with continuous health monitoring and immediate rollback when needed. Today, operations teams manually plan deployment waves, monitor success rates, and make rollback decisions. As fleet size grows, the manual approach becomes a bottleneck.

In this post, we show you how to build an AI agent that autonomously orchestrates firmware deployments across your IoT fleet. The agent selects deployment waves based on device risk profiles and schedules around production windows. It monitors rollout health in real time and triggers automatic rollback when failure rates exceed thresholds.

The challenge: Firmware deployments at fleet scale

Firmware updates to IoT fleets involve decisions that grow more complex as your fleet scales:

Wave planning: Deciding which devices go first requires context. Best practice is to start with low-risk devices (development, non-production), then canary groups (small production subset), then full rollout. What counts as low-risk depends on device type, location, production schedule, and criticality.
Timing: Updates that restart devices shouldn’t happen during peak production. Each facility has different schedules, time zones, and maintenance windows.
Health monitoring: After each wave, you need to verify devices come back online, report correct firmware version, and continue operating normally. For illustrative purposes, consider a fleet of 5,000 devices. A 2 percent failure rate in a canary group of 50 is one device, but a 2 percent failure rate fleet-wide is 100 bricked devices.
Rollback decisions: The threshold for stopping and rolling back depends on the failure mode: a connectivity-lost failure might be transient (wait), but a boot-loop failure is permanent (rollback immediately). An AI agent adds failure-type reasoning on top of the percentage-based cancellation that AWS IoT Jobs provides natively.

An AI agent makes these decisions dynamically based on real-time fleet state rather than static rules.

Solution overview

The solution uses an AI agent as the decision-maker and AWS IoT Jobs for the actual firmware delivery. The agent plans deployment waves, monitors health after each wave, and decides whether to proceed, pause, or roll back. AWS Step Functions orchestrates the end-to-end workflow, and Amazon DynamoDB stores the fleet inventory and deployment history.

Architecture

The following diagram shows the AI-driven firmware update orchestration architecture. The workflow moves through three phases: deployment planning (steps 1–3), wave execution (steps 4–6), and health assessment with conditional rollback (steps 7–9).

Figure 1: AI-driven firmware update orchestration architecture on AWS

Deployment planning

The following steps describe how the agent plans deployment waves based on the fleet profile.

An operator uploads a new firmware binary to Amazon Simple Storage Service (Amazon S3) and triggers the agent through Amazon EventBridge with target criteria (device type, minimum version, target version).
The agent queries Amazon DynamoDB for the fleet inventory. For each device, it retrieves type, location, firmware version, criticality, last update result, and production schedule. For the DynamoDB table schema and access patterns, see the stacks/firmware_agent_stack.py file in the sample code repository.
The agent uses Amazon Bedrock to plan deployment waves based on the fleet profile. The resulting plan includes a canary wave (5 percent of low-risk devices), an early adopter wave (20 percent mixed), and full rollout waves (remaining 75 percent in batches of 500). Before including a device in a wave, the agent evaluates the device’s production schedule. Each device defines active hours by facility and time zone. If a device is currently within its production window, the agent excludes it from the current wave and defers it to a later batch. This prevents firmware restarts from disrupting active manufacturing processes.

Production window scheduling

Before including a device in any wave, the agent evaluates the device’s production schedule using the get_device_risk_profile tool. Each device record in DynamoDB contains a production_schedule field with start_hour, end_hour, and timezone values. The agent converts the current time to the device’s local timezone and checks whether it falls within the active window.

If a device is currently within its production window, the agent excludes it from the current wave and defers it to a later batch. For overnight schedules that span midnight (for example, start_hour: 22, end_hour: 6), the agent handles the wraparound correctly. This prevents firmware restarts from disrupting active manufacturing processes.

You can observe this behavior in the Step Functions execution history. When the agent plans waves, devices in active production windows don’t appear in the wave’s thing_names list. The get_device_risk_profile tool returns an is_in_production_window boolean for each device, which the agent uses during wave composition.

Wave execution

AWS Step Functions executes the deployment plan. For each wave, it creates an AWS IoT job targeting the selected devices with the firmware from Amazon S3.
AWS IoT Jobs delivers the firmware to each device, managing the download, verification, and installation lifecycle. Devices report status back to AWS IoT Core as one of: queued, in-progress, succeeded, failed, rejected, or timed-out.
Step Functions waits for the wave to complete (devices report final status) or times out after a configurable window (default: 30 minutes per wave).

Health assessment

After each wave completes, the deployment agent queries AWS IoT Core for device shadows and telemetry to assess fleet health: success count, failure count, and failure types (connectivity-lost, boot-loop, version-mismatch).
The agent uses Amazon Bedrock to reason over the health data and decide: proceed to next wave, pause for investigation, or rollback the current wave.

Rollback

When the agent decides to roll back, it invokes the rollback_wave tool. This tool cancels the in-progress AWS IoT job and creates a new job, targeting only the failed devices with the previous firmware version. Devices that successfully updated remain on the new firmware. The agent notifies the operator through Amazon Simple Notification Service (Amazon SNS) with an explanation of the failure mode, affected device count, and the firmware version restored. No subsequent waves execute after a rollback.

Step-by-step deployment

In this tutorial, you deploy the firmware orchestration agent and test it with a simulated fleet of 100 devices.

Prerequisites

Verify that you have the following:

An AWS account with AWS Cloud Development Kit (AWS CDK) bootstrapped.
Python 3.13 or later.
AWS credentials configured.
Amazon Bedrock access with AWS Identity and Access Management (IAM) permissions to invoke Anthropic Claude Haiku 4.5 (or your preferred foundation model).
An IoT fleet registered on AWS IoT Core (or use the included simulator).

The sample-iot-firmware-orchestration-agent contains the complete implementation, including the CDK stack, agent tools, Step Functions workflow, and fleet simulator scripts. Clone the repository to get started:

git clone https://github.com/aws-samples/sample-iot-firmware-orchestration-agent.git
cd sample-iot-firmware-orchestration-agent

To deploy the infrastructure

The AWS CDK stack deploys the core orchestration components: AWS Step Functions state machine, deployment agent AWS Lambda function, and Amazon DynamoDB tables (fleet inventory and deployment history). It also provisions the supporting infrastructure: Amazon S3 bucket for firmware binaries, Amazon SNS topic for notifications, and Amazon EventBridge trigger.

cdk deploy FirmwareAgentStack

Verify the stack deployed successfully by checking the AWS CloudFormation console for the FirmwareAgentStack in CREATE_COMPLETE status.

Deployment agent configuration

The deployment agent uses the Strands Agents SDK (pip install strands-agents), an open source Python framework for building AI agents that integrates with Amazon Bedrock. Amazon Bedrock provides access to foundation models (FMs) from multiple providers. This solution uses Anthropic Claude Haiku 4.5 for its fast inference speed and cost efficiency for agentic workloads. The agent invokes the model through Amazon Bedrock with the fleet inventory as context, so it can reason about device risk profiles and generate an optimal wave plan.

The following table describes the five tools the agent exposes to Amazon Bedrock:

Tool	Purpose
`get_fleet_inventory`	Query DynamoDB for devices eligible for update (by type, version)
`get_device_risk_profile`	Retrieve criticality, production schedule, and update history per device
`get_wave_health`	Get success/failure/timeout counts from a running AWS IoT job
`create_deployment_wave`	Create an AWS IoT job targeting a specific set of devices
`rollback_wave`	Cancel the current job and redeploy previous firmware to failed devices

The get_device_risk_profile tool retrieves device metadata from the fleet inventory: criticality level, hardware revision, production schedule, and last update result. In the sample, these attributes are populated by the fleet simulator script. In a production environment, you would populate these fields from your existing asset management, serialization, and install-tracking systems. The criticality designation determines wave ordering: LOW-criticality devices go into the canary wave first, accepting the highest risk of failure on devices where the operational impact is lowest.

This sample uses explicit device enumeration (SNAPSHOT targeting) when creating AWS IoT jobs. In practice, firmware-over-the-air (FOTA) jobs at scale use static and dynamic Thing Groups to define update targets. Dynamic Thing Groups automatically include devices matching a query (for example, all devices with firmware_version < 1.2.0 and device_type = sensor-v2). This handles devices that come online mid-rollout. For more information about Thing Group targeting patterns, refer to Design IoT Jobs for rapid large-scale device updates with advanced device group target patterns and Using dynamic thing groups to continuously update software on devices.

The agent’s system prompt encodes the wave planning rules: canary at 5 percent, early adopter at 20 percent, then full rollout. It also encodes health assessment thresholds: proceed above 98 percent, pause at 95–98 percent, and rollback below 95 percent or on boot-loop detection.

The agent is configured in lambda/deployment_agent/agent.py. It uses the Strands Agents SDK BedrockModel class to invoke Anthropic Claude Haiku 4.5 (model ID: us.anthropic.claude-haiku-4-5-20251001-v1:0) through the Amazon Bedrock ConverseStream API. The Agent class registers the five tools previously listed and passes the system prompt containing the wave planning rules and decision thresholds.

To test with simulated fleet

The repository includes a fleet simulator that registers virtual devices and simulates update outcomes:

# Register 100 simulated devices with varied risk profiles
python scripts/setup_fleet.py --devices 100

# Trigger a deployment (success scenario - 99% success rate)
python scripts/trigger_deployment.py --scenario successful_rollout

# Trigger a deployment (rollback scenario - firmware causes boot loops on 8% of devices)
python scripts/trigger_deployment.py --scenario canary_failure

# Trigger a deployment (partial failure - connectivity issues in one facility)
python scripts/trigger_deployment.py --scenario partial_connectivity_loss

The following example shows the expected behavior for the canary_failure scenario:

Agent plans three waves: canary (five devices), early adopter (20 devices), full (75 devices).
Wave 1 (canary) executes: 4 succeed, 1 fails with boot-loop.
Agent assesses: 1/5 = 20 percent failure rate, and boot-loop detected.
Agent decision: ROLLBACK – “Boot-loop failure detected in canary wave. 20 percent failure rate exceeds 5 percent threshold. Rolling back affected device and halting deployment. Firmware might have a compatibility issue with device hardware revision.”
Agent rolls back the failed device, cancels remaining waves, sends Amazon Simple Notification Service (Amazon SNS) notification to operator.

The partial_connectivity_loss scenario demonstrates threshold-triggered rollback distinct from boot-loop detection. In this scenario, connectivity failures in one facility produce a success rate between 95–98 percent. The agent pauses and retries up to three times. If the success rate doesn’t improve after three consecutive pauses, the agent escalates to rollback based purely on the threshold rule rather than a specific failure type.

Monitoring wave health

After triggering a deployment, you can monitor the agent’s health assessment in real time through the AWS Step Functions console. Each execution shows the wave-by-wave progression with the agent’s decision at each checkpoint.

The following JSON shows the summary that the get_wave_health tool returns after each wave completes:

{
  "wave": 1,
  "total": 5,
  "succeeded": 4,
  "failed": 1,
  "timed_out": 0,
  "success_rate": 0.80,
  "failure_types": {
    "boot_loop": 1,
    "connectivity_lost": 0,
    "version_mismatch": 0
  }
}

The agent uses this data along with the decision framework to determine the next action. You can view the full reasoning chain in the Step Functions execution history. This includes the agent’s natural language explanation for each decision it makes at every wave checkpoint.

Deployment decision flowchart

The agent applies the following decision logic after each wave completes: if the success rate exceeds 98 percent and no boot-loop failures exist, it proceeds. If any boot-loop failure is detected, it rolls back immediately regardless of other metrics. If the success rate falls between 95–98 percent with only connectivity-lost failures, it pauses and retries after 10 minutes. Mixed failure types in the 95–98 percent range trigger a rollback. Success rates below 95 percent trigger an immediate rollback.

The agent encodes this logic in its system prompt but can reason beyond it for novel situations. For example, if all failures share the same hardware revision, the agent pauses to investigate a compatibility issue rather than performing a blanket rollback.

The following diagram shows the agent’s decision logic after each wave completes:

Deployment decision flowchart showing proceed, pause, and rollback paths based on success rate and failure type

Figure 2: Deployment decision flowchart

How this differs from AWS IoT Jobs built-in cancellation configuration

AWS IoT Jobs provides a native cancellation configuration that cancels a job when a failure percentage threshold is exceeded. The AI agent extends this foundation with contextual reasoning:

Capability	AWS IoT Jobs cancellation configuration	AI orchestration agent
Trigger condition	Static percentage threshold (for example, >10% failed)	Reasons over failure TYPES (boot-loop, connectivity-lost, timeout)
Context awareness	Same threshold for all devices in a job	Considers device criticality, production schedule, historical success rate
Wave planning	Rate-based rollout with configurable rate limits	Plans canary, then early adopter, then full rollout based on risk profiles
Novel situations	Percentage-based pass/fail evaluation	Reasons over patterns (for example, “all failures are same hardware revision, investigate compatibility”)
Action options	Cancel only	Proceed, pause and investigate, rollback specific devices, retry transient failures
Scheduling	Time-window scheduling only	Avoids production peaks, coordinates across facilities and time zones

AWS IoT Jobs handles firmware delivery as the execution layer. On top of this, the agent adds a decision layer, proceeding, pausing, or rolling back based on semantic reasoning rather than static counts. They are complementary: the agent creates and manages AWS IoT Jobs rather than replacing them.

Responsible AI considerations

With this solution, you deploy an agentic system that autonomously decides whether to advance, hold, or revert firmware deployments. The following guardrails support responsible operation:

Encoded thresholds: The agent’s system prompt contains explicit decision thresholds (proceed above 98 percent, rollback below 95 percent) and a restricted tool allowlist (only five tools). The agent can’t create, delete, or modify devices. Wave sizes are capped at 500 devices maximum.
Human oversight: For production fleets, we recommend adding human approval gates before full-rollout waves. The canary and early-adopter waves validate automatically, but a human operator can review the agent’s reasoning before approving deployment to the full fleet.
Audit trail: Every agent decision, including the natural language reasoning chain, is logged in the AWS Step Functions execution history. Operators can review why the agent decided to advance, hold, or revert at each checkpoint. Structured JSON logs in Amazon CloudWatch provide deployment_id and wave_number correlation for end-to-end tracing.

Security considerations

When deploying firmware to IoT devices, implement the following security controls:

Firmware signing: Sign firmware binaries with Code Signing for AWS IoT before uploading to S3. Devices verify the signature before applying the update, preventing tampered binaries from being installed.
Encryption: Enable server-side encryption with AWS Key Management Service (SSE-KMS) encryption on the Amazon S3 bucket storing firmware binaries. Enforce HTTPS-only access through a bucket policy. AWS IoT Jobs delivers firmware URLs over Transport Layer Security (TLS).
AWS Identity and Access Management (IAM) least privilege: The deployment agent Lambda role needs only iot:CreateJob, iot:DescribeJob, iot:CancelJob, dynamodb:Query, dynamodb:GetItem, and bedrock:InvokeModel. It doesn’t need iot:DeleteThing, iot:UpdateCertificate, or administrative permissions.
Device authentication: Devices authenticate to AWS IoT Core using X.509 certificates provisioned during manufacturing. Authenticated devices can receive job documents and download firmware from the presigned S3 URL.

Cost considerations

The AI orchestration layer adds minimal cost on top of the standard AWS IoT Jobs deployment. For a fleet of 1,000 devices deployed in three waves (canary, early adopter, full rollout), the agent reasoning cost is approximately $0.02. Amazon Bedrock charges apply per agent decision point (one per wave), not per device. AWS IoT Jobs has no per-execution charge. Standard AWS IoT Core messaging fees apply for device status updates.

For larger fleets of over 5,000 devices with five waves, the total orchestration overhead remains approximately under $0.05 per deployment. The cost scales with the number of wave decisions, not fleet size.

Clean up

To avoid ongoing charges, delete the deployed resources:

cdk destroy FirmwareAgentStack

# Remove simulated devices
python scripts/cleanup_fleet.py

Conclusion

In this post, you learned how to build an AI agent that plans deployment waves, evaluates production schedules to avoid disruptions, and monitors rollout health. The agent makes autonomous decisions to advance, hold, or revert based on failure-type analysis. The agent starts with a conservative 5 percent canary and scales up only when the data supports it. Because the agent evaluates health data programmatically as soon as a wave completes, deployment decisions happen without waiting for manual review cycles.

The test scenarios in this post exercise 100 simulated devices. For larger production fleets, the architecture scales horizontally. AWS IoT Jobs handles delivery at fleet scale, and the agent’s reasoning cost applies to each wave rather than each device.

You can apply this pattern to other phased fleet-wide operations, such as configuration changes, certificate rotation, and feature flag rollouts. This is a reference implementation. Before deploying to production, conduct a thorough security review. Implement additional controls such as human approval gates before full-rollout waves. Test extensively in non-production environments.

Clone the sample-iot-firmware-orchestration-agent and configure the wave rules and health thresholds for your fleet.

The Internet of Things on AWS – Official Blog