Author: Make.com Service User

O problema do modelo único para tudo

Quem já construiu agentes de Inteligência Artificial (IA) conhece bem o dilema: toda requisição — seja uma simples consulta de status ou uma análise complexa — acaba sendo enviada para o mesmo modelo grande e caro hospedado na nuvem. Essa abordagem de tamanho único eleva os custos de API, introduz latência imprevisível e torna o sistema completamente dependente de conectividade.

Para endereçar esse problema, a AWS publicou um artigo técnico apresentando o Adaptive Agentic Intelligence Framework (AAIF), construído sobre o Strands Agents. A ideia central é simples: usar Modelos de Linguagem Pequenos (SLMs) para resolver tarefas rotineiras localmente, e acionar modelos de nuvem via Amazon Bedrock apenas quando a complexidade realmente exigir. Essa lógica tem respaldo acadêmico: pesquisadores Belcak et al. da NVIDIA argumentam que SLMs são “suficientemente poderosos, inerentemente mais adequados e necessariamente mais econômicos para muitas invocações em sistemas agênticos”.

Arquitetura em três camadas

O AAIF organiza o processamento de IA em três camadas, cada uma otimizada para um tipo diferente de tarefa:

• Orquestração inteligente: um SLM leve (llama3.2:1b) atua como camada de decisão. Ele classifica cada requisição recebida e a direciona para a camada adequada, sem regras fixas codificadas manualmente.
• Processamento local: tarefas rotineiras como recuperação de telemetria de dispositivos e análise de imagens são tratadas por SLMs rodando no próprio hardware, via Ollama. Essas tarefas completam com baixa latência e sem dependência de nuvem.
• Processamento em nuvem: análises de padrões complexos e recomendações estratégicas são enviadas para modelos de fronteira no Amazon Bedrock, que oferecem raciocínio de múltiplos passos e contexto mais amplo.

No centro da arquitetura está o agente Strands, que se conecta a um runtime Ollama hospedando tanto o modelo orquestrador de 1 bilhão de parâmetros quanto o modelo de visão. O agente expõe três ferramentas: get_device_telemetry para recuperação local de dados de sensores, analyze_camera_feed para processamento de visão no dispositivo via llama3.2-vision, e get_expert_insights que aciona o Amazon Bedrock via boto3 para análises complexas.

O framework se adapta às restrições do ambiente de implantação sem exigir reestruturação de infraestrutura. Ele roda em dispositivos de borda como um Raspberry Pi com 8 GB de memória, em implantações totalmente em nuvem onde toda inferência passa pelo Amazon Bedrock, ou em configurações híbridas que combinam velocidade local com raciocínio em nuvem.

Pré-requisitos para o walkthrough

Para seguir o passo a passo técnico descrito no artigo original, os seguintes componentes são necessários:

• Uma conta AWS com acesso ao Amazon Bedrock configurado na região desejada.
• Python 3.10+ instalado.
• Ollama instalado com os modelos llama3.2:1b (orquestrador) e llama3.2-vision (análise visual) disponíveis.
• Strands Agents instalado: pip install strands-agents strands-agents-tools.
• Interface de Linha de Comando da AWS (AWS CLI) configurada com credenciais apropriadas.
• Boto3 instalado: pip install boto3.

Configurando o ambiente

O primeiro passo é criar o diretório do projeto e iniciar o servidor Ollama:

mkdir aaif-demo && cd aaif-demo
ollama serve

Em seguida, baixar os modelos necessários:

ollama pull llama3.2:1b
ollama pull llama3.2-vision

Implementando as ferramentas de processamento local

O Strands Agents utiliza o decorador @tool para definir as capacidades que os agentes podem invocar. A primeira ferramenta recupera dados de telemetria de dispositivos. Em produção, ela se conectaria a sensores reais de Internet das Coisas (IoT); no walkthrough, usa dados simulados:

from strands import Agent, tool
import random

DEVICE_TELEMETRY = {
    "sensor-001": {
        "device_type": "Temperature Sensor",
        "location": "Building A - Floor 2",
        "temperature": 72.5,
        "humidity": 45.2,
        "status": "normal"
    },
    "camera-001": {
        "device_type": "Security Camera",
        "location": "Main Entrance",
        "fps": 30,
        "resolution": "1080p",
        "status": "recording"
    },
    "hvac-001": {
        "device_type": "HVAC Controller",
        "location": "Building A - Central",
        "set_temp": 71.0,
        "current_temp": 72.5,
        "mode": "cooling",
        "status": "active"
    }
}

@tool
def get_device_telemetry() -> str:
    """Retrieve current telemetry data from connected IoT devices."""
    device_id = random.choice(list(DEVICE_TELEMETRY.keys()))
    device_data = DEVICE_TELEMETRY[device_id]
    report = f"Device: {device_id} ({device_data['device_type']})\n"
    report += f"Location: {device_data['location']}\n"
    report += f"Status: {device_data['status']}\n"
    for key, value in device_data.items():
        if key not in ['device_type', 'location', 'status']:
            report += f"{key}: {value}\n"
    return report

A segunda ferramenta realiza análise visual usando um SLM local. O modelo llama3.2-vision roda inteiramente no hardware local, o que significa que feeds sensíveis de câmera não saem do dispositivo:

import ollama

@tool
def analyze_camera_feed(image_path: str) -> str:
    """Analyze visual data from cameras using local vision model."""
    stream = ollama.chat(
        model='llama3.2-vision',
        messages=[{
            'role': 'user',
            'content': 'Describe this image in one sentence. '
                       'What are the 3 most important things you see?',
            'images': [image_path]
        }],
        stream=True,
    )
    full_response = ""
    for chunk in stream:
        chunk_content = chunk['message']['content']
        print(chunk_content, end='', flush=True)
        full_response += chunk_content
    return f"Object Detection Report:\n{full_response}"

Implementando o processamento em nuvem

Para análises que requerem raciocínio mais amplo, uma terceira ferramenta aciona o Amazon Bedrock. Ela é invocada apenas quando o orquestrador determina que os modelos locais não conseguem resolver a requisição:

import boto3

@tool
def get_expert_insights(context_data: str, question: str) -> str:
    """Get advanced analysis and expert recommendations for complex questions via Amazon Bedrock."""
    client = boto3.client("bedrock-runtime", region_name="us-east-1")
    conversation = [
        {
            "role": "user",
            "content": [
                {"text": f"Context: {context_data}\n\nQuestion: {question}"}
            ],
        }
    ]
    response = client.converse(
        modelId="<", //Refer model id [details](https://docs.aws.amazon.com/bedrock/latest/userguide/foundation-models-reference.html)
        messages=conversation,
        inferenceConfig={
            "maxTokens": 512,
            "temperature": 0.5,
            "topP": 0.9
        }
    )
    response_text = response["output"]["message"]["content"][0]["text"]
    return f"Expert Analysis:\n{response_text}"

Configurando o agente com orquestração inteligente

O núcleo do AAIF é a configuração do agente Strands. Ele utiliza um SLM local (llama3.2:1b) como orquestrador, via provedor Ollama:

from strands.models.ollama import OllamaModel

model = OllamaModel(
    model_id="llama3.2:1b",
    host="http://localhost:11434",
    params={
        "max_tokens": 300,
        "temperature": 0.3,
    },
)

system_prompt = """You are a monitoring assistant for operational facilities.
You have access to device telemetry tools, analysis capabilities, and expert insights to help monitor operations effectively.

When users ask for:
- Device status or telemetry: use get_device_telemetry
- Image or data analysis: use analyze_camera_feed
- Expert advice or complex questions: use get_expert_insights

Always return the complete tool results directly to the user."""

