Strands Agents is an open-source Python SDK for building AI agents that use tools. For IoT, the examples describe three separate patterns: local and cloud monitoring, edge-based agriculture monitoring, and coordination across robot fleets.
The practical difference is where each task runs. Local processing can keep sensor work going during a network outage, while analysis that calls Amazon Bedrock depends on connectivity.
AAIF splits monitoring between local tools and the cloud
AWS’s Adaptive Agentic Intelligence Framework (AAIF) describes three layers: a small language model (SLM), meaning a compact model, orchestrates requests; local tools handle routine work; and Amazon Bedrock handles selected cloud analysis. The example uses llama3.2:1b through Ollama for orchestration, llama3.2-vision for local image analysis, and a Bedrock call for expert insights.
The AAIF walkthrough’s get_device_telemetry tool reads a hard-coded Python dictionary and randomly selects among three example devices. Its sensor values are simulated, not live readings. AWS says a production version would connect the tool to actual sensors.
The example lists Python 3.10 or newer, AWS credentials and Bedrock model access among its requirements. Its code is not ready to run unchanged: the Bedrock model ID is a placeholder, and the // comment syntax shown in the Python code is invalid.
Greengrass keeps sensor work at the edge
In a separate agriculture example, AWS describes a Strands agent running as an AWS IoT Greengrass component on a Raspberry Pi 5. It reads a digital soil-moisture sensor connected through GPIO pin 17. MQTT, a messaging protocol for connected devices, carries requests on gg/monitor/request and responses on gg/monitor/response.
AWS’s example lists Raspberry Pi 5 models with 4 GB or 8 GB of RAM, 64-bit Raspberry Pi OS, a camera module v2 or v3, Python 3.9 or newer, and AWS CLI 2.0 or later. Those requirements belong to this Greengrass implementation, not the separate AAIF walkthrough.
Local soil-sensor readings and device-health checks continue without network access. Plant-image analysis that calls Amazon Bedrock requires connectivity. The dashboard owns the camera and provides snapshots at localhost:8080/snapshot, so the agent component can use images without competing for camera access. AWS says Bedrock model invocations incur a charge per request.
Strands Robots coordinates connected machines
Strands Robots describes a different task: discovering and coordinating networked robots or devices, rather than monitoring sensor readings. The project describes Zenoh as the default peer-to-peer transport for robots on the same local network, and AWS IoT Core for fleets spread across networks or managed from the cloud.
Its example uses a Universal Robots UR10e in a MuJoCo simulation, which the project says needs neither a GPU nor physical robot hardware. The project also describes agents discovering peers, querying device state, sending instructions, broadcasting, and triggering a fleet-wide emergency stop.
Support for the Model Hardware Standard (MHS), an interface with read and write operations and declared bounds, interlocks, and emergency stops, is described as pre-release functionality in a limited research preview.
Choose by task and connectivity
| Pattern | Task | Local processing or communication | Cloud role and connectivity boundary |
| AAIF | Facility monitoring with telemetry and image analysis | A local model orchestrates requests; local tools handle telemetry and image work | Selected complex analysis goes to Amazon Bedrock and needs network access |
| Greengrass agriculture | Soil moisture, plant images, and device health | Sensor readings and device-health checks run on the Raspberry Pi 5 | Plant-image analysis uses Amazon Bedrock and needs network access |
| Strands Robots | Coordination across robots or connected devices | Zenoh connects peers on the same local network | AWS IoT Core supports distributed or cloud-managed fleets |
