Strands Agents es un SDK de Python de código abierto para crear agentes de IA que usan herramientas. En IoT, el término puede referirse a patrones distintos: monitorizar sensores, procesar datos en un dispositivo de borde o coordinar robots conectados. Elegir entre ellos depende de qué tarea debe seguir funcionando cuando falla la conexión.
Tres formas de llevar Strands a IoT
Un agente de IoT recibe información de dispositivos y puede usar herramientas para responder o actuar. En los ejemplos descritos por AWS y por el proyecto Strands Agents aparecen tres enfoques separados: la arquitectura Adaptive Agentic Intelligence Framework (AAIF), una implementación agrícola con AWS IoT Greengrass y una malla de robots con Strands Robots.
La diferencia práctica está en el trabajo que cada patrón asigna al dispositivo y a la nube. AAIF combina procesamiento local con análisis opcional en Amazon Bedrock. El ejemplo agrícola conecta sensores a un Raspberry Pi 5 y reserva Bedrock para analizar imágenes de plantas. Strands Robots se centra en conectar varios dispositivos físicos para que se descubran y coordinen.
AAIF combina herramientas locales y análisis en la nube
AWS describe AAIF como una arquitectura de tres capas: un modelo de lenguaje pequeño (SLM) dirige las solicitudes, las herramientas locales resuelven tareas rutinarias y Amazon Bedrock atiende algunos análisis más complejos. En el ejemplo, llama3.2:1b hace de orquestador local, mientras que llama3.2-vision analiza imágenes en el dispositivo y get_expert_insights llama a Bedrock.
La telemetría del ejemplo no procede de sensores: get_device_telemetry selecciona datos simulados de un diccionario escrito en Python. AWS señala que una implementación de producción conectaría sensores reales. Por tanto, el ejemplo sirve para mostrar cómo se enrutan tareas, no para observar lecturas de una instalación IoT.
El recorrido AAIF indica Python 3.10 o posterior y requiere credenciales de AWS y acceso a modelos de Bedrock para la herramienta en la nube. AWS cobra por las invocaciones de modelos de Bedrock según cada solicitud. El ejemplo deja el identificador del modelo como marcador y contiene comentarios //, que no son comentarios válidos en Python; tal como está, ese fragmento no es código listo para ejecutar.
Greengrass mantiene algunas tareas en el dispositivo
En una implementación agrícola distinta, AWS describe Strands Agents como un componente de Greengrass en un Raspberry Pi 5 con 4 u 8 GB de RAM. El ejemplo conecta un sensor digital de humedad del suelo al GPIO 17. Las solicitudes y respuestas del agente circulan por MQTT, un protocolo de mensajería, mediante los temas gg/monitor/request y gg/monitor/response.
El dispositivo realiza las lecturas del sensor y las consultas sobre su estado localmente. AWS describe que esas tareas continúan si se pierde la conexión; el análisis de imágenes de plantas depende de Amazon Bedrock y requiere acceso a la red. Así, una interrupción afecta a la función de visión en la nube, pero no a las tareas locales que contempla este ejemplo.
El diseño también separa el control de la cámara: el panel web la gestiona y ofrece capturas mediante localhost:8080/snapshot, que puede consultar el agente. La configuración descrita incluye Raspberry Pi OS de 64 bits, una cámara módulo v2 o v3, Python 3.9 o posterior y AWS CLI 2.0 o posterior. Son requisitos de esta implementación agrícola, distintos de los que AWS enumera para AAIF.
Strands Robots coordina dispositivos conectados
Strands Robots aborda otra tarea: conectar robots y permitir que los agentes descubran pares, consulten su estado y coordinen operaciones. El proyecto describe Zenoh como transporte predeterminado entre dispositivos de una red local y AWS IoT Core para flotas distribuidas o gestionadas desde la nube.
El ejemplo de un brazo Universal Robots UR10e se ejecuta en una simulación MuJoCo, que no requiere una GPU ni hardware físico para ese caso. La compatibilidad con Model Hardware Standard (MHS), un estándar para que los agentes interactúen con equipos mediante operaciones de lectura y escritura con límites declarados, se describe como previa al lanzamiento y disponible en una vista previa de investigación limitada.
Qué patrón encaja con cada tarea
| Patrón | Tarea descrita | Trabajo local | Papel de la nube o de la red |
| AAIF | Monitorización y análisis de telemetría e imágenes | Orquestación, telemetría y análisis local de imágenes | Bedrock atiende análisis complejos y necesita conexión |
| Greengrass agrícola | Humedad del suelo, estado del dispositivo y salud de las plantas | Lecturas del sensor y consultas de estado | Bedrock analiza imágenes de plantas y requiere conexión |
| Strands Robots | Descubrimiento y coordinación de varios robots o dispositivos | Zenoh conecta pares en una red local | AWS IoT Core conecta flotas distribuidas o gestionadas desde la nube |
Para monitorizar sensores y conservar sus lecturas locales durante una caída de red, el ejemplo de Greengrass delimita con claridad qué tareas continúan. AAIF muestra cómo derivar algunas solicitudes a un servicio en la nube, aunque su telemetría de demostración es simulada. Si el objetivo es coordinar robots, Strands Robots plantea una malla de dispositivos, no una variante del monitor de sensores.