agent = Agent(
    model=model,
    system_prompt=system_prompt,
    tools=[
        get_device_telemetry,
        analyze_camera_feed,
        get_expert_insights,
    ],
)

O orquestrador baseado em SLM analisa cada requisição e a encaminha para a ferramenta adequada sem correspondência de palavras-chave codificada. O roteamento acontece pelo entendimento contextual do modelo. A tabela abaixo resume o comportamento esperado:

• “Verificar status do dispositivo” → SLM local, baixa latência
• “Analisar esta imagem” → IA de visão local, baixa latência
• “Quais estratégias de otimização você recomenda?” → Nuvem (Amazon Bedrock), latência maior por round-trip de rede

Com o agente configurado, a interação é direta:

# Local processing - device telemetry
response = agent("What's the current status of our devices?")
print(response)

# Local processing - vision analysis
response = agent("Analyze the camera feed from camera-001")
print(response)

# Cloud processing - complex analysis
response = agent(
    "Based on current telemetry patterns, "
    "what optimization strategies do you recommend?"
)
print(response)

Adaptando para diferentes cenários de implantação

A arquitetura AAIF suporta três configurações principais, ajustáveis apenas trocando a configuração do modelo:

Totalmente em nuvem

Quando não há hardware de borda disponível, toda inferência passa pelo Amazon Bedrock com escalonamento automático:

from strands.models import BedrockModel

model = BedrockModel(
    model_id="<", //Refer model id [details](https://docs.aws.amazon.com/bedrock/latest/userguide/foundation-models-reference.html)
    region_name="us-east-1"
)

Híbrido (configuração padrão do AAIF)

Mantém o orquestrador SLM local e aciona modelos de nuvem apenas para requisições que excedem a capacidade local. Cerca de 80% do tráfego não atinge um endpoint de API pago, o que representa economia significativa de custos.

Totalmente local (air-gapped)

Para ambientes com requisitos estritos de soberania de dados ou sem conectividade, um modelo local maior substitui a ferramenta de nuvem. Um modelo de 3 bilhões de parâmetros consegue lidar com tarefas moderadamente complexas que o orquestrador de 1B escalaria para a nuvem. A contrapartida é menor profundidade de raciocínio nas consultas mais difíceis:

model = OllamaModel(
    model_id="llama3.2:3b",  # Larger local model for complex tasks
    host="http://localhost:11434",
)

Próximos passos: servidores MCP para chamadas centralizadas de ferramentas

A implementação descrita usa chamadas de ferramentas locais definidas diretamente no código do agente. Para implantações em produção com múltiplos agentes compartilhando ferramentas entre serviços, o artigo recomenda expor essas ferramentas como servidores do Protocolo de Contexto de Modelo (MCP). O MCP fornece uma interface padronizada para descoberta e invocação de ferramentas, permitindo centralizar o gerenciamento e reutilizar ferramentas em diferentes agentes.

Na configuração distribuída, o Dispositivo 1 atua como hub orquestrador, rodando o agente Strands com o roteador SLM e uma ferramenta de telemetria local. Ele se conecta via protocolo MCP ao Dispositivo 2, que roda um servidor de processamento de visão de borda com llama3.2-vision, e ao Dispositivo 3, que serve como gateway de análise em nuvem conectado ao Amazon Bedrock. Do ponto de vista do orquestrador, todas as ferramentas remotas aparecem como chamadas de função locais, pois a camada de transporte MCP cuida da serialização e comunicação de rede de forma transparente.

Limpeza do ambiente

Para evitar cobranças futuras, o artigo recomenda os seguintes passos de limpeza:

• Desabilitar o acesso ao modelo no Amazon Bedrock: abrir o console do Amazon Bedrock, acessar “Model access” e revogar o acesso ao Amazon Nova Lite. Consulte Gerenciar acesso a modelos no Guia do Usuário do Amazon Bedrock para detalhes.
• Parar o servidor Ollama e remover os modelos para liberar espaço em disco (aproximadamente 2 GB):

  ollama stop
  ollama rm llama3.2:1b
  ollama rm llama3.2-vision

• Deletar o diretório do projeto se o código de exemplo não for mais necessário:

  rm -rf aaif-demo

IA responsável no caminho de inferência em nuvem

Antes de executar esse padrão em produção, o artigo recomenda adicionar controles de IA responsável ao caminho de inferência em nuvem, já que essas requisições carregam saídas de ferramentas, dados recuperados e entradas do usuário. É possível anexar Amazon Bedrock Guardrails ao BedrockModel do Strands com um ID e versão de guardrail. Ele então aplica filtros de conteúdo para categorias prejudiciais, filtros de injeção de prompt e verificações de fundamentação contextual que bloqueiam respostas não suportadas pelos dados de origem. Para aplicar as mesmas políticas à camada de SLM local, basta chamar a API ApplyGuardrail standalone nas entradas e saídas — garantindo que toda requisição siga um único padrão de segurança, independentemente de qual modelo a processa.

Aplicações além do monitoramento de IoT

O padrão arquitetural descrito vai muito além do cenário de monitoramento de IoT usado como referência. Uma organização de saúde poderia rodar monitoramento de pacientes localmente enquanto roteia suporte a diagnósticos para modelos em nuvem. Uma empresa de serviços financeiros poderia processar transações on-premises e reservar capacidade de nuvem para análise de risco. Uma equipe de manufatura poderia rodar modelos de visão para controle de qualidade na borda enquanto envia requisições de otimização para a nuvem.

Para saber mais sobre como construir agentes com Strands Agents, consulte a documentação do Strands Agents. Para informações sobre os modelos de fundação disponíveis, acesse o Amazon Bedrock.

Fonte

