Escopo do projeto
A primeira metade (specs com o Kiro) é adoção guiada do Kiro no time de desenvolvimento: instalação (IDE e CLI), steering (product.md, tech.md, structure.md) com os padrões do time, uma spec real pequena (bug ou funcionalidade de um dia) revisada antes de gerar código, execução de tarefas uma a uma com revisão de código e testes, um hook (ex.: rodar os testes ao salvar) e a política de uso: segredo e dado de cliente fora do prompt, código gerado passa por revisão, modelo fixo nos primeiros ciclos.
A segunda metade (o agente no AgentCore) leva IA para dentro do produto da software house: a primeira funcionalidade com o Amazon Bedrock (ex.: triagem de chamados, rascunho de resposta ao suporte com a documentação do produto via Knowledge Bases, extração de dados de pedidos), com Guardrails, teto de custo e trilha; e, quando a funcionalidade precisa executar ações em outros sistemas, o agente roda no Amazon Bedrock AgentCore: AgentCore Runtime para executar com qualquer framework e modelo, Identity para o agente ter identidade própria e permissões mínimas, Gateway para expor ferramentas (APIs do produto) de forma controlada, Memory para contexto entre sessões, Observability para rastrear cada passo, Policy para regras antes de cada ação e Evaluations para medir qualidade. Humano no circuito para toda ação que muda dados ou dinheiro. O escopo inclui a PoC com critério de sucesso escrito, o desenho de custo por conversa, a conta AWS governada e a operação inicial; refatorar o produto e treinar modelo próprio ficam fora.
Desafio e problemas de hoje
- Requisito chega por WhatsApp, vira código sem spec e volta como retrabalho; o cliente diz "não era isso".
- Time pequeno atende muitos clientes; documentação do sistema está na cabeça de quem o escreveu.
- Clientes pedem "IA no sistema"; o time testa uma API de IA direto do código, sem guardrail, sem teto, com chave no repositório.
- Protótipos de agente que funcionam no notebook e chegam à produção sem identidade, memória, observabilidade nem política.
- Custo por chamada desconhecido; um cliente grande pode estourar a conta de todos.
- Dado de cliente da software house (que é dado de cliente do cliente) em prompt de ferramenta pessoal.
O ambiente de partida (perfil típico deste exemplo)
| Item | O que costuma existir |
|---|---|
| Time | De 3 a 25 desenvolvedores; 1 ou 2 fazem também operação |
| Produto | SaaS ou sistema sob medida, multi-cliente, em .NET, Java, Node, PHP ou Python; API REST; banco relacional |
| Repositório e CI | GitHub, GitLab ou Azure DevOps; testes parciais; deploy manual ou pipeline simples |
| Infra | AWS (EC2, ECS ou EKS, RDS) ou ainda em datacenter ou VPS |
| Uso de IA | Assistentes de código por conta própria; chamadas a API de IA em teste, sem governança |
| Documentação | Desatualizada; conhecimento tácito |
| Dados pessoais | Dos clientes dos clientes (LGPD por contrato, como operador) |
| Restrições | Contratos de nível de serviço, prazos de entrega, custo por cliente, segredo de código e de dados |
Perfil típico, com faixas, construído a partir de projetos desse tipo. O inventário real é o primeiro entregável da descoberta.
Requisitos
- R1Spec (requisitos, design, tarefas) revisada por humano antes de qualquer código gerado; código gerado passa por revisão e testes.
- R2Padrões do projeto versionados e aplicados pela IA (steering); segredo e dado de cliente fora de prompt e de arquivo de contexto.
- R3Primeira funcionalidade com IA no produto com Guardrails, teto de custo por cliente e por dia, e trilha, na conta AWS da software house (ou do cliente, quando o contrato exigir).
- R4Agente em produção com identidade própria, permissões mínimas por ferramenta, memória, observabilidade por passo e política antes de cada ação.
- R5Humano aprova toda ação que muda dados ou dinheiro; o agente começa lendo e recomendando.
- R6Qualidade e custo medidos com conjunto de avaliação versionado, antes de cada mudança de modelo ou prompt.
- R7Região e LGPD registradas por cliente (como operador), e modelo trocável preservando a aplicação.
O que desenhamos para cada requisito
| Requisito | Decisão de arquitetura | Serviço AWS |
|---|---|---|
| R1 | Specs do Kiro: requirements.md, design.md, tasks.md revisados em PR antes do código; tarefas executadas uma a uma; revisão de código e testes obrigatórios no pipeline | Kiro (specs) |
| R2 | Steering em .kiro/steering/ versionado no repositório; hook para rodar testes e varredura de segredo ao salvar; política de uso de uma página; modelo fixo nos primeiros ciclos | Kiro (steering, hooks) |
| R3 | Amazon Bedrock por API gerenciada, modelo escolhido por configuração; Guardrail com filtro de informação sensível (cobre português) e temas negados na camada Standard, que em 06/10/2026 não está disponível em São Paulo e usa inferência cross-region; guardrail criado em São Paulo só aplica temas negados em inglês, francês e espanhol; contador de gasto por cliente e por dia lido antes de cada chamada; chaves fora do código | Amazon Bedrock, Amazon Bedrock Guardrails, Amazon Bedrock Knowledge Bases (documentação do produto), AWS Secrets Manager, Amazon DynamoDB, AWS Budgets |
| R4 | AgentCore Runtime (execução isolada, qualquer framework), AgentCore Identity (identidade do agente e acesso a APIs com credenciais próprias), AgentCore Gateway (ferramentas do produto expostas com controle), AgentCore Memory (contexto entre sessões), AgentCore Observability (rastro por passo), Policy in AgentCore (regras antes da ação) | Amazon Bedrock AgentCore |
| R5 | Ferramentas de escrita só por aprovação: o agente propõe, a pessoa confirma na interface; fase inicial só com ferramentas de leitura | Amazon Bedrock AgentCore (Gateway, Policy), aplicação |
| R6 | Conjunto de 30 a 100 casos reais anonimizados com saída esperada; AgentCore Evaluations e testes automatizados no pipeline; comparação de dois modelos por qualidade e custo | Amazon Bedrock AgentCore (Evaluations), Amazon CloudWatch |
| R7 | Registro de tratamento por cliente; rota de inferência do modelo como configuração por cliente (em 06/10/2026 os modelos de texto atendem São Paulo só por inferência global: endpoint e armazenamento em São Paulo, processamento possível em outra região comercial), registrada no tratamento de cada cliente; CloudTrail e acesso central | Amazon Bedrock (perfis de inferência), AWS CloudTrail, IAM Identity Center |
Arquitetura
Primeira metade: specs e código revisável com o Kiro
Componentes e fluxos deste diagrama
- Usuários
- Amazon Bedrock (aplicação de IA)
- Amazon Bedrock Guardrails
- Equipe de desenvolvimento
- Kiro (IDE com IA)
- Amazon GuardDuty (detecção)
- AWS Security Hub (postura)
- IAM Identity Center (acesso central)
- AWS CloudTrail (registro)
- Fluxos: uso da aplicação; filtros; specs e código; detecção e postura; acesso; registro.
Segunda metade: o agente do produto no Amazon Bedrock AgentCore
Componentes e fluxos deste diagrama
- Usuários do produto
- Aplicação do produto (interface e aprovação humana)
- AgentCore Runtime (execução isolada do agente, qualquer framework)
- AgentCore Gateway (ferramentas do produto expostas com controle)
- AgentCore Identity e Policy (identidade própria do agente e regras antes de cada ação)
- AgentCore Memory e Observability (contexto entre sessões e rastro por passo)
- Amazon Bedrock (modelos)
- Amazon Bedrock Guardrails (filtros)
- Amazon Bedrock Knowledge Bases (documentação do produto)
- APIs do produto e sistemas do cliente
- Amazon CloudWatch (rastros e custo)
- AWS CloudTrail (chamadas)
- Fluxos: tarefa; proposta de ação para aprovação; contexto; raciocínio; filtros; chamada de ferramenta; identidade e política; APIs com permissão mínima; memória e rastro; registro.
Ganhos: o que medimos no projeto
| Indicador | Como medimos | O que muda |
|---|---|---|
| Tempo do pedido ao pull request | Carimbos no repositório, antes e depois do Kiro, em tarefas de tamanho comparável | Requisito vira spec e código revisável, em vez de retrabalho |
| Retrabalho por tarefa | Reaberturas e correções após a entrega, por sprint | O "não era isso" cai, e é medido |
| Cobertura e execução de testes | Pipeline, antes e depois dos hooks | Teste deixa de ser opcional |
| Segredos e dados de cliente em prompts e repositórios | Varredura automática no pipeline | Zero é o único valor aceitável |
| Qualidade do agente no conjunto de avaliação | AgentCore Evaluations e testes, a cada mudança de modelo ou prompt | Mudança de modelo é decisão com número |
| Custo por conversa e por cliente contra o teto | Métricas por chamada; AWS Budgets | Um cliente grande deixa de estourar a conta de todos |
| Ações propostas, aprovadas e rejeitadas por humanos | Contadores da aplicação | Mostra quando o agente está pronto para mais autonomia, e quando ainda não |
| Incidentes atribuídos ao agente | Registro de incidentes | Observabilidade por passo encurta o diagnóstico |
Indicadores que a RFX mede na PoC e em produção. Os valores são da sua empresa; resultados de clientes ficam sob confidencialidade.
Escopo e entregáveis por fase
| Fase | O que acontece | Entregáveis | Duração |
|---|---|---|---|
| Fase 1: adoção do Kiro (oferta Amazon Kiro) | Instalação; steering; spec real pequena revisada; tarefas com revisão e testes; hook; política de uso; modelo fixo; critério de sucesso escrito (ex.: "três tarefas reais entregues por spec com revisão, tempo do pedido ao PR menor que a média do trimestre em tarefas comparáveis, zero segredo em prompt, em 2 semanas") | Repositório com steering e primeira spec; política; medição | 2 semanas |
| Fase 2: primeira funcionalidade com IA no produto (PoC com critério de sucesso escrito) | Caso com dono e volume (ex.: rascunho de resposta ao suporte com a documentação do produto); protótipo no console do Bedrock com dois modelos e 30 exemplos anonimizados; Guardrail; teto por cliente e por dia; conjunto de avaliação; integração mínima | Funcionalidade em beta para um cliente piloto; relatório de qualidade e custo; registro LGPD | De 3 a 4 semanas |
| Fase 3: agente em produção (oferta Assistente ou agente na sua conta AWS) | Desenho do agente com o mínimo de ferramentas; Runtime, Identity, Gateway, Memory, Observability, Policy; ações de escrita só por aprovação; Evaluations no pipeline; runbook; operação inicial | Agente no ar; painel de custo e qualidade; política de autonomia (o que o agente pode fazer sozinho, o que exige aprovação) | De 6 a 10 semanas |
| Fase 4: operação | Revisão mensal de custo e qualidade; ampliação de autonomia por evidência; conjunto de avaliação crescendo com casos reais; transferência ao time da software house com operação assistida | Rotina de operação | Contínua |
Durações típicas, em faixa. O plano do projeto fixa as datas reais.
Algo a mais: o modo autônomo do Kiro na manutenção
Quando o time já trabalha por specs, o modo autônomo do Kiro (frontier agent da AWS, no Kiro Web, disponível nos planos Pro, Pro+, Pro Max e Power e executado em US East (N. Virgínia) em 06/10/2026) recebe tarefas com reprodução clara, como corrigir um bug ou escrever testes para código existente, planeja, codifica num ambiente isolado e abre o pull request para revisão; tudo entra só com aprovação. Para a software house, isso vira capacidade de atender manutenção enquanto o time constrói o novo. A RFX ajuda a escolher quais tarefas vão para o modo autônomo primeiro e como medir.
Cuidados: LGPD, região e revisão humana
- Revisão humana obrigatória em todo código gerado e em toda spec; segredo, chave e dado de cliente fora de prompt, steering e arquivo de contexto; varredura automática no pipeline.
- A software house é operadora de dados dos clientes dos seus clientes: registro de tratamento por cliente, região por cliente como configuração, e contrato com o cliente final atualizado antes de IA tocar dado pessoal.
- Humano no circuito para toda ação que muda dados ou dinheiro; comece com o agente lendo e recomendando; amplie autonomia só com evidência do conjunto de avaliação.
- Região: em São Paulo, o AgentCore oferece Runtime, Memory, Gateway, Identity, Observability, Policy e Evaluations em 06/10/2026; Runtime Instances e a ferramenta de busca na web ficam fora de São Paulo nessa data. Para os modelos vale a tabela de região do tema. A Policy em São Paulo usa inferência global (o processamento pode ocorrer em qualquer região comercial) e entra no registro de tratamento; na Memory, se a inferência cross-region não servir ao cliente, usa-se a estratégia com modelo próprio.
- Meça custo por conversa e por cliente desde o primeiro dia; agente sem teto é a forma mais rápida de surpresa na fatura.
- Leia os termos do plano do Kiro sobre uso de dados e lembre que o Kiro Web processa o repositório em US East (N. Virgínia); fixe o modelo nos primeiros ciclos e compare depois.
- Plugins do Amazon Q Developer para IDE encerram em 30/04/2027; a AWS indica o Kiro.
Perguntas frequentes deste exemplo
São duas metades independentes. O exemplo as junta porque o time que desenvolve por specs tende a construir agentes melhores, e porque a matriz de decisão de IA as indica juntas para quem desenvolve.
Só por ferramentas expostas pelo AgentCore Gateway, com identidade própria e permissão mínima, e, na fase inicial, só com aprovação humana para o que muda dados ou dinheiro. A autonomia cresce por evidência.
Sim; o Amazon Bedrock dá acesso a modelos de vários fornecedores pela mesma API e o AgentCore aceita qualquer modelo e framework. A troca é decisão com número: o conjunto de avaliação roda antes.
Depende do contrato. O desenho funciona nos dois casos; o que muda é quem é o controlador e o operador dos dados, e isso entra no registro de tratamento.
Depende do modelo, do tamanho do contexto e do número de passos do agente. A Fase 2 mede o custo real com dois modelos; a produção tem teto por cliente e por dia.
Serviços AWS deste exemplo
- Kiro
- Amazon Bedrock
- Amazon Bedrock Guardrails
- Amazon Bedrock Knowledge Bases
- Amazon Bedrock AgentCore (Runtime, Identity, Gateway, Memory, Observability, Policy, Evaluations)
- AWS Secrets Manager
- Amazon DynamoDB
- AWS Budgets
- Amazon CloudWatch
- AWS CloudTrail
- IAM Identity Center
Incentivos AWS
A RFX busca para o projeto os programas de incentivo, créditos e verbas de PoC da AWS e da distribuição aplicáveis, sempre sujeitos a aprovação da AWS e da distribuição.