10 arquiteturas de copiloto interno e produtividade
⏱ 20 min·⭐ 80 XP
Pré-requisitos (0/1)0%
- ⬜🤖 10 arquiteturas de agentes que agem em produção(100 Arquiteturas de IA na AWS)
Recomendamos completar os pré-requisitos antes de seguir, mas nada te impede de continuar.
O que une estas dez arquiteturas
Esta é a família com mais retorno e menos apresentação: IA voltada para dentro. O material já está digitalizado — código, runbook, histórico de incidente, decisão de arquitetura —, o usuário é colega e não cliente, e o custo de um erro é uma correção em vez de uma captura de tela no Twitter. É o melhor lugar para começar, e quase sempre não é onde as empresas começam.
A decisão que atravessa as dez: o agente propõe, o humano publica. Revisão de código, atualização de documentação, geração de SQL, modernização de legado — em todos os casos o padrão que funciona coloca a saída num pedido de mesclagem, num painel de aprovação ou numa réplica de leitura, e não direto no destino final.
| # | Problema | A decisão que transfere |
|---|---|---|
| 41 | Modernizar aplicação legada com esforço alto | 40% menos esforço de desenvolvimento e 300 dias de engenharia economizados — em migração, o ganho é em trabalho mecânico |
| 42 | Pergunta repetida no canal do time | Material interno já é digitalizado: é o caso com retorno mais rápido e menos risco de imagem |
| 43 | Revisão de código que não escala | "Revise este PR" produz opinião genérica; "aponte só o que quebra em produção, com arquivo e linha" produz achado acionável |
| 44 | Geração de código sem barreira de segurança | Guardrails em geração de código filtra o que o modelo produz; permissão é que impede o que ele executa |
| 45 | Documentação que envelhece | Documentação gerada sem revisão humana vira ruído — o padrão é o agente PROPOR, não publicar |
| 46 | Onboarding lento de quem entra no time | O que reduz tempo até o primeiro commit é convenção acessível, não mais documentação |
| 47 | Consulta a banco por quem não escreve SQL | Gerar SQL é fácil; a parte difícil é limitar o que ele pode consultar e quanto pode varrer |
| 48 | Análise de conteúdo com revisão manual longa | Redução de 95% no tempo de revisão vem de triar, não de eliminar o revisor |
| 49 | Plataforma de IA para milhares de funcionários | Sem portal, cada aplicação reimplementa autenticação, cota e custo — e nenhuma implementa as três |
| 50 | Agente de engenharia sem observabilidade | "O agente travou" só é investigável com um trecho de rastro por ferramenta |
#41
ProblemaModernizar aplicação legada com esforço alto
A decisão que transfere40% menos esforço de desenvolvimento e 300 dias de engenharia economizados — em migração, o ganho é em trabalho mecânico
#42
ProblemaPergunta repetida no canal do time
A decisão que transfereMaterial interno já é digitalizado: é o caso com retorno mais rápido e menos risco de imagem
#43
ProblemaRevisão de código que não escala
A decisão que transfere"Revise este PR" produz opinião genérica; "aponte só o que quebra em produção, com arquivo e linha" produz achado acionável
#44
ProblemaGeração de código sem barreira de segurança
A decisão que transfereGuardrails em geração de código filtra o que o modelo produz; permissão é que impede o que ele executa
#45
ProblemaDocumentação que envelhece
A decisão que transfereDocumentação gerada sem revisão humana vira ruído — o padrão é o agente PROPOR, não publicar
#46
ProblemaOnboarding lento de quem entra no time
A decisão que transfereO que reduz tempo até o primeiro commit é convenção acessível, não mais documentação
#47
ProblemaConsulta a banco por quem não escreve SQL
A decisão que transfereGerar SQL é fácil; a parte difícil é limitar o que ele pode consultar e quanto pode varrer
#48
ProblemaAnálise de conteúdo com revisão manual longa
A decisão que transfereRedução de 95% no tempo de revisão vem de triar, não de eliminar o revisor
#49
ProblemaPlataforma de IA para milhares de funcionários
A decisão que transfereSem portal, cada aplicação reimplementa autenticação, cota e custo — e nenhuma implementa as três
#50
ProblemaAgente de engenharia sem observabilidade
A decisão que transfere"O agente travou" só é investigável com um trecho de rastro por ferramenta
41. Modernizar aplicação legada com esforço alto
Migrar uma aplicação de vinte anos é sobretudo trabalho mecânico: traduzir sintaxe, trocar biblioteca, reescrever acesso a dados. O trabalho difícil — decidir o que a regra de negócio realmente faz — é a menor parte do esforço e a que mais custa errar.
Entrada
Repositório legadocódigo, dependências, testes
Inventáriomódulos, acoplamento, cobertura
Transformação
AWS Transformtradução mecânica por módulo
Claudeexplica o que a regra faz
Revisão
Pedido de mesclagemum por módulo, revisável
Testes existenteso critério de equivalência
Engenheiroaprova módulo por módulo
- → código e dependências
- → ordem por acoplamento
- → código traduzido
- → regra obscura
- → explicação anexada
- → roda a suíte do legado
- → passou / falhou
- → mescla
- Fora da AWS
- Compute
- IA e machine learning
- Gestão e governança
- Conceito de arquitetura
Em migração, o retorno vem do trabalho mecânico e repetitivo — e a revisão humana por módulo é o que impede a tradução de mudar o comportamento sem ninguém perceber. Sem suíte de teste, o primeiro passo é escrevê-la.
- Inventariar antes de traduzir. A ordem da migração sai do acoplamento: módulo folha primeiro. Traduzir na ordem alfabética garante conflito no meio do caminho.
- Um pedido de mesclagem por módulo. Migração inteira num pedido só não é revisável — ninguém lê 40 mil linhas. Fatiar é o que transforma a revisão em trabalho possível.
- O teste existente é o critério de equivalência. A pergunta não é "o código novo é bonito?": é "faz a mesma coisa?". Sem suíte, o primeiro trabalho da migração é escrever teste sobre o legado.
- O modelo explica a regra obscura. Aquele bloco de 1998 sem comentário. Fazer o modelo descrever o que ele faz acelera a revisão mais que a tradução em si.
- O ganho é mecânico e é grande. Centenas de dias de engenharia economizados em tradução repetitiva. A decisão de negócio continua sendo humana — e é ela que define se a migração foi correta.
Cadeia de serviçosAWS Transform sobre o código, com revisão humana por módulo
A decisão que transfere40% menos esforço de desenvolvimento e 300 dias de engenharia economizados — em migração, o ganho é em trabalho mecânico
Origem da informaçãoCaso público documentado, com fonte citada no catálogo — fonte [24]
42. Pergunta repetida no canal do time
A mesma pergunta aparece no canal toda semana, e a resposta está num incidente de oito meses atrás que ninguém acha. O engenheiro sênior responde de novo, e o conhecimento continua não sendo recuperável.
Acervo interno
Código e ADRse as decisões de arquitetura registradas
Runbookso procedimento que o time já escreveu
Histórico de incidentea fonte mais subaproveitada
Knowledge Basesingestão por evento no repositório
Canal
Canal do timeonde a pergunta já acontece
Clauderesponde com link do trecho
Aprendizado
Perguntas sem respostaa lista do que documentar
- → código e ADRs indexados
- → procedimentos indexados
- → incidentes indexados
- → pergunta
- → consulta do canal
- → trechos + origem
- → resposta com link
- → não encontrei
- Fora da AWS
- Conceito de arquitetura
- Gestão e governança
- IA e machine learning
É o caso com retorno mais rápido e menor risco de imagem: material interno já digitalizado, usuário colega, erro corrigível. E o que o assistente NÃO consegue responder é a melhor lista de documentação que você vai ter.
- O acervo já existe — é o diferencial deste caso. Nada precisa ser escrito antes: código, runbook e incidente estão digitalizados. É por isso que este é o caso de retorno mais rápido da lista.
- O histórico de incidente é a fonte mais valiosa. Ele contém o que deu errado, por que e como foi resolvido — exatamente o que a pergunta repetida procura. E é o que ninguém indexa.
- Onde a pergunta já acontece. Assistente em portal separado não é usado. Responder no canal em que a pergunta já é feita elimina a fricção que mata a adoção.
- Link do trecho, não resumo solto. Quem pergunta muitas vezes precisa do documento inteiro depois. O link é metade do valor da resposta.
- O que ele não responde é a lista de tarefas. Pergunta sem resposta no acervo indica lacuna real de documentação. Essa lista vale mais que a taxa de acerto.
Cadeia de serviçosKnowledge Bases sobre código, runbook e histórico de incidente → Bedrock com citação
A decisão que transfereMaterial interno já é digitalizado: é o caso com retorno mais rápido e menos risco de imagem
Origem da informaçãoPadrão composto — a topologia que se repete, sem cliente nomeado
43. Revisão de código que não escala
Quatro pessoas revisam o que quarenta escrevem, e a revisão vira gargalo. Ligar um revisor automático genérico piora: ele comenta estilo em vinte linhas por pedido, e o time aprende a ignorar todos os comentários — inclusive os certos.
Gatilho
CI no pedido de mesclagemroda a cada pedido de mesclagem, não a cada commit
Diff + contextoarquivos vizinhos e testes tocados
Revisão
Claudecritério estreito e explícito
Critério de saídasó o que quebra em produção
Saída
Comentário com arquivo e linhaacionável ou nada
Taxa de supressãoquantos achados o time descarta
- → só o que mudou
- → diff + vizinhança
- → define o que reportar
- → achado com endereço
- → quantos foram descartados
- Gestão e governança
- Conceito de arquitetura
- IA e machine learning
- Fora da AWS
Revisão automática vive ou morre pelo critério de saída. Comentário sem endereço e achado de estilo ensinam o time a ignorar o robô — e a partir daí o achado correto também é ignorado.
- O critério de saída é a peça de engenharia. "Aponte só o que quebra em produção, com arquivo e linha" produz achado acionável. "Revise este PR" produz parágrafo genérico que ninguém aplica.
- Diff mais contexto, não o repositório inteiro. O modelo precisa dos arquivos vizinhos e dos testes tocados. Mandar o repositório encarece e dilui a atenção no que mudou.
- Comentário sem endereço não é revisão. Arquivo e linha são o que permite agir. Achado sem localização o revisor humano tem de reencontrar — e não reencontra.
- A taxa de supressão mede o revisor. Se o time descarta a maior parte dos achados, o revisor está gastando atenção. É o sinal para estreitar o critério, não para insistir.
- Ruído destrói a confiança de forma permanente. Depois que o time aprende a ignorar o robô, o achado correto também é ignorado. Recuperar essa confiança é mais difícil que ligar a ferramenta.
Cadeia de serviçosAgente em CI com diff como entrada e critério de saída explícito
A decisão que transfere"Revise este PR" produz opinião genérica; "aponte só o que quebra em produção, com arquivo e linha" produz achado acionável
Origem da informaçãoPadrão composto — a topologia que se repete, sem cliente nomeado
44. Geração de código sem barreira de segurança
O assistente de código sugere trechos com credencial em texto puro, chamada insegura e dependência abandonada. Filtrar a saída ajuda — mas confundir esse filtro com controle de execução é o erro que deixa a porta aberta.
Geração
Editoronde a sugestão aparece para o desenvolvedor
Bedrockgera sob a política de conteúdo declarada
Guardrailspadrão de segredo e conteúdo
O que impede execução
Permissão do ambienteo que o código PODE fazer
Segredo gerenciadonão existe credencial para colar
Varredura no CIdependência e padrão inseguro
Registro
Bloqueios por tipoo que o time mais tenta gerar
- → trecho pedido
- → antes de exibir
- → sugestão filtrada
- → bloqueio por tipo
- → no pedido de mesclagem
- → não há credencial para colar
- → confere permissão pedida
- Fora da AWS
- IA e machine learning
- Segurança e identidade
- Gestão e governança
Filtro de conteúdo e controle de execução resolvem problemas diferentes: um decide o que aparece na tela, o outro o que acontece na conta. Tratar o primeiro como se fosse o segundo é o erro que deixa a porta aberta.
- Guardrails atua na saída do modelo. Ele impede que um trecho com credencial ou padrão proibido apareça. É filtro de conteúdo — e para isso funciona bem.
- O que impede dano é a permissão do ambiente. Código que pede acesso amplo falha por falta de permissão, não por filtro de texto. Confundir os dois é achar que o filtro protege a produção.
- Credencial gerenciada elimina a tentação. Se não existe credencial em variável de ambiente para copiar, não há o que colar no código. Remover a possibilidade vence filtrar a ocorrência.
- A varredura no CI é a rede de baixo. Filtro na geração pega o que passa pelo assistente. A varredura pega também o que a pessoa escreveu à mão — que continua sendo a maior parte.
- Bloqueio por tipo é sinal de treinamento. Se o time tenta gerar o mesmo padrão proibido toda semana, falta biblioteca interna ou falta clareza — não falta filtro.
Cadeia de serviçosBedrock Guardrails aplicado ao fluxo de geração, com política de conteúdo e de segredo
A decisão que transfereGuardrails em geração de código filtra o que o modelo produz; permissão é que impede o que ele executa
Origem da informaçãoArquitetura de referência publicada pela AWS — fonte [25]
45. Documentação que envelhece
A documentação descreve o sistema de dois anos atrás, e cada divergência descoberta custa uma hora de alguém. Gerar documentação automaticamente parece a solução óbvia — e publicar sem revisão troca documentação velha por documentação errada, que é pior.
Gatilho
Semanalou por mudança relevante
Repositóriocódigo + documentação atual
Detecção de divergênciaVPC
Comparadoro que o código faz vs. o que o doc diz
Bedrock em loteninguém está esperando
Proposta
Pedido de mesclagemcom o antes e o depois
Dono do móduloaprova ou descarta
- → dispara a comparação
- → código e documentação atual
- → só o divergente
- → texto proposto
- → proposta com o antes e o depois
- → mesclado
- Conceito de arquitetura
- Fora da AWS
- Compute
- Gestão e governança
Documentação gerada sem revisão troca conteúdo velho por conteúdo errado. O padrão sustentável é agente que propõe divergências, em lote, com dono nomeado para aprovar.
- Propor, não publicar. Documentação gerada sem revisão vira ruído com aparência de oficial. Um pedido de mesclagem preserva o controle e mantém o histórico.
- Só o que divergiu. Regerar a documentação inteira produz um pedido de mesclagem impossível de revisar. Detectar divergência primeiro é o que torna a proposta pequena.
- Em lote, porque não há ninguém esperando. Esse trabalho roda de madrugada. Sob demanda seria pagar o dobro por urgência que não existe.
- O dono do módulo é quem aprova. Documentação sem dono acumula proposta aberta. Roteamento por dono é o que faz a proposta ser lida.
- O antes e o depois no mesmo lugar. Revisar texto novo sem ver o antigo esconde o que mudou. O diff é o que torna a revisão de minutos em vez de horas.
Cadeia de serviçosAgente em lote sobre o repositório, abrindo pedido de mesclagem com a atualização
A decisão que transfereDocumentação gerada sem revisão humana vira ruído — o padrão é o agente PROPOR, não publicar
Origem da informaçãoPadrão composto — a topologia que se repete, sem cliente nomeado
Quiz rápido
Um revisor automático de código comenta estilo em 20 linhas por pedido de mesclagem. Qual é o risco maior?
46. Onboarding lento de quem entra no time
Quem entra leva semanas para o primeiro commit útil, e a maior parte desse tempo não é aprender o domínio: é descobrir a convenção da casa — onde mora o quê, como se roda o teste, qual padrão de nome, por que aquela biblioteca e não a outra.
Convenção da casa
Decisões registradaspor que, não só o quê
Convençõesnome, camada, teste
Knowledge Baseconvenção e exemplo do próprio repositório
Onde a dúvida aparece
Editorcom o arquivo aberto como contexto
Clauderesponde com o exemplo do próprio repositório
Medida
Tempo até o 1º commita métrica que importa
- → o porquê das decisões
- → padrão de nome e camada
- → dúvida + arquivo aberto
- → dúvida de convenção
- → convenção + exemplo real
- → resposta com o exemplo real
- → tempo até o commit
- Conceito de arquitetura
- IA e machine learning
- Fora da AWS
O gargalo do onboarding é convenção inacessível, não falta de documentação. Responder com o exemplo que já existe no repositório é o que encurta o tempo até o primeiro commit.
- A dúvida é de convenção, não de domínio. Domínio se aprende com o time. Convenção é o que trava o dia: onde criar o arquivo, qual padrão seguir, como rodar. E é isso que está espalhado.
- Exemplo do próprio repositório vence texto genérico. Apontar o arquivo que já faz aquilo é mais útil que descrever o padrão. Copiar o vizinho é como se aprende convenção de verdade.
- O "por quê" evita a segunda discussão. Decisão registrada com motivo impede que o novato proponha, de boa-fé, o que já foi descartado por razão que ninguém lembra de contar.
- No editor, com o arquivo como contexto. A dúvida acontece com o código na tela. Assistente que não vê o arquivo aberto responde genérico e obriga a reformular.
- Mais documentação não é a resposta. A métrica é tempo até o primeiro commit. O que a move é acessibilidade da convenção — não volume de texto que ninguém lê.
Cadeia de serviçosAssistente interno com o contexto do projeto e as convenções da casa
A decisão que transfereO que reduz tempo até o primeiro commit é convenção acessível, não mais documentação
Origem da informaçãoPadrão composto — a topologia que se repete, sem cliente nomeado
47. Consulta a banco por quem não escreve SQL
A área de negócio espera dias por um número que é uma consulta de três linhas. Gerar o SQL com um modelo funciona na primeira demonstração — e a segunda derruba o banco de produção com uma varredura completa de tabela.
Pergunta
Área de negóciosabe a pergunta e não escreve SQL
Claudeesquema descrito no contexto
ContençãoVPC
Validador de SQLsó SELECT, tabelas da lista
Limitestempo, linhas e dado varrido
Execução isoladaVPC
Réplica de leituranunca a instância primária
Consulta exibidaquem lê o número vê o SQL
- → pergunta em português
- → SQL proposto
- → aprovado
- → executa com teto
- → resultado
- → número + consulta
- → recusado, com o motivo
- Fora da AWS
- IA e machine learning
- Compute
- Conceito de arquitetura
O difícil em texto-para-SQL não é gerar: é conter. Réplica de leitura, lista de tabelas permitidas e três tetos de custo — e a consulta exibida, porque número sem consulta ninguém assume.
- A réplica é o que protege a produção. Consulta gerada é imprevisível por natureza. Executar na primária é apostar que nenhuma vai varrer a tabela inteira — e uma vai.
- Lista de tabelas permitidas, não lista de proibidas. Permitir explicitamente é o padrão seguro. Proibir tabela por tabela sempre esquece a que foi criada na semana passada.
- Teto de tempo, de linhas e de dado varrido. Três limites, porque a consulta pode ser custosa de três formas diferentes. Um só deixa as outras duas abertas.
- O esquema descrito é o que mais melhora o SQL. Nome de coluna raramente diz o significado. Descrição de coluna no contexto rende mais que qualquer refinamento de instrução.
- Mostrar a consulta é o que dá confiança. Quem vai defender o número precisa poder conferir como ele foi obtido. Número sem consulta não é aceito por quem responde por ele.
Cadeia de serviçosBedrock com esquema no contexto → SQL gerado → execução em réplica de leitura com limite
A decisão que transfereGerar SQL é fácil; a parte difícil é limitar o que ele pode consultar e quanto pode varrer
Origem da informaçãoCaso público documentado, com fonte citada no catálogo — fonte [26]
48. Análise de conteúdo com revisão manual longa
Uma equipe lê e classifica todo o conteúdo que entra, e a fila cresce mais rápido que a capacidade. Automatizar tudo é tentador e inaceitável: o erro tem custo. A questão é onde exatamente o humano continua.
Fila
Conteúdo a analisarfila que cresce mais rápido que a capacidade
Bedrock em loteclassifica e resume
Triagem
Confiança por classealta vai direto, baixa vai a humano
Revisoros duvidosos, integralmente
Amostragemdos automáticos, para medir o erro
Saída
Classificação finalcom a marca de automático ou revisado
Erro na amostracalibra o limiar
- → fila do dia
- → classe + confiança
- → baixa confiança
- → alta confiança
- → os duvidosos, corrigidos
- → sorteia os automáticos
- → erro medido na amostra
- → ajusta o limiar
- Armazenamento
- Conceito de arquitetura
- IA e machine learning
- Banco de dados
A economia vem de triar: o revisor lê o duvidoso e a amostra, não a fila inteira. E amostrar o que passou automaticamente é o único jeito de ver o erro que não gera reclamação.
- Triar, não substituir. O revisor continua — só para de ler o que é evidente. É de onde vem a redução de tempo, e é o que mantém o erro sob controle.
- Em lote porque a fila não tem alguém aguardando. Conteúdo entra durante o dia e é analisado em janela. Custa metade da inferência sob demanda.
- A amostragem mede o que passou direto. Sem amostrar os automáticos, o erro perigoso é invisível: ele não gera reclamação porque ninguém o vê.
- O limiar é calibrado pelo erro medido. Ele não é escolhido uma vez: sobe quando o erro na amostra sobe, desce quando a capacidade de revisão sobra.
- Confiança por classe, não global. Algumas classes são fáceis e outras ambíguas por natureza. Um limiar único revisa demais nas fáceis e de menos nas difíceis.
Cadeia de serviçosBedrock classificando e resumindo em lote, com amostragem humana
A decisão que transfereRedução de 95% no tempo de revisão vem de triar, não de eliminar o revisor
Origem da informaçãoCaso público documentado, com fonte citada no catálogo — fonte [26]
49. Plataforma de IA para milhares de funcionários
Dez times construíram dez integrações com o modelo, e nenhuma tem cota, atribuição de custo e registro de uso ao mesmo tempo. A conta chega agregada, ninguém sabe reduzir, e o time de segurança descobre uma credencial compartilhada em produção.
Porta única
Portal de IAuma porta, um contrato
Identidade corporativaquem é, de que time
Cota por timee limite de taxa por usuário
RoteamentoVPC
Roteador de modelotarefa simples → modelo pequeno
Bedrockuma porta para dez times
Custo e uso
Atribuição por timemetadado na chamada
Painel de consumocada time vê o próprio gasto
- → quem é e de que time
- → consome a cota do time
- → dentro da cota
- → chamada roteada
- → tokens da chamada
- → gasto por time
- → excedeu: recusa clara
- Rede e entrega
- Segurança e identidade
- Conceito de arquitetura
- Compute
- IA e machine learning
- Gestão e governança
- Analytics
O portal existe para implementar uma vez o que toda aplicação precisa e nenhuma implementa inteiro: identidade, cota e atribuição de custo. Sem ele, a conta chega agregada e ninguém consegue reduzi-la.
- Uma porta implementa as três coisas uma vez. Autenticação, cota e atribuição de custo. Dez integrações implementam em média uma delas cada — e nunca as três.
- Identidade corporativa, não credencial compartilhada. Chave única entre times impede cota por time e destrói o rastro. É o achado clássico da primeira auditoria.
- Cota com recusa clara. Estourar a cota tem de devolver mensagem que o time entenda, com o número. Erro genérico gera ticket e pedido de aumento sem análise.
- Roteamento por dificuldade dentro do portal. Centralizar permite trocar o modelo padrão de tarefa simples sem alterar dez aplicações.
- Cada time vê o próprio gasto. Custo visível é custo que o dono reduz. Conta agregada é número que ninguém sabe atacar.
Cadeia de serviçosPortal interno com cota, roteamento de modelo e atribuição de custo por time
A decisão que transfereSem portal, cada aplicação reimplementa autenticação, cota e custo — e nenhuma implementa as três
Origem da informaçãoCaso público documentado, com fonte citada no catálogo — fonte [27]
50. Agente de engenharia sem observabilidade
O relato é sempre o mesmo: "o agente travou" ou "ele fez uma coisa estranha". Sem rastro, a investigação começa pedindo à pessoa que reproduza — e ela não sabe o que fez. O caso é fechado como não reproduzível e volta na semana seguinte.
ExecuçãoVPC
Agenteid de correlação por sessão
Ferramenta Aum trecho de rastro por chamada
Ferramenta Bcom o argumento e a duração
Rastro
X-Rayum trecho por chamada de ferramenta
CloudWatchtokens, passos, duração
Anotação de negóciousuário, caso, decisão
Investigação
Quem investigareconstrói a sessão pelo id
- → chamada com id de correlação
- → mesma sessão, outro trecho
- → trecho
- → trecho
- → métricas
- → enriquece
- → a sessão inteira
- IA e machine learning
- Conceito de arquitetura
- Gestão e governança
- Fora da AWS
Agente é sistema distribuído com laço: sem um trecho de rastro por ferramenta e um id por sessão, "travou" não é investigável. E rastro sem anotação de negócio mostra o sintoma sem permitir reproduzir.
- Um trecho por chamada de ferramenta. É a granularidade que permite ver onde parou: qual ferramenta, com que argumento, quanto tempo. Rastro por requisição inteira não distingue nada.
- Identificador de correlação por sessão. Uma sessão de agente são dezenas de chamadas. Sem id comum, elas são eventos soltos que não se juntam.
- Anotação de negócio no rastro. Saber que a chamada demorou não permite reproduzir. Saber que era o caso do cliente X pedindo o relatório Y permite.
- Passos e tokens por sessão como métrica. É o que revela laço e crescimento de custo antes de a fatura chegar. Duração sozinha não distingue tarefa difícil de laço.
- A investigação parte do id, não do relato. Com o rastro, "travou ontem à tarde" vira uma sessão específica. Sem ele, toda investigação depende da memória de quem reclamou.
Cadeia de serviçosRastro por chamada de ferramenta com identificador único, em CloudWatch e X-Ray
A decisão que transfere"O agente travou" só é investigável com um trecho de rastro por ferramenta
Origem da informaçãoArquitetura de referência publicada pela AWS — fonte [28]
Perguntas frequentes
❓ Por onde começar a usar IA numa empresa de engenharia?
Comece por dentro: assistente sobre código, runbook e histórico de incidente. O material já está digitalizado, o usuário é colega e não cliente, e o custo de um erro é uma correção em vez de uma captura de tela pública. É o caso com retorno mais rápido e menor risco de imagem da lista inteira — e o histórico de incidente, que quase ninguém indexa, é justamente a fonte que responde a pergunta repetida do canal do time.
❓ Como fazer revisão automática de código sem o time ignorar os comentários?
Estreitando o critério de saída e exigindo endereço. "Revise este PR" produz parágrafo genérico; "aponte só o que quebra em produção, com arquivo e linha" produz achado acionável. A métrica a acompanhar é a taxa de supressão: se o time descarta a maior parte dos achados, o critério está largo demais. Isso importa porque ruído destrói a confiança de forma permanente — depois que o time aprende a ignorar o robô, o achado correto também é ignorado.
❓ É seguro deixar um modelo gerar SQL sobre o banco da empresa?
Somente com contenção no código: execução em réplica de leitura, lista de tabelas permitidas, e teto de tempo, de linhas e de dado varrido. Gerar SQL é a parte fácil e funciona na primeira demonstração; a segunda derruba a produção com uma varredura completa de tabela. Vale mostrar a consulta gerada junto do número, porque quem vai defender o resultado precisa poder conferir como ele foi obtido — e descrição de coluna no contexto melhora o SQL mais que qualquer refinamento de instrução.
Fixando
Quiz rápido
Guardrails está filtrando sugestões de código com credencial em texto puro. Isso protege contra o quê?
Quiz rápido
Numa análise de conteúdo em lote, por que amostrar o que foi classificado automaticamente com alta confiança?
💡
Próximo passo
A próxima família de arquiteturas é **Dados, analytics e BI conversacional** — mesma estrutura: dez soluções, cada uma com o desenho completo e a decisão que ela transfere. Se o que falta é praticar em vez de ler — nenhum destes desenhos tem código, de propósito, porque quem constrói é a trilha 100 Laboratórios de Arquitetura AWS —, comece por um laboratório da família equivalente.
Terminou de ler?
Marcar como concluído registra o XP, mantém sua sequência e coloca 3 cartas deste módulo na fila de revisão espaçada.
Próximos passos sugeridos
Temas deste módulo
Discussão
Carregando comentários…