Um agente IoT com Strands é um programa que combina um modelo de linguagem e ferramentas para interpretar dados ou executar tarefas em dispositivos conectados. Os exemplos da AWS e do projeto Strands Agents descrevem três usos diferentes: monitorar sensores com processamento local e na nuvem, operar sensores na borda com Greengrass e coordenar robôs em rede.
A diferença prática está no trabalho que precisa ser feito e no que depende de conexão. A telemetria do exemplo AAIF é simulada; já a implementação agrícola da AWS descreve leituras locais de sensores que continuam mesmo sem acesso à nuvem.
Três padrões para tarefas diferentes
| Padrão | Tarefa descrita | Processamento ou comunicação local | Papel da nuvem e limite de conectividade |
| AAIF | Monitorar dados de dispositivos e analisar imagens | Um modelo pequeno coordena ferramentas locais de telemetria e visão | A análise complexa selecionada pode seguir para o Amazon Bedrock e depende de conexão |
| Greengrass para agricultura | Consultar umidade do solo e saúde das plantas e dos dispositivos | O Raspberry Pi 5 lê o sensor e executa tarefas locais de monitoramento | A análise de imagens de plantas usa o Amazon Bedrock e não funciona sem acesso à rede |
| Strands Robots | Coordenar vários robôs ou dispositivos físicos | O Zenoh conecta participantes na mesma rede local | O AWS IoT Core atende à comunicação de frotas distribuídas ou gerenciadas pela nuvem |
AAIF combina orquestração local e análise na nuvem
O Adaptive Agentic Intelligence Framework (AAIF), descrito pela AWS, separa o trabalho em três camadas: orquestração inteligente, processamento local e processamento na nuvem. Orquestração é a escolha e o encaminhamento da tarefa apropriada. No exemplo, o modelo local llama3.2:1b coordena ferramentas e modelos executados com Ollama; uma solicitação mais complexa pode seguir para o Amazon Bedrock.
A divisão permite manter algumas tarefas perto dos dispositivos. A ferramenta analyze_camera_feed, por exemplo, usa o modelo local llama3.2-vision, enquanto get_expert_insights chama o Bedrock. Mas a ferramenta get_device_telemetry não consulta sensores reais: ela seleciona dados de uma lista fixa de demonstração. A AWS diz que uma versão de produção conectaria a ferramenta aos sensores de verdade.
O trecho de Bedrock do exemplo não está pronto para execução tal como aparece: o identificador do modelo é um marcador genérico, e os comentários com // não são sintaxe válida em Python. A demonstração exige credenciais da AWS e acesso ao modelo no Bedrock para usar a ferramenta na nuvem.
Greengrass leva o monitoramento até o dispositivo
Na implementação agrícola descrita pela AWS, o Strands Agents roda como componente do AWS IoT Greengrass em um Raspberry Pi 5. Um sensor digital de umidade do solo se conecta ao pino GPIO 17, uma entrada e saída de uso geral do dispositivo. O agente consulta as leituras e métricas do próprio equipamento localmente.
Os componentes trocam solicitações e respostas por MQTT, um protocolo de mensagens entre dispositivos e serviços. O exemplo usa os tópicos gg/monitor/request e gg/monitor/response. Para imagens, o painel controla a câmera e fornece capturas pelo endereço local localhost:8080/snapshot; assim, o componente do agente não tenta acessar a mesma câmera ao mesmo tempo.
Sem conexão com a nuvem, leituras do sensor e consultas sobre a saúde do dispositivo continuam no exemplo. A análise da imagem da planta depende do Amazon Bedrock e deixa de funcionar sem acesso à rede. A AWS também informa que as chamadas ao Bedrock são cobradas por solicitação.
A configuração descrita usa Raspberry Pi 5 com 4 GB ou 8 GB de memória, Raspberry Pi OS de 64 bits, câmera módulo v2 ou v3, Python 3.9 ou posterior e AWS CLI 2.0 ou posterior. Esses requisitos pertencem à implementação agrícola; o exemplo AAIF lista Python 3.10 ou posterior.
Strands Robots coordena dispositivos em rede
Strands Robots aborda outra tarefa: descobrir e coordenar vários robôs ou dispositivos físicos, em vez de apenas monitorar telemetria. O projeto descreve o Zenoh como transporte padrão entre participantes na mesma rede local e o AWS IoT Core para frotas distribuídas entre redes ou gerenciadas pela nuvem.
O exemplo de simulação usa um braço robótico Universal Robots UR10e no MuJoCo e, nesse modo, não exige GPU nem equipamento físico. Já a integração com o Model Hardware Standard (MHS), padrão para interação com equipamentos físicos, aparece como pré-lançamento em uma prévia de pesquisa limitada. O MHS define operações de leitura e escrita, limites declarados, intertravamentos e paradas de emergência.
Qual padrão combina com cada tarefa?
Para dividir o monitoramento entre ferramentas locais e análise remota, o AAIF descreve a arquitetura correspondente. Para manter leituras de sensores e consultas de saúde do dispositivo no equipamento, a implementação com Greengrass mostra uma fronteira concreta: o monitoramento local continua, enquanto a análise de imagens depende do Bedrock. Para coordenar robôs na mesma rede, o exemplo do projeto usa Zenoh; para frotas distribuídas, descreve o AWS IoT Core.
Esses padrões não são partes de uma única configuração. A escolha depende de a aplicação precisar interpretar telemetria, continuar tarefas locais durante uma interrupção de rede ou coordenar dispositivos físicos. A integração MHS no Strands Robots permanece em prévia de pesquisa limitada.
