Un agente IoT basato su Strands combina un modello linguistico con strumenti software per lavorare con dispositivi connessi. Gli esempi descrivono tre architetture diverse: monitoraggio con elaborazione locale e cloud, un sistema agricolo su dispositivo edge e una rete per coordinare robot.
La scelta dipende dal compito: leggere sensori, analizzare immagini di piante oppure far comunicare una flotta di robot richiede componenti e connessioni differenti.
Tre architetture, tre compiti
| Architettura | Attività descritta | Lavoro locale | Ruolo del cloud e connettività |
| Adaptive Agentic Intelligence Framework (AAIF) | Monitoraggio di telemetria e analisi di immagini | Un modello locale orchestra le richieste; strumenti e modelli locali elaborano alcuni compiti | Amazon Bedrock gestisce le analisi complesse che gli vengono inoltrate e richiede connettività |
| Esempio agricolo con AWS IoT Greengrass | Lettura dell’umidità del suolo, stato dei dispositivi e analisi delle immagini delle piante | Un agente su Raspberry Pi 5 legge il sensore e gestisce le attività locali, anche senza connessione | Amazon Bedrock analizza le immagini delle piante; questa funzione richiede accesso alla rete |
| Strands Robots | Scoperta e coordinamento di robot e altri dispositivi | Zenoh collega i dispositivi sulla stessa rete locale | AWS IoT Core è descritto per le flotte distribuite o gestite dal cloud |
AAIF separa l’orchestrazione dall’analisi
Nel walkthrough pubblicato il 21 ottobre 2026, AWS descrive l’AAIF come un’architettura a tre livelli: orchestrazione intelligente, elaborazione locale e analisi nel cloud. Il modello locale llama3.2:1b coordina le richieste; Ollama esegue i modelli locali, tra cui llama3.2-vision per l’analisi delle immagini, mentre uno strumento dedicato può inoltrare a Amazon Bedrock le richieste più complesse.
L’esempio non legge sensori reali: la funzione get_device_telemetry sceglie a caso un dispositivo da un dizionario Python con valori simulati. AWS indica che una versione di produzione si collegherebbe a sensori effettivi. Perciò il walkthrough illustra il flusso tra strumenti locali e cloud, ma i valori mostrati non sono misurazioni ambientali.
Per provare l’esempio AAIF, AWS elenca Python 3.10 o successivo, Ollama, i modelli locali e credenziali AWS con accesso ai modelli di Amazon Bedrock per la funzione cloud. Le invocazioni di Bedrock sono soggette a costi per richiesta. Nel codice pubblicato, modelId è un segnaposto e // non è una sintassi valida per i commenti Python: quel frammento non è pronto da eseguire così com’è.
Greengrass porta sensori e agenti sul dispositivo
L’implementazione agricola descritta da AWS è distinta dall’esempio AAIF. Usa un Raspberry Pi 5 con AWS IoT Greengrass, un sensore digitale di umidità del suolo collegato al pin GPIO 17 e componenti separati per l’agente Strands e la dashboard. La configurazione indicata comprende Raspberry Pi OS a 64 bit, una fotocamera Camera Module v2 o v3 e Python 3.9 o successivo.
I componenti si scambiano richieste e risposte tramite i topic MQTT gg/monitor/request e gg/monitor/response. La dashboard gestisce la fotocamera e rende disponibili le istantanee all’indirizzo locale localhost:8080/snapshot, così l’agente può richiedere un’immagine senza accedere direttamente alla fotocamera.
In questo schema, la lettura del sensore e le verifiche sullo stato del dispositivo proseguono anche quando manca la connessione. L’analisi delle immagini delle piante, affidata ad Amazon Bedrock, richiede invece l’accesso alla rete. Il confine è concreto: una perdita di connettività non interrompe le operazioni locali descritte, ma impedisce la funzione che dipende dal servizio cloud.
Strands Robots coordina dispositivi in rete
Strands Robots affronta un problema diverso dal monitoraggio dei sensori: far scoprire e coordinare più robot o dispositivi. Il progetto indica Zenoh come trasporto predefinito per i dispositivi sulla stessa rete locale e AWS IoT Core per le flotte distribuite o gestite dal cloud. Gli agenti possono interrogare lo stato dei dispositivi, inviare istruzioni e coordinare azioni di gruppo.
L’esempio di simulazione usa un braccio robotico Universal Robots UR10e in MuJoCo e, per quella simulazione, non richiede una GPU né hardware fisico. Il progetto descrive inoltre il Model Hardware Standard (MHS), un’interfaccia con primitive read e write, limiti dichiarati, interblocchi e arresti di emergenza. Il supporto MHS in Strands Robots è presentato come pre-release nell’ambito di un’anteprima di ricerca limitata.