Adaptive agentic intelligence framework using Strands Agents (https://aws.amazon.com/blogs/machine-learning/adaptive-agentic-intelligence-framework-using-strands-agents/)

Da prova de conceito à produção: onde os sistemas multi-agente travam

Criar um agente de Inteligência Artificial (IA) funcional ficou relativamente simples. Com frameworks open source e serviços de nuvem, é possível ter algo rodando em poucos dias — algumas chamadas de ferramentas, um prompt bem escrito e o resultado já impressiona. O problema começa quando a equipe tenta levar esse agente para além do piloto e aplicá-lo em processos reais de negócio.

Quem já passou por isso reconhece a frustração: o agente não segue a lógica de negócio, pula etapas de validação, ignora casos de borda. Você ajusta o prompt, troca o modelo, adiciona exemplos — e os mesmos problemas voltam. Isso acontece porque agentes não executam uma sequência fixa de instruções: eles tomam decisões com base no contexto. Prompt sozinho não resolve. É preciso projetar como o agente raciocina, quando ele verifica e o que faz quando algo dá errado.

Com esse diagnóstico em mente, a equipe de Arquitetura de Soluções da AWS construiu o Deep Insight, um sistema multi-agente de nível produtivo. A AWS publicou uma série de três posts documentando o que aprendeu ao longo desse processo. Este artigo cobre a Parte 1 da série, que mapeia os cinco desafios centrais e mostra como cada camada da solução os endereça — do Strands Agents SDK e Amazon Bedrock ao Amazon Bedrock AgentCore, Application Load Balancer e AWS Fargate.

O que é o Deep Insight

O Deep Insight é um sistema multi-agente que transforma análises de dados complexas em relatórios automatizados. Dado um arquivo CSV e um prompt em linguagem natural, uma hierarquia de agentes especializados — Coordinator (Coordenador), Planner (Planejador), Supervisor, Coder (Programador), Validator (Validador), Reporter (Relator) e Tracker (Rastreador) — colabora para carregar os dados, executar análises, gerar gráficos, validar cálculos e produzir um relatório profissional no formato .docx com citações.

O vídeo de demonstração web do Deep Insight mostra o fluxo completo, desde o upload dos dados e a revisão do plano de análise até o streaming em tempo real e o download do relatório final. O projeto está disponível no GitHub com três opções de implantação:

• Versão Self-Hosted: roda localmente via Interface de Linha de Comando (CLI), com acesso total ao código de cada agente, prompt e fluxo. Configuração em cerca de 10 minutos, ideal para desenvolvimento. Uma demonstração está disponível no YouTube.
• Versão Web: interface no navegador para upload de dados, revisão de planos com Humano no Ciclo (HITL — Human-in-the-Loop) e download de relatórios, sem necessidade de escrever código.
• Versão Managed AgentCore: implantação em produção com Amazon Bedrock AgentCore, executando os agentes em uma Nuvem Privada Virtual (VPC — Virtual Private Cloud) privada, com isolamento de sessão por usuário e um interpretador de código customizado no AWS Fargate.

As três versões compartilham a mesma arquitetura multi-agente, então um agente validado em desenvolvimento pode ser implantado em produção sem alterações.

Os cinco desafios e como a arquitetura os resolve

A tabela abaixo resume os cinco desafios e as tecnologias escolhidas para cada um:

• “Como controlar o fluxo de execução entre múltiplos agentes?” → Strands Agents SDK com o padrão Graph e o padrão Agents-as-Tools.
• “Qual Modelo de Linguagem de Grande Escala (LLM — Large Language Model) cada agente deve usar?” → Amazon Bedrock com modelos Claude selecionados por papel: Haiku para roteamento, Opus para planejamento, Sonnet para execução.
• “Como operar um agente de forma confiável em produção?” → Amazon Bedrock AgentCore com runtime gerenciado, isolamento de sessão e implantação em VPC privada.
• “Como mitigar riscos de segurança ao executar código gerado por IA?” → AWS Fargate + Application Load Balancer (ALB) com contêineres sandbox efêmeros por sessão.
• “Como monitorar e gerenciar o sistema?” → Amazon DynamoDB + Amazon Simple Notification Service (Amazon SNS) + Amazon Cognito com painel administrativo e alertas de falha.

Design do sistema multi-agente

O Deep Insight organiza oito agentes em três camadas. Cada agente opera em seu próprio contexto independente, executa apenas suas tarefas especializadas e repassa somente os resultados comprimidos para o próximo.

Dois padrões do Strands Agents SDK combinados controlam esse fluxo. O primeiro é o padrão Graph, que define a ordem de execução dos agentes como um grafo direcionado: as requisições fluem do Coordinator para o Planner, depois para o Plan Reviewer e então para o Supervisor, com uma ramificação condicional que retorna ao Planner em caso de revisão. O segundo é o padrão Agents-as-Tools, que permite ao Supervisor invocar agentes especializados como ferramentas apenas quando necessário, minimizando o uso de contexto.

Camada 1 — Do Coordinator ao Plan Reviewer

Esta camada transforma uma requisição do usuário em um plano de execução aprovado. O Coordinator é o ponto de entrada: responde diretamente a saudações simples e encaminha tarefas complexas ao Planner. A decisão de usar o modelo Claude Haiku aqui é deliberada — como o Coordinator apenas classifica requisições, não faz sentido incorrer no custo de um modelo mais potente.

O Planner usa Claude Opus com Extended Thinking (Raciocínio Estendido) ativado para decompor a análise em 5 a 10 etapas concretas, organizadas em um checklist atribuído a cada agente especializado. Sem esse planejamento prévio, o agente tomaria todas as decisões em tempo de execução, e qualquer correção no meio do caminho invalidaria o trabalho anterior.

O Plan Reviewer é um nó de Humano no Ciclo (HITL): apresenta o plano ao usuário e coleta aprovação ou feedback de revisão. Se houver revisão, o fluxo retorna ao Planner. Um contador máximo de revisões (MAX_PLAN_REVISIONS) evita loops infinitos. Na versão Web, um modal no navegador exibe o plano com um countdown de 300 segundos que aprova automaticamente caso não haja resposta.

Camada 2 — O Supervisor como orquestrador

O Supervisor executa o plano do Planner em ordem, invocando os agentes da Camada 3 como ferramentas registradas via Tool Use (Uso de Ferramentas). Seu prompt de sistema define regras estritas: ordem obrigatória de execução, regra de conclusão de seção (não avança enquanto todos os itens do checklist não estiverem marcados como concluídos) e preservação de contexto ao passar variáveis entre os agentes.

Camada 3 — Agentes especializados

Cada agente da Camada 3 é uma instância independente com seu próprio prompt de sistema, modelo e conjunto de ferramentas:

• Coder: carrega dados, escreve e executa código Python de análise, gera gráficos (.png) e deixa metadados de cálculo para verificação.
• Validator: reexecuta cada cálculo dos metadados a partir dos dados originais. Correspondências dentro de 0,01 são aprovadas; divergências são sinalizadas. Os cálculos verificados vão para citations.json.
• Reporter: lê os resultados e as citações para gerar o relatório final em DOCX em duas versões — com e sem citações.
• Tracker: atualiza o checklist após cada agente usando apenas raciocínio do LLM, sem ferramentas, adicionando pouco overhead.

Configuração de modelo por agente

A seleção de modelo para cada papel é uma decisão arquitetural, não apenas de preferência. O Coordinator usa Haiku (sem cache, executa uma vez). O Planner usa Opus com Extended Thinking (planejamento profundo). O Supervisor, o Coder e o Reporter usam Sonnet com Prompt Caching (Cache de Prompt), reduzindo custos de tokens de entrada em até 90% em chamadas repetidas. O Validator e o Tracker operam com contextos diferentes a cada execução, tornando o cache ineficaz para eles.

Implantação e operações em produção

Execução segura de código gerado por IA

O agente Coder escreve e executa Python para análise de dados. Em produção, executar código gerado por LLM diretamente em um servidor é arriscado: o modelo pode deletar arquivos do sistema, esgotar recursos em um loop infinito ou acessar dados de outros usuários. O Deep Insight resolve isso com contêineres efêmeros por sessão no AWS Fargate, acessados via ALB.

O AgentCore runtime, o ALB e as tarefas do Fargate rodam dentro da mesma VPC privada. Endpoints de VPC conectam esses componentes ao Amazon Simple Storage Service (Amazon S3), ao Amazon Bedrock e ao Amazon Elastic Container Registry (Amazon ECR) sem trafegar pela internet pública. Grupos de segurança restringem quais componentes podem alcançar os contêineres do interpretador de código, e funções do AWS Identity and Access Management (IAM) limitam cada componente apenas aos recursos da AWS que ele precisa.

O fluxo de execução usa dois passos: o código gerado pelo LLM é codificado em base64, enviado via HTTP, gravado em arquivo (Passo 1) e depois executado via subprocess (Passo 2). Cookies de sessão do ALB (sticky sessions) garantem que o agente retorne ao mesmo contêiner em chamadas subsequentes. Ao final da análise, artefatos como gráficos e relatórios são enviados ao Amazon S3, e os contêineres encerram automaticamente após uma hora.

A AWS recomenda adicionar Amazon Bedrock Guardrails como controle de IA responsável em implantações de produção: filtros de conteúdo e detecção de ataques de prompt nos dados enviados pelos usuários, além de verificações de fundamentação contextual nas saídas dos agentes.

Visibilidade operacional

O Deep Insight oferece uma interface web baseada em FastAPI que se comunica com o backend via protocolo nativo do AgentCore. Os usuários monitoram o progresso via Server-Sent Events (SSE) em streaming e podem aprovar ou revisar o plano via modal (HITL). O relatório final pode ser baixado diretamente pela interface, que suporta coreano e inglês.

Para equipes que precisam de visibilidade operacional mais ampla, há um painel de operações opcional com rastreamento de tarefas no Amazon DynamoDB, alertas de falha por e-mail via Amazon SNS e um painel administrativo protegido por autenticação via JSON Web Token (JWT) com Amazon Cognito.

A arquitetura além da análise de dados

O design hierárquico do Deep Insight não se limita à geração de relatórios analíticos. Dois casos validam isso:

LG Electronics: a divisão de vendas da LG na Coreia construiu o ChatInsight sobre a mesma arquitetura multi-agente. Análises que levavam 3 dias passaram a ser concluídas em 30 minutos — uma melhoria de produtividade de 288 vezes. Profissionais de marketing sem conhecimento de SQL conseguem deixar o agente explorar dados e propor estratégias. Mais detalhes estão disponíveis no post sobre o Sistema de Extração de Insights da LG Electronics no AWS Tech Blog.

TechRecon (re:Invent 2025): apresentado na sessão SNR203 do AWS re:Invent 2025, o TechRecon aplica a arquitetura do Deep Insight à inteligência tecnológica estratégica. Dado uma empresa e setor, um agente Researcher coleta tendências, o Coder analisa, o Validator verifica e o Reporter produz documentos de posicionamento técnico. A arquitetura é praticamente idêntica à do Deep Insight — basta trocar os papéis e prompts dos agentes para resolver problemas completamente diferentes. Mais informações no repositório do TechRecon no GitHub e no vídeo da sessão no AWS re:Invent.

Conclusão

Colocar um agente em produção não é uma questão de capacidade do modelo — é uma questão de arquitetura. O Deep Insight oferece uma resposta concreta para os cinco desafios centrais: o padrão Graph do Strands Agents SDK para controle de fluxo e HITL, o padrão Agents-as-Tools para orquestração sob demanda, modelos Claude do Amazon Bedrock selecionados por papel, Amazon Bedrock AgentCore para runtime gerenciado, AWS Fargate + ALB para execução isolada de código e DynamoDB + Cognito + SNS para visibilidade operacional.

O projeto é open source. Explore o código, adapte para o seu domínio e acompanhe as próximas partes da série: a Parte 2 aborda técnicas de Context Engineering (Engenharia de Contexto) para superar os limites da janela de contexto, e a Parte 3 cobre a implantação e operação em produção com o AgentCore. O workshop está disponível em inglês e coreano.

Fonte

5 production challenges in multi-agent systems and how Deep Insight solved them (https://aws.amazon.com/blogs/machine-learning/5-production-challenges-in-multi-agent-systems-and-how-deep-insight-solved-them/)

Visão geral

A AWS publicou um guia técnico mostrando como treinar o modelo Qwen3 usando o framework torchtitan sobre o hardware AWS Trainium. O ponto central da abordagem é que o TorchNeuron registra o Trainium como um dispositivo PyTorch nativo, o que permite ao torchtitan utilizá-lo pelas interfaces padrão do PyTorch — sem adaptações especiais no fluxo de trabalho.

O walkthrough cobre três configurações distintas, todas executadas em uma única instância trn2.48xlarge: treinamento via Hugging Face Transformers v5, treinamento com a implementação nativa Qwen3 do torchtitan, e uso de kernels NKI (Interface de Kernel Neuron) para camadas de Mistura de Especialistas (MoE). As três abordagens compartilham o mesmo padrão de lançamento com torchrun e a mesma estrutura de configuração.

Pré-requisitos

Para reproduzir os exemplos, a AWS recomenda usar uma instância trn2.48xlarge com a AWS Deep Learning AMI para Neuron ou um container de treinamento PyTorch Neuron. Ambos os ambientes já incluem o driver, runtime e compilador Neuron necessários.

Antes de instalar o torchtitan-neuron, vale verificar se o ambiente já o contém:

python3 -c "import torchtitan, torchtitan_neuron; print(torchtitan.__version__, torchtitan_neuron.__file__)"

As versões utilizadas no guia são as seguintes:

• Instância: trn2.48xlarge — 16 aceleradores Trainium2, 128 NeuronCores físicos
• NeuronCores lógicos: 64 com LNC=2
• torch / torch_neuronx: 2.14.0 / 2.14.3
• transformers: 5.16.0
• torchtitan-neuron: release-2.33 (0.2.2+neuron.1)

Quando o torch_neuronx está instalado, o TorchNeuron registra o Trainium como dispositivo neuron e o torchtitan o detecta na inicialização. No modo eager, o Neuron compila as operações conforme são executadas. Com torch.compile, o Neuron compila o grafo capturado.

Para instalar o torchtitan-neuron preservando o build Neuron do torch:

git clone https://github.com/aws-neuron/torchtitan-neuron
cd torchtitan-neuron
pip install -r requirements.txt

Antes de iniciar o treinamento, é necessário baixar os artefatos do modelo Qwen3 do Hugging Face Hub:

hf download Qwen/Qwen3-4B-Instruct-2507 \
  --local-dir "$PWD/assets/hf/Qwen3-4B-Instruct-2507"

Configuração 1: Treinamento com Hugging Face Transformers v5

Na primeira configuração, o Transformers v5 constrói o Qwen3 via AutoModelForCausalLM. A definição do modelo vinda do Hub é utilizada nos passos de forward e backward. O modelo é selecionado pelo seu ID no Hub.

Crie o arquivo neuron_qwen3.py na raiz do repositório torchtitan-neuron e adicione as importações, o caminho dos artefatos e a configuração base:

import os
from torchtitan.experiments.transformers_modeling_backend.config_registry import (
    transformers_modeling_backend_full,
)
from torchtitan.experiments.transformers_modeling_backend.configs import (
    TransformersBackendConfig,
)

ASSETS = os.path.abspath("./assets/hf/Qwen3-4B-Instruct-2507")

def v5_qwen3_4b() -> TransformersBackendConfig:
    config = transformers_modeling_backend_full()
    config.hf_model = "Qwen/Qwen3-4B-Instruct-2507"
    config.hf_assets_path = ASSETS
    config.dataloader.dataset = "c4_test"
    config.training.steps = 10
    config.training.local_batch_size = 1
    config.parallelism.data_parallel_shard_degree = -1
    return config

torchrun --nproc_per_node=64 --rdzv_backend c10d --rdzv_endpoint localhost:0 \
  --local-ranks-filter 0 --role rank --tee 3 \
  -m torchtitan.train --module neuron_qwen3 --config v5_qwen3_4b

Esse comando lança 64 processos de treinamento — um por NeuronCore lógico. O parâmetro --module neuron_qwen3 importa o módulo de configuração local, e --config v5_qwen3_4b seleciona a função de configuração.

Carregamento e salvamento de checkpoints Hugging Face

Para fazer fine-tuning a partir de pesos publicados, basta habilitar o carregamento de checkpoint e apontar initial_load_path para o diretório de artefatos. O adaptador de dicionário de estado ajusta o prefixo model. e lida com embeddings compartilhados. O checkpoint final é salvo no formato safetensors do Hugging Face.

def v5_qwen3_4b_finetune() -> TransformersBackendConfig:
    config = v5_qwen3_4b()
    config.checkpoint.enable = True
    config.checkpoint.folder = "checkpoint_qwen3_4b_ft"
    config.checkpoint.initial_load_path = ASSETS  # absolute path required
    config.checkpoint.initial_load_in_hf = True
    config.checkpoint.initial_load_model_only = True
    config.checkpoint.last_save_in_hf = True
    config.checkpoint.last_save_model_only = True
    return config

A loss no primeiro passo serve como verificação rápida de que os pesos publicados foram carregados corretamente. No run validado pela AWS, o Qwen/Qwen3-4B-Instruct-2507 produziu loss de 6,54 a partir dos pesos publicados e de 12,43 a partir de inicialização aleatória. Após o treinamento, o checkpoint exportado pode ser carregado com AutoModelForCausalLM e load_state_dict sem chaves faltando ou inesperadas — exceto lm_head.weight, que o Qwen3-4B vincula aos embeddings de token.

Configuração 2: Treinamento com os modelos nativos do torchtitan

Na segunda configuração, o torchtitan constrói seu próprio Qwen3Model nativo. Adicione as importações e a função de configuração ao neuron_qwen3.py:

from torchtitan.models.qwen3 import model_registry
from torchtitan.models.qwen3.config_registry import qwen3_32b
from torchtitan.trainer import Trainer

def native_qwen3_4b() -> Trainer.Config:
    config = qwen3_32b()
    config.model_spec = model_registry("4B", attn_backend="sdpa")
    config.hf_assets_path = ASSETS
    config.dataloader.dataset = "c4_test"
    config.training.steps = 10
    config.training.local_batch_size = 1
    config.training.global_batch_size = 64
    config.parallelism.data_parallel_shard_degree = -1
    return config

torchrun --nproc_per_node=64 --rdzv_backend c10d --rdzv_endpoint localhost:0 \
  --local-ranks-filter 0 --role rank --tee 3 \
  -m torchtitan.train --module neuron_qwen3 --config native_qwen3_4b

O campo config.model_spec seleciona a classe do modelo e define como o torchtitan fragmenta o modelo e mapeia as chaves do checkpoint. Aqui, model_registry("4B", attn_backend="sdpa") seleciona a implementação nativa Qwen3 com atenção por produto escalar (SDPA — Scaled Dot Product Attention).

Configuração 3: Kernels NKI para Mistura de Especialistas (MoE)

Na terceira configuração, as camadas de Mistura de Especialistas (MoE) são executadas com kernels escritos em NKI, a linguagem de kernels do Neuron. Adicione as importações e a função de configuração:

from torchtitan.config import CompileConfig
from torchtitan_neuron.models.qwen3.config_registry import qwen3_nki_moe_config

def nki_qwen3_30b_a3b() -> Trainer.Config:
    config = qwen3_nki_moe_config(
        "30B-A3B",
        compile_config=CompileConfig(enable=False, backend="neuron"),
        n_layers=4,
        num_experts=64,
        top_k=4,
    )
    config.hf_assets_path = ASSETS
    return config

torchrun --nproc_per_node=64 --rdzv_backend c10d --rdzv_endpoint localhost:0 \
  --local-ranks-filter 0 --role rank --tee 3 \
  -m torchtitan.train --module neuron_qwen3 --config nki_qwen3_30b_a3b

Esta configuração usa fragmentação de dados paralelos (data parallel sharding) em 64 ranks com grau de paralelismo tensorial igual a 1. Não utiliza paralelismo de especialistas. O parâmetro num_experts=64 define o número de especialistas no modelo — não o grau de paralelismo entre eles. Definir CompileConfig(enable=False) executa o exemplo em modo eager. O TorchNeuron suporta operadores NKI registrados tanto em execução eager quanto com torch.compile.

O exemplo reduz o Qwen3-30B-A3B para 4 camadas e 64 especialistas para que caiba em uma única instância trn2.48xlarge. Cada token é roteado para 4 especialistas com top_k=4.

Adicionando seu próprio kernel NKI

Em alguns casos, pode ser vantajoso otimizar uma operação para os formatos de tensor específicos do seu modelo. Um kernel especializado pode ajustar seu tiling e movimentação de dados a esses formatos, ou substituir uma sequência crítica de operações PyTorch por um único operador otimizado.

O guia demonstra esse mecanismo usando rope_hf da nkilib.core.embeddings, que espera o layout de tensor do Hugging Face e suporta seu próprio modo backward. Crie o arquivo my_neuron_kernels.py na raiz do repositório:

import torch
from nkilib.core.embeddings.rope_hf import rope_hf
from torch_neuronx import nki_op
from torch_neuronx.nki_hop import wrap_nki
from torch_neuronx.utils import get_logical_neuron_cores

LNC = (int(get_logical_neuron_cores()),)
wrapped_rope = wrap_nki(rope_hf)

@nki_op("my_kernels::rope_fwd")
def rope_fwd(query, key, rope_cache):
    q = query.permute(0, 2, 1, 3).contiguous()
    k = key.permute(0, 2, 1, 3).contiguous()
    cache = rope_cache.reshape(-1, rope_cache.shape[-1])
    q_out, k_out = wrapped_rope[LNC](
        q, k,
        torch.empty_like(q), torch.empty_like(k),
        rope_cache=cache,
    )
    return (
        q_out.permute(0, 2, 1, 3).contiguous(),
        k_out.permute(0, 2, 1, 3).contiguous(),
    )

O torchtitan armazena query e key como [batch, seq, heads, head_dim], enquanto o rope_hf espera [batch, heads, seq, head_dim]. A conversão de layout acontece dentro do operador. Registre também um operador separado para o modo backward, salvando o cache rotacional durante o forward para reutilização:

@nki_op("my_kernels::rope_bwd")
def rope_bwd(grad_query, grad_key, rope_cache):
    gq = grad_query.permute(0, 2, 1, 3).contiguous()
    gk = grad_key.permute(0, 2, 1, 3).contiguous()
    cache = rope_cache.reshape(-1, rope_cache.shape[-1])
    out_q, out_k = wrapped_rope[LNC](
        gq, gk,
        torch.empty_like(gq), torch.empty_like(gk),
        rope_cache=cache,
        backward=True,
    )
    return (
        out_q.permute(0, 2, 1, 3).contiguous(),
        out_k.permute(0, 2, 1, 3).contiguous(),
    )

def _setup_context(ctx, inputs, output):
    ctx.save_for_backward(inputs[2])

def _backward(ctx, grad_query, grad_key):
    (rope_cache,) = ctx.saved_tensors
    grad_q, grad_k = rope_bwd(grad_query, grad_key, rope_cache)
    return grad_q, grad_k, None

rope_fwd.register_autograd(_backward, setup_context=_setup_context)

Em seguida, crie a subclasse NKIRoPE estendendo CosSinRoPE e chame rope_fwd a partir de apply_rotary_emb:

from dataclasses import dataclass
from torchtitan.config import derive, override
from torchtitan.models.common.rope import CosSinRoPE

class NKIRoPE(CosSinRoPE):
    @dataclass(kw_only=True, slots=True)
    class Config(CosSinRoPE.Config):
        pass

    @staticmethod
    def apply_rotary_emb(query, key, rope_cache):
        stride = 128 * LNC[0]
        if query.shape[1] % stride:
            raise ValueError(
                f"rope_hf requires a sequence length that is a multiple of "
                f"128 * LNC={stride}, got {query.shape[1]}"
            )
        q_out, k_out = rope_fwd(query, key, rope_cache)
        return q_out.type_as(query), k_out.type_as(key)

Registre o NKIRoPE como substituto do CosSinRoPE usando o decorator @override:

@override(
    "nki_rope",
    target=CosSinRoPE.Config,
    exact=True,
    description="nkilib rope_hf kernel in place of the PyTorch rotation",
)
def _nki_rope(cfg: CosSinRoPE.Config) -> NKIRoPE.Config:
    return derive(cfg, NKIRoPE.Config)

Para carregar o override customizado, passe o nome do módulo via --override.imports:

torchrun --nproc_per_node=64 --rdzv_backend c10d --rdzv_endpoint localhost:0 \
  --local-ranks-filter 0 --role rank --tee 3 \
  -m torchtitan.train --module neuron_qwen3 --config native_qwen3_4b \
  --override.imports my_neuron_kernels

Antes do início do treinamento, o torchtitan registra cada nó de configuração substituído pelo override. Confirme que a saída contém uma entrada nki_rope para cada camada do Qwen3:

[Override] nki_rope: model_spec.model.layers.0.attention.rope CosSinRoPEConfig -> NKIRoPE.Config
[Override] nki_rope: model_spec.model.layers.1.attention.rope CosSinRoPEConfig -> NKIRoPE.Config

Defina o comprimento de sequência como múltiplo de 128 * LNC — ou seja, 256 quando LNC é 2. Reformate o cache rotacional para [seq, head_dim * 2], com valores cosseno na primeira metade e seno na segunda. O kernel valida essas restrições antes do início do treinamento.

Paralelismo e escalabilidade

As mesmas configurações de paralelismo se aplicam tanto às configurações Transformers quanto às nativas. Uma instância trn2.48xlarge expõe 64 NeuronCores lógicos com LNC=2. Definir data_parallel_shard_degree = -1 fragmenta os parâmetros do modelo, gradientes e estado do otimizador entre todos os ranks iniciados pelo torchrun. Definir config.parallelism.tensor_parallel_degree fragmenta os pesos de cada camada entre um grupo de ranks — cada rank computa uma fatia de cada multiplicação matricial. Com o paralelismo de sequência habilitado por padrão, as camadas de normalização operam em ativações fragmentadas ao longo da dimensão de sequência.

O torchtitan combina paralelismo tensorial com FSDP (Paralelismo de Dados Totalmente Fragmentado) em uma DeviceMesh multidimensional. Acompanhe o uso de HBM (Memória de Alta Largura de Banda) por rank ao aumentar o tamanho do modelo, comprimento de sequência ou tamanho de batch local — esses valores determinam a memória necessária por rank.

Limpeza do ambiente

Se quiser manter os checkpoints gerados, copie-os para armazenamento persistente antes de encerrar o ambiente. Se planeja reutilizar a instância, pare-a. Quando não precisar mais dela, encerre-a.

Conclusão

O AWS Trainium funciona como um dispositivo torchtitan suportado nas três configurações apresentadas. É possível treinar o Qwen3 via Hugging Face Transformers v5, carregando e salvando safetensors publicados diretamente. Também é possível treinar com a implementação nativa Qwen3 do torchtitan definindo config.model_spec. Para modelos com Mistura de Especialistas (MoE), as receitas NKI do torchtitan-neuron estão disponíveis. Para kernels customizados, o registro de overrides permite anexar operadores NKI ao mesmo fluxo de lançamento.

Para orientações de configuração, consulte a documentação do AWS Neuron. Para o código-fonte atual e receitas de treinamento, consulte o repositório torchtitan.

Fonte

Train Qwen3 on AWS Trainium with torchtitan (https://aws.amazon.com/blogs/machine-learning/train-qwen3-on-aws-trainium-with-torchtitan/)

O que mudou no Amazon Polly Generative

A AWS anunciou uma atualização significativa no motor Generative do Amazon Polly, seu serviço gerenciado de conversão de texto em fala. O novo modelo por trás do engine entrega uma saída de voz mais natural, precisa e com baixa latência. A atualização traz 14 novas vozes distribuídas em nove localidades, além de dois novos idiomas — hindi e finlandês — agora disponíveis de forma geral no motor Generative pela primeira vez.

Novas vozes disponíveis

As novas vozes adicionadas ao portfólio incluem:

• Inglês americano: Kenneth e Nate
• Inglês australiano: Russell e Curtis
• Hindi e inglês indiano: Kiara e Arjun
• Alemão: Tina
• Espanhol americano: Carlos
• Português brasileiro: Leo e Carolina
• Coreano: Hyunduk
• Finlandês: Suvi

Um destaque importante para o público brasileiro: duas das novas vozes — Leo e Carolina — são em português brasileiro. Isso amplia as possibilidades de uso do Polly Generative em aplicações voltadas ao mercado nacional.

Melhorias na qualidade da fala

Segundo a AWS, essa atualização funciona como um upgrade direto no modelo, sem necessidade de mudanças na integração existente. As vozes Generative ficaram mais naturais e precisas, especialmente em conteúdos complexos como números, endereços de e-mail e endereços postais, que agora são pronunciados de forma mais confiável. Isso reduz a necessidade de ajustes finos na saída de fala.

O suporte a tags de Linguagem de Marcação para Síntese de Fala (SSML) continua disponível no motor Generative, permitindo o controle da saída de voz da mesma forma que antes.

Casos de uso e aplicações

A API de streaming com baixa latência facilita a construção de experiências em centrais de atendimento, chatbots e aplicações de voz baseadas em Modelos de Linguagem de Grande Escala (LLM) para conversas em tempo real. A variedade e riqueza das opções de voz também são adequadas para cenários de notícias, mídia, entretenimento, e-learning e acessibilidade.

Outro ponto relevante é que este lançamento expande a oferta do Amazon Polly Generative para o AWS GovCloud, oferecendo mais opções para o setor público e indústrias reguladas.

Regiões disponíveis

Todas as novas vozes Generative estão disponíveis nas seguintes regiões da AWS:

• US East (N. Virginia)
• US West (Oregon)
• Europe (Frankfurt)
• Europe (Zurich)
• Europe (London)
• Asia Pacific (Sydney)
• Asia Pacific (Seoul)
• Asia Pacific (Singapore)
• Asia Pacific (Tokyo)
• Canada (Central)
• AWS GovCloud (US-West)

Próximos passos

Para ouvir como as vozes do Polly soam na prática, vale conferir a página de recursos do Amazon Polly. Para mais detalhes sobre as ofertas e uso do serviço, consulte a documentação do Amazon Polly e a página de preços.

Fonte

Polly Generative engine upgraded with more natural speech, 14 new voices, and 2 new languages (https://aws.amazon.com/about-aws/whats-new/2026/10/polly-generative/)

Agentes de IA com contexto real de gestão de trabalho

Agentes de IA são mais úteis quando conseguem atuar sobre o trabalho real que acontece dentro de uma organização. Gestão de trabalho envolve tarefas complexas e multifuncionais — atualizar cronogramas de projetos, reatribuir tarefas, levantar status — e agentes de IA podem ajudar nisso sem que ninguém precise trocar de ferramenta.

A Smartsheet, plataforma de gestão de trabalho para projetos, portfólios e operações, lançou em disponibilidade geral o seu servidor de Protocolo de Contexto de Modelo (MCP). Com o Smartsheet MCP Server, assistentes de IA podem ler, escrever e gerenciar dados do Smartsheet por meio de um protocolo padronizado. O protocolo abrange mais de 40 ferramentas para explorar, criar e gerenciar planilhas, linhas, colunas e automações. É possível atualizar status de tarefas, criar linhas e modificar a estrutura de projetos diretamente por linguagem natural.

O artigo original do blog da AWS apresenta duas formas de conectar esse servidor aos fluxos de trabalho existentes:

• Amazon Quick — um workspace de IA agêntica voltado para usuários de negócio, gerentes de projeto e equipes de operações. Eles podem fazer perguntas, atualizar planilhas e construir dashboards por linguagem natural, sem escrever código.
• Kiro — uma IDE agêntica onde desenvolvedores se conectam ao Smartsheet via MCP para consultar especificações de projetos, atualizar status de tarefas e acompanhar dependências sem sair do ambiente de codificação.

Visão geral da arquitetura

O Smartsheet MCP Server funciona como a camada central de integração que conecta os serviços da AWS. O Amazon Quick e o Kiro se conectam diretamente como clientes MCP. O Amazon Quick atende trabalhadores do conhecimento, gerentes de projeto e equipes de operações que querem consultar, atualizar e automatizar o Smartsheet por linguagem natural. Já o Kiro permite que desenvolvedores referenciem especificações de projetos, atualizem status de tarefas e rastreiem dependências sem sair do fluxo de codificação.

A arquitetura descrita no artigo original mostra o Smartsheet MCP Server no centro, com o Amazon Quick e o Kiro como clientes MCP de um lado, e a API e camada de dados do Smartsheet do outro.

Gestão de sprints com Amazon Quick e Kiro

Para ilustrar, considere uma equipe de engenharia de software que acompanha sua sprint no Smartsheet. Tarefas, responsáveis, status e bloqueios ficam todos em uma planilha de projeto. Veja como cada caminho funciona para a mesma equipe:

Cenário com Amazon Quick: quando um gerente de projeto quer verificar quais tarefas da sprint estão bloqueadas naquela semana, basta perguntar ao Amazon Quick em linguagem natural. O agente de chat do Amazon Quick consulta o Smartsheet MCP Server, busca as linhas relevantes e apresenta um resumo com nomes dos responsáveis e datas de entrega. A resposta é gerada a partir de dados ao vivo do Smartsheet, sem precisar construir relatórios ou dashboards.

Cenário com Kiro: para desenvolvedores que estão corrigindo bugs ou trabalhando em funcionalidades, é possível pedir ao Kiro para buscar a planilha da sprint atual e mostrar as tarefas de backend abertas atribuídas a eles. O Kiro consulta o Smartsheet via MCP e exibe a lista inline. Quando a correção é commitada, um hook do Kiro atualiza automaticamente o status da linha correspondente para “Complete”.

Pré-requisitos

O Smartsheet MCP Server entrega contexto precisamente estruturado, incluindo relacionamentos entre linhas, tipos de colunas, histórico de células e comentários. Isso produz payloads eficientes em tokens, em vez de retornar payloads brutos da API. Essa decisão de engenharia se acumula em redução de custo e melhoria de latência em escala, quando se executam centenas de consultas assistidas por IA em um portfólio de projetos.

Para entender como a Smartsheet construiu seu servidor MCP remoto na AWS, vale conferir o artigo How Smartsheet built a remote MCP server on AWS.

Antes de conectar o Smartsheet MCP Server ao Amazon Quick ou ao Kiro, é necessário ter:

• Uma conta AWS ativa com permissões apropriadas de Gerenciamento de Identidade e Acesso (IAM) para o serviço que será conectado (Amazon Quick ou Kiro).
• Uma conta Smartsheet nos planos Business, Enterprise ou AWM.
• Um Token de Acesso Pessoal do Smartsheet, ou credenciais OAuth se o cliente suportar o fluxo OAuth.
• Para Amazon Quick: permissões de Author ou superiores na conta do Amazon Quick.
• Para Kiro: a IDE Kiro instalada a partir de kiro.dev com Node.js disponível no ambiente.

O Smartsheet MCP Server está disponível em três endpoints regionais. Ele utiliza transporte Streamable HTTP (versões da especificação MCP 2025-06-18 e 2025-03-26) e é autenticado com OAuth 2.0 ou Token de Acesso Pessoal:

• EUA Comercial: https://mcp.smartsheet.com
• EU: https://mcp.smartsheet.eu
• AU: https://mcp.smartsheet.au

Ambas as opções expõem o mesmo conjunto de ferramentas do Smartsheet. A escolha certa depende de onde o trabalho é realizado:

• Amazon Quick — se a necessidade é uma solução totalmente gerenciada e de alcance organizacional que toda a equipe possa usar: sem registro de aplicativo, com OAuth pré-configurado, e que escala para trabalhadores do conhecimento na empresa.
• Kiro — se o usuário é um desenvolvedor que quer algo leve: sem infraestrutura, apenas um arquivo de configuração e um token de acesso pessoal, com escopo limitado ao próprio fluxo de trabalho.

Integração com Amazon Quick

O Amazon Quick inclui o Smartsheet como conector pré-construído em seu diretório. Isso significa que ler status de projetos, atualizar linhas, criar discussões e identificar riscos acontece na mesma interface que os usuários de negócio já utilizam. O Amazon Quick disponibiliza essa integração para toda a organização — de gerentes de projeto e equipes de operações a usuários de negócio que gerenciam trabalho no Smartsheet.

Para adicionar a integração, os passos são:

• No console do Amazon Quick, navegar até Connectors e encontrar o Smartsheet no diretório.
• Selecionar o tile do conector Smartsheet.
• Inserir os detalhes da integração:
  • Name — nome descritivo para a integração com o Smartsheet.
  • Manter as configurações de Connection type e Auth como estão.
  • Base URL — https://mcp.smartsheet.com
  • Client ID — ID do cliente do app registrado nas Smartsheet Developer Tools.
  • Client Secret — segredo do app registrado nas Smartsheet Developer Tools.
  • Token URL — https://api.smartsheet.com/2.0/token
  • Auth URL — https://app.smartsheet.com/b/authorize
• Clicar em Next. Na página Manage Tools & Permissions, visualizar a lista de ferramentas disponíveis e clicar em Next.
• Na página Publish, escolher quem pode acessar a conexão e clicar em Publish.

Após a conexão, o agente de chat do Amazon Quick pode trabalhar com dados do Smartsheet por linguagem natural. Exemplos de prompts mencionados no artigo original:

• “What projects in our portfolio are currently At Risk?”
• “Update the status of the authentication task in the Backend API sheet to Complete.”
• “Create a summary of all overdue items across the Q3 Roadmap and send it to the team.”

Integração com Kiro

O Kiro é o caminho indicado quando desenvolvedores querem ter o contexto de projetos do Smartsheet disponível diretamente no ambiente de desenvolvimento, ao lado do código, sem troca de contexto.

O Kiro é construído em torno de desenvolvimento orientado a especificações. Ele transforma prompts de alto nível em especificações estruturadas e, a partir delas, gera código, documentação e testes. Servidores MCP são a forma como o Kiro obtém contexto do mundo real — conectando-se a documentação, bancos de dados, APIs e sistemas corporativos para fundamentar seu agente em dados ao vivo, em vez de conhecimento do tempo de treinamento.

Uma funcionalidade do Kiro chamada powers é um pacote instalável com um clique que empacota um servidor MCP curado com arquivos de direcionamento e hooks. Isso dá ao agente de codificação do Kiro uma nova capacidade pronta para uso. Para o Smartsheet, configurar a conexão requer apenas um bloco de configuração JSON — a partir daí, o agente do Kiro pode referenciar dados de projetos ao vivo como parte do fluxo de desenvolvimento.

Para conectar o Smartsheet MCP Server ao Kiro, basta adicioná-lo à configuração MCP do Kiro (.kiro/settings/mcp.json para escopo de workspace). Para um passo a passo completo, consultar Getting Started with Kiro and MCP Servers:

{
  "mcpServers": {
    "smartsheet-us": {
      "type": "http",
      "url": "https://mcp.smartsheet.com",
      "headers": {
        "Authorization": "Bearer "
      }
    }
  }
}

Essa configuração utiliza a abordagem de Token de Acesso Pessoal (chave de API). Para implantações em produção, OAuth é recomendado. A variável SMARTSHEET_API_TOKEN deve ser definida com o Token de Acesso Pessoal do Smartsheet no ambiente.

O Kiro carrega servidores MCP como processos em segundo plano na inicialização. Após a inicialização, as ferramentas do Smartsheet ficam disponíveis para o agente do Kiro em todos os modos: chat, planejamento de especificações e automação baseada em hooks. Detalhes completos estão na documentação do Smartsheet MCP Server.

A partir daí, o Kiro pode referenciar dados do Smartsheet como parte dos fluxos de desenvolvimento. Exemplos de prompts mencionados no artigo:

• “Check the Backend API project sheet for any open bugs and generate a prioritized fix list.”
• “Pull the Q3 Roadmap sheet and create a spec for the features marked In Progress.”

Governança corporativa

Para equipes que trabalham em ambientes regulados ou corporativos, o modelo de segurança do Smartsheet MCP Server é construído sobre a mesma infraestrutura e camada de permissões da API REST do Smartsheet. Não se trata de uma nova fronteira de confiança:

• Autenticação OAuth 2.0 e Token de Acesso Pessoal: o método de autenticação é escolhido conforme o suporte do cliente MCP.
• Aplicação de permissões no nível do usuário: agentes só podem acessar dados que o usuário autenticado tem permissão para visualizar. Não há escalação de privilégios por meio de prompts em linguagem natural.
• Controles de IA no nível organizacional: administradores de sistema podem ativar ou desativar funcionalidades de IA globalmente. O acesso a ferramentas de escrita é configurável por grupo de usuários.
• Transporte Streamable HTTP: a liberação em firewall é feita por Nome de Domínio Totalmente Qualificado (FQDN) (mcp.smartsheet.com), não por endereço IP.

Para arquitetos de conformidade, é importante saber que o MCP Server não armazena prompts, e o conteúdo dos prompts permanece entre o cliente de IA e o modelo. O Smartsheet recebe apenas as chamadas de ferramentas estruturadas e seus resultados.

Limpeza de recursos

Para quem seguiu o passo a passo e deseja remover a integração depois:

Amazon Quick:

• No console do Amazon Quick, navegar até Connectors.
• Selecionar o conector Smartsheet.
• Escolher Delete para remover a conexão. Isso revoga o token OAuth e interrompe o acesso do agente aos dados do Smartsheet.

Kiro:

• Abrir o arquivo de configuração MCP (.kiro/settings/mcp.json).
• Remover a entrada smartsheet-us do objeto mcpServers.
• Reiniciar o Kiro para descarregar o servidor.

Próximos passos

Para entender os bastidores de como o servidor funciona, vale consultar How Smartsheet built a remote MCP server on AWS.

Após conectar o Smartsheet MCP Server ao sistema de escolha, o artigo original sugere quatro ações para experimentar:

• Monitorar planilhas de projetos ativos: pedir ao agente de chat para identificar linhas marcadas como Blocked ou At Risk, anotar projetos com comentários de discussão e entregar um resumo estruturado para a equipe. Esse fluxo encadeia get_sheet_summary, search e create_discussion_on_row.
• Reconciliar status de tarefas: o agente pode buscar dados via Smartsheet MCP Server para reconciliar status de tarefas entre o rastreador de issues e o plano de projeto no Smartsheet. Ele pode sinalizar divergências e atualizar as linhas afetadas, usando get_sheet_summary, get_columns, update_rows e create_discussion_on_row em sequência.
• Agregar sinais de saúde do projeto: usar relatórios e dashboards para produzir um briefing estruturado sem coleta manual de dados, utilizando list_reports, get_report, list_dashboards, get_dashboard e search.
• Criar trilha de auditoria: usar o agente para acompanhar cada escrita com um comentário de discussão explicando o que mudou e por quê. Isso cria uma trilha de auditoria legível dentro do Smartsheet, combinando update_rows e create_discussion_on_row.

Todos os quatro padrões funcionam nos dois caminhos apresentados: Amazon Quick para fluxos de trabalho voltados a usuários de negócio e Kiro para ações iniciadas por desenvolvedores.

Para quem estiver construindo algo com Smartsheet MCP e AWS, a Smartsheet Developer Community é um bom ponto de partida para compartilhar experiências e trocar ideias.

Fonte

Work management context for AI agents with Smartsheet MCP on AWS (https://aws.amazon.com/blogs/machine-learning/work-management-context-for-ai-agents-with-smartsheet-mcp-on-aws/)

O que foi anunciado

A AWS anunciou que o Amazon Bedrock passa a suportar saídas estruturadas para todos os modelos Anthropic Claude disponíveis na plataforma. A novidade vale tanto para o endpoint bedrock-runtime quanto para o endpoint bedrock-mantle, cobrindo as duas principais formas de integração com esses modelos.

Como funciona na prática

Independentemente de como a aplicação se comunica com o Claude — seja via boto3 e as APIs do bedrock-runtime, ou pela Messages API através do endpoint bedrock-mantle — agora é possível receber respostas em JSON estritamente compatíveis com um esquema previamente definido.

Na prática, isso elimina a necessidade de escrever lógica customizada de parsing, implementar retentativas por falhas de formato ou fazer pós-processamento dos dados retornados pelo modelo. O JSON que chega já está no formato esperado pela aplicação.

Casos de uso suportados

A AWS destaca que o recurso abre caminho para automação confiável em diversas indústrias. Entre os exemplos citados estão:

• Extração de campos obrigatórios em relatórios financeiros e documentos de conformidade regulatória;
• Conversão de anotações clínicas em registros estruturados para Prontuários Eletrônicos de Saúde (EHR — Electronic Health Records);
• Enriquecimento de catálogos de produtos com dados validados e consistentes;
• Análise de contratos para identificação de termos-chave, partes envolvidas e obrigações;
• Roteamento inteligente de tickets de suporte, garantindo que intenções, sentimentos e entidades estejam sempre alinhados ao modelo de dados da aplicação.

Disponibilidade

O suporte a saídas estruturadas está disponível nas mesmas regiões onde os modelos Claude já podem ser utilizados no Amazon Bedrock. Para verificar a disponibilidade regional, consulte a disponibilidade regional dos modelos Anthropic.

Para se aprofundar na implementação, a AWS disponibiliza a documentação oficial do Amazon Bedrock com detalhes técnicos sobre como utilizar saídas estruturadas com os modelos Claude.

Fonte

Structured outputs for Claude models available on Amazon Bedrock (https://aws.amazon.com/about-aws/whats-new/2026/10/claude-structured-outputs-bedrock/)