[{"content":"","date":"24/09/2026","externalUrl":null,"permalink":"/pt-br/tags/agentic-architecture/","section":"Tags","summary":"","title":"Agentic-Architecture","type":"tags"},{"content":"","date":"24/09/2026","externalUrl":null,"permalink":"/pt-br/tags/ai-fluency/","section":"Tags","summary":"","title":"Ai-Fluency","type":"tags"},{"content":"","date":"24/09/2026","externalUrl":null,"permalink":"/pt-br/tags/anthropic/","section":"Tags","summary":"","title":"Anthropic","type":"tags"},{"content":"","date":"24/09/2026","externalUrl":null,"permalink":"/pt-br/series/becoming-a-claude-architect/","section":"Series","summary":"","title":"Becoming-a-Claude-Architect","type":"series"},{"content":"","date":"24/09/2026","externalUrl":null,"permalink":"/pt-br/categories/","section":"Categories","summary":"","title":"Categories","type":"categories"},{"content":"","date":"24/09/2026","externalUrl":null,"permalink":"/pt-br/tags/certification/","section":"Tags","summary":"","title":"Certification","type":"tags"},{"content":"","date":"24/09/2026","externalUrl":null,"permalink":"/pt-br/tags/ci-cd/","section":"Tags","summary":"","title":"Ci-Cd","type":"tags"},{"content":"","date":"24/09/2026","externalUrl":null,"permalink":"/pt-br/categories/claude/","section":"Categories","summary":"","title":"Claude","type":"categories"},{"content":"","date":"24/09/2026","externalUrl":null,"permalink":"/pt-br/tags/claude/","section":"Tags","summary":"","title":"Claude","type":"tags"},{"content":"","date":"24/09/2026","externalUrl":null,"permalink":"/pt-br/tags/claude-agent-sdk/","section":"Tags","summary":"","title":"Claude-Agent-Sdk","type":"tags"},{"content":"","date":"24/09/2026","externalUrl":null,"permalink":"/pt-br/tags/claude-architect/","section":"Tags","summary":"","title":"Claude-Architect","type":"tags"},{"content":"","date":"24/09/2026","externalUrl":null,"permalink":"/pt-br/tags/claude-code/","section":"Tags","summary":"","title":"Claude-Code","type":"tags"},{"content":"","date":"24/09/2026","externalUrl":null,"permalink":"/pt-br/tags/claude-md/","section":"Tags","summary":"","title":"Claude-Md","type":"tags"},{"content":"","date":"24/09/2026","externalUrl":null,"permalink":"/pt-br/tags/context-management/","section":"Tags","summary":"","title":"Context-Management","type":"tags"},{"content":"","date":"24/09/2026","externalUrl":null,"permalink":"/pt-br/tags/json-schema/","section":"Tags","summary":"","title":"Json-Schema","type":"tags"},{"content":"","date":"24/09/2026","externalUrl":null,"permalink":"/pt-br/tags/mcp/","section":"Tags","summary":"","title":"Mcp","type":"tags"},{"content":"","date":"24/09/2026","externalUrl":null,"permalink":"/pt-br/tags/multi-agent/","section":"Tags","summary":"","title":"Multi-Agent","type":"tags"},{"content":" Meu currículo ","date":"24/09/2026","externalUrl":null,"permalink":"/pt-br/","section":"Newton Rocha","summary":" Meu currículo ","title":"Newton Rocha","type":"page"},{"content":"","date":"24/09/2026","externalUrl":null,"permalink":"/pt-br/posts/","section":"Posts","summary":"","title":"Posts","type":"posts"},{"content":"","date":"24/09/2026","externalUrl":null,"permalink":"/pt-br/tags/practice-quiz/","section":"Tags","summary":"","title":"Practice-Quiz","type":"tags"},{"content":"","date":"24/09/2026","externalUrl":null,"permalink":"/pt-br/tags/prompt-engineering/","section":"Tags","summary":"","title":"Prompt-Engineering","type":"tags"},{"content":"","date":"24/09/2026","externalUrl":null,"permalink":"/pt-br/tags/reliability/","section":"Tags","summary":"","title":"Reliability","type":"tags"},{"content":"","date":"24/09/2026","externalUrl":null,"permalink":"/pt-br/series/","section":"Series","summary":"","title":"Series","type":"series"},{"content":"","date":"24/09/2026","externalUrl":null,"permalink":"/pt-br/tags/structured-output/","section":"Tags","summary":"","title":"Structured-Output","type":"tags"},{"content":"","date":"24/09/2026","externalUrl":null,"permalink":"/pt-br/tags/subagents/","section":"Tags","summary":"","title":"Subagents","type":"tags"},{"content":"","date":"24/09/2026","externalUrl":null,"permalink":"/pt-br/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"},{"content":"","date":"24/09/2026","externalUrl":null,"permalink":"/pt-br/tags/tool-use/","section":"Tags","summary":"","title":"Tool-Use","type":"tags"},{"content":" Do que se trata # O Domínio 1 — Agentic Architecture \u0026amp; Orchestration — é o domínio mais pesado isolado da prova Claude Certified Architect – Foundations, valendo 27% sozinho. O guia oficial da prova o divide em sete áreas de tarefa: o agentic loop, orquestração multiagente, configuração de subagentes, workflows de múltiplas etapas, hooks do SDK, decomposição de tarefas e gerenciamento de sessão. É muita coisa, então este post condensa tudo nas cinco ideias que realmente carregam o peso, com as duas menores reunidas num resumo rápido no final.\nPonto-chave 1: o agentic loop roda em cima do stop_reason, não interpretando as palavras do Claude # Todo o agentic loop se resume a um sinal: stop_reason. Sua aplicação envia uma requisição, o Claude responde, e você verifica esse campo. stop_reason: \u0026quot;tool_use\u0026quot; significa que o Claude decidiu chamar uma ou mais ferramentas — você as executa, empacota a saída como blocos tool_result, e envia uma nova requisição com os resultados anexados. O loop se repete enquanto stop_reason == \u0026quot;tool_use\u0026quot;. Qualquer outro valor — o mais comum sendo \u0026quot;end_turn\u0026quot; — significa que o Claude produziu sua resposta final e o loop termina.\nO ponto no nível de arquiteto aqui é o antipadrão a evitar: não tente detectar \u0026ldquo;o Claude terminou?\u0026rdquo; interpretando o texto da resposta em busca de frases como \u0026ldquo;terminei\u0026rdquo; ou \u0026ldquo;aqui está a resposta\u0026rdquo;. Isso é frágil e depende do modelo. stop_reason é um sinal estruturado e contratual feito exatamente para isso — use-o.\nPonto-chave 2: orquestração multiagente é um hub, não uma malha # Quando um agente não é suficiente, o padrão cobrado na prova é o hub-and-spoke coordenador/subagente: um único agente coordenador gerencia toda a comunicação entre subagentes, o tratamento de erros e o roteamento de informação. Subagentes não conversam diretamente entre si — tudo passa pelo coordenador. Isso mantém o tratamento de falhas centralizado e evita a bagunça combinatória de cada agente precisar conhecer todos os outros.\nDois hábitos de design importam dentro desse padrão: seleção dinâmica de subagentes (o coordenador decide quais subagentes uma tarefa específica realmente precisa, em vez de sempre acionar todos) e particionamento de escopo — dividir o trabalho para que os subagentes não dupliquem esforço em partes sobrepostas do mesmo problema. Uma orquestração bem projetada também permite loops de refinamento iterativo, onde a saída de um subagente pode disparar uma nova passada em vez de o coordenador tratar todo resultado como final.\nflowchart LR U[Requisição] --\u003e C[Agente coordenador] C --\u003e S1[Subagente A] C --\u003e S2[Subagente B] C --\u003e S3[Subagente C] S1 --\u003e C S2 --\u003e C S3 --\u003e C C --\u003e R[Resultado roteado] style C fill:#2a78d6,stroke:#1c5cab,color:#fff style S1 fill:#c9ddf6,stroke:#86b6ef,color:#0b0b0b style S2 fill:#c9ddf6,stroke:#86b6ef,color:#0b0b0b style S3 fill:#c9ddf6,stroke:#86b6ef,color:#0b0b0b Repare no que não está nesse diagrama: nenhuma seta entre os subagentes. Essa é a disciplina do hub-and-spoke — todo caminho passa pelo coordenador.\nPonto-chave 3: subagentes não herdam contexto, você precisa entregar a eles # Esse é o detalhe que mais derruba as pessoas: acionar um subagente (via a ferramenta Agent — internamente ainda construída sobre o mecanismo Task, então o allowedTools de um coordenador precisa incluí-la) não entrega automaticamente o histórico da conversa do pai para esse subagente. Um subagente não bifurcado (\u0026ldquo;fork\u0026rdquo;) começa do zero — ele recebe seu próprio system prompt e o que você colocar na string de prompt da ferramenta Agent, e nada mais do pai. Nenhum resultado de ferramenta anterior, nenhum raciocínio anterior, nenhum contexto compartilhado presumido.\nA implicação arquitetural: se um subagente precisa de um caminho de arquivo, uma mensagem de erro, uma decisão anterior ou qualquer outro detalhe do trabalho já feito pelo pai, esse detalhe precisa ser escrito explicitamente no prompt que você entrega a ele. É também por isso que subagentes são úteis para isolamento de contexto — um subagente de pesquisa pode ler dezenas de arquivos sem que nada desse conteúdo vaze para a conversa principal, porque só a mensagem final dele retorna ao pai. O isolamento e a regra \u0026ldquo;você precisa passar contexto explicitamente\u0026rdquo; são o mesmo mecanismo, visto por dois lados.\nPonto-chave 4: para etapas críticas de compliance, aplique com hooks — não peça só no prompt # Uma instrução no prompt (\u0026ldquo;sempre valide o valor antes de submeter um pagamento\u0026rdquo;) é orientação, não garantia — um agente sob pressão de contexto suficiente ainda pode pular essa etapa. Quando uma etapa genuinamente não pode acontecer fora de ordem ou sem verificação — o exemplo do guia oficial é operações financeiras —, a resposta no nível de arquiteto é enforcement programático: hooks e gates de pré-requisito que rodam em código, não na discrição do modelo.\nOs hooks do Claude Agent SDK disparam em eventos específicos do ciclo de vida — uma ferramenta prestes a rodar (PreToolUse), uma ferramenta que acabou de retornar (PostToolUse), um subagente iniciando ou parando, entre outros. Um hook de PostToolUse, por exemplo, pode inspecionar e normalizar a saída de uma ferramenta, ou bloquear um resultado não conforme, antes que ele chegue à próxima etapa do agentic loop. A distinção a guardar para a prova: orientação via prompt molda o comportamento de forma probabilística; hooks aplicam de forma determinística. Recorra a hooks quando \u0026ldquo;provavelmente segue a regra\u0026rdquo; não for suficiente.\nUma nota rápida sobre escala: decomposição de tarefas e gerenciamento de sessão # Duas peças menores completam o domínio. Decomposição de tarefas é a escolha entre um pipeline sequencial fixo (encadeamento de prompts — faça A, depois B, depois C, sempre nessa ordem) e decomposição adaptativa, onde a próxima etapa é escolhida com base no que a etapa anterior realmente encontrou. Gerenciamento de sessão cobre retomar uma sessão nomeada para continuar exatamente de onde um agente parou, fork_session para ramificar e explorar uma direção alternativa sem perturbar o histórico da conversa original, e saber quando uma sessão nova com um resumo injetado é melhor do que retomar uma sessão longa (contexto mais curto, mas você controla exatamente o que segue adiante).\nO quanto isso pesa # Mais de um quarto da prova inteira depende de acertar esse domínio Conclusão # O Domínio 1 em uma passada: o agentic loop é uma máquina de estados baseada em stop_reason, não um problema de interpretar texto. Trabalho multiagente deve passar por um coordenador, nunca por uma malha de subagentes. Subagentes começam com contexto em branco — entregue a eles o que precisam explicitamente. Etapas críticas de compliance são aplicadas com hooks, não apenas pedidas num prompt. E decomposição de tarefas/gerenciamento de sessão completam o domínio como peças de apoio em torno dessas quatro ideias maiores. Com 27% da prova, esse é o domínio que mais vale a pena estudar além do necessário.\nFontes # Claude Certified Architect – Foundations Exam Guide — declarações de tarefa do Domínio 1 How tool use works — Claude Platform Docs — stop_reason, tool_use, end_turn Subagents in the SDK — Claude API Docs — padrão coordenador, herança de contexto, restrições de ferramenta Intercept and control agent behavior with hooks — Claude API Docs — PreToolUse/PostToolUse Work with sessions — Claude API Docs — resume vs. fork vs. sessão nova A pesquisa e a checagem de precisão técnica contra a documentação oficial são feitas com apoio de IA; o enquadramento, os julgamentos sobre \u0026ldquo;o que isso significa para a prova\u0026rdquo; e eventuais histórias de campo são meus.\nOnde isso se encaixa # Parte 2 de Tornando-se um Claude Architect, seguindo a visão geral da série. A Parte 3 assume o Domínio 2 — Tool Design \u0026amp; MCP Integration.\n","date":"24/09/2026","externalUrl":null,"permalink":"/pt-br/posts/claude-architect-02-agentic-architecture-orchestration/","section":"Posts","summary":"Do que se trata # O Domínio 1 — Agentic Architecture \u0026 Orchestration — é o domínio mais pesado isolado da prova Claude Certified Architect – Foundations, valendo 27% sozinho. O guia oficial da prova o divide em sete áreas de tarefa: o agentic loop, orquestração multiagente, configuração de subagentes, workflows de múltiplas etapas, hooks do SDK, decomposição de tarefas e gerenciamento de sessão. É muita coisa, então este post condensa tudo nas cinco ideias que realmente carregam o peso, com as duas menores reunidas num resumo rápido no final.\n","title":"Tornando-se um Claude Architect: Agentic Architecture \u0026 Orchestration — Domínio 1","type":"posts"},{"content":" Do que se trata # O Domínio 3 — Claude Code Configuration \u0026amp; Workflows — empata com Prompt Engineering \u0026amp; Structured Output como o segundo domínio mais pesado da prova Claude Certified Architect – Foundations, com 20%. Suas seis áreas de tarefa giram em torno de como você configura e conduz o próprio Claude Code: hierarquia de arquivos de configuração, comandos e skills customizados, rules condicionais, escolher entre plan mode e ir direto ao ponto, iterar bem, e integrar o Claude Code ao CI/CD.\nPonto-chave 1: o CLAUDE.md tem uma hierarquia — saiba onde cada regra pertence # O Claude Code carrega instruções de vários escopos, do mais amplo ao mais específico: um arquivo de política gerenciada em nível de organização (controlado pelo TI), um ~/.claude/CLAUDE.md de nível de usuário (suas preferências pessoais em todos os projetos), nível de projeto (./CLAUDE.md ou ./.claude/CLAUDE.md, compartilhado com o time via controle de versão), e um CLAUDE.local.md no .gitignore para suas preferências pessoais específicas do projeto que não devem ser commitadas. Eles carregam nessa ordem, então uma instrução de projeto aparece no contexto depois de uma instrução de usuário — coloque uma regra no escopo a que ela realmente pertence, não onde for mais conveniente. Para um projeto grande, a sintaxe de import @caminho/para/arquivo permite que um CLAUDE.md puxe um README, um package.json, ou um guia de workflow dedicado sem duplicar esse conteúdo, com imports resolvidos em relação ao arquivo que os referencia e aninhamento de até quatro níveis.\nPonto-chave 2: comandos e skills customizados — com escopo, e com acesso a ferramentas que você controla # Comandos com escopo de projeto ficam em .claude/commands/ (versionados, compartilhados com o time) versus comandos com escopo de usuário em ~/.claude/commands/ (pessoais, não compartilhados). Skills vão além: o frontmatter de um SKILL.md pode definir context: fork para rodar a skill em um subagente isolado sem visibilidade do histórico da conversa principal — útil para uma tarefa autocontida como uma revisão de código — e allowed-tools para pré-aprovar um conjunto específico e restrito de ferramentas só para aquela invocação (a concessão expira depois da próxima mensagem), em vez de a skill herdar acesso irrestrito a ferramentas.\nPonto-chave 3: rules com escopo por caminho carregam só quando são relevantes # Em vez de empilhar toda convenção num único CLAUDE.md que carrega em toda sessão independente do que você está mexendo, arquivos em .claude/rules/ podem ter um campo paths no frontmatter YAML — um padrão glob como src/api/**/*.ts — para que aquela regra só entre no contexto quando o Claude estiver de fato trabalhando com arquivos correspondentes. Isso mantém as convenções de um projeto grande modulares por tópico (testing.md, security.md, api-design.md) e reduz o uso de contexto, já que uma regra sobre validação de API não precisa carregar enquanto você edita um arquivo CSS.\nPonto-chave 4: plan mode é para incerteza e mudanças em múltiplos arquivos, não para tudo # O plan mode — o Claude lê e raciocina sem fazer mudanças, e então propõe um plano que você aprova antes de ele tocar em qualquer coisa — é feito para trabalho complexo e de grande escala: quando você não tem certeza da abordagem certa, a mudança abrange múltiplos arquivos, ou você não conhece bem o código sendo modificado. Para uma mudança simples e bem delimitada — corrigir um erro de digitação, uma linha de log, renomear uma variável — o plan mode é uma sobrecarga desnecessária. O teste prático: se você conseguisse descrever o diff em uma frase, pule o plano e deixe o Claude executar direto.\nflowchart TD A[Nova tarefa] --\u003e B{Você conseguiria descrevero diff em uma frase?} B --\u003e|Sim| C[Execução direta] B --\u003e|Não| D{Múltiplos arquivos, códigodesconhecido, ou abordagem incerta?} D --\u003e|Sim| E[Plan mode] D --\u003e|Não| C style C fill:#c9ddf6,stroke:#86b6ef,color:#0b0b0b style E fill:#2a78d6,stroke:#1c5cab,color:#fff Ponto-chave 5: itere com exemplos, testes e uma entrevista prévia — não com feedback vago # Três técnicas concretas para melhoria progressiva, todas sobre dar ao Claude algo contra o que checar o próprio trabalho, em vez de \u0026ldquo;melhore isso\u0026rdquo;: fornecer exemplos de entrada/saída (\u0026ldquo;essa entrada deveria produzir aquela saída\u0026rdquo;) em vez de descrever o comportamento de forma abstrata; iteração orientada a testes, em que o Claude roda uma checagem real — uma suíte de testes, um build, uma comparação de screenshot — e continua iterando até passar, em vez de parar no momento em que o trabalho apenas parece pronto; e o padrão de entrevista para funcionalidades maiores, em que você faz o Claude te perguntar sobre implementação técnica, UI/UX e casos extremos antes de escrever uma especificação e começar a implementação, trazendo à tona considerações que você talvez não tivesse pensado em mencionar de início.\nUma nota rápida sobre escala: integração com CI/CD # Completando o domínio: o Claude Code roda de forma não interativa com a flag -p (ou --print), o que é o que o torna utilizável dentro de um pipeline de CI, um pre-commit hook, ou qualquer script, em vez de apenas uma sessão interativa de terminal. Combine com --output-format json para obter uma resposta estruturada que seu pipeline consegue interpretar programaticamente em vez de raspar texto simples — útil para qualquer coisa, de um linter de erros de digitação rodado em todo diff de PR a um resumidor de log de build que escreve suas descobertas num arquivo.\nO quanto isso pesa # Empatado em segundo lugar com 20% — hábitos de configuração que você monta uma vez e colhem em toda sessão seguinte Conclusão # O Domínio 3 em uma passada: o CLAUDE.md tem uma hierarquia real — gerenciado, usuário, projeto, local — e imports permitem puxar material de referência sem duplicar conteúdo. Comandos e skills têm escopo por projeto vs. pessoal, e skills adicionam context: fork e allowed-tools para isolamento e acesso controlado a ferramentas. Rules com escopo por caminho mantêm as convenções de projetos grandes modulares sem inchar o contexto de toda sessão. O plan mode compensa sua sobrecarga em trabalho incerto e de múltiplos arquivos, e não custa nada num diff de uma frase só. A iteração funciona melhor com exemplos, checagens reais, e uma entrevista prévia para funcionalidades maiores. E -p mais --output-format json é o que transforma o Claude Code de uma ferramenta só-de-terminal num cidadão de CI/CD.\nFontes # Claude Certified Architect – Foundations Exam Guide — declarações de tarefa do Domínio 3 How Claude remembers your project — Claude Code Docs — hierarquia do CLAUDE.md, imports, .claude/rules/ Extend Claude with skills — Claude Code Docs — context: fork, allowed-tools, escopo de comandos Best practices for Claude Code — Claude Code Docs — plan mode, verificação, o padrão de entrevista Run Claude Code programmatically — Claude Code Docs — -p, --output-format json A pesquisa e a checagem de precisão técnica contra a documentação oficial são feitas com apoio de IA; o enquadramento, os julgamentos sobre \u0026ldquo;o que isso significa para a prova\u0026rdquo; e eventuais histórias de campo são meus.\nOnde isso se encaixa # Parte 4 de Tornando-se um Claude Architect, seguindo o Domínio 2 — Tool Design \u0026amp; MCP Integration. A Parte 5 assume o Domínio 4 — Prompt Engineering \u0026amp; Structured Output.\n","date":"24/09/2026","externalUrl":null,"permalink":"/pt-br/posts/claude-architect-04-claude-code-configuration-workflows/","section":"Posts","summary":"Do que se trata # O Domínio 3 — Claude Code Configuration \u0026 Workflows — empata com Prompt Engineering \u0026 Structured Output como o segundo domínio mais pesado da prova Claude Certified Architect – Foundations, com 20%. Suas seis áreas de tarefa giram em torno de como você configura e conduz o próprio Claude Code: hierarquia de arquivos de configuração, comandos e skills customizados, rules condicionais, escolher entre plan mode e ir direto ao ponto, iterar bem, e integrar o Claude Code ao CI/CD.\n","title":"Tornando-se um Claude Architect: Claude Code Configuration \u0026 Workflows — Domínio 3","type":"posts"},{"content":" Do que se trata # O Domínio 5 — Context Management \u0026amp; Reliability — é o domínio mais leve da prova Claude Certified Architect – Foundations, com 15%, mas suas seis áreas de tarefa cobrem o que decide se um agente de execução longa permanece confiável: preservar fatos críticos ao longo de interações longas, saber quando escalar, permitir que um sistema multiagente se recupere de falhas em vez de degradar silenciosamente, gerenciar contexto em escala, e calibrar o quanto confiar na saída.\nPonto-chave 1: a sumarização progressiva apaga silenciosamente os fatos que importam # Condensar uma conversa longa numa sumarização é onde a informação morre: datas, percentuais e a expectativa exata declarada por um cliente são suavizadas numa prosa vaga, e a tendência do próprio modelo de \u0026ldquo;lost in the middle\u0026rdquo; significa que qualquer coisa enterrada no meio de uma entrada longa é menos confiável do que o que está perto do início ou do fim. A correção no nível de arquiteto é parar de tratar a sumarização como o único mecanismo — extrair fatos transacionais para um bloco estruturado e persistente (um registro de \u0026ldquo;fatos do caso\u0026rdquo;) que sobrevive independentemente do resumo narrativo, aparar a saída verbosa de ferramentas antes que ela se acumule em vez de depois, e colocar resumos no início do prompt para trabalhar a favor do efeito de posição, não contra ele.\nPonto-chave 2: escalonamento precisa de gatilhos explícitos, não sentimento ou pontuação de confiança # Nem a análise de sentimento nem a própria pontuação de confiança do modelo são sinais confiáveis de quando encaminhar para um humano — ambos podem parecer calmos num caso que na verdade está travado, ou ansiosos num que não está. A correção da prova é ter critérios explícitos de escalonamento apoiados por exemplos few-shot: um pedido explícito do cliente por um humano é honrado imediatamente, uma exceção ou lacuna de política escala em vez de ser contornada, e múltiplas correspondências ambíguas de cliente disparam um pedido por outro identificador em vez de uma seleção por melhor palpite. A distinção que importa na prática: reconheça a frustração quando ela estiver presente, mas não trate a frustração em si como o gatilho de escalonamento quando a questão é de fato resolúvel.\nPonto-chave 3: propagação estruturada de erros é o que permite que um coordenador realmente se recupere # Um status genérico de \u0026ldquo;falhou\u0026rdquo; lançado por um subagente esconde tudo que um coordenador precisaria para agir com inteligência. O padrão que este domínio testa: retornar contexto de erro estruturado — tipo de falha, e quais alternativas existem — em vez de um status simples; distinguir uma falha de acesso genuína de um resultado válido, porém vazio, já que colapsar essas duas coisas em \u0026ldquo;sem dados\u0026rdquo; produz a decisão de recuperação errada; tentar recuperação local dentro do subagente antes de propagar qualquer falha para cima; e, ao sintetizar resultados de vários subagentes, anotar a saída com lacunas de cobertura em vez de apresentar silenciosamente resultados parciais como completos.\nflowchart TD A[Tarefa do subagente falha] --\u003e B{Recuperável localmente?} B --\u003e|Sim| C[Tentar de novo / fallbackdentro do subagente] C --\u003e D[Retornar resultado] B --\u003e|Não| E[Retornar erro estruturado:tipo de falha + alternativas] E --\u003e F[Coordenador decide:tentar de novo, redirecionar, ou anotar lacuna] style D fill:#28c840,stroke:#1c9c30,color:#fff style E fill:#2a78d6,stroke:#1c5cab,color:#fff style F fill:#1c5cab,stroke:#14417f,color:#fff Ponto-chave 4: exploração de bases de código grandes precisa da própria disciplina de contexto # Sessões estendidas degradam — a prova nomeia isso diretamente, descrevendo uma degradação de contexto que produz respostas inconsistentes quanto mais longa a sessão fica. As contramedidas são concretas: arquivos scratchpad que persistem descobertas-chave através de fronteiras de contexto, para que sobrevivam mesmo que a sessão não sobreviva; gerar subagentes para isolar exploração verbosa, para que o ruído de buscar numa base de código grande nunca entre na conversa principal; resumir as descobertas de uma fase antes de delegar a próxima, em vez de deixar a exploração bruta se acumular; projetar exportações de estado especificamente para recuperação de falhas; e usar o comando /compact do Claude Code durante uma sessão longa para recuperar espaço com instruções sobre o que preservar, em vez de deixar a auto-compactação adivinhar.\nPonto-chave 5: calibre confiança e preserve proveniência — não confie numa métrica agregada # Uma métrica de acurácia agregada pode esconder um modelo excelente num tipo de documento e não confiável em outro; a correção é amostragem aleatória estratificada entre segmentos, não um único percentual geral, mais pontuações de confiança em nível de campo calibradas contra um conjunto de dados rotulado, para que extrações de baixa confiança sejam roteadas para revisão humana antes de serem entregues. A mesma disciplina se aplica à síntese multi-fonte: a atribuição de fonte se perde no momento em que um fato é resumido sem sua origem, então mapeamentos estruturados de afirmação-para-fonte (URL, trecho, data de publicação) precisam sobreviver intactos à síntese, estatísticas conflitantes de fontes confiáveis devem ser mostradas lado a lado com atribuição em vez de silenciosamente mescladas num único número, e qualquer coisa sensível ao tempo precisa carregar sua data de coleta ou publicação em vez de ser apresentada como atual.\nO quanto isso pesa # 15% da prova — e o domínio com mais chance de determinar se seu agente ainda é confiável depois da sexta hora Conclusão # O Domínio 5 em uma passada: a sumarização apaga silenciosamente fatos concretos a menos que você os extraia para um registro estruturado que sobrevive independentemente, e o efeito lost-in-the-middle significa que a posição no prompt importa tanto quanto o conteúdo. Escalonamento precisa de gatilhos explícitos, apoiados por exemplos — sentimento e pontuações de confiança não são sinais confiáveis por si só. Propagação estruturada de erros, com uma distinção real entre falha e vazio-mas-válido, é o que permite que um sistema multiagente se recupere em vez de degradar silenciosamente. Exploração de bases de código grandes precisa de scratchpads, isolamento por subagente e compactação deliberada para evitar a deterioração do contexto. E a confiança na saída vem de amostragem estratificada e pontuações de confiança calibradas, não de um número de acurácia agregado — combinada com proveniência que sobrevive à síntese em vez de se dissolver nela.\nFontes # Claude Certified Architect – Foundations Exam Guide — declarações de tarefa do Domínio 5 Context editing — Claude Platform Docs — limpeza automática de resultados de ferramentas, a memory tool Manage costs effectively — Claude Code Docs — /compact, gerenciamento de contexto em sessões longas Best practices for Claude Code — Claude Code Docs — delegação a subagentes para exploração verbosa A pesquisa e a checagem de precisão técnica contra a documentação oficial são feitas com apoio de IA; o enquadramento, os julgamentos sobre \u0026ldquo;o que isso significa para a prova\u0026rdquo; e eventuais histórias de campo são meus.\nOnde isso se encaixa # Parte 6 de Tornando-se um Claude Architect, seguindo o Domínio 4 — Prompt Engineering \u0026amp; Structured Output. A Parte 7 fecha a série com um quiz interativo de 100 perguntas cobrindo os cinco domínios.\n","date":"24/09/2026","externalUrl":null,"permalink":"/pt-br/posts/claude-architect-06-context-management-reliability/","section":"Posts","summary":"Do que se trata # O Domínio 5 — Context Management \u0026 Reliability — é o domínio mais leve da prova Claude Certified Architect – Foundations, com 15%, mas suas seis áreas de tarefa cobrem o que decide se um agente de execução longa permanece confiável: preservar fatos críticos ao longo de interações longas, saber quando escalar, permitir que um sistema multiagente se recupere de falhas em vez de degradar silenciosamente, gerenciar contexto em escala, e calibrar o quanto confiar na saída.\n","title":"Tornando-se um Claude Architect: Context Management \u0026 Reliability — Domínio 5","type":"posts"},{"content":" Do que se trata # O Domínio 4 — Prompt Engineering \u0026amp; Structured Output — empata com Claude Code Configuration \u0026amp; Workflows como o segundo domínio mais pesado da prova Claude Certified Architect – Foundations, com 20%. Suas seis áreas de tarefa saem de como você escreve um prompt para como você garante que o que volta é de fato utilizável: critérios explícitos, exemplos few-shot, saída reforçada por schema, loops de validação, revisão multi-instância e processamento em lote para escala.\nPonto-chave 1: critérios explícitos vencem instruções vagas, sempre # A própria documentação de prompting do Claude enquadra bem isso: trate o Claude como um funcionário brilhante, mas novo, que não tem contexto sobre suas normas. \u0026ldquo;Revise esse código\u0026rdquo; deixa o Claude adivinhando o que vale a pena sinalizar. \u0026ldquo;Reporte vulnerabilidades de segurança e erros de lógica; ignore preferências de estilo\u0026rdquo; não deixa. A versão em nível de arquiteto disso aparece em coisas como classificação de severidade — dar ao Claude critérios concretos do que é crítico versus menor, com exemplos reais de código de cada um — em vez de confiar que ele vai calibrar a severidade a partir de uma instrução de uma linha. O teste que a documentação sugere: mostre seu prompt para um colega com contexto mínimo e veja se ele saberia exatamente o que fazer. Se ele ficaria confuso, o Claude também ficará.\nPonto-chave 2: um punhado de bons exemplos vence uma página de descrição # Few-shot (multishot) prompting é uma das formas mais confiáveis de guiar formato, tom e estrutura da saída — o Claude generaliza a partir de exemplos concretos de forma muito mais confiável do que a partir de regras abstratas. Para tarefas de extração especificamente, em que os documentos de origem variam em estrutura, 2 a 4 exemplos bem escolhidos cobrindo os cenários ambíguos ou de borda fazem mais para reduzir alucinação do que uma especificação escrita mais longa. Os exemplos precisam merecer o espaço, porém: relevantes (próximos do seu caso de uso real), diversos (cobrindo casos extremos para que o Claude não trave num padrão não intencional), e claramente demarcados do resto do prompt (a documentação do Claude recomenda envolvê-los em tags \u0026lt;example\u0026gt; para que sejam lidos como demonstrações, não instruções).\nPonto-chave 3: tool use com JSON schemas é como você garante o formato da saída # Pedir educadamente por JSON num prompt de texto te dá JSON na maior parte do tempo. Tool use com um JSON schema — especialmente com strict: true — te dá saída em conformidade com o schema através de decodificação restrita, o que é uma garantia materialmente diferente: sem erros de parsing, sem retentativas por um formato malformado. O tool_choice te dá o controle por cima disso: auto deixa o Claude decidir se chama a ferramenta; any garante que alguma ferramenta seja chamada; e uma escolha forçada prende a uma ferramenta específica. O detalhe que vale internalizar para extração no mundo real: quando documentos de origem podem não conter todos os campos, projete esses campos como opcionais no schema (deixe-os fora de required) em vez de forçar o Claude a inventar um valor só para satisfazer o schema.\nPonto-chave 4: quando a validação falha, devolva o erro — não apenas tente de novo às cegas # Uma retentativa que reenvia o prompt idêntico depois de uma falha de validação desperdiça uma chamada e frequentemente reproduz o mesmo erro. O padrão mais forte anexa o erro de validação específico ao prompt na retentativa, para que o Claude veja exatamente o que estava errado e possa corrigir diretamente em vez de adivinhar de novo do zero. Parte de projetar isso bem é distinguir erros semânticos (o dado está errado — um campo tem um valor implausível) de erros de sintaxe (o formato está errado — JSON malformado, uma chave obrigatória faltando): eles pedem feedbacks diferentes e, em escala, rastrear quais tipos de erro se repetem mostra onde o schema ou o próprio prompt precisa mudar, não só a lógica de retentativa.\nflowchart LR A[Gerar saída] --\u003e B{Passa na validação?} B --\u003e|Sim| C[Aceitar] B --\u003e|Não| D[Anexar erro específicoao prompt] D --\u003e A style C fill:#28c840,stroke:#1c9c30,color:#fff style D fill:#2a78d6,stroke:#1c5cab,color:#fff Ponto-chave 5: um modelo revisando sua própria saída é uma checagem mais fraca do que uma instância nova revisando # A autorrevisão tem uma limitação estrutural: o modelo ainda carrega o contexto de ter gerado aquilo que agora está revisando, o que o torna menos propenso a questionar suas próprias escolhas — ele está preparado para confirmar, não para interrogar. Uma instância de revisão independente, sem memória de ter escrito o trabalho, detecta problemas mais sutis com mais confiabilidade porque não tem nada investido na abordagem original. Para revisões grandes, a mesma ideia escala em revisão multi-passo: dividir o trabalho num passo local (checando cada peça isoladamente) e num passo separado de integração ou cruzamento de arquivos (checando como as peças se encaixam), em vez de esperar que um único passo capture os dois tipos de problema de uma vez.\nUma nota rápida sobre escala: processamento em lote para cargas de trabalho tolerantes a latência # Fechando o domínio: a Message Batches API troca imediatismo por custo — cerca de 50% de desconto sobre o preço padrão de tokens, com a maioria dos lotes terminando em até uma hora e uma janela máxima de processamento de 24 horas. Ela é feita exatamente para o tipo de trabalho que este domínio aborda: extração em massa, avaliação em larga escala, moderação de conteúdo em volume — qualquer coisa não bloqueante em que um usuário não está esperando a resposta em tempo real. Cada requisição num lote carrega um custom_id, o que importa porque os resultados voltam em ordem arbitrária, não na ordem em que foram enviados; esse mesmo ID é o que permite identificar e reenviar de forma limpa só as requisições que falharam em vez de rodar o lote inteiro de novo.\nO quanto isso pesa # Empatado em segundo lugar com 20% — o domínio em que um bom prompt para de ser suficiente sozinho Conclusão # O Domínio 4 em uma passada: critérios explícitos e verificáveis vencem instruções vagas sempre. Um punhado de exemplos relevantes e diversos guia a saída de forma mais confiável do que uma descrição escrita mais longa. Tool use com um JSON schema estrito é o que de fato garante o formato da sua saída, com tool_choice como o controle e campos opcionais para dados de origem incompletos. Falhas de validação devem devolver o erro específico na retentativa, não apenas repetir o prompt. Instâncias de revisão independentes capturam o que a autorrevisão estruturalmente não consegue. E a Message Batches API é a alavanca para escala assim que a latência deixa de ser uma restrição.\nFontes # Claude Certified Architect – Foundations Exam Guide — declarações de tarefa do Domínio 4 Prompting best practices — Claude Platform Docs — critérios explícitos, exemplos few-shot Structured outputs — Claude Platform Docs — tool use estrito, JSON schema, campos opcionais Batch processing — Claude Platform Docs — Message Batches API, custom_id Best practices for Claude Code — Claude Code Docs — padrão de revisão adversarial/independente A pesquisa e a checagem de precisão técnica contra a documentação oficial são feitas com apoio de IA; o enquadramento, os julgamentos sobre \u0026ldquo;o que isso significa para a prova\u0026rdquo; e eventuais histórias de campo são meus.\nOnde isso se encaixa # Parte 5 de Tornando-se um Claude Architect, seguindo o Domínio 3 — Claude Code Configuration \u0026amp; Workflows. A Parte 6 assume o Domínio 5 — Context Management \u0026amp; Reliability.\n","date":"24/09/2026","externalUrl":null,"permalink":"/pt-br/posts/claude-architect-05-prompt-engineering-structured-output/","section":"Posts","summary":"Do que se trata # O Domínio 4 — Prompt Engineering \u0026 Structured Output — empata com Claude Code Configuration \u0026 Workflows como o segundo domínio mais pesado da prova Claude Certified Architect – Foundations, com 20%. Suas seis áreas de tarefa saem de como você escreve um prompt para como você garante que o que volta é de fato utilizável: critérios explícitos, exemplos few-shot, saída reforçada por schema, loops de validação, revisão multi-instância e processamento em lote para escala.\n","title":"Tornando-se um Claude Architect: Prompt Engineering \u0026 Structured Output — Domínio 4","type":"posts"},{"content":" Do que se trata # Isso fecha a série Tornando-se um Claude Architect com uma autoavaliação: 100 perguntas de prática, 20 por domínio, cobrindo tudo desde o Domínio 1 — Agentic Architecture \u0026amp; Orchestration até o Domínio 5 — Context Management \u0026amp; Reliability. Clique numa resposta e você verá imediatamente se está certa, com uma explicação curta de qualquer forma.\nIsto é um material de estudo não oficial, com apoio de IA — não validado contra o estilo ou dificuldade da prova real. Eu mesmo redigi essas perguntas, fundamentadas nas declarações de tarefa do guia oficial da prova e no conteúdo das Partes 2 a 6 desta série, mas a Anthropic não revisou nem endossou esse material. Trate isso como uma forma de testar seu próprio entendimento, não como substituto do guia oficial da prova ou do material de preparação da própria Anthropic.\n20 perguntas por domínio, ajustadas à participação de cada domínio na prova real Como usar # flowchart LR A[Leia a pergunta] --\u003e B[Escolha uma resposta] B --\u003e C{Correta?} C --\u003e|Sim| D[Marca verde + explicação] C --\u003e|Não| E[X vermelho na sua escolha,marca verde na certa,+ explicação] D --\u003e F[Vá para a próxima pergunta] E --\u003e G[Releia a seção relevantedo post do domínio] G --\u003e F style D fill:#28c840,stroke:#1c9c30,color:#fff style E fill:#e0524a,stroke:#b3261e,color:#fff Sem pontuação, sem embaralhamento, sem cronômetro — apenas clique nas 20 perguntas de um domínio, em ordem, e veja como você se sai. Se uma pergunta te derrubar, ela nomeia o conceito claramente o suficiente na explicação para você voltar à seção completa daquele domínio no post correspondente.\nDomínio 1 — Agentic Architecture \u0026amp; Orchestration (27%) # Domínio 2 — Tool Design \u0026amp; MCP Integration (18%) # Domínio 3 — Claude Code Configuration \u0026amp; Workflows (20%) # Domínio 4 — Prompt Engineering \u0026amp; Structured Output (20%) # Domínio 5 — Context Management \u0026amp; Reliability (15%) # Conclusão # Essa é a série: cinco domínios, trinta e um pontos-chave, cinco diagramas, cinco gráficos, e agora cem perguntas para checar o que ficou. A prova Claude Certified Architect – Foundations testa julgamento arquitetural real — quando recorrer a um subagente em vez de fazer o trabalho diretamente, como projetar uma descrição de ferramenta que um modelo consegue de fato interpretar corretamente, quando o plan mode compensa sua sobrecarga, como garantir saída estruturada em vez de simplesmente esperar por ela, e como manter um agente de execução longa honesto sobre o que sabe e o que não sabe. Se este quiz revelou uma lacuna, os posts de domínio linkados acima são a forma mais rápida de fechá-la.\nFontes # Claude Certified Architect – Foundations Exam Guide — declarações de tarefa dos cinco domínios Série Tornando-se um Claude Architect — Partes 1 a 6, a fonte primária de cada pergunta acima Essas 100 perguntas foram redigidas com IA e checadas contra o conteúdo dos próprios posts de domínio e o guia da prova; eu as revisei quanto à precisão e adequação, mas elas não foram validadas contra o estilo ou dificuldade reais das perguntas da prova.\nOnde isso se encaixa # Parte 7 — o final — de Tornando-se um Claude Architect, seguindo o Domínio 5 — Context Management \u0026amp; Reliability. Essa é a série completa: da Parte 1 — Visão Geral até este quiz de prática.\n","date":"24/09/2026","externalUrl":null,"permalink":"/pt-br/posts/claude-architect-07-practice-quiz/","section":"Posts","summary":"Do que se trata # Isso fecha a série Tornando-se um Claude Architect com uma autoavaliação: 100 perguntas de prática, 20 por domínio, cobrindo tudo desde o Domínio 1 — Agentic Architecture \u0026 Orchestration até o Domínio 5 — Context Management \u0026 Reliability. Clique numa resposta e você verá imediatamente se está certa, com uma explicação curta de qualquer forma.\n","title":"Tornando-se um Claude Architect: Quiz de Prática com 100 Perguntas — Parte 7","type":"posts"},{"content":" Do que se trata # O Domínio 2 — Tool Design \u0026amp; MCP Integration — representa 18% da prova Claude Certified Architect – Foundations, dividido em cinco áreas de tarefa: projetar interfaces de ferramentas, estruturar respostas de erro, distribuir ferramentas entre agentes, integrar servidores MCP e escolher bem as ferramentas nativas. É um domínio mais leve que Agentic Architecture, mas talvez o mais imediatamente prático — cada ponto aqui aparece na primeira vez que você dá a um agente uma ferramenta que não funciona do jeito que você esperava.\nPonto-chave 1: a descrição da ferramenta é o mecanismo de seleção # Um LLM não lê o código da sua ferramenta antes de decidir chamá-la — ele lê a descrição. Essa é toda a base da seleção de ferramentas, o que significa que uma descrição mínima (\u0026ldquo;busca arquivos\u0026rdquo;) é um risco no momento em que você tem duas ferramentas que poderiam plausivelmente atender a um mesmo pedido. A correção que a prova cobra é específica: descrições devem incluir formatos de entrada, exemplos de consultas, casos extremos e limites explícitos — o que a ferramenta faz e o que ela não cobre. Na prática, isso costuma significar renomear ferramentas para eliminar sobreposição funcional, ou dividir uma ferramenta genérica em várias específicas com contratos bem definidos, em vez de tentar escrever uma descrição cada vez mais longa para uma ferramenta que faz coisa demais.\nPonto-chave 2: erros estruturados permitem que o agente se recupere, erros genéricos não # Quando uma chamada de ferramenta falha, \u0026ldquo;Operação falhou\u0026rdquo; não diz nada que o modelo consiga usar. O mecanismo real do MCP distingue duas camadas: erros de protocolo (requisição malformada, ferramenta desconhecida — retornados como erros JSON-RPC, e menos recuperáveis) versus erros de execução de ferramenta (falhas de validação, erros de lógica de negócio, falhas de API — retornados dentro do resultado da ferramenta com isError: true, especificamente para que o modelo consiga se autocorrigir e tentar de novo com parâmetros ajustados). A habilidade no nível de arquiteto vai além da flag isolada: retornar metadados de erro estruturados que categorizam a falha (transitório, validação, negócio, permissão) com uma flag de \u0026ldquo;pode tentar de novo\u0026rdquo;, e distinguir uma falha de acesso genuína de um resultado válido, porém vazio — porque essas duas coisas nunca deveriam parecer iguais para o agente.\nPonto-chave 3: menos ferramentas por agente, escolhidas de propósito # O guia oficial da prova afirma isso quase como uma regra prática: dar a um agente acesso a ferramentas demais — o exemplo usado é 18 em vez de 4-5 — degrada a confiabilidade da seleção de ferramentas. A correção não é reduzir as capacidades no geral, é o acesso escopado: dar a cada subagente só as ferramentas relevantes para o seu papel, e substituir uma ferramenta genérica demais por uma alternativa mais restrita e específica quando um subagente insiste em usá-la mal. A API do Claude te dá uma segunda alavanca para o mesmo problema: tool_choice. auto deixa o Claude decidir se chama alguma ferramenta; any (ou uma escolha forçada de tool nomeando uma específica) garante que uma ferramenta seja usada, o que é a decisão certa quando você precisa que uma ferramenta em particular seja chamada primeiro, antes de o Claude raciocinar sobre qualquer outra coisa.\nPonto-chave 4: servidores MCP têm escopo por um motivo — não use o errado por padrão # O Claude Code separa a configuração de servidores MCP por escopo: nível de projeto (.mcp.json, versionado no controle de versão) é para ferramentas compartilhadas do time que todo mundo no repositório recebe automaticamente, enquanto nível de usuário (~/.claude.json) é para servidores pessoais ou experimentais que você não quer commitar. Credenciais passam por expansão de variável de ambiente (${API_KEY}, com sintaxe de fallback ${VAR:-default}) em vez de ficarem fixas no arquivo de configuração, o que é o que torna um .mcp.json seguro para commitar em primeiro lugar — o arquivo tem o formato da configuração, não o segredo. O outro hábito no nível de arquiteto que vale destacar: preferir um servidor MCP comunitário já existente e bem mantido antes de construir um customizado, e expor conteúdo de leitura pesada (como um catálogo ou base de conhecimento) como resources do MCP, em vez de embrulhá-lo numa ferramenta que só retorna um bloco de texto.\nEscopo de projeto (.mcp.json) Escopo de usuário (~/.claude.json) Carrega em Projeto atual Todos os seus projetos Compartilhado com o time Sim, via controle de versão Não Uso típico Ferramentas compartilhadas do time Servidores pessoais ou experimentais Ponto-chave 5: escolha a ferramenta nativa certa para o trabalho # A prova também cobra julgamento simples de seleção de ferramenta entre as nativas do próprio Claude Code. Grep é para busca de conteúdo — encontrar onde uma função é chamada em uma base de código. Glob é para correspondência de padrão de caminho de arquivo — encontrar arquivos por nome ou extensão, não pelo que está dentro deles. Read e Write lidam com operações de arquivo inteiro; Edit é para uma modificação pontual e no lugar, em vez de reescrever um arquivo inteiro. Encadeadas bem, essas ferramentas constroem entendimento de código incrementalmente — Glob para achar candidatos, Grep para restringir por conteúdo, Read para confirmar, Edit para alterar — em vez de usar Read em todo arquivo de um diretório por precaução.\nflowchart TD A[O que você precisa fazer?] --\u003e B{Está buscando algo?} B --\u003e|Por nome/padrão de arquivo| C[Glob] B --\u003e|Por conteúdo do arquivo| D[Grep] A --\u003e E{Está alterando um arquivo?} E --\u003e|Mudança pequena e pontual| F[Edit] E --\u003e|Leitura ou reescrita completa| G[Read / Write] style C fill:#c9ddf6,stroke:#86b6ef,color:#0b0b0b style D fill:#c9ddf6,stroke:#86b6ef,color:#0b0b0b style F fill:#2a78d6,stroke:#1c5cab,color:#fff style G fill:#86b6ef,stroke:#5598e7,color:#0b0b0b O quanto isso pesa # 18% da prova, mas o domínio com mais chance de quebrar seu primeiro agente em produção Conclusão # O Domínio 2 em uma passada: a descrição é a interface — escreva-a como se o modelo estivesse escolhendo às cegas, porque é exatamente isso. Erros estruturados com isError e uma flag de categoria/pode-tentar-de-novo permitem que um agente se recupere em vez de simplesmente falhar. Menos ferramentas, bem escopadas por agente, vencem uma lista de ferramentas de pia de cozinha, e tool_choice te dá uma segunda alavanca para garantir que a certa seja chamada. Servidores MCP se dividem claramente entre compartilhado-de-projeto e pessoal-de-usuário por um motivo — respeite esse escopo. E as ferramentas nativas recompensam quem escolhe de propósito: Grep para conteúdo, Glob para caminhos, Edit para mudanças pequenas, Read/Write para arquivos inteiros.\nFontes # Claude Certified Architect – Foundations Exam Guide — declarações de tarefa do Domínio 2 Tools — Model Context Protocol specification — isError, erros de protocolo vs. erros de execução de ferramenta Implement tool use — Claude API Docs — opções de tool_choice Connect Claude Code to tools via MCP — Claude Code Docs — escopo de servidor de projeto vs. usuário, expansão de variável de ambiente A pesquisa e a checagem de precisão técnica contra a documentação oficial são feitas com apoio de IA; o enquadramento, os julgamentos sobre \u0026ldquo;o que isso significa para a prova\u0026rdquo; e eventuais histórias de campo são meus.\nOnde isso se encaixa # Parte 3 de Tornando-se um Claude Architect, seguindo o Domínio 1 — Agentic Architecture \u0026amp; Orchestration. A Parte 4 assume o Domínio 3 — Claude Code Configuration \u0026amp; Workflows.\n","date":"24/09/2026","externalUrl":null,"permalink":"/pt-br/posts/claude-architect-03-tool-design-mcp-integration/","section":"Posts","summary":"Do que se trata # O Domínio 2 — Tool Design \u0026 MCP Integration — representa 18% da prova Claude Certified Architect – Foundations, dividido em cinco áreas de tarefa: projetar interfaces de ferramentas, estruturar respostas de erro, distribuir ferramentas entre agentes, integrar servidores MCP e escolher bem as ferramentas nativas. É um domínio mais leve que Agentic Architecture, mas talvez o mais imediatamente prático — cada ponto aqui aparece na primeira vez que você dá a um agente uma ferramenta que não funciona do jeito que você esperava.\n","title":"Tornando-se um Claude Architect: Tool Design \u0026 MCP Integration — Domínio 2","type":"posts"},{"content":" Do que se trata # O Claude Certified Architect – Foundations é a certificação da Anthropic para projetar sistemas com Claude, não só usá-los. Enquanto a prova Claude Certified Associate testa se você consegue operar o Claude com disciplina profissional — bons prompts, julgamento sólido sobre o resultado, o ponto de entrada certo para o trabalho —, a prova Architect testa um nível acima: você consegue projetar o sistema agêntico, as integrações de ferramentas e a configuração sobre os quais outras pessoas vão construir. O candidato ideal tem 6+ meses de experiência prática construindo com a API do Claude, o Claude Agent SDK, o Claude Code e o Model Context Protocol (MCP) — essa não é uma primeira certificação, é a próxima.\nIsso abre uma nova série, Tornando-se um Claude Architect, separada da minha série Getting Claude Certified sobre a prova Associate. Se você ainda não fez essa, é o ponto natural para começar — esta série assume que os hábitos de fluência daquela já estão consolidados.\nPonto-chave 1: a prova, em números # 60 itens, múltipla escolha e múltipla resposta, 120 minutos, aplicada com proctoring online ou em centro de testes. A aprovação é uma pontuação escalonada de 720 em uma escala de 100 a 1.000 — a Anthropic não publica a conversão de acertos brutos para pontuação escalonada, então \u0026ldquo;720\u0026rdquo; não é \u0026ldquo;72% das questões certas\u0026rdquo;, é uma régua calibrada. A credencial custa $125 e vale por 12 meses, e o resultado volta como aprovado/reprovado mais um detalhamento de percentual de acerto por domínio, então você sabe exatamente onde focar numa segunda tentativa.\nPonto-chave 2: cinco domínios, um claramente mais pesado # flowchart LR A[Agentic Architecture\u0026 Orchestration — 27%] --\u003e F[Prova Architect] B[Claude Code Configuration\u0026 Workflows — 20%] --\u003e F C[Prompt Engineering\u0026 Structured Output — 20%] --\u003e F D[Tool Design\u0026 MCP Integration — 18%] --\u003e F E[Context Management\u0026 Reliability — 15%] --\u003e F style A fill:#2a78d6,stroke:#1c5cab,color:#fff style B fill:#86b6ef,stroke:#5598e7,color:#0b0b0b style C fill:#86b6ef,stroke:#5598e7,color:#0b0b0b style D fill:#c9ddf6,stroke:#86b6ef,color:#0b0b0b style E fill:#c9ddf6,stroke:#86b6ef,color:#0b0b0b Agentic Architecture and Orchestration sozinho vale mais que os dois domínios mais leves somados Agentic Architecture \u0026amp; Orchestration carrega mais peso que qualquer outro domínio isolado — mais de um quarto da prova —, o que mostra onde a Anthropic acredita estar a real lacuna de habilidade entre alguém que usa bem o Claude e alguém que projeta sistemas com Claude: não em conhecer a superfície da API, mas em projetar como o trabalho autônomo é orquestrado, repassado e mantido confiável.\nPonto-chave 3: habilidade de uso e habilidade de arquitetura são provas diferentes por um motivo # Ser bom em prompting não torna alguém automaticamente bom em decidir quando um workflow deveria virar um sistema multiagente, como deveria ser a interface de uma ferramenta para um LLM que a chama às cegas, ou como um deployment do Claude Code deveria ser configurado para um time confiar nele em produção. A prova Associate testa julgamento dentro de uma única conversa. A prova Architect testa julgamento sobre o sistema ao redor da conversa — as partes que um bom prompt sozinho não resolve.\nPonto-chave 4: o que esta série vai cobrir # Mais seis posts seguem este, cada um cobrindo um domínio na ordem do guia da prova: Agentic Architecture \u0026amp; Orchestration, Tool Design \u0026amp; MCP Integration, Claude Code Configuration \u0026amp; Workflows, Prompt Engineering \u0026amp; Structured Output, e Context Management \u0026amp; Reliability. A série se encerra com um conjunto interativo de 100 questões práticas — 20 por domínio, clique numa resposta e veja na hora se está certa — construído como material de estudo não oficial depois que os cinco posts de domínio estiverem prontos.\nConclusão # O Claude Certified Architect – Foundations em uma passada: é a certificação seguinte depois da Associate, não uma versão mais difícil da mesma — ela testa design de sistemas, não disciplina de uso. 60 itens, 120 minutos, um 720 escalonado para passar. Agentic Architecture \u0026amp; Orchestration é o domínio a levar mais a sério, com 27% da prova, com Claude Code Configuration \u0026amp; Workflows e Prompt Engineering \u0026amp; Structured Output empatados logo atrás, com 20% cada. Seis posts domínio por domínio e um quiz prático vêm a seguir.\nFontes # Claude Certified Architect – Foundations Certification — Anthropic Partner Academy Claude Certified Architect – Foundations Exam Guide — PDF oficial Onde isso se encaixa # Parte 1 de Tornando-se um Claude Architect. Esta série continua a partir de Getting Claude Certified, minha série de 9 partes sobre a prova Claude Certified Associate – Foundations — comece por lá se você ainda está começando com o Claude. A Parte 2 assume o Domínio 1 — Agentic Architecture \u0026amp; Orchestration.\n","date":"24/09/2026","externalUrl":null,"permalink":"/pt-br/posts/claude-architect-01-overview/","section":"Posts","summary":"Do que se trata # O Claude Certified Architect – Foundations é a certificação da Anthropic para projetar sistemas com Claude, não só usá-los. Enquanto a prova Claude Certified Associate testa se você consegue operar o Claude com disciplina profissional — bons prompts, julgamento sólido sobre o resultado, o ponto de entrada certo para o trabalho —, a prova Architect testa um nível acima: você consegue projetar o sistema agêntico, as integrações de ferramentas e a configuração sobre os quais outras pessoas vão construir. O candidato ideal tem 6+ meses de experiência prática construindo com a API do Claude, o Claude Agent SDK, o Claude Code e o Model Context Protocol (MCP) — essa não é uma primeira certificação, é a próxima.\n","title":"Tornando-se um Claude Architect: Visão Geral — Claude Certified Architect – Foundations","type":"posts"},{"content":" Do que se trata # O Domínio 7 da prova Claude Certified Associate – Foundations é Troubleshooting e Otimização. Vale 10% — o domínio mais leve da prova. Mas é o que fecha o ciclo dos outros seis: tudo, do prompting à configuração à seleção de modelo, eventualmente produz um resultado abaixo do esperado, e esse domínio é a disciplina de rastrear essa falha até a causa raiz, corrigi-la, e garantir que a correção persista em vez de ser redescoberta na semana seguinte.\nTroubleshooting and Optimization é o domínio mais leve da prova — mas é aquele por onde todo os outros eventualmente passam Ponto-chave 1: quatro padrões de falha, quatro correções diferentes # O desempenho abaixo do esperado quase sempre se rastreia a um de quatro padrões, e cada um deixa uma assinatura de sintoma distinta. A sub-especificação — o prompt deixa inferência demais a cargo do Claude — aparece como formato de saída inconsistente em execuções por outro lado parecidas. A sobrecarga de contexto — informação demais competindo e sufocando instruções iniciais — aparece como qualidade que estava boa e foi silenciosamente decaindo conforme a sessão crescia. A funcionalidade ou modelo errado — a tarefa precisa de outra ferramenta completamente — aparece como um prompt correto mas com um teto limitado pela configuração por trás dele. A configuração desatualizada — instruções, conhecimento ou uma Skill refletindo um processo antigo — aparece como um resultado que estava correto por meses e de repente errado sem nenhuma razão do lado do prompt. Nomear o padrão antes de buscar uma correção já é a maior parte do diagnóstico.\nCombine o sintoma com o padrão antes de mexer em qualquer coisa — os quatro padrões raramente compartilham uma correção Ponto-chave 2: corrija o mais barato primeiro # A sequência de diagnóstico vai do menor custo ao maior: verifique o prompt e as instruções antes de trocar de modelo, verifique a configuração antes de reconstruir o workflow. Recorrer a um modelo maior ou a um redesenho completo do workflow antes de descartar uma instrução vaga ou uma configuração desatualizada consome tempo e muitas vezes nem resolve o problema, porque a causa raiz nunca foi capacidade de modelo, para começo de conversa.\nflowchart TD A[Resultado abaixo do esperado] --\u003e B{O prompt ou a instruçãoé específico o bastante?} B --\u003e|Não| C[Corrija o prompt/instruçõesmais barato, tente primeiro] B --\u003e|Sim| D{A configuração estádesatualizada ou ausente?} D --\u003e|Sim| E[Atualize instruções,conhecimento ou Skill] D --\u003e|Não| F{É a funcionalidade ounível de modelo certo?} F --\u003e|Não| G[Troque o ponto de entradaou o nível de modelo] F --\u003e|Sim| H[Redesenhe o workflowúltimo recurso, maior custo] style C fill:#86b6ef,stroke:#5598e7,color:#0b0b0b style E fill:#2a78d6,stroke:#1c5cab,color:#fff style G fill:#104281,stroke:#0d366b,color:#fff style H fill:#d03b3b,stroke:#a32e2e,color:#fff Ponto-chave 3: transforme crítica vaga em ajuste específico # \u0026ldquo;Deixa melhor\u0026rdquo; não é acionável — não dá ao Claude nada de novo para agir, então a próxima tentativa decai do mesmo jeito que a primeira. Nomear a dimensão exata que falhou é o que de fato muda o resultado: não \u0026ldquo;o tom está errado\u0026rdquo;, mas \u0026ldquo;tire os pontos de exclamação e corte toda frase que repete a anterior.\u0026rdquo; A diferença entre uma correção capturada e uma perdida é se esse ajuste específico é escrito em uma instrução permanente, ou só aplicado uma vez, no momento, e esquecido na sessão seguinte.\nPonto-chave 4: encontre atrito com três sinais, depois promova a correção # Três sinais apontam para uma correção que vale a pena tornar permanente: repetição (você está digitando a mesma correção em sessões diferentes), correção (você está editando o mesmo tipo de erro para fora do resultado toda vez), e variância (o mesmo pedido produz qualidade bem diferente dependendo de quem pergunta ou de quando). Assim que um sinal aparece, a correção precisa de um lar — e o teste para qual é simples: uma regra sobre comportamento vai nas instruções permanentes, um fato de referência vai na base de conhecimento, um procedimento com múltiplas etapas vira uma Skill. Promover a correção para o slot certo é o que impede a correção de se repetir.\nPonto-chave 5: meça a melhoria contra a métrica que importa # Uma auditoria de workflow que vai de 45 minutos para 25 minutos só conta se os 45 minutos eram de fato o gargalo e os 25 minutos são medidos da mesma forma — mesma tarefa, mesmo padrão de revisão, não um mais frouxo. A tentação é otimizar o que for mais fácil de medir; a disciplina é otimizar a métrica que era de fato a reclamação original, seja ela tempo, número de revisões, ou com que frequência um humano precisa intervir.\nO ciclo completo de diagnóstico até otimização do Domínio 7 em uma folha de referência Conclusão # O Domínio 7 em uma passada: nomeie o padrão de falha antes de buscar uma correção — sub-especificação, sobrecarga de contexto, funcionalidade ou modelo errado, configuração desatualizada, cada um deixa um sintoma diferente. Corrija o mais barato primeiro: prompt e instruções antes de trocar de modelo, configuração antes de redesenhar o workflow. Transforme crítica vaga em um ajuste específico e capturável em vez de uma correção pontual. Observe repetição, correção e variância, depois promova a correção para o lar certo — regra, referência ou procedimento. E meça a melhoria contra a métrica que era de fato a reclamação, não a que for mais fácil de acompanhar.\nFontes # Troubleshooting \u0026amp; Optimization — Anthropic Partner Academy Claude Certified Associate – Foundations Exam Guide — PDF oficial Onde isso se encaixa # Parte 9 de Getting Claude Certified. A Parte 1 cobriu o Framework 4D, a Parte 2 cobriu Chat, Projects, Artifacts e Research, a Parte 3 cobriu o Domínio 1 — Avaliação e Validação de Resultados, a Parte 4 cobriu o Domínio 2 — Integração de Workflow e Design de Soluções, a Parte 5 cobriu o Domínio 3 — Governança, Risco e Uso Responsável, a Parte 6 cobriu o Domínio 4 — Prompting e Execução de Tarefas, a Parte 7 cobriu o Domínio 5 — Seleção de Produto e Modelo, a Parte 8 cobriu o Domínio 6 — Configuração e Gestão de Conhecimento. São os 7 domínios da prova completos — a série se encerra aqui.\n","date":"19/09/2026","externalUrl":null,"permalink":"/pt-br/posts/claude-cert-09-troubleshooting-and-optimization/","section":"Posts","summary":"Do que se trata # O Domínio 7 da prova Claude Certified Associate – Foundations é Troubleshooting e Otimização. Vale 10% — o domínio mais leve da prova. Mas é o que fecha o ciclo dos outros seis: tudo, do prompting à configuração à seleção de modelo, eventualmente produz um resultado abaixo do esperado, e esse domínio é a disciplina de rastrear essa falha até a causa raiz, corrigi-la, e garantir que a correção persista em vez de ser redescoberta na semana seguinte.\n","title":"Claude Certified Associate – Foundations: Domínio 7 — Troubleshooting e Otimização","type":"posts"},{"content":"","date":"19/09/2026","externalUrl":null,"permalink":"/pt-br/series/getting-claude-certified/","section":"Series","summary":"","title":"Getting-Claude-Certified","type":"series"},{"content":"","date":"19/09/2026","externalUrl":null,"permalink":"/pt-br/tags/optimization/","section":"Tags","summary":"","title":"Optimization","type":"tags"},{"content":"","date":"19/09/2026","externalUrl":null,"permalink":"/pt-br/tags/troubleshooting/","section":"Tags","summary":"","title":"Troubleshooting","type":"tags"},{"content":" Do que se trata # O Domínio 6 da prova Claude Certified Associate – Foundations é Configuração e Gestão de Conhecimento. Vale 12%. A linha que ele traça: usar o Claude significa digitar um bom prompt hoje. Operar o Claude significa construir um ambiente em que o contexto certo, as instruções e os procedimentos já existem, para que toda conversa comece de uma base configurada em vez de uma folha em branco. Configuração é alavancagem — você configura uma vez e se beneficia em toda conversa que vem depois — e também é o que transforma habilidade individual em capacidade de time, já que duas pessoas fazendo a mesma pergunta contra o mesmo Project configurado recebem a mesma qualidade de resposta.\nConfiguração e Gestão de Conhecimento empata no quinto lugar mais pesado da prova Ponto-chave 1: quatro mecanismos, quatro trabalhos diferentes # As instruções governam comportamento — tom, padrões de formato, hábitos de verificação — não fatos. A base de conhecimento guarda fatos e material de referência que o Claude deve usar sem precisar reenviar — não comportamento. As Skills carregam um procedimento repetível, construído uma vez no nível da conta em Customize e reutilizado em qualquer Project que precise dele — não uma instrução pontual. A Memory com escopo mantém continuidade dentro de um Project, isolada dos seus outros Projects para que o contexto nunca vaze entre workstreams.\nCombine a necessidade com o slot certo — colocar um procedimento nas instruções ou uma regra de comportamento no conhecimento é o erro de configuração mais comum flowchart TD A[Uma necessidade recorrente] --\u003e B{Que tipo denecessidade é essa?} B --\u003e|Como o Claude deve se comportar| C[Instructions] B --\u003e|Um fato que o Claude deve saber| D[Knowledge base] B --\u003e|Um procedimento repetível de múltiplas etapas| E[Skill] B --\u003e|Continuidade dentro deste Project| F[Scoped Memory] style C fill:#2a78d6,stroke:#1c5cab,color:#fff style D fill:#eb6834,stroke:#c14e22,color:#fff style E fill:#1baf7a,stroke:#0d8a5c,color:#fff style F fill:#eda100,stroke:#c98500,color:#fff Ponto-chave 2: a maioria das necessidades mapeia para dois slots conectados # As configurações mais limpas raramente cabem em um único mecanismo. \u0026ldquo;Sempre cite o documento-fonte para afirmações factuais\u0026rdquo; é uma instrução permanente, mas os documentos que ela cita vivem na base de conhecimento — nenhum dos dois funciona sozinho. Um consultor rodando um Project por cliente se combina da mesma forma: instruções permanentes definem o registro formal e o hábito de citação, a base de conhecimento guarda o guia de marca do cliente e o escopo de trabalho atual, uma Skill no nível da conta formata todo relatório de status da mesma forma, e a Memory com escopo guarda os nomes dos stakeholders daquele cliente — mantidos fora do Project de qualquer outro cliente.\nPonto-chave 3: conectores têm limites de capacidade, não bugs # Um conector — Google Drive, Gmail — estende o alcance do Claude aos dados que você autoriza, e cada um tem um limite definido. Um conector de e-mail que consegue buscar e ler mas não enviar não está quebrado; ele está no seu limite. Duas armadilhas aparecem com frequência no uso real: o caminho óbvio de \u0026ldquo;adicionar um conector\u0026rdquo; pode levar a um diretório público em vez dos conectores aprovados pela sua organização, então confirme o caminho certo com seu admin no Team ou Enterprise; e quando um conector atinge seu limite, a falha parece um bug em vez de comportamento documentado, o que manda relatos para o time errado e trava a correção. Conhecer o limite de cada conector antes de construir um workflow sobre ele evita as duas coisas.\nPonto-chave 4: uma instrução vaga falha silenciosamente # \u0026ldquo;Faça os relatórios bons e precisos\u0026rdquo; dá ao Claude quase nada para agir — a qualidade do resultado varia de conversa para conversa e nada nunca anuncia a falha. \u0026ldquo;Para cada número em um relatório, indique sua fonte. Se um número não estiver nos dados fornecidos, marque-o como \u0026rsquo;não verificado\u0026rsquo; em vez de incluí-lo. Comece cada relatório com uma manchete de uma frase\u0026rdquo; é precisa o suficiente para de fato mudar o resultado, de forma consistente. O teste para qualquer instrução permanente: duas pessoas diferentes lendo ela produziriam o mesmo comportamento?\nPonto-chave 5: configurações envelhecem — agende a manutenção # Instruções, conhecimento, Skills e Memory todos tendem a ficar desatualizados, e nenhum deles lança um erro quando isso acontece — o resultado só degrada silenciosamente. Uma revisão mensal nos Projects ativos pega a maior parte disso: as instruções permanentes ainda combinam com o processo atual, a base de conhecimento está livre de documentos superados, as Skills certas estão habilitadas. Skills construídas pela Anthropic ou provisionadas pela organização se atualizam automaticamente; suas próprias Skills personalizadas só mudam quando você as reenvia. Um Project de relatório recorrente com números desatualizados é um caso clássico — a base de conhecimento já tinha as metas atuais, mas a instrução permanente e uma entrada de Memory ainda apontavam para o modelo do ano passado. A correção foi atualizar essas duas coisas, não escrever um prompt melhor.\nO framework inteiro do Domínio 6 em uma página — feito para compartilhar como resumo autônomo Conclusão # O Domínio 6 em uma passada: combine cada necessidade recorrente com o mecanismo certo — instruções para comportamento, conhecimento para fatos, Skills para procedimento, Memory com escopo para continuidade — e espere que a maioria das necessidades reais conecte dois deles. Conheça o limite de capacidade de cada conector antes de construir sobre ele. Escreva instruções precisas o suficiente para que duas pessoas as leiam da mesma forma. E agende manutenção, porque a configuração decai silenciosamente e a correção quase sempre é atualizar a configuração, não o prompt.\nFontes # Configuration \u0026amp; Knowledge Management — Anthropic Partner Academy Claude Certified Associate – Foundations Exam Guide — PDF oficial Onde isso se encaixa # Parte 8 de Getting Claude Certified. A Parte 1 cobriu o Framework 4D, a Parte 2 cobriu Chat, Projects, Artifacts e Research, a Parte 3 cobriu o Domínio 1 — Avaliação e Validação de Resultados, a Parte 4 cobriu o Domínio 2 — Integração de Workflow e Design de Soluções, a Parte 5 cobriu o Domínio 3 — Governança, Risco e Uso Responsável, a Parte 6 cobriu o Domínio 4 — Prompting e Execução de Tarefas, a Parte 7 cobriu o Domínio 5 — Seleção de Produto e Modelo. A Parte 9 cobriu o Domínio 7 — Troubleshooting and Optimization — encerrando os 7 domínios da prova.\n","date":"18/09/2026","externalUrl":null,"permalink":"/pt-br/posts/claude-cert-08-configuration-and-knowledge-management/","section":"Posts","summary":"Do que se trata # O Domínio 6 da prova Claude Certified Associate – Foundations é Configuração e Gestão de Conhecimento. Vale 12%. A linha que ele traça: usar o Claude significa digitar um bom prompt hoje. Operar o Claude significa construir um ambiente em que o contexto certo, as instruções e os procedimentos já existem, para que toda conversa comece de uma base configurada em vez de uma folha em branco. Configuração é alavancagem — você configura uma vez e se beneficia em toda conversa que vem depois — e também é o que transforma habilidade individual em capacidade de time, já que duas pessoas fazendo a mesma pergunta contra o mesmo Project configurado recebem a mesma qualidade de resposta.\n","title":"Claude Certified Associate – Foundations: Domínio 6 — Configuração e Gestão de Conhecimento","type":"posts"},{"content":"","date":"18/09/2026","externalUrl":null,"permalink":"/pt-br/tags/configuration/","section":"Tags","summary":"","title":"Configuration","type":"tags"},{"content":"","date":"18/09/2026","externalUrl":null,"permalink":"/pt-br/tags/knowledge-management/","section":"Tags","summary":"","title":"Knowledge-Management","type":"tags"},{"content":" Do que se trata # O Domínio 5 da prova Claude Certified Associate – Foundations é Seleção de Produto e Modelo. Vale 12%. O enquadramento: antes mesmo do prompting começar, quatro decisões já definem o teto de qualidade da sessão — o ponto de entrada certo, a camada de capacidade certa, o nível de modelo certo, a estratégia de contexto certa. Errar essas quatro e nenhuma quantidade de polimento no prompt conserta. Acertar essas quatro e o prompt precisa fazer muito menos trabalho.\nSeleção de Produto e Modelo empata no quinto lugar mais pesado da prova Ponto-chave 1: escolha o ponto de entrada pelo trabalho, não pelo hábito # O Chat é para uma pergunta pontual ou tarefa rápida sem necessidade de configuração recorrente. Um Project é para trabalho recorrente com contexto estável e formato de saída consistente. Um Artifact é para um entregável autônomo e editável, feito para durar além do chat. O Research é para uma investigação profunda, atual e multi-fonte, com citações. Recorrer ao Chat para tudo é o descompasso mais comum — funciona, mas joga fora o valor de carregar contexto que os outros três existem para oferecer.\nEscolha o ponto de entrada pelo que a tarefa precisa, não pelo que você abriu primeiro Existe um teste rápido para saber se vale a pena construir um Project: a tarefa se repete, o contexto de fundo é estável, o formato de saída é consistente? Se duas ou mais dessas coisas forem verdadeiras, um Project geralmente se paga.\nPonto-chave 2: quatro camadas de capacidade, um gancho de memória # Os Projects carregam contexto recorrente e configuração permanente. As Skills definem um procedimento repetível. A Code Execution verifica qualquer coisa que precise ser calculada em vez de estimada. A Memory mantém fatos relevantes entre sessões. As camadas são independentes e se combinam — um Project pode usar Skills, que podem acionar Code Execution, em uma conversa em que a Memory também tem contexto. O atalho que vale lembrar: Projects guardam conhecimento; Skills executam tarefas.\nPonto-chave 3: o frame de decisão Haiku / Sonnet / Opus # Três níveis, combinados com quão estruturada e quão consequente é a tarefa. O Haiku se encaixa em trabalho rápido, estruturado, de alto volume e baixa ambiguidade — extração, classificação, formatação, resumo direto. O Sonnet é o nível balanceado de partida para a maioria do trabalho profissional — redação, síntese, análise, apoio a pesquisa, revisão de documentos. O Opus justifica seu custo quando o teto de qualidade importa mais que a velocidade — julgamento sutil, raciocínio complexo em múltiplas etapas, entradas ambíguas, síntese de alto risco.\nflowchart TD A[Nova tarefa] --\u003e B{Estruturada, alto volume,baixa ambiguidade?} B --\u003e|Sim| C[Haikuextração, classificação, formatação] B --\u003e|Não| D{A maioria do trabalho profissional:redação, análise, síntese?} D --\u003e|Sim| E[Sonnetnível balanceado de partida] D --\u003e|Não, precisa de julgamentosutil ou de alto risco| F[Opusteto de qualidade acima da velocidade] style C fill:#86b6ef,stroke:#5598e7,color:#0b0b0b style E fill:#2a78d6,stroke:#1c5cab,color:#fff style F fill:#104281,stroke:#0d366b,color:#fff A pegadinha da prova que vale lembrar: não recorra ao Opus só porque o assunto soa importante. Se a tarefa é altamente estruturada, inequívoca e de alto volume, o Haiku costuma ser a resposta melhor, independente de quão relevante o tema pareça.\nPonto-chave 4: gerencie o contexto antes que ele degrade o resultado # Sessões longas perdem detalhes iniciais conforme o contexto enche e é comprimido. Quando uma conversa que funcionou bem por muito tempo de repente para de seguir uma instrução inicial, o sinal é degradação de contexto, não um problema de qualidade do modelo. A correção tem três movimentos: reiniciar uma nova conversa quando a atual não é mais confiável; antes de reiniciar, escrever um resumo de estado com decisões, progresso e questões em aberto, e começar a nova conversa a partir dele; e persistir qualquer coisa que deva durar além da conversa na Memory, no conhecimento do Project, ou nas instruções permanentes, em vez de reexplicar toda vez.\nPonto-chave 5: web search, Research, Enterprise Search, ou Thinking # Quatro ferramentas diferentes de busca e raciocínio, fáceis de escolher errado. O web search é para um fato atual rápido a partir de poucas fontes. O Research é para investigação abrangente, multi-fonte, com citações, e síntese comparativa. O Enterprise Search é para conhecimento organizacional interno — políticas, Slack, e-mail, documentos, contexto da empresa entre fontes. O Thinking é para raciocínio profundo em que informação externa não é a necessidade central.\nNecessidade Recorra a Fato atual rápido Web search Investigação abrangente multi-fonte Research Conhecimento interno da empresa entre ferramentas Enterprise Search Raciocínio profundo, sem busca externa necessária Thinking O framework inteiro do Domínio 5 em uma página — feito para compartilhar como resumo autônomo Conclusão # O Domínio 5 em uma passada: escolha o ponto de entrada que combina com o trabalho (Chat, Project, Artifact ou Research), saiba qual das quatro camadas de capacidade a tarefa realmente precisa e lembre que Projects guardam conhecimento enquanto Skills executam tarefas, combine o nível de modelo com quão estruturado e consequente é o trabalho em vez de recorrer por padrão ao maior modelo, e trate uma conversa que parou de seguir instruções como um problema de contexto a resolver com reiniciar-resumir-persistir, não um problema de modelo a combater. Essas quatro decisões acontecem antes do prompt fazer qualquer trabalho.\nFontes # Claude Platform \u0026amp; Model Foundations — Anthropic Partner Academy Claude Certified Associate – Foundations Exam Guide — PDF oficial Onde isso se encaixa # Parte 7 de Getting Claude Certified. A Parte 1 cobriu o Framework 4D, a Parte 2 cobriu Chat, Projects, Artifacts e Research, a Parte 3 cobriu o Domínio 1 — Avaliação e Validação de Resultados, a Parte 4 cobriu o Domínio 2 — Integração de Workflow e Design de Soluções, a Parte 5 cobriu o Domínio 3 — Governança, Risco e Uso Responsável, a Parte 6 cobriu o Domínio 4 — Prompting e Execução de Tarefas. A Parte 8 assume o Domínio 6 — Configuração e Gestão de Conhecimento.\n","date":"17/09/2026","externalUrl":null,"permalink":"/pt-br/posts/claude-cert-07-product-and-model-selection/","section":"Posts","summary":"Do que se trata # O Domínio 5 da prova Claude Certified Associate – Foundations é Seleção de Produto e Modelo. Vale 12%. O enquadramento: antes mesmo do prompting começar, quatro decisões já definem o teto de qualidade da sessão — o ponto de entrada certo, a camada de capacidade certa, o nível de modelo certo, a estratégia de contexto certa. Errar essas quatro e nenhuma quantidade de polimento no prompt conserta. Acertar essas quatro e o prompt precisa fazer muito menos trabalho.\n","title":"Claude Certified Associate – Foundations: Domínio 5 — Seleção de Produto e Modelo","type":"posts"},{"content":"","date":"17/09/2026","externalUrl":null,"permalink":"/pt-br/tags/model-selection/","section":"Tags","summary":"","title":"Model-Selection","type":"tags"},{"content":"","date":"17/09/2026","externalUrl":null,"permalink":"/pt-br/tags/product-selection/","section":"Tags","summary":"","title":"Product-Selection","type":"tags"},{"content":" Do que se trata # O Domínio 4 da prova Claude Certified Associate – Foundations é Prompting e Execução de Tarefas. Vale 14%. O enquadramento que importa aqui: peça ao Claude \u0026ldquo;escreva algo sobre nossos resultados do Q3\u0026rdquo; e você recebe um parágrafo genérico. Especifique o público, os três resultados que importam, o formato e o tamanho, e você recebe um rascunho quase pronto para enviar. O modelo não ficou mais inteligente entre uma solicitação e outra. O prompt que mudou. Este domínio trata prompting como uma disciplina de comunicação com estrutura que se aprende, não um dom que algumas pessoas têm.\nPrompting e Execução de Tarefas é o quarto domínio mais pesado da prova Ponto-chave 1: a pilha de cinco componentes # Cinco componentes carregam quase todo o peso de um prompt profissional: Role (quem o Claude deve ser para esta tarefa), Context (o contexto que o Claude não consegue saber a menos que você forneça), Task (uma ação inequívoca), Constraints (tamanho, tom, o que incluir ou evitar), e Output format (o formato do resultado). Nem todo prompt precisa dos cinco — uma pergunta rápida precisa de uma tarefa e talvez uma restrição. Context é o que os profissionais mais pulam, porque ele existe só na sua cabeça e nunca chega ao prompt.\nA maioria dos prompts fracos está faltando uma linha desta lista, geralmente Context Ponto-chave 2: decomponha solicitações complexas em etapas ordenadas # Uma solicitação com vários estágios distintos comprimida em um único prompt produz trabalho raso em cada estágio. \u0026ldquo;Avalie esses três fornecedores e me diga qual escolher\u0026rdquo; força o Claude a inventar critérios, aplicá-los, ponderar trade-offs e recomendar, tudo em uma única passada — você nunca vê o raciocínio. Divida em uma sequência em vez disso, e cada etapa produz um resultado verificável antes que a próxima rode.\nflowchart LR A[Derivar critériosdo documento de requisitos] --\u003e B[Pontuar cada fornecedorcontra esses critérios] B --\u003e C[Levantar trade-offsonde os fornecedores mais divergem] C --\u003e D[Recomendarvinculado aos critérios ponderados] style A fill:#2a78d6,stroke:#1c5cab,color:#fff style B fill:#2a78d6,stroke:#1c5cab,color:#fff style C fill:#2a78d6,stroke:#1c5cab,color:#fff style D fill:#1c5cab,stroke:#104281,color:#fff Se os critérios na primeira etapa estiverem errados, você pega isso antes da pontuação, não depois que a recomendação já saiu. Mantenha etapas que se constroem umas sobre as outras em uma única conversa; separe em uma nova conversa só quando uma etapa for genuinamente independente ou quando a thread já tiver crescido o suficiente para o contexto inicial começar a degradar.\nPonto-chave 3: itere no componente que falhou, não no prompt inteiro # Um primeiro rascunho raramente sai perfeito, e a correção nunca é reescrever o prompt inteiro — isso perde as partes que funcionaram e esconde qual mudança de fato resolveu o problema. Leia o resultado como um diagnóstico em vez disso: ele aponta direto para o componente que falhou.\nSintoma Causa provável Correção Resultado genérico ou fora do alvo Context estava raso Adicione o contexto que o Claude não conseguiu inferir Resultado respondeu a pergunta errada Verbo da task era ambíguo Deixe a instrução mais precisa Resultado com tamanho, tom ou formato errado Faltou uma constraint ou o format Adicione Resultado quase certo mas erra em uma seção — Itere só nessa seção Mude o único componente que o resultado indicou, reenvie e compare. Pare quando uma rodada produzir mudança marginal em vez de melhora real — nesse ponto, uma edição manual rápida vence outra rodada de prompting.\nPonto-chave 4: combine a estratégia com o tipo de tarefa # Os cinco componentes se aplicam sempre, mas a ênfase muda conforme o que você está fazendo. Análise quer restrições apertadas e critérios explícitos — baixa liberdade criativa, alta especificação. Pesquisa quer escopo claro e disciplina de fontes, com citações que você consegue de fato checar. Redação quer público, tom e formato fixados, com espaço para o Claude encontrar a fraseologia. Brainstorming quer restrições soltas e alta liberdade — superespecificar mata a variedade que você está buscando.\nTipo de tarefa Apertar Soltar Análise Critérios, padrões, escopo Fraseologia Pesquisa Pergunta, fontes, citações Abordagem de síntese Redação Público, tom, formato Escolha de palavras Brainstorming Só objetivo e limites Quantidade e direção Ponto-chave 5: um prompt fraco, reparado # Fraco: \u0026ldquo;Resuma o feedback dos clientes e me diga o que fazer.\u0026rdquo; Resultado: uma lista genérica de cinco bullets com temas, nada vinculado aos dados reais, nada acionável — porque o prompt quase não especificou nada.\nReparado: \u0026ldquo;Você é um analista de produto (role). Em anexo estão 200 respostas de pesquisa com clientes (context). Identifique os três problemas mais frequentemente levantados, classificados por quantas respostas mencionam cada um (task), e para cada um inclua uma citação verbatim representativa e a proporção aproximada de respostas em que aparece (constraints) — use execução de código para contar com precisão em vez de estimar. Formate como uma lista classificada, do mais frequente para o menos frequente (output format).\u0026rdquo;\nMesmo modelo, mesmos dados. A diferença entre os dois resultados está inteiramente na especificação, não na capacidade subjacente.\nO framework inteiro do Domínio 4 em uma página — feito para compartilhar como resumo autônomo Conclusão # O Domínio 4 em uma passada: rode todo prompt não trivial contra os cinco componentes (role, context, task, constraints, format), e espere que context seja o que você esqueceu. Decomponha trabalho de múltiplos estágios em etapas ordenadas para que cada uma produza um resultado verificável antes que a próxima rode. Quando o resultado decepcionar, diagnostique qual componente falhou e corrija só aquele — não comece do zero. Combine seu estilo de especificação com a tarefa: apertado para análise e pesquisa, mais solto para redação, o mais solto possível para brainstorming. Estrutura é o que impulsiona a qualidade aqui, não sagacidade.\nFontes # Prompting \u0026amp; Task Execution — Anthropic Partner Academy Claude Certified Associate – Foundations Exam Guide — PDF oficial Onde isso se encaixa # Parte 6 de Getting Claude Certified. A Parte 1 cobriu o Framework 4D, a Parte 2 cobriu Chat, Projects, Artifacts e Research, a Parte 3 cobriu o Domínio 1 — Avaliação e Validação de Resultados, a Parte 4 cobriu o Domínio 2 — Integração de Workflow e Design de Soluções, a Parte 5 cobriu o Domínio 3 — Governança, Risco e Uso Responsável. A Parte 7 assume o Domínio 5 — Seleção de Produto e Modelo.\n","date":"16/09/2026","externalUrl":null,"permalink":"/pt-br/posts/claude-cert-06-prompting-and-task-execution/","section":"Posts","summary":"Do que se trata # O Domínio 4 da prova Claude Certified Associate – Foundations é Prompting e Execução de Tarefas. Vale 14%. O enquadramento que importa aqui: peça ao Claude “escreva algo sobre nossos resultados do Q3” e você recebe um parágrafo genérico. Especifique o público, os três resultados que importam, o formato e o tamanho, e você recebe um rascunho quase pronto para enviar. O modelo não ficou mais inteligente entre uma solicitação e outra. O prompt que mudou. Este domínio trata prompting como uma disciplina de comunicação com estrutura que se aprende, não um dom que algumas pessoas têm.\n","title":"Claude Certified Associate – Foundations: Domínio 4 — Prompting e Execução de Tarefas","type":"posts"},{"content":"","date":"16/09/2026","externalUrl":null,"permalink":"/pt-br/tags/prompting/","section":"Tags","summary":"","title":"Prompting","type":"tags"},{"content":"","date":"16/09/2026","externalUrl":null,"permalink":"/pt-br/tags/task-execution/","section":"Tags","summary":"","title":"Task-Execution","type":"tags"},{"content":" Do que se trata # O Domínio 3 da prova Claude Certified Associate – Foundations é Governança, Risco e Uso Responsável. Vale 15%. O enquadramento é direto: dados sensíveis enviados para o lugar errado, uma Skill não confiável com acesso amplo, uma violação silenciosa de política no momento errado — qualquer um desses pode congelar todo o programa de IA de uma organização e custar a produtividade que cada time havia ganhado. Governança não é um manual de política na prateleira. Ela é exercida por praticantes, uma decisão de cada vez — o que a torna uma habilidade que você constrói, não um documento que você lê uma vez.\nGovernança, Risco e Uso Responsável é o terceiro domínio mais pesado da prova Ponto-chave 1: filtre casos de uso com quatro perguntas, não com instinto # Todo caso de uso proposto é testado contra quatro critérios: reversibilidade (dá para pegar um resultado errado antes que ele cause dano?), consequência do erro (quanto custa se estiver errado?), necessidade de criatividade ou empatia humana (isso exige julgamento que um modelo não consegue fornecer?), e responsabilização (quem responde pelo resultado?). Rode os quatro, depois identifique qual deles é o que sustenta a classificação — aquele que, se mudasse, moveria o caso de uso para outra categoria. Isso é o que torna uma classificação defensável para um revisor, em vez de só uma sensação.\nflowchart TD A[Caso de uso proposto] --\u003e B{Rode os 4 critérios:reversibilidade, consequência,elemento humano, responsabilização} B --\u003e|Tudo certo| C[Totalmente apropriadorevisão normal] B --\u003e|Útil, mas risco ouresponsabilização exigem um portão| D[Apropriado com revisão humanadefina quem/o quê/quando] B --\u003e|Irreversível, alta consequência,ou responsabilização não transferível| E[Inapropriadonomeie o papel humano que deve assumir] style C fill:#0ca30c,stroke:#087a08,color:#fff style D fill:#fab219,stroke:#c98500,color:#0b0b0b style E fill:#d03b3b,stroke:#a82f2f,color:#fff A caixa do meio é onde a maioria das pessoas relaxa demais: \u0026ldquo;apropriado com revisão humana\u0026rdquo; só é real quando o portão é específico — quem revisa, o que verifica, e quando no workflow isso acontece. \u0026ldquo;Um gerente revisa a lista final buscando padrões de impacto desigual antes de qualquer candidato ser contatado\u0026rdquo; é um portão. \u0026ldquo;Vamos manter um humano no circuito\u0026rdquo; não é.\nPonto-chave 2: uma Skill é software — avalie-a como software # Uma Skill pode acessar tudo que sua sessão já tem acesso e pode tomar ações através de execução de código. Ela não solicita permissões; ela herda as que já existem. Antes de habilitar uma, cheque três coisas: origem (quem publicou — Anthropic, aprovada internamente, ou um terceiro desconhecido), alcance (o que ela realmente consegue tocar nas sessões em que roda, e isso é proporcional à tarefa), e adequação (é a ferramenta certa para o trabalho, ou é mais capacidade do que o necessário). \u0026ldquo;Interna\u0026rdquo; não é o mesmo que \u0026ldquo;avaliada\u0026rdquo; — uma Skill construída por outro time da sua própria empresa ainda precisa da mesma checagem.\nTrês resultados saem dessa checagem: habilitar quando origem, permissões e adequação estão todos claros; escalar para seu admin ou função de segurança quando é útil mas a origem ou as permissões não estão claras; recusar quando as permissões são claramente desproporcionais ou a origem não pode ser estabelecida. O mesmo hábito de proporcionalidade se aplica a qualquer capacidade que possa ler ou agir sobre seus dados, não só Skills — privilégio mínimo, revisitado quando o trabalho muda.\nPonto-chave 3: classifique os dados antes que toquem em um recurso # Divida os dados em três níveis antes que cheguem perto de qualquer recurso. Verde — material público, anonimizado, ou material interno já liberado — não precisa de tratamento especial. Amarelo — documentos só internos, qualquer coisa com nomes ou contatos, material de negócio ou produto ainda não anunciado — precisa de checagem de política primeiro, e do modo Incógnito para não entrar na Memória nem no histórico do chat (ainda que a política de retenção de dados da sua organização continue valendo). Vermelho — dados regulados, credenciais, qualquer coisa sob obrigação de confidencialidade com terceiros — precisa de um ponto de entrada aprovado confirmado antes de qualquer upload, sem exceção.\nO Incógnito controla o que é lembrado, não se o dado era permitido ali para começar — para dados vermelhos, essa pergunta vem primeiro O erro comum é tratar o Incógnito como uma rede de segurança para dados vermelhos. Não é. O Incógnito controla se algo é lembrado — ele não diz nada sobre se o dado era permitido naquele recurso para começar. Para dados regulados, \u0026ldquo;isso é permitido aqui\u0026rdquo; é respondido antes de \u0026ldquo;como eu lido com isso aqui\u0026rdquo;.\nPonto-chave 4: diligência é um hábito, não uma checagem única # Uma política seguida só quando alguém está olhando não é governança — a lacuna entre o que a política diz e o que as pessoas realmente fazem é exatamente onde o risco se acumula, silenciosamente, nas decisões rotineiras de baixa visibilidade, não nas óbvias de alto risco. A correção é uma auditoria periódica: compare o que seu time realmente está fazendo com o que a política exige, e trate cada divergência — um upload não aprovado, um portão de revisão pulado, uma Skill não avaliada — como uma lacuna a fechar, não uma violação a punir. A maior parte do desvio não é maliciosa. É fricção: as pessoas pegam o caminho mais fácil quando o aprovado é mais lento, então a correção duradoura geralmente é remover a fricção, não adicionar uma regra.\nPonto-chave 5: risco ético se esconde em resultados comuns # Risco de viés e imparcialidade não aparece etiquetado como um problema ético — ele aparece como um resumo, uma recomendação, ou uma lista final rotineira que silenciosamente favorece um grupo, construída sobre um enquadramento que ninguém questionou. Isso pertence à revisão de rotina, especialmente em trabalho voltado a pessoas como contratação ou avaliação, não a um exercício de ética separado. Transparência também importa: saiba quando seu contexto ou política exige divulgar assistência de IA, e opte por divulgar por padrão quando estiver em dúvida. Para casos genuinamente ambíguos, raciocine sobre quem é afetado, o que pode dar errado, como é o resultado justo, e qual divulgação se aplica — e quando a população afetada é grande ou o dano é significativo, escale o raciocínio em vez de decidir sozinho. Um \u0026ldquo;eu não sei, e eis o porquê\u0026rdquo; documentado é mais útil para um revisor do que um palpite confiante.\nO framework inteiro do Domínio 3 em uma página — feito para compartilhar como resumo autônomo Conclusão # O Domínio 3 em uma passada: filtre todo caso de uso contra reversibilidade, consequência, elemento humano e responsabilização, e torne o portão de revisão humana específico quando essa for a resposta. Avalie a origem e o alcance de uma Skill como avaliaria qualquer software antes de instalar. Classifique dados como verde, amarelo ou vermelho antes que toquem em um recurso, e lembre que o Incógnito não substitui essa classificação. Audite o uso real contra a política em uma cadência, porque o desvio acontece silenciosamente. E cheque resultados de rotina quanto a viés e divulgação do mesmo jeito que checaria quanto à precisão — porque o risco ético nunca ia se anunciar sozinho.\nFontes # Governance, Risk \u0026amp; Responsible Use — Anthropic Partner Academy Claude Certified Associate – Foundations Exam Guide — PDF oficial Onde isso se encaixa # Parte 5 de Getting Claude Certified. A Parte 1 cobriu o Framework 4D, a Parte 2 cobriu Chat, Projects, Artifacts e Research, a Parte 3 cobriu o Domínio 1 — Avaliação e Validação de Resultados, a Parte 4 cobriu o Domínio 2 — Integração de Workflow e Design de Soluções. A Parte 6 assume o Domínio 4 — Prompting e Execução de Tarefas.\n","date":"15/09/2026","externalUrl":null,"permalink":"/pt-br/posts/claude-cert-05-governance-risk-and-responsible-use/","section":"Posts","summary":"Do que se trata # O Domínio 3 da prova Claude Certified Associate – Foundations é Governança, Risco e Uso Responsável. Vale 15%. O enquadramento é direto: dados sensíveis enviados para o lugar errado, uma Skill não confiável com acesso amplo, uma violação silenciosa de política no momento errado — qualquer um desses pode congelar todo o programa de IA de uma organização e custar a produtividade que cada time havia ganhado. Governança não é um manual de política na prateleira. Ela é exercida por praticantes, uma decisão de cada vez — o que a torna uma habilidade que você constrói, não um documento que você lê uma vez.\n","title":"Claude Certified Associate – Foundations: Domínio 3 — Governança, Risco e Uso Responsável","type":"posts"},{"content":"","date":"15/09/2026","externalUrl":null,"permalink":"/pt-br/tags/governance/","section":"Tags","summary":"","title":"Governance","type":"tags"},{"content":"","date":"15/09/2026","externalUrl":null,"permalink":"/pt-br/tags/responsible-ai/","section":"Tags","summary":"","title":"Responsible-Ai","type":"tags"},{"content":" Do que se trata # O Domínio 2 da prova Claude Certified Associate – Foundations é Integração de Workflow e Design de Soluções. Vale 16% — atrás apenas de Avaliação de Resultados, que a Parte 3 já cobriu. Enquanto aquele domínio perguntava \u0026ldquo;esse resultado específico é bom?\u0026rdquo;, este faz uma pergunta diferente: onde o Claude realmente se encaixa dentro de um workflow feito de múltiplas etapas, sistemas e pessoas — e onde ele não se encaixa? Acertar uma resposta individual não importa muito se você a conectou no lugar errado do processo.\nPeso do domínio # Integração de Workflow e Design de Soluções é o segundo domínio mais pesado da prova, logo atrás de Avaliação de Resultados Ponto-chave 1: três padrões de interação, não um só # O Claude se encaixa em uma solução de três formas diferentes, cada uma com um custo e uma necessidade de supervisão diferentes: chamadas aumentadas, em que um humano executa cada etapa e o Claude assiste uma chamada de cada vez; workflows, em que o Claude executa sozinho uma sequência fixa e previsível de etapas; e agentes, em que o Claude planeja suas próprias etapas para atingir um objetivo. A autonomia aumenta a cada estágio — e o custo de dar errado sem supervisão aumenta junto.\nAutonomia e o custo de dar errado sobem juntos — escolha o padrão que combina com quanta supervisão a tarefa realmente precisa Escolher entre os três se resume a duas perguntas: a tarefa precisa de mais de uma etapa, e ela precisa que o Claude decida as etapas sozinho?\nflowchart TD A[Nova tarefa] --\u003e B{Mais deuma etapa?} B --\u003e|Não| C[Chamada aumentadahumano executa, Claude assiste] B --\u003e|Sim| D{Etapas são fixase previsíveis?} D --\u003e|Sim| E[WorkflowClaude executa a sequência fixa] D --\u003e|Não, Claude precisadecidir as etapas| F[AgenteClaude planeja e se adapta ao longo do caminho] style C fill:#86b6ef,stroke:#5598e7,color:#0b0b0b style E fill:#2a78d6,stroke:#1c5cab,color:#fff style F fill:#104281,stroke:#0d366b,color:#fff Cada passo dessa árvore troca previsibilidade por alcance — um agente consegue lidar com uma tarefa que ninguém roteirizou de antemão, mas também precisa da maior supervisão para pegar quando o próprio plano dá errado.\nPonto-chave 2: decomponha o requisito antes de escolher um padrão # Antes de escolher um padrão, divida o problema em três perguntas de propriedade: o que é trabalho do Claude, o que é trabalho do sistema existente, e o que é trabalho do humano. Pular essa etapa é como uma tarefa que deveria ser uma única chamada aumentada acaba superdimensionada como um agente, ou como um processo genuinamente de múltiplas etapas é espremido em um único prompt longo porque ninguém separou \u0026ldquo;o que o Claude faz\u0026rdquo; do \u0026ldquo;o que o banco de dados já faz\u0026rdquo;.\nPonto-chave 3: arquitetura de referência — retrieval vs. estado ao vivo # Depois que o papel do Claude está definido, a próxima decisão de design é como ele acessa a informação: retrieval, buscando em conteúdo indexado ou armazenado que não precisa estar atualizado ao segundo, ou integração de estado ao vivo, chamando um sistema ou API ao vivo quando a resposta precisa refletir o que é verdade agora. Preço, estoque e saldo de conta precisam de estado ao vivo. Uma resposta de base de conhecimento sobre uma política do trimestre passado geralmente não precisa.\nPonto-chave 4: escolhendo o ponto de entrada # O Claude aparece por várias portas — Claude.ai, a API, SDKs, Claude Code, servidores MCP — e cada uma é a camada certa para um tipo diferente de personalização. O Claude.ai é a interface voltada ao usuário, para pessoas trabalhando diretamente com o Claude. A API e os SDKs são a camada de engenharia em tempo de build para incorporar o Claude no seu próprio produto. Servidores MCP são como o Claude alcança ferramentas e dados externos sem código de integração personalizado para cada um. Escolher o ponto de entrada errado significa resolver de novo um problema que a plataforma já resolveu em outra camada.\nPonto-chave 5: comunicando valor e limites para os stakeholders # A última peça deste domínio não é técnica: é conseguir explicar a um stakeholder o que o Claude realmente vai fazer, o que não vai, e onde um humano ainda precisa estar envolvido — antes da solução ir ao ar, não depois que ela decepcionar alguém. Uma solução em que ninguém confia porque ninguém explicou seus limites de antemão falha por um motivo que não tem nada a ver com o modelo.\nO framework inteiro do Domínio 2 em uma página — feito para compartilhar como resumo autônomo Conclusão # O Domínio 2 se resume a isso: escolha o padrão de interação que combina com quanta autonomia a tarefa realmente precisa (chamada aumentada, workflow ou agente), decomponha o requisito para que o Claude, o sistema existente e o humano tenham cada um uma parte clara, escolha retrieval ou estado ao vivo com base em se a resposta precisa estar atualizada, escolha o ponto de entrada da plataforma que combina com o tipo de personalização que o trabalho precisa, e seja direto com os stakeholders sobre o que a solução vai e não vai fazer. Isso é design de soluções — a camada acima de qualquer resultado individual bom.\nFontes # Claude Platform \u0026amp; Solution Design — Anthropic Partner Academy Claude Certified Associate – Foundations Exam Guide — PDF oficial Onde isso se encaixa # Parte 4 de Getting Claude Certified. A Parte 1 cobriu o Framework 4D, a Parte 2 cobriu Chat, Projects, Artifacts e Research, a Parte 3 cobriu o Domínio 1 — Avaliação e Validação de Resultados. A Parte 5 assume o Domínio 3 — Governança, Risco e Uso Responsável.\n","date":"14/09/2026","externalUrl":null,"permalink":"/pt-br/posts/claude-cert-04-workflow-integration-and-solution-design/","section":"Posts","summary":"Do que se trata # O Domínio 2 da prova Claude Certified Associate – Foundations é Integração de Workflow e Design de Soluções. Vale 16% — atrás apenas de Avaliação de Resultados, que a Parte 3 já cobriu. Enquanto aquele domínio perguntava “esse resultado específico é bom?”, este faz uma pergunta diferente: onde o Claude realmente se encaixa dentro de um workflow feito de múltiplas etapas, sistemas e pessoas — e onde ele não se encaixa? Acertar uma resposta individual não importa muito se você a conectou no lugar errado do processo.\n","title":"Claude Certified Associate – Foundations: Domínio 2 — Integração de Workflow e Design de Soluções","type":"posts"},{"content":"","date":"14/09/2026","externalUrl":null,"permalink":"/pt-br/tags/solution-design/","section":"Tags","summary":"","title":"Solution-Design","type":"tags"},{"content":"","date":"14/09/2026","externalUrl":null,"permalink":"/pt-br/tags/workflow-integration/","section":"Tags","summary":"","title":"Workflow-Integration","type":"tags"},{"content":" Do que se trata # O Domínio 1 da prova Claude Certified Associate – Foundations é Avaliação e Validação de Resultados. Vale 21% — mais do que qualquer outro domínio da prova. O domínio inteiro se resume a uma ideia: resultado com boa aparência não é a mesma coisa que resultado validado. Um texto fluente e confiante não diz nada sobre se está de fato correto. Este post detalha o framework para fechar essa lacuna de propósito, em vez de por acidente.\nPor que esse domínio pesa mais que qualquer outro # O Domínio 1 sozinho pesa mais que Product \u0026amp; Model Selection e Configuration \u0026amp; Knowledge Management juntos Um retrato rápido da prova em si, do guia oficial de exame da Anthropic:\nDuração 120 minutos Questões 60 Preço US$ 99 Nota de corte 720 (escala de 100–1.000) Ponto-chave 1: cheque o resultado contra três referências, não uma # Todo resultado relevante é avaliado contra três coisas separadas:\nRequisitos — ele respondeu o que realmente foi pedido? Seções certas, público certo, escopo certo, formato certo. Material-fonte — bate com aquilo que deveria usar como base? Não assuma que o Claude \u0026ldquo;leu corretamente\u0026rdquo; — rastreie você mesmo as afirmações importantes. Padrões profissionais — sobreviveria a uma revisão na área em questão? Um número sem unidade, uma citação que ninguém encontra, uma conclusão que nada sustenta — isso passa numa leitura casual e não passa numa leitura de verdade. Checar só uma das três e chamar de validado é o erro por trás da maior parte do que vem a seguir.\nPonto-chave 2: precisão e completude são testes diferentes # Precisão pergunta: o que está presente está correto? Completude pergunta: falta algo importante? Uma resposta pode ser totalmente precisa e ainda assim inutilizável porque deixou de fora um fator que importava. Se os números batem mas algo parece faltando, a correção não é reconferir os números de novo — é rodar uma checagem de completude separada contra os requisitos originais.\nPonto-chave 3: a triagem em três vias # Todo resultado cai em um de três grupos:\nflowchart TD A[Resultado produzido] --\u003e B{Requisitos cumpridos?Checagens de fonte passam?Padrão profissional OK?} B --\u003e|Sim, risco aceitável| C[Pronto para uso] B --\u003e|Lacuna específica e corrigível| D[Precisa de revisão] B --\u003e|Risco, exposição regulatóriaou responsabilidade exige| E[Precisa de decisão humana] D --\u003e|Corrige e checa de novo| B E --\u003e|Humano decide,independente da qualidade| F[Revisão humana] style C fill:#1baf7a,stroke:#0d8a5c,color:#fff style D fill:#eda100,stroke:#c98500,color:#fff style E fill:#e34948,stroke:#c73b3a,color:#fff A distinção que importa é entre as duas últimas caixas. Um subtotal errado precisa de revisão — corrija e siga em frente. Uma interpretação regulatória destinada a uma submissão oficial precisa da assinatura de um especialista humano mesmo que pareça completamente correta para você, porque \u0026ldquo;parece correto pra mim\u0026rdquo; nunca foi o critério para esse tipo de resultado.\nPonto-chave 4: reconhecendo uma alucinação pelo formato # Seis padrões reconhecíveis, não um aviso vago:\nAfirmação plausível mas sem sustentação — soa razoável, sem embasamento por trás Especificidade fabricada — uma estatística, data, nome ou citação inventada. Precisão sem fonte é suspeita, não tranquilizadora Tom confiante mascarando incerteza — confiança não é evidência Contradição interna — um número ou premissa afirmado no início conflita com outro afirmado depois Viés de confirmação no enquadramento — um prompt que insinua a resposta recebe essa resposta Alucinação de capacidade — o Claude diz \u0026ldquo;enviei o e-mail\u0026rdquo; ou \u0026ldquo;salvei o arquivo\u0026rdquo; quando nenhuma ferramenta capaz disso estava disponível. Sempre verifique se a ação aconteceu Ponto-chave 5: quando um humano precisa estar no circuito # Quatro perguntas decidem isso, independente de quão bom o resultado pareça:\nRisco — quanto custa se isso estiver errado? Reversibilidade — pode ser desfeito? Público — rascunho interno, ou externo / executivo / regulatório? Exposição regulatória — isso é regido por lei, política ou contrato? Entregas finais para clientes, cálculos críticos para auditoria e comunicações públicas ou jurídicas caem, por padrão, no território de \u0026ldquo;revisão obrigatória.\u0026rdquo; Um rascunho bem-acabado não reduz a necessidade de revisão — pelo contrário, acabamento é o que faz algo ser aprovado sem revisão nenhuma.\nMais algumas checagens que valem a pena saber # Code Execution calcula, não valida a lógica. Use para totais, projeções e qualquer coisa que precise ser calculada em vez de estimada — mas um resultado calculado ainda não é automaticamente uma metodologia correta. Curadoria de entrada é parte da validação, não um preparo prévio. Material-fonte ruidoso e contraditório produz saída ruidosa. Um modelo maior não resolve isso — eliminar duplicatas e rotular suas fontes resolve. Os mesmos fatos, entregas diferentes. Um executivo quer a decisão e o impacto primeiro. Um time de trabalho quer o método e quem é responsável. Um público externo precisa de divulgação controlada. Mandar o mesmo rascunho bruto para os três falha com pelo menos dois deles. O framework inteiro do Domínio 1 em uma página — feito para compartilhar como resumo autônomo Conclusão # O Domínio 1 é a seção de maior peso da prova de certificação Claude porque avaliação é a habilidade de verdade — não prompting, não design de workflow. A versão curta: cheque o resultado contra requisitos, fonte e padrão profissional; trate precisão e completude como testes separados; faça a triagem entre pronto / precisa de revisão / precisa de um humano; conheça os seis padrões de alucinação; e conheça as quatro perguntas que forçam revisão humana independente de quão bom o resultado pareça. Isso é o domínio inteiro, e é a parte de trabalhar com o Claude que mais compensa.\nFontes # Claude Certified Associate – Foundations Exam Guide — PDF oficial Claude Certified Associate – Foundations Prep Course — módulo \u0026ldquo;Evaluating \u0026amp; Validating Claude\u0026rsquo;s Output\u0026rdquo; Onde isso se encaixa # Parte 3 de Getting Claude Certified. A Parte 1 cobriu o Framework 4D, a Parte 2 cobriu Chat, Projects, Artifacts e Research. A Parte 4 assume o Domínio 2 — Integração de Workflow e Design de Soluções.\n","date":"13/09/2026","externalUrl":null,"permalink":"/pt-br/posts/claude-cert-03-output-evaluation-and-validation/","section":"Posts","summary":"Do que se trata # O Domínio 1 da prova Claude Certified Associate – Foundations é Avaliação e Validação de Resultados. Vale 21% — mais do que qualquer outro domínio da prova. O domínio inteiro se resume a uma ideia: resultado com boa aparência não é a mesma coisa que resultado validado. Um texto fluente e confiante não diz nada sobre se está de fato correto. Este post detalha o framework para fechar essa lacuna de propósito, em vez de por acidente.\n","title":"Claude Certified Associate – Foundations: Domínio 1 — Avaliação e Validação de Resultados","type":"posts"},{"content":"","date":"13/09/2026","externalUrl":null,"permalink":"/pt-br/tags/discernment/","section":"Tags","summary":"","title":"Discernment","type":"tags"},{"content":"","date":"13/09/2026","externalUrl":null,"permalink":"/pt-br/tags/evaluation/","section":"Tags","summary":"","title":"Evaluation","type":"tags"},{"content":"","date":"12/09/2026","externalUrl":null,"permalink":"/pt-br/tags/artifacts/","section":"Tags","summary":"","title":"Artifacts","type":"tags"},{"content":"","date":"12/09/2026","externalUrl":null,"permalink":"/pt-br/tags/projects/","section":"Tags","summary":"","title":"Projects","type":"tags"},{"content":"","date":"12/09/2026","externalUrl":null,"permalink":"/pt-br/tags/research/","section":"Tags","summary":"","title":"Research","type":"tags"},{"content":" A janela de chat é onde a maioria para # Você abre o Claude, digita uma pergunta, recebe uma resposta, fecha a aba. Na semana seguinte, uma tarefa parecida aparece, e lá está você de novo: a mesma janela de chat em branco, explicando tudo do zero — quem você é, no que está trabalhando, o que significa um bom resultado nesse tipo de tarefa. Se essa é toda a sua relação com a ferramenta, você está usando uma das ferramentas mais capazes disponíveis hoje exatamente como usaria uma caixa de busca — ou, mais precisamente, exatamente como as pessoas usavam o ChatGPT em 2020, quando um contexto novo a cada sessão era simplesmente como essas coisas funcionavam.\nNão é mais assim, e tratar o Claude dessa forma custa mais caro do que parece.\nO que reexplicar tudo a cada sessão realmente custa # Nada disso aparece como uma falha dramática única. Aparece como atrito que você já parou de perceber.\nVocê reenvia as mesmas diretrizes de marca, as mesmas notas de arquitetura, o mesmo \u0026ldquo;é assim que nosso time escreve documentação\u0026rdquo;, toda vez, porque o chat anterior não carregou nada disso adiante. Você recebe de volta um diagrama ou rascunho genuinamente útil, e ele vive exatamente na profundidade de uma rolagem de tela dentro da transcrição do chat — encontrável se você lembrar qual conversa foi, perdido na prática se não lembrar. Você faz uma pergunta que realmente precisa que alguém vasculhe várias fontes, compare e sintetize uma resposta de verdade, e recebe de volta uma resposta confiante de uma única passada que parece ter feito esse trabalho, mas não fez. Parecia completa. Não era. E a próxima pessoa do seu time que fizer a mesma pergunta que você já resolveu começa do zero também, porque nada do que você descobriu está em nenhum lugar que o Claude — ou ela — consiga encontrar.\nNada disso é uma limitação do Claude. É uma limitação do Chat, e o Chat é uma entre várias formas de trabalhar com o Claude, não a única.\nO mapa do resto deste post — quatro superfícies, quatro tarefas diferentes Chat: ainda é a ferramenta certa para muita coisa # Para ficar claro, o Chat não é o problema — é o padrão, e padrões existem justamente para dar conta bem da maioria dos casos. Uma pergunta pontual, um rascunho rápido, uma conversa de \u0026ldquo;me ajuda a pensar nisso\u0026rdquo; que não vai precisar existir na semana que vem: o Chat é exatamente certo para isso. O erro não é usar o Chat. É usar só o Chat para um trabalho que na verdade é contínuo, reutilizável, ou complexo o suficiente para exigir investigação de verdade.\nA própria limitação do Chat, dita sem rodeios: o contexto não persiste entre chats separados Aqui está o que eu uso no lugar disso, e quando.\nProjects: pare de reenviar o mesmo contexto # Um project é um espaço de trabalho autocontido, com sua própria base de conhecimento, suas próprias instruções e seu próprio histórico de conversas — separado do seu Chat comum. Você envia o material de referência uma vez (as convenções de escrita do meu site, rascunhos de posts anteriores, minhas notas de currículo e certificações), escreve as instruções uma vez (\u0026ldquo;voz de praticante em primeira pessoa, citar fontes no corpo do texto, nenhuma comparação entre as categorias IBM Sterling e Claude\u0026rdquo;) e toda conversa dentro daquele project já tem tudo isso disponível. Sem reexplicar.\nEu mantenho um project específico para este blog. Quando começo a escrever um novo post, o Claude já sabe o formato do frontmatter, o tom que eu quero e a única regra rígida sobre não cruzar links entre meu conteúdo de middleware e meu conteúdo sobre Claude — porque eu disse isso uma vez, nas instruções do project, em vez de repetir toda vez que abro um chat novo. É esse o valor todo: o contexto se acumula em vez de reiniciar.\nO gatilho prático para \u0026ldquo;isso deveria ser um project, não mais um chat\u0026rdquo; é simples — se você consegue imaginar fazendo uma variação da mesma pergunta de novo no mês que vem, isso pertence a um project.\nO que realmente vive dentro de um project — conhecimento, instruções e conversas, tudo dentro de um único espaço de trabalho Artifacts: o resultado deveria sobreviver à conversa # Um artifact é um conteúdo substancial o suficiente para ganhar sua própria janela dedicada ao lado da conversa — um documento, um diagrama, uma página HTML funcional, um trecho de código — em vez de um bloco de texto enterrado no chat que você nunca vai rolar a tela para encontrar de novo. O Claude cria um automaticamente quando algo cruza a linha para \u0026ldquo;significativo e autocontido\u0026rdquo;: geralmente mais de 15 linhas, e algo que você realmente vai editar, reutilizar ou consultar depois, em vez de só ler uma vez.\nA distinção que importa aqui não é o tamanho, é a descartabilidade. Uma explicação rápida pertence ao chat. Um diagrama do seu processo de onboarding, o primeiro rascunho de um relatório, um protótipo funcional — essas coisas têm vida depois que a conversa termina, e enterrá-las na rolagem do chat é como você as perde. Usei exatamente isso para o gráfico do iceberg do framework 4D no primeiro post desta série: ele precisava existir como algo que eu pudesse extrair, refinar e reutilizar no LinkedIn — não como uma descrição no meio de uma resposta de chat.\nSe você pedir algo substancial e o Claude apenas responder no chat em vez de criar um artifact, você pode pedir diretamente: \u0026ldquo;crie isso como um artifact.\u0026rdquo; Nem sempre é automático, e vale a pena pedir.\nO painel do artifact ao lado do chat — o resultado ganha seu próprio espaço em vez de viver perdido na rolagem Research: quando a resposta realmente exige investigação # O Research é onde o problema da \u0026ldquo;resposta confiante de uma única passada que só parece completa\u0026rdquo; realmente se resolve. Ative e o Claude para de fazer uma única busca — ele planeja uma abordagem, executa várias buscas que se constroem uma sobre a outra, decide o que investigar em seguida com base no que já encontrou, e compila o resultado em um relatório com citações que você pode conferir de verdade. Leva minutos em vez de segundos, porque está fazendo minutos de trabalho em vez de segundos de trabalho.\nEssa troca é o ponto principal, e significa que o Research não é a escolha certa para tudo. Um fato rápido — a data de hoje, um número específico, uma afirmação pontual — não precisa disso; uma única busca na web responde mais rápido e o Research só seria mais lento sem ganho nenhum. Onde ele realmente vale o tempo é em trabalho comparativo ou de múltiplos ângulos: avaliar um punhado de opções pelos mesmos critérios, reunir um panorama técnico espalhado por várias fontes de documentação, ou sintetizar o que já foi discutido nas suas próprias ferramentas conectadas antes de somar pesquisa externa. O teste que eu uso: se a resposta honesta para \u0026ldquo;quantas fontes eu precisaria checar para realmente confiar nisso?\u0026rdquo; é mais do que duas ou três, isso é uma pergunta para o Research, não para o Chat.\nA etapa que a maioria pula mentalmente: o Research planeja antes de pesquisar, em vez de fazer uma única busca e considerar resolvido Combine a ferramenta com a tarefa # Chat Projects Artifacts Research Persiste entre sessões? Não Sim — base de conhecimento + instruções Sim — vive na própria janela Não — o resultado pode virar um artifact Melhor para Perguntas pontuais, rascunhos rápidos Trabalho contínuo com contexto reutilizável Resultados substanciais e reutilizáveis Investigação de múltiplas fontes Pule quando A tarefa é realmente contínua É um caso pontual de verdade O conteúdo é curto ou descartável Uma ou duas fontes resolveriam Nenhuma dessas quatro ferramentas substitui a outra. Elas se combinam — um project guardando seu contexto, produzindo um artifact que vale a pena manter, disparando ocasionalmente uma passada de Research quando uma pergunta dentro daquele project exige investigação de verdade. O Framework 4D da Parte 1 desta série é exatamente isso em miniatura: Delegation e Description são você decidindo qual dessas ferramentas a tarefa realmente pede e dizendo isso com clareza; Discernment e Diligence continuam sendo seus, independente de qual ferramenta você usou.\nUma declaração de diligência, já que a série insiste que eu escreva uma # Colaborei com o Claude para pesquisar e redigir este post, partindo da própria documentação de suporte da Anthropic sobre Projects, Artifacts e Research, e da minha experiência usando cada um deles neste site. O enquadramento, os exemplos e o argumento de \u0026ldquo;combine a ferramenta com a tarefa\u0026rdquo; são meus; conferi as descrições das funcionalidades com a documentação linkada antes de publicar e assumo isto como um relato preciso de como essas ferramentas funcionam e de como eu realmente as uso.\nFontes e leitura complementar # Central de Ajuda do Claude — primeiros passos O que são projects? O que são artifacts e como usá-los? Usando o research no Claude Como no resto deste site: as definições das funcionalidades são da Anthropic, o enquadramento e o argumento de que \u0026ldquo;você está deixando valor na mesa\u0026rdquo; são meus.\nOnde isso se encaixa # Esta é a Parte 2 de Getting Claude Certified. A Parte 1 cobriu o Framework 4D — a camada de decisão por trás de tudo. Este post é a camada de superfície: qual recurso do Claude usar de fato depois que essa decisão já foi tomada.\nO que vem a seguir # A Parte 3, Domínio 1 — Avaliação e Validação de Resultados, aprofunda o Discernment: é o domínio de maior peso na prova de certificação de verdade, e merece o mesmo rigor que eu aplicaria para verificar qualquer outro sistema antes de confiar nele em produção.\n","date":"12/09/2026","externalUrl":null,"permalink":"/pt-br/posts/claude-cert-02-using-claude-chat-projects-artifacts-and-research/","section":"Posts","summary":"A janela de chat é onde a maioria para # Você abre o Claude, digita uma pergunta, recebe uma resposta, fecha a aba. Na semana seguinte, uma tarefa parecida aparece, e lá está você de novo: a mesma janela de chat em branco, explicando tudo do zero — quem você é, no que está trabalhando, o que significa um bom resultado nesse tipo de tarefa. Se essa é toda a sua relação com a ferramenta, você está usando uma das ferramentas mais capazes disponíveis hoje exatamente como usaria uma caixa de busca — ou, mais precisamente, exatamente como as pessoas usavam o ChatGPT em 2020, quando um contexto novo a cada sessão era simplesmente como essas coisas funcionavam.\n","title":"Você Está Usando o Claude Como se Fosse o ChatGPT de 2020","type":"posts"},{"content":"","date":"11/09/2026","externalUrl":null,"permalink":"/pt-br/tags/ai-ops/","section":"Tags","summary":"","title":"Ai-Ops","type":"tags"},{"content":" Do que se trata # O curso AI Fluency da Anthropic divide o trabalho com IA em quatro competências em vez de uma pilha de truques de prompt: Delegation, Description, Discernment, Diligence. Os 4Ds. Eu esperava um curso de prompting e saí com um framework de decisão — algo menos sobre escrever prompts melhores e mais sobre decidir o que delegar, como comunicar isso, como julgar o que volta, e quem responde pelo resultado. Aqui está cada um, condensado no que realmente importa.\nPonto-chave 1: Delegation — a decisão antes do prompt # Delegation é decidir o que é seu para fazer, o que é da IA para fazer, e o que vale a pena fazer junto — antes que qualquer coisa disso vire um prompt. Se resume a conhecer o objetivo de verdade, saber no que aquele sistema de IA específico é bom e no que não é, e só então tomar a decisão de repassar a tarefa. A parte que a maioria subestima: o que é seguro delegar muda de acordo com o contexto. Uma resposta rápida no chat e um agente autônomo rodando chamadas de ferramenta sem supervisão não recebem a mesma confiança por padrão — então a pergunta é refeita toda vez, não decidida uma vez e reaproveitada.\nPonto-chave 2: Description — a IA não lê sua mente # Description é comunicar o que você quer de forma clara o suficiente para que a IA consiga de fato entregar — não só o resultado final, mas o método que você quer que ela siga e como ela deve se comportar enquanto trabalha com você. A maioria dos resultados decepcionantes de IA vem de especificar só o resultado final e pular os outros dois. Peça um resumo sem dizer o quão direto você quer o feedback, e não se surpreenda quando ela concordar com tudo que você escreveu.\nPonto-chave 3: Discernment — o outro lado da description # Discernment é julgar o que volta: o resultado em si, o raciocínio por trás dele, e se a interação foi de fato responsiva à sua direção ou só concordou com tudo. A pegadinha — seu discernimento é tão forte quanto sua própria experiência no assunto. Uma afirmação errada na sua área salta aos olhos numa frase. A mesma afirmação errada fora da sua área soa completamente correta, porque para você ela é indistinguível de uma afirmação certa.\nPonto-chave 4: Diligence — a parte que não é sobre qualidade # Diligence não é sobre conseguir um resultado melhor — é sobre assumir responsabilidade pelo que você fez para chegar até ele: ser criterioso sobre qual sistema você usa, ser honesto com as pessoas sobre o papel da IA quando elas veem o resultado, e de fato defender esse resultado depois que ele sai com o seu nome. A parte mais pulada é justamente defender o resultado — ninguém checa isso até que algo esteja errado na frente de alguém importante, e \u0026ldquo;a IA escreveu essa parte\u0026rdquo; não sustenta esse momento.\nComo os quatro se encaixam # flowchart LR A[Delegationdecidir o que repassar] --\u003e B[Descriptiondizer como, não só o quê] B --\u003e C{Discernmentjulgar o resultado} C --\u003e|Lacunas encontradas| B C --\u003e|Se sustenta| D[Diligenceassumir o resultado] D --\u003e|Próxima tarefa| A style A fill:#2a78d6,stroke:#1a5fb4,color:#fff style B fill:#2a78d6,stroke:#1a5fb4,color:#fff style C fill:#eda100,stroke:#c98500,color:#fff style D fill:#eda100,stroke:#c98500,color:#fff Delegation e Description são as duas competências visíveis em qualquer demonstração de IA — são elas que produzem o resultado. Discernment e Diligence são as duas que ninguém vê no palco, e são elas que de fato determinam se aquele resultado era seguro de usar.\nDelegation e description são a metade visível do trabalho. Discernment e diligence são a metade que ninguém vê na demonstração. Conclusão # O framework 4D em uma linha: decida o que delegar, descreva por completo (não só o resultado final), julgue o que volta com o mesmo rigor que aplicaria ao trabalho de um colega, e assuma o resultado depois que ele sai. A maioria das experiências decepcionantes com IA vem de pular uma dessas quatro — geralmente Description ou Diligence — não do modelo em si. Esse é o framework inteiro, e tudo mais sobre usar o Claude bem se constrói em cima dele.\nFontes # AI Fluency: Framework \u0026amp; Foundations — Claude Academy AI Fluency Framework — documentação, artigos e recursos abertos Onde isso se encaixa # Parte 1 de Getting Claude Certified. A Parte 2 cobre Chat, Projects, Artifacts e Research, a Parte 3 cobre Domínio 1 — Avaliação e Validação de Resultados, que é o aprofundamento de Discernment.\n","date":"11/09/2026","externalUrl":null,"permalink":"/pt-br/posts/claude-cert-01-fluency-4d-framework/","section":"Posts","summary":"Do que se trata # O curso AI Fluency da Anthropic divide o trabalho com IA em quatro competências em vez de uma pilha de truques de prompt: Delegation, Description, Discernment, Diligence. Os 4Ds. Eu esperava um curso de prompting e saí com um framework de decisão — algo menos sobre escrever prompts melhores e mais sobre decidir o que delegar, como comunicar isso, como julgar o que volta, e quem responde pelo resultado. Aqui está cada um, condensado no que realmente importa.\n","title":"The 4D Framework: Delegation, Description, Discernment, Diligence","type":"posts"},{"content":"","date":"10/09/2026","externalUrl":null,"permalink":"/pt-br/categories/ibm-sterling/","section":"Categories","summary":"","title":"IBM Sterling","type":"categories"},{"content":"","date":"10/09/2026","externalUrl":null,"permalink":"/pt-br/tags/ibm-sterling/","section":"Tags","summary":"","title":"Ibm-Sterling","type":"tags"},{"content":"","date":"10/09/2026","externalUrl":null,"permalink":"/pt-br/tags/mft/","section":"Tags","summary":"","title":"Mft","type":"tags"},{"content":"","date":"10/09/2026","externalUrl":null,"permalink":"/pt-br/tags/security/","section":"Tags","summary":"","title":"Security","type":"tags"},{"content":"","date":"10/09/2026","externalUrl":null,"permalink":"/pt-br/tags/sftp/","section":"Tags","summary":"","title":"Sftp","type":"tags"},{"content":"","date":"10/09/2026","externalUrl":null,"permalink":"/pt-br/tags/ssh/","section":"Tags","summary":"","title":"Ssh","type":"tags"},{"content":" O aviso que ninguém deveria simplesmente clicar e ignorar # Todo cliente SSH e SFTP tem o mesmo momento assustador: você se conecta a um servidor ao qual já se conectou centenas de vezes, e em vez de um prompt normal, recebe algo assim do OpenSSH:\n@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! Mencionei isso de passagem no post de SFTP/FTP/FTPS como uma das coisas operacionais que costumam confundir, e o assunto merece seu próprio post, porque a resposta honesta e completa para \u0026ldquo;o que eu faço aqui\u0026rdquo; é mais do que uma frase — e \u0026ldquo;simplesmente desabilita a checagem estrita\u0026rdquo; é a resposta errada com frequência suficiente para valer a pena explicar exatamente por quê.\nO que o known_hosts realmente é # Durante o handshake SSH — o mesmo do diagrama de sequência do post de SFTP — o servidor apresenta uma host key para provar sua identidade, da mesma forma que um par de chave privada/pública prova a identidade de um cliente durante a autenticação. O trabalho do cliente é verificar que essa host key realmente pertence ao servidor com quem ele acha que está falando, antes de confiar em qualquer outra coisa sobre a conexão, incluindo para onde ele envia sua senha ou quais arquivos ele entrega.\nO SSH faz isso com um modelo de confiança no primeiro uso (trust-on-first-use, ou TOFU), não uma cadeia de autoridade certificadora como o TLS normalmente usa. Na primeira vez que você se conecta a um determinado host, o OpenSSH mostra a fingerprint da chave do servidor e pede para você confirmá-la, depois armazena uma entrada — hostname (ou IP), algoritmo de chave e a própria chave — em um arquivo known_hosts local (~/.ssh/known_hosts por usuário, ou /etc/ssh/ssh_known_hosts para todo o sistema). Toda conexão depois dessa compara a chave apresentada com a entrada armazenada automaticamente, sem prompt, a menos que algo não bata.\nIsso é genuinamente simples, e é exatamente por isso que o aviso acima é assustador: uma divergência significa que uma de exatamente duas coisas aconteceu, e o cliente não tem como saber qual delas sozinho — ou o servidor legitimamente recebeu uma nova host key, ou algo está interceptando sua conexão e apresentando uma chave completamente diferente. ssh(1) e sshd(8) cobrem esse modelo em detalhe; é em ssh_config(5) que esse comportamento é de fato configurado.\nModos de StrictHostKeyChecking # StrictHostKeyChecking no ssh_config controla o que acontece em uma primeira conexão e em uma divergência:\nyes — recusa se conectar a um host desconhecido completamente, e recusa em qualquer divergência. Sem prompts, falha de forma fechada. A configuração certa para qualquer coisa automatizada e sem supervisão. accept-new — o padrão atual do OpenSSH para uso interativo. Aceita e armazena silenciosamente uma chave na primeira conexão (ainda TOFU), mas ainda falha de forma fechada em uma divergência contra uma entrada existente. ask — pergunta na primeira conexão (o clássico diálogo \u0026ldquo;tem certeza que quer continuar se conectando?\u0026rdquo;) e ainda falha de forma fechada em caso de divergência. no — aceita e armazena automaticamente qualquer chave, primeira conexão ou mudada, sem prompts, nunca. Isso desabilita a verificação de host completamente. Aparece constantemente em instruções de \u0026ldquo;conserto\u0026rdquo; em fóruns, e anula o propósito inteiro do mecanismo — você aceitaria a chave de um atacante man-in-the-middle tão prontamente quanto a chave real. Para qualquer coisa voltada a parceiros ou automatizada — o que descreve basicamente toda conexão SFTP do B2Bi — StrictHostKeyChecking yes com um arquivo known_hosts deliberadamente gerenciado é a postura certa. Jobs sem supervisão nunca deveriam ser os que decidem se confiam em uma chave mudada.\nAqui está toda a decisão de verificação em uma única imagem — isso é o que roda em toda conexão SSH ou SFTP, não só nas assustadoras:\nflowchart TD A[\"Cliente conecta\"] --\u003e B{\"Host já está no\\nknown_hosts?\"} B --\u003e|\"Não — primeira vez\"| C{\"Modo do\\nStrictHostKeyChecking\"} C --\u003e|\"yes\"| D[\"Recusa a conexão\"] C --\u003e|\"accept-new\"| E[\"Armazena a chave\\nsilenciosamente, prossegue\"] C --\u003e|\"ask\"| F[\"Pergunta ao usuário,\\ndepois armazena se confirmado\"] C --\u003e|\"no\"| G[\"Armazena a chave\\nsilenciosamente, prossegue — sem verificação\"] B --\u003e|\"Sim\"| H{\"Chave apresentada bate\\ncom a entrada armazenada?\"} H --\u003e|\"Bate\"| I[\"Prossegue normalmente —\\nsem prompt, sem aviso\"] H --\u003e|\"Não bate\"| J[\"⚠ REMOTE HOST IDENTIFICATION\\nHAS CHANGED — falha de forma fechada\"] style D fill:#4a1a1a,stroke:#c0392b style J fill:#4a1a1a,stroke:#c0392b style G fill:#4a1a1a,stroke:#c0392b style I fill:#1a3a1a,stroke:#27ae60 Aquela caixa vermelha no canto inferior direito é o aviso do topo deste post. Tudo acima dela é o que te levou até ali — e o caminho no (canto inferior esquerdo, também vermelho) é o \u0026ldquo;conserto\u0026rdquo; de fórum que pula a verificação completamente em vez de realmente resolver algo.\nFingerprints e algoritmos de host key # Uma fingerprint de host key é um hash curto da chave real, usado porque comparar uma chave completa visualmente é impraticável. O OpenSSH moderno mostra fingerprints como SHA256 codificado em base64 por padrão:\nSHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Ferramentas e documentação mais antigas às vezes ainda mostram o formato legado MD5 em hexadecimal separado por dois-pontos — os dois representam a mesma chave por baixo, só com hash exibido de forma diferente; ssh-keygen -l pode imprimir qualquer um dos dois (-E md5 força o formato antigo).\nServidores podem manter múltiplas host keys de tipos diferentes simultaneamente — comumente RSA e ed25519 lado a lado, às vezes ECDSA também — e cliente e servidor negociam qual usar da mesma forma que negociam cifras e MACs, via ordem de preferência de HostKeyAlgorithms. Isso importa na prática: se um servidor rotaciona só a host key RSA, mas um cliente está configurado para preferir ed25519, esse cliente pode nem perceber que a chave RSA mudou, porque nunca usa esse tipo de chave. Vale a pena saber a qual tipo de chave os seus jobs automatizados estão de fato fixados antes de assumir que uma rotação foi \u0026ldquo;silenciosa.\u0026rdquo;\nO ssh-keyscan busca a(s) chave(s) atualmente apresentada(s) por um host sem passar pelo prompt interativo de TOFU — útil para pré-popular um arquivo known_hosts a partir de um processo confiável e automatizado, em vez de um clique interativo de \u0026ldquo;sim, tenho certeza\u0026rdquo;, e é assim que eu gero as entradas de known_hosts que entrego como parte de um checklist de onboarding de parceiro, em vez de confiar no que um engenheiro clicou uma vez.\nknown_hosts com hash # Por padrão, o OpenSSH moderno armazena entradas de known_hosts com o próprio hostname com hash (HashKnownHosts), especificamente para que um arquivo known_hosts vazado não entregue a um atacante uma lista pronta de todo host ao qual você se conecta. Vale a pena saber que isso vem habilitado por padrão e por quê, especialmente em qualquer máquina compartilhada ou multi-tenant — como um Perimeter Server do Sterling terminando conexões de dezenas de trading partners — onde esse arquivo se torna, por si só, uma informação relevante.\nO problema da rotação: mudança legítima vs. algo pior # Aqui está a decisão real que você enfrenta quando aquele aviso aparece, sem a formatação assustadora: uma chave mudou — era para mudar?\nA única forma confiável de responder isso é verificar a nova fingerprint através de um canal que não seja a própria conexão SSH. Na prática, para conexões de parceiro, isso significa:\nNão aceite nada ainda. A entrada antiga falhando de forma fechada está fazendo o trabalho dela. Contate o parceiro através de um canal já confiável — uma ligação para um número conhecido, uma mensagem através de um portal de suporte já estabelecido, uma thread de e-mail assinada com a qual você já tem um relacionamento — e peça para confirmarem a nova fingerprint diretamente. Não \u0026ldquo;vocês mudaram o servidor SFTP\u0026rdquo;, especificamente a fingerprint SHA256 da nova chave, lida de volta para você ou enviada por esse canal separado. Compare com o que a conexão está de fato apresentando. Um ssh-keyscan ou uma tentativa manual de conexão vai te mostrar a fingerprint sendo oferecida; ela precisa bater com o que o parceiro confirmou, não só \u0026ldquo;parecer plausível.\u0026rdquo; Só então remova a entrada antiga e reconecte. ssh-keygen -R hostname remove a entrada antiga do known_hosts de forma limpa (também trata corretamente o caso de hostname com hash, o que editar o arquivo manualmente não faz); reconectar sob accept-new ou interativamente então armazena a nova chave já verificada. Pular direto para ssh-keygen -R no momento em que uma conexão falha é o erro mais comum aqui — isso \u0026ldquo;conserta\u0026rdquo; o sintoma de forma idêntica, seja a causa uma reconstrução legítima do servidor ou uma interceptação ativa, que é exatamente a distinção que esse mecanismo inteiro existe para preservar.\nComo árvore de decisão, os quatro passos acima ficam assim:\nflowchart TD A[\"⚠ Aviso de divergência de host key\"] --\u003e B[\"NÃO aceite —\\ndeixe a conexão falhar\"] B --\u003e C[\"Contate o parceiro por um canal\\nout-of-band já confiável\"] C --\u003e D[\"Parceiro lê de volta a nova\\nfingerprint SHA256 diretamente\"] D --\u003e E{\"Bate com o que a\\nconexão está apresentando?\"} E --\u003e|\"Sim\"| F[\"ssh-keygen -R hostname\\n— remove a entrada antiga\"] F --\u003e G[\"Reconecta — nova chave\\narmazenada e confiável\"] E --\u003e|\"Não\"| H[\"PARE — trate como uma\\npossível interceptação\"] H --\u003e I[\"Investigue o caminho de rede.\\nNão se conecte.\"] style A fill:#4a3a1a,stroke:#d4a017 style H fill:#4a1a1a,stroke:#c0392b style I fill:#4a1a1a,stroke:#c0392b style G fill:#1a3a1a,stroke:#27ae60 O ponto central do fluxo inteiro é que a etapa de verificação (D → E) acontece em um canal que o atacante em um cenário de MITM não controla. Pule essa etapa e o fluxograma colapsa em \u0026ldquo;aceita o que quer que a conexão me mostre\u0026rdquo; — que é só StrictHostKeyChecking no com passos extras.\nEscalando isso além da verificação caso a caso # Verificação por telefone não escala além de um punhado de parceiros. Duas abordagens que escalam:\nUm processo documentado e automatizado de distribuição de known_hosts — popular e atualizar entradas de known_hosts a partir de um pipeline controlado (infraestrutura como código, uma execução de gerenciamento de configuração, um manifesto assinado) em vez de prompts interativos individuais, para que \u0026ldquo;aceitar uma chave nova\u0026rdquo; seja uma mudança auditável e deliberada, não um clique ad hoc. Certificados SSH (uma CA assina host keys, e clientes confiam na CA em vez de fixar host keys individuais) resolvem isso corretamente em escala, embora exijam uma infraestrutura de CA e coordenação que a maioria dos relacionamentos com parceiros não vai ter em vigor. As opções de autoridade certificadora do ssh-keygen e as opções TrustedUserCAKeys/certificado de host do sshd_config cobrem a mecânica; vale a pena saber que a opção existe, mesmo que a maioria das configurações de SFTP de parceiro com as quais você vai lidar seja fixação simples de chave via TOFU. Dá para manter a mesma host key durante uma atualização do Linux? # Sim — e para qualquer coisa voltada a parceiros, geralmente deveria. Uma host key não é nada além de um par de arquivos em disco (tipicamente sob /etc/ssh/, uma chave privada como ssh_host_ecdsa_key e sua .pub correspondente), e o sshd apresenta qualquer material de chave que esses arquivos contenham. Nada na chave está atrelado à versão do SO, à versão do pacote, ou ao hardware — desde que os mesmos arquivos de chave existam exatamente nos caminhos que as diretivas HostKey do sshd_config apontam quando o sshd inicia, ele vai apresentar a chave idêntica, com a fingerprint idêntica, e nenhum cliente em lugar nenhum vai ver nada mudar.\nIsso significa que o padrão seguro para uma atualização de SO (ou uma migração de servidor, uma reconstrução de container, uma restauração de disaster recovery, qualquer coisa onde a máquina em si muda mas a identidade dela não deveria) é:\nFaça backup de /etc/ssh/ssh_host_*_key e ssh_host_*_key.pub (todos os tipos de chave que você está servindo atualmente) antes da atualização, preservando dono e permissões — chaves privadas precisam continuar com permissão 600, de propriedade do root. Rode a atualização. A maioria dos gerenciadores de pacote vai gerar host keys novas automaticamente se nenhuma existir, que é exatamente o caso que você está evitando. Restaure os arquivos de chave originais nos mesmos caminhos, com as mesmas permissões, antes que o sshd volte a atender conexões (ou reinicie-o depois de restaurar). Verifique a fingerprint com ssh-keygen -lf /etc/ssh/ssh_host_ecdsa_key.pub (ou qualquer que seja o tipo) e confirme que bate com a de antes — um seguro barato antes de dar a atualização como concluída. Faça isso corretamente e a entrada de known_hosts de cada parceiro, e cada host key registrada dentro da configuração de trading partner do Sterling, continua válida sem nenhuma coordenação necessária. Pule isso — deixe a atualização gerar chaves novas — e você acabou de fabricar exatamente o cenário de \u0026ldquo;REMOTE HOST IDENTIFICATION HAS CHANGED\u0026rdquo; do início deste post, para cada parceiro conectando naquela máquina, em uma agenda auto-infligida. Se você de fato acabar rotacionando (deliberadamente, ou porque uma chave nova foi inevitável), esse é o momento de voltar aos passos de verificação acima e tratar isso como qualquer outra rotação planejada: fingerprint comunicada com antecedência, por um canal que você já confia.\nComo isso se parece no B2Bi # A versão do Sterling de um arquivo known_hosts é a tela SSH Known Host Key, dentro da configuração de trading partner/adapter — é aqui que o B2Bi armazena as host keys que coletou de servidores SFTP remotos antes de confiar neles, seja o servidor de um parceiro (para uma conexão de saída do SFTP Client Adapter) ou outro node no seu próprio cluster.\nColetar uma chave nova passa pela mesma etapa de revisão de fingerprint que o ssh faz na primeira conexão, só que com uma UI na frente — aqui ela está puxando a chave do host 192.168.100.251, mostrando o algoritmo, o tamanho em bits e a fingerprint SHA256 antes de qualquer coisa ser confiada:\nRevisando uma host key recém-coletada antes de confiar nela — esta é a UI do Sterling sobre a exata etapa de verificação TOFU descrita acima Repare na opção Save To Disk na parte de baixo, com uma escolha entre OpenSSH Format e SECSH Format — exatamente os mesmos dois formatos de arquivo de chave cobertos no post de SFTP/FTP/FTPS. É exatamente por isso que essa distinção importa na prática: exportar uma host key do Sterling para entregar a um parceiro (ou importar uma que ele te envia) significa escolher o formato que o sistema receptor de fato entende, não só baixar o que quer que seja o padrão.\nDepois que uma chave é revisada e registrada, ela aparece como uma entrada gerenciada — ID da chave, nome, tipo, tamanho, status e fingerprint, tudo visível de relance:\nUma entrada de host key registrada — o equivalente do Sterling a uma linha de known_hosts, com a fingerprint em destaque Esse Key Type: EC / Key Length: 256 é o rótulo do Sterling para uma chave ECDSA na curva P-256 — o mesmo algoritmo ecdsa-sha2-nistp256 mostrado na tela de coleta acima, só exposto com nomes de campo mais amigáveis.\nQuando a host key de um parceiro muda e a antiga é a que está registrada aqui, a conexão de saída simplesmente começa a falhar com um erro de verificação de host key nos logs do Business Process — o mesmo comportamento de falha fechada de um cliente ssh encontrando uma divergência de known_hosts, só que registrado de forma diferente. Não há ambiguidade no modo de falha, mas isso significa que um parceiro reconstruindo o servidor dele em um fim de semana vira um Business Process travado na segunda-feira de manhã, se ninguém foi avisado com antecedência.\nO processo prático que eu sigo: o parceiro nos avisa (ou nós percebemos a falha) → verificamos a nova fingerprint através de um canal out-of-band seguindo os passos acima → coletamos e revisamos a nova chave nessa tela, confirmando que a fingerprint bate com o que foi verificado → registramos ela, substituindo a entrada antiga → re-testamos com uma única transferência manual antes de deixar a agenda automatizada retomar. Vale a pena ter isso escrito em algum lugar que sua equipe consiga achar às 2 da manhã, porque \u0026ldquo;em qual tela eu atualizo isso mesmo\u0026rdquo; não é uma pergunta que você quer estar pesquisando durante um incidente.\nFontes e leituras complementares # ssh(1) sshd(8) ssh_config(5) ssh-keygen(1) ssh-keyscan(1) Documentação IBM: Services \u0026amp; Adapters Como no resto do que escrevo sobre esse assunto: o conteúdo das páginas de manual é a fonte autoritativa linkada acima, o enquadramento, o processo de rotação e as notas específicas do B2Bi são meus.\nEste post é um spin-off de SFTP, FTP, FTPS: O Protocolo Por Trás dos Adapters — vale a pena ler primeiro se você quiser o quadro completo de onde a verificação de host key se encaixa no handshake SSH.\n","date":"10/09/2026","externalUrl":null,"permalink":"/pt-br/posts/sterling-b2bi-08-ssh-known-hosts-host-key-verification/","section":"Posts","summary":"O aviso que ninguém deveria simplesmente clicar e ignorar # Todo cliente SSH e SFTP tem o mesmo momento assustador: você se conecta a um servidor ao qual já se conectou centenas de vezes, e em vez de um prompt normal, recebe algo assim do OpenSSH:\n","title":"SSH known_hosts: Como a Verificação de Host Key Realmente Funciona (e o Que Fazer Quando Ela Quebra)","type":"posts"},{"content":"","date":"09/09/2026","externalUrl":null,"permalink":"/pt-br/tags/ftp/","section":"Tags","summary":"","title":"Ftp","type":"tags"},{"content":"","date":"09/09/2026","externalUrl":null,"permalink":"/pt-br/tags/ftps/","section":"Tags","summary":"","title":"Ftps","type":"tags"},{"content":"","date":"09/09/2026","externalUrl":null,"permalink":"/pt-br/tags/middleware/","section":"Tags","summary":"","title":"Middleware","type":"tags"},{"content":"","date":"09/09/2026","externalUrl":null,"permalink":"/pt-br/tags/networking/","section":"Tags","summary":"","title":"Networking","type":"tags"},{"content":" Três protocolos, um trabalho, mecânicas internas muito diferentes # FTP, FTPS e SFTP todos afirmam fazer a mesma coisa — mover um arquivo de um lugar para outro — e os parceiros usam os nomes quase como sinônimos, o que é exatamente o problema. São três protocolos genuinamente diferentes, com modelos de porta diferentes, propriedades de segurança diferentes e modos de falha diferentes, e o SFTP Server Adapter e o SFTP Client Adapter que você configura no Sterling só fazem sentido depois que você sabe qual deles está realmente rodando. Este post passa por cada um nos seus próprios termos, e depois dedica a segunda metade especificamente ao SFTP, já que é isso que carrega a esmagadora maioria do tráfego de parceiros no B2Bi.\nO que é FTP # File Transfer Protocol, definido lá atrás na RFC 959 (1985), é o mais antigo dos três e aquele ao qual todos os outros estão reagindo. Sua característica definidora — e também sua fraqueza — é que ele usa duas conexões TCP separadas: uma conexão de controle que fica aberta durante a sessão e carrega comandos e respostas, e uma conexão de dados completamente separada que é aberta do zero para cada transferência de arquivo ou listagem de diretório.\nsequenceDiagram participant Client as Cliente participant Server as Servidor Client-\u003e\u003eServer: Conexão TCP, porta 21 (controle) Server-\u003e\u003eClient: Banner de boas-vindas Client-\u003e\u003eServer: USER / PASS (texto plano) Server-\u003e\u003eClient: Login OK Note over Client,Server: Conexão de controle permanece aberta rect rgb(40,40,40) Note over Client,Server: Modo ativo Client-\u003e\u003eServer: PORT (IP:porta do cliente para conexão de retorno) Server-\u003e\u003eClient: Conecta a partir da porta 20 até a porta do cliente end rect rgb(40,40,40) Note over Client,Server: Modo passivo Client-\u003e\u003eServer: PASV Server-\u003e\u003eClient: Aqui está uma porta alta aleatória para se conectar Client-\u003e\u003eServer: Conecta a essa porta end Note over Client,Server: Os dados do arquivo trafegam por essa SEGUNDAconexão separada — sem criptografia Portas: 21 para controle, mais a porta 20 (modo ativo, o servidor conecta de volta ao cliente) ou uma porta alta aleatória negociada via PASV (modo passivo, o cliente conecta para fora, até o servidor). O modo ativo espera que o servidor abra uma conexão de entrada até o cliente — o que quase nunca sobrevive a um NAT ou firewall hoje em dia, então o modo passivo virou o padrão prático. Segurança: nenhuma, por padrão. Usuário, senha, comandos e o próprio conteúdo do arquivo atravessam a rede em texto plano. Qualquer um posicionado no caminho de rede consegue ler credenciais e dados com uma captura de pacotes e esforço zero. Por que ainda existe: sistemas legados, transferências internas em redes já consideradas confiáveis, e algumas integrações de parceiro genuinamente antigas, anteriores a qualquer um que trabalhe nelas hoje. Por que não usar para troca com parceiros: credenciais em texto plano e conteúdo de arquivo em texto plano pela internet aberta não é uma posição defensável em 2026, ponto final. Se um parceiro pedir FTP puro hoje, isso é uma conversa, não uma tarefa de configuração. O que é FTPS # FTP sobre TLS/SSL (também escrito FTPES na variante explícita) é a tentativa do FTP de corrigir o problema do texto plano sem redesenhar o protocolo — ele envolve o mesmo modelo de duas conexões do FTP em TLS. Isso traz criptografia, mas herda o problema arquitetural fundamental do FTP: duas conexões ainda significam duas coisas para proteger e duas coisas que podem falhar de forma independente.\nsequenceDiagram participant Client as Cliente participant Server as Servidor rect rgb(40,40,40) Note over Client,Server: FTPS Explícito (FTPES) — porta 21 Client-\u003e\u003eServer: Conexão TCP, porta 21 Client-\u003e\u003eServer: AUTH TLS Server-\u003e\u003eClient: Handshake TLS começa Note over Client,Server: Conexão de controle agora criptografada Client-\u003e\u003eServer: USER / PASS (agora criptografado) Client-\u003e\u003eServer: PBSZ / PROT P (solicita canal de dados criptografado) Client-\u003e\u003eServer: PASV → conexão de dados, também envolvida em TLS end rect rgb(40,40,40) Note over Client,Server: FTPS Implícito — porta 990 Client-\u003e\u003eServer: Conexão TCP, porta 990 Note over Client,Server: O handshake TLS acontece imediatamente,antes de qualquer comando FTP ser enviado end Portas: o FTPS explícito negocia TLS na porta padrão 21 depois de conectar (AUTH TLS); o FTPS implícito espera TLS imediatamente em uma porta dedicada, convencionalmente 990. Os dois ainda precisam de uma segunda conexão de dados, o que — por estar agora também envolvida em TLS — torna as faixas de porta do modo passivo através de um firewall uma dor de cabeça ainda maior do que no FTP puro, já que o firewall precisa permitir uma sessão TLS que não consegue inspecionar. Segurança: genuinamente melhor que o FTP — credenciais e dados são criptografados em trânsito, assumindo que o TLS esteja configurado corretamente (validação de certificado, sem versões antigas de TLS deixadas habilitadas). Ainda autentica com usuário e senha por padrão, então você está confiando só na criptografia de transporte, a menos que autenticação de cliente baseada em certificado seja adicionada por cima. Quando usar: quando a infraestrutura de um parceiro é padronizada especificamente em FTPS (comum em algumas indústrias onde é um padrão de compliance) e ele não vai migrar para SFTP. É uma escolha legítima e segura o suficiente quando configurada corretamente. Por que ainda prefiro o SFTP: o modelo de duas conexões não desaparece só porque está criptografado — você ainda está lidando com faixas de porta do modo passivo e interação com NAT/firewall, só que agora com TLS no meio também. O SFTP evita essa categoria inteira de problema. O que é SFTP / SSH / SCP # Este é o que realmente mais importa para o B2Bi, então ele leva o resto deste post. Primeiro, o nome precisa ser desembaraçado, porque \u0026ldquo;SFTP é FTP sobre SSH\u0026rdquo; é a coisa mais comum que as pessoas erram sobre ele — e não é verdade. SFTP — o SSH File Transfer Protocol — é um subsistema do próprio SSH, não FTP envolvido em nada. Ele não compartilha nada com o conjunto de comandos ou o modelo de conexão do FTP. Uma conexão TCP, um canal criptografado negociado, operações de arquivo definidas como parte da família de protocolos SSH desde a base.\nsequenceDiagram participant Client as Cliente participant Server as Servidor Client-\u003e\u003eServer: Conexão TCP, porta 22 Client-\u003e\u003eServer: Troca de versão do protocolo SSH Note over Client,Server: Negociação de algoritmos:método de troca de chaves, cifras, MACs Client-\u003e\u003eServer: Troca de chaves (ex: curve25519-sha256) Server-\u003e\u003eClient: Host key apresentada Note over Client,Server: Cliente verifica a host key contra known_hosts —falha de forma fechada em caso de divergência Client-\u003e\u003eServer: Autentica (chave pública ou senha) Server-\u003e\u003eClient: Resultado da autenticação Note over Client,Server: Canal único criptografado agora estabelecido Client-\u003e\u003eServer: Solicita o subsistema \"sftp\" Note over Client,Server: Todas as operações de arquivo (abrir, ler, escrever,stat, renomear, apagar) rodam como pacotesbinários dentro deste único canal Portas: uma. Porta 22, igual a qualquer conexão SSH. Nenhuma segunda conexão de dados, nenhuma faixa de modo passivo, nada extra para abrir em um firewall. Segurança: forte por design — todo pacote, de controle e de dados igualmente, trafega pelo mesmo canal criptografado e com verificação de integridade estabelecido durante o handshake SSH. A autenticação suporta tanto senha quanto autenticação por chave pública (mais sobre isso adiante), e o servidor prova a própria identidade via sua host key, que o cliente deveria verificar contra uma entrada confiável em known_hosts antes de confiar em qualquer coisa que vem depois. Quando usar: essa é a escolha padrão para novas conexões de parceiro, a menos que os requisitos de segurança ou compliance do próprio parceiro determinem especificamente outra coisa. É o que eu uso primeiro, e é a esmagadora maioria do que o tráfego de parceiros do B2Bi roda na prática. Por que não FTP ou FTPS no lugar: nenhuma opção em texto plano para configurar errado por acidente (FTP), e nenhuma segunda conexão brigando com o seu firewall (FTPS) — o modelo de canal único do SFTP é simplesmente estruturalmente mais simples de proteger corretamente. SCP merece uma menção aqui porque é o outro subsistema de transferência de arquivos do SSH e é confundido com o SFTP o tempo todo. scp(1) é mais antigo e muito mais simples que o SFTP — efetivamente um cp com transporte SSH, sem listagem de diretório, sem suporte a retomada, sem rename atômico. O OpenSSH moderno vem silenciosamente reimplementando o cliente do SCP por cima dos internos do SFTP há anos, especificamente porque o design de protocolo do SFTP é melhor em quase todos os aspectos. Se você tiver escolha entre os dois hoje, escolha SFTP — é o protocolo ativamente mantido e mais capaz, e é o que os adapters de client e server do Sterling implementam.\nMaterial de referência que vale a pena ter salvo em vez de confiar em explicações de segunda mão: ssh(1) e sftp(1), as páginas de manual canônicas do OpenBSD/OpenSSH.\nComparação rápida # FTP FTPS SFTP Conexões 2 (controle + dados) 2, envolvidas em TLS 1 Porta(s) 21 + dinâmica/20 21 ou 990 + dinâmica 22 Criptografia Nenhuma TLS Criptografia de transporte do SSH Autenticação Usuário/senha, texto plano Usuário/senha (+ certificados de cliente opcionais) Senha ou chave pública Amigável a Firewall/NAT Ruim Ruim (canal de dados envolvido em TLS) Bom — conexão única Adapter no Sterling FTP Adapter FTP Adapter (com SSL habilitado) SFTP Client/Server Adapter Pares de chaves SSH # A autenticação por chave pública é a que você realmente quer para qualquer coisa automatizada ou voltada a parceiros — nenhuma credencial parada em um script ou job agendado, nenhuma discussão de rotação de senha com o time de segurança de um parceiro, e é em torno disso que a maioria das configurações de trading partner do SFTP Server Adapter no B2Bi é construída.\nO que é: um par de chaves ligadas matematicamente, geradas em conjunto. A chave privada fica exatamente onde foi gerada e nunca é transmitida para lugar nenhum, por design — se ela sair dessa máquina, o par de chaves é considerado comprometido. A chave pública é a metade feita para ser compartilhada livremente; ela é colocada em um arquivo authorized_keys em um servidor OpenSSH comum, ou registrada como a chave pública conhecida do parceiro dentro da configuração de trading partner do Sterling. A autenticação funciona porque o cliente consegue provar posse da chave privada (assinando um desafio) sem nunca enviá-la para lugar nenhum — o servidor só precisa da metade pública para verificar essa assinatura.\nssh-keygen(1) é a ferramenta que gera as duas metades.\nTipos e tamanhos de chave:\nRSA — o velho confiável, e ainda o que a maioria das stacks legadas de MFT e ferramentas mais antigas próximas de mainframe esperam. 2048 bits é o piso prático hoje (o OpenSSH moderno recusa qualquer coisa menor por padrão); 3072 ou 4096 bits é a escolha mais segura para qualquer coisa de vida longa. ssh-keygen -t rsa -b 4096. ed25519 — o padrão moderno. Tamanho de chave fixo (sem parâmetro de tamanho para errar), mais rápido para gerar e verificar, e considerado pelo menos tão forte quanto RSA-3072/4096 com muito menos material de chave. ssh-keygen -t ed25519. É o que eu uso primeiro para qualquer par de chaves novo, a menos que a ferramenta de um parceiro genuinamente não consiga interpretá-lo — o que, com sistemas mais antigos, acontece mais do que se gostaria. ECDSA — suportado, ocasionalmente visto, raramente minha primeira escolha dadas as preocupações com curvas NIST que alguns times de segurança levantam; o ed25519 cobre o mesmo terreno com menos bagagem. DSA — descontinuado e desabilitado por padrão no OpenSSH atual por completo. Um parceiro insistindo nele é, na verdade, uma conversa sobre quão antigo é o sistema dele. Formatos de arquivo de chave — a parte que causa atrito de verdade durante a troca de chaves com parceiros:\nO formato de chave privada próprio do OpenSSH (-----BEGIN OPENSSH PRIVATE KEY-----) é o padrão desde o OpenSSH 7.8, e é o que o ssh-keygen produz a menos que seja instruído de outra forma. PEM / PKCS#1 é o formato de chave privada mais antigo, ainda o que muitas ferramentas fora do OpenSSH e bibliotecas mais antigas esperam. ssh-keygen -m PEM força esse formato quando o outro lado não consegue interpretar o mais novo. O formato de chave pública SECSH, definido na RFC 4716, é um formato de intercâmbio de chave pública que alguns servidores SFTP fora do OpenSSH e plataformas de MFT legadas esperam, em vez do formato de linha única estilo authorized_keys do OpenSSH. ssh-keygen -e exporta uma chave pública em formato OpenSSH para o formato RFC 4716; -i importa de volta. Na prática: um parceiro te entrega uma chave pública no formato que o sistema dele produziu, ela não bate com o que o seu lado espera, e a correção é um ciclo de ssh-keygen -e/-i, não um par de chaves regerado do zero. Saber que esses três formatos existem transforma um onboarding de parceiro travado em uma correção de dois minutos.\nCifras e MACs # O que são: durante a etapa de troca de chaves SSH no diagrama de handshake acima, cliente e servidor anunciam cada um uma lista ordenada de algoritmos suportados e concordam com o mais forte que os dois lados suportam — uma cifra para criptografar o fluxo de dados, e um MAC (código de autenticação de mensagem) para verificar que os pacotes não foram adulterados em trânsito. Essa negociação é exatamente o que os campos de preferência de cifra e MAC do SFTP Server Adapter (visíveis nas capturas de tela da Parte 2) estão configurando — não é algo específico do Sterling, é a própria negociação de algoritmos do SSH exposta através de um console de administração.\nPor que isso importa: o SSH existe há tempo suficiente para acumular algoritmos que eram escolhas razoáveis há uma década e hoje são considerados fracos ou quebrados. Um servidor que ainda os oferece não está necessariamente comprometido, mas está carregando um risco evitável, e é rotineiramente o que scans de segurança sinalizam em um servidor de MFT.\nEscolhas boas e atuais (o que o OpenSSH moderno usa por padrão e o que eu gostaria que uma conexão de parceiro realmente estivesse usando):\nCifras: chacha20-poly1305@openssh.com, aes256-gcm@openssh.com, aes128-gcm@openssh.com MACs: as variantes -etm (encrypt-then-MAC) — hmac-sha2-256-etm@openssh.com, hmac-sha2-512-etm@openssh.com — preferidas sobre suas equivalentes não-ETM porque encrypt-then-MAC evita algumas armadilhas criptográficas às quais MAC-then-encrypt está exposto. Fracos ou descontinuados — não deveriam aparecer em uma configuração ativa:\nCifras: 3des-cbc (lenta e criptograficamente cansada), arcfour/arcfour128/arcfour256 (baseadas em RC4, quebradas), qualquer cifra em modo -cbc puro onde uma alternativa GCM ou ChaCha20 esteja disponível. MACs: hmac-md5 e hmac-sha1 (MD5 e SHA-1 são ambos considerados fracos demais para esse uso), e MACs não-ETM em geral, se a variante ETM for suportada pelos dois lados. A lista atual e autoritativa do que o OpenSSH suporta — e como definir uma ordem de preferência explícita — está em ssh_config(5) e sshd_config(5). A regra prática que sigo: usar por padrão as recomendações atuais do OpenSSH, e só adicionar uma cifra ou MAC mais antigo à lista permitida para aquela conexão de parceiro específica que genuinamente precisa dele — nunca globalmente, e nunca permanentemente sem um chamado para revisitar e removê-lo depois.\nOperações que costumam confundir # Leituras parciais de arquivo. O job automatizado de um parceiro começa a fazer polling em uma mailbox no instante em que um arquivo começa a ser enviado, e pega um arquivo pela metade. A correção é operacional, não a nível de protocolo: fazer upload para um nome de arquivo temporário, depois renomear atomicamente assim que a transferência terminar. O SFTP suporta rename atômico como operação nativa; use-a.\n\u0026ldquo;Funciona no FileZilla mas não a partir do nosso sistema.\u0026rdquo; Quase sempre uma divergência de método de autenticação (o cliente gráfico lembrou uma senha salva; o job automatizado está tentando autenticação por chave com a chave errada) ou uma host key que mudou e o cliente automatizado está falhando de forma fechada por uma divergência em known_hosts, enquanto o cliente gráfico simplesmente clicou para passar por uma caixa de diálogo de aviso. Verifique os dois antes de assumir que é um problema de rede.\nLimites de thread e conexão. A configuração do SFTP Client Adapter da Parte 2 tem limites explícitos de thread por um motivo — um parceiro rodando uma rajada de transferências paralelas contra um adapter compartilhado pode esgotar os slots de conexão de todo outro parceiro que o compartilha. Vale a pena saber os limites do seu adapter antes de um parceiro perguntar \u0026ldquo;podemos enviar 200 arquivos de uma vez?\u0026rdquo;\nMudanças de host key sem aviso. Parceiros reconstroem servidores e rotacionam chaves sem te avisar com antecedência. Uma política estrita de known_hosts é o padrão certo, mas significa que toda rotação não anunciada vira uma conexão falha até que alguém verifique e aceite manualmente a nova chave — vale a pena ter um caminho de verificação rápido e documentado, em vez de recorrer a \u0026ldquo;só desabilita a checagem estrita\u0026rdquo;, o que anula o propósito inteiro. Isso acontece com frequência suficiente, e tem nuance suficiente, para merecer seu próprio post: SSH known_hosts: Como a Verificação de Host Key Realmente Funciona.\nOnde isso se encaixa no Sterling # Tudo acima é a nível de protocolo e se aplica a qualquer servidor ou cliente FTP, FTPS ou SFTP — IBM ou não. O que o Sterling adiciona é uma UI de console de administração exatamente sobre esses conceitos: o campo de host identity key do SFTP Server Adapter é o par de chaves de host SSH do servidor; suas listas de preferência de cifra e MAC são as listas de negociação de ssh_config/sshd_config descritas acima; a chave pública registrada de um trading partner é uma entrada de authorized_keys, só que armazenada na configuração de trading partner do Sterling em vez de um arquivo plano; e o FTP Adapter comum com SSL habilitado é exatamente o handshake de FTPS diagramado acima. Nada disso é o Sterling reinventando esses protocolos — é o Sterling expondo a superfície de configuração nativa deles através de um console, e é por isso que entender os protocolos por baixo faz as telas de adapter da Parte 2 fazerem muito mais sentido numa segunda olhada.\nFontes e leituras complementares # RFC 959 — File Transfer Protocol OpenSSH ssh(1) sftp(1) scp(1) ssh-keygen(1) ssh_config(5) sshd_config(5) RFC 4716 — The Secure Shell (SSH) Public Key File Format Documentação IBM: Services \u0026amp; Adapters Como no resto desta série: as definições de protocolo, as RFCs e o conteúdo das páginas de manual são as fontes autoritativas linkadas acima, o enquadramento, as comparações e os conselhos operacionais são meus.\nO que vem a seguir # A seguir: Mailboxes e File Gateway — desembaraçando a confusão sinalizada lá na Parte 1, com um olhar mais de perto sobre como o roteamento do File Gateway realmente se apoia na estrutura de mailbox e adapters por baixo dele. Leia aqui: Parte 5.\n","date":"09/09/2026","externalUrl":null,"permalink":"/pt-br/posts/sterling-b2bi-07-sftp-protocol-fundamentals/","section":"Posts","summary":"Três protocolos, um trabalho, mecânicas internas muito diferentes # FTP, FTPS e SFTP todos afirmam fazer a mesma coisa — mover um arquivo de um lugar para outro — e os parceiros usam os nomes quase como sinônimos, o que é exatamente o problema. São três protocolos genuinamente diferentes, com modelos de porta diferentes, propriedades de segurança diferentes e modos de falha diferentes, e o SFTP Server Adapter e o SFTP Client Adapter que você configura no Sterling só fazem sentido depois que você sabe qual deles está realmente rodando. Este post passa por cada um nos seus próprios termos, e depois dedica a segunda metade especificamente ao SFTP, já que é isso que carrega a esmagadora maioria do tráfego de parceiros no B2Bi.\n","title":"SFTP, FTP, FTPS: O Protocolo Por Trás dos Adapters","type":"posts"},{"content":"","date":"09/09/2026","externalUrl":null,"permalink":"/pt-br/series/sterling-b2bi-architecture/","section":"Series","summary":"","title":"Sterling-B2bi-Architecture","type":"series"},{"content":"","date":"08/09/2026","externalUrl":null,"permalink":"/pt-br/tags/architecture/","section":"Tags","summary":"","title":"Architecture","type":"tags"},{"content":"","date":"08/09/2026","externalUrl":null,"permalink":"/pt-br/tags/b2bi/","section":"Tags","summary":"","title":"B2bi","type":"tags"},{"content":"","date":"08/09/2026","externalUrl":null,"permalink":"/pt-br/tags/dmz/","section":"Tags","summary":"","title":"Dmz","type":"tags"},{"content":"","date":"08/09/2026","externalUrl":null,"permalink":"/pt-br/tags/network-security/","section":"Tags","summary":"","title":"Network-Security","type":"tags"},{"content":" A conexão roda ao contrário do que você imaginaria # A primeira suposição da maioria das pessoas sobre uma caixa na DMZ é que a sua rede interna e confiável é quem alcança ela — o lado seguro inicia, o lado exposto escuta. Um Perimeter Server faz o oposto. O motor central do B2Bi, seguro dentro da sua rede, nunca abre uma conexão para fora, em direção à DMZ. Em vez disso, o Perimeter Server — a caixa que de fato está de frente para os parceiros e a internet — disca de volta para o motor central e mantém essa conexão aberta. O tráfego do parceiro chega primeiro na caixa da DMZ, e só então é encaminhado para dentro por um canal que o próprio lado da DMZ estabeleceu.\nMencionei esse componente na Parte 1 e prometi voltar ao assunto, porque a maioria do material introdutório o ignora completamente — o que é uma pena, já que é o motivo real pelo qual um diagrama de implantação do Sterling tem caixas fora do firewall, para começo de conversa, e é o detalhe que faz toda a história da DMZ fazer sentido depois que você entende em que direção o fio realmente corre. Lado a lado, a suposição e a realidade se parecem assim:\nflowchart TB subgraph Assumed[\"O que você imaginaria\"] direction LR C1[\"Core Engine\\n(zona confiável)\"] FW1{{\"Firewall Interno\"}} PS1[\"Perimeter Server\\n(DMZ)\"] C1 -- \"Core abre uma nova\\nconexão para dentro da DMZ\" --\u003e FW1 FW1 -- \"exige uma regra de\\nliberação de entrada vinda da DMZ\" --\u003e PS1 end subgraph Actual[\"O que de fato acontece\"] direction LR PS2[\"Perimeter Server\\n(DMZ)\"] FW2{{\"Firewall Interno\"}} C2[\"Core Engine\\n(zona confiável)\"] PS2 -- \"PS disca para fora\\n(reverseConnect)\" --\u003e FW2 FW2 -- \"regra somente de saída —\\nnenhum buraco de entrada necessário\" --\u003e C2 end style FW1 fill:#4a1a1a,stroke:#c0392b style FW2 fill:#12331a,stroke:#27ae60 A metade de cima é a regra que o seu firewall interno precisaria se o motor central alcançasse a DMZ — uma regra de liberação de entrada que deixa um host da DMZ iniciar tráfego para dentro da zona confiável, que é precisamente o tipo de buraco que uma DMZ existe para evitar. A metade de baixo é o que um Perimeter Server realmente exige: uma regra somente de saída, e nada escutando por conexões vindas do lado da DMZ.\nO que é um Perimeter Server # Um Perimeter Server é um processo leve e independente que fica na DMZ e termina o handshake de protocolo com o mundo externo — SFTP, FTP/FTPS, HTTP/S, AS2, Connect:Direct, OdetteFTP, SOAP — em nome do B2Bi. Ele não roda Business Processes, não toca em mailboxes, e não guarda configuração de trading partner. O trabalho inteiro dele é gerenciamento de socket: aceitar a conexão, gerenciar a sessão e a thread, e repassar o tráfego para o motor de verdade através de um canal seguro, para que o motor em si — com o database, o histórico de rastreamento de documentos, o arquivo de cada parceiro — nunca precise ficar perto de uma interface voltada ao público (Documentação IBM).\nEssa é a proposta de valor inteira em uma frase: ela permite expor endpoints voltados a parceiros sem nunca colocar o motor central ao alcance da internet pública. Além da fronteira de segurança, a IBM também documenta um ângulo de performance — o gerenciamento de sessão e thread na caixa da DMZ reduz a carga que o motor central precisa carregar diretamente, o que importa mais do que parece quando você está rodando dezenas de parceiros com perfis de tráfego muito diferentes através do mesmo node.\nEmbutido vs. remoto: duas implantações bem diferentes escondidas atrás de um único nome # \u0026ldquo;Perimeter Server\u0026rdquo; se refere a duas configurações distintas, e misturá-las é uma fonte comum de confusão:\nPerimeter Server embutido (local). Empacotado diretamente dentro do próprio B2Bi — sem instalação separada, sem posicionamento na DMZ. Ele existe para que adapters que esperam uma atribuição de perimeter server tenham algo para apontar em um laboratório, um ambiente de desenvolvimento, ou qualquer implantação onde você genuinamente não precisa de uma fronteira de DMZ. Ele não fornece nenhuma das separações de segurança reais que um remoto fornece.\nPerimeter Server remoto (instalado). Uma instalação separada, implantada em seu próprio host, física ou logicamente dentro da DMZ, independente da própria instalação do B2Bi. Esse é o que faz o trabalho de verdade em qualquer topologia de produção — o que o tráfego de parceiro de fato atinge.\nMúltiplos Perimeter Servers remotos podem rodar contra um único node de B2Bi ao mesmo tempo, o que é o que permite segmentar o tráfego deliberadamente: uma caixa de DMZ lidando com SFTP de alto volume dos seus maiores trading partners, uma separada para um parceiro cujo time de segurança insiste em infraestrutura fisicamente isolada, sem tocar na configuração do motor central para adicionar nenhum dos dois. Essa atribuição por adapter é exatamente o campo que você teria passado batido na captura de tela do SFTP Client Adapter da Parte 2 — \u0026ldquo;nome do sistema, ambiente, uma atribuição de perimeter server e limites de thread\u0026rdquo; estava fazendo bastante trabalho silencioso naquela única linha.\nA mecânica do reverseConnect # Aqui está a parte que surpreende quem já trabalhou com reverse proxies antes e espera a direção usual de confiança: o Perimeter Server remoto é quem inicia a conexão com o motor central, não o contrário. A própria documentação de suporte da IBM para o arquivo remote_perimeter.properties que configura isso lista exatamente os parâmetros que você esperaria para esse modelo — reverseConnect, remoteAddress, remotePort, e uma port local (Suporte IBM) — e documentação da comunidade sobre o mesmo mecanismo descreve o Perimeter Server remoto estabelecendo uma conexão persistente de volta com o sistema central, comumente na porta 9999 (Pronteff).\nPor que construir dessa forma, em vez de deixar o motor central alcançar a DMZ? Porque isso significa que o seu firewall interno nunca precisa de uma regra de entrada que deixe um host da DMZ iniciar tráfego para dentro das portas de escuta da sua rede confiável — a caixa da DMZ só origina a única conexão de que precisa, e tudo depois disso trafega dentro dela. Essa única decisão de design é o motivo pelo qual a topologia funciona sem abrir exatamente o tipo de buraco que uma DMZ existe para evitar.\nsequenceDiagram participant Partner as Parceiro participant PS as Perimeter Server (DMZ) participant Core as B2Bi Core Engine (zona confiável) Note over PS,Core: Conexão persistente estabelecida primeiro —PS disca para o Core, não o contrário PS-\u003e\u003eCore: Conexão de saída (reverseConnect, tipicamente porta 9999) Core--\u003e\u003ePS: Conexão aceita, mantida aberta Partner-\u003e\u003ePS: Conecta (SFTP / AS2 / HTTP) PS-\u003e\u003ePS: Termina o handshake de protocolo PS-\u003e\u003eCore: Encaminha a sessão pelo canal já existente Core-\u003e\u003eCore: Repassa para Adapter → Business Process Note over Partner,Core: O firewall interno nunca precisa aceitaruma conexão de entrada iniciada pela DMZ Essa sequência esconde um detalhe importante: na camada de rede, na verdade existem duas conexões separadas fazendo dois trabalhos separados, não uma. Desenhado como topologia em vez de linha do tempo, fica assim:\nflowchart LR subgraph Internet[\"Internet\"] Partner[\"Parceiro Comercial\"] end subgraph DMZ[\"DMZ\"] PS[\"Perimeter Server\"] end subgraph Trusted[\"Zona Confiável\"] Core[\"B2Bi Core Engine\"] end PS == \"1 — saída, iniciada pelo PS\\ncanal de controle persistente\\n(reverseConnect, porta 9999)\" ==\u003e Core Partner -- \"2 — entrada só até o PS\\n(SFTP / AS2 / HTTP)\" --\u003e PS PS -. \"3 — sessão do parceiro tunelada\\npelo canal aberto no passo 1\" .-\u003e Core O passo 1 precisa acontecer primeiro e fica de pé continuamente — é infraestrutura, não tráfego por sessão. O passo 2 é a única conexão que um parceiro faz, e ela termina no Perimeter Server; ela nunca vira uma segunda conexão independente alcançando a zona confiável. O passo 3 não é uma conexão nova — é a sessão do parceiro trafegando dentro do canal que já existe desde o passo 1. Do ponto de vista do firewall interno, exatamente uma conexão cruza a fronteira, e é a caixa da DMZ que a abriu.\n(Placeholder de captura de tela: a tela \u0026ldquo;Add Perimeter Server\u0026rdquo; no console de administração — Deployment \u0026gt; Perimeter Servers \u0026gt; Add — mostrando o nome, a descrição, e o seletor de tipo local/embutido vs. remoto. Vale uma segunda captura de tela da visão de detalhe de um Perimeter Server remoto configurado, se os valores de remote_perimeter.properties estiverem visíveis ali.)\nPerimeter Server vs. Sterling Secure Proxy — não é o mesmo produto # Esta é a outra fonte recorrente de confusão, e vale a pena ser preciso sobre ela: o Sterling Secure Proxy (SSP) é um produto IBM separado, um gateway de segurança e reverse-proxy completo para DMZ, com suas próprias capacidades de quebra de sessão, filtragem de protocolo e mapeamento de credenciais, muito além do que um Perimeter Server faz. Os dois são confundidos constantemente porque implantações de SSP também envolvem um componente \u0026ldquo;Parameter Server\u0026rdquo; instalado na frente dele, e porque os dois produtos vivem na mesma parte voltada à DMZ de um diagrama de arquitetura Sterling (Suporte IBM). Se uma vaga de emprego ou um colega diz \u0026ldquo;perimeter server\u0026rdquo; e quer dizer comportamento de proxy com quebra de sessão, inspeção completa de protocolo, ou mapeamento de credenciais entre uma identidade externa e interna, eles quase certamente estão descrevendo o SSP, não o Perimeter Server simples que este post cobre. O Perimeter Server simples é um componente muito mais estreito e muito mais simples — ele move bytes com segurança através da fronteira da DMZ; não inspeciona, transforma ou autentica nada por conta própria.\nCenários operacionais # \u0026ldquo;Parceiros conseguem se conectar mas os arquivos nunca aparecem.\u0026rdquo; Cheque primeiro a qual Perimeter Server o adapter que está falhando está de fato atribuído — com múltiplos Perimeter Servers remotos em um node, um parceiro caindo no errado (ou em um que está fora do ar) parece idêntico a um problema de rede do lado do parceiro, mas é uma incompatibilidade de configuração do seu lado.\nCloseCode.NO_AVAILABLE_PORT em perimeter.log. Isso aparece como uma falha de bind — java.net.BindException: Cannot assign requested address — quando o Perimeter Server não consegue alocar uma porta para uma sessão nova (Suporte IBM). Na prática, isso quase sempre é exaustão de portas sob carga ou uma regra de firewall/SO local limitando a faixa de portas efêmeras no host da DMZ — cheque a faixa de portas do próprio host da DMZ e qualquer regra de firewall a nível de host antes de assumir que é um problema do lado do B2Bi. Vale lembrar que isso é genuinamente separado do mundo de mailbox e Business Process — é uma falha de camada de rede, mais baixa.\nDois arquivos de log, duas classes de falha diferentes. Problemas de conexão e sessão do perimeter ficam em perimeter.log, no próprio host do Perimeter Server. Problemas do lado do motor central na passagem de bastão — o Perimeter Services Manager registrando ou perdendo um Perimeter Server conectado — aparecem nos próprios logs do motor central. Perseguir um problema de conectividade no log errado é uma forma rápida de perder vinte minutos à toa; se um adapter de protocolo voltado a parceiro está falhando em receber conexões completamente, o perimeter.log na caixa da DMZ é a primeira parada, não o log de aplicação do motor central.\nUm Perimeter Server \u0026ldquo;some\u0026rdquo; depois de um restart. Como o lado da DMZ é dono da conexão, a ordem de restart importa: se o motor central volta antes que o Perimeter Server remoto reconecte, adapters atribuídos a esse Perimeter Server vão mostrá-lo como indisponível até que o processo do lado da DMZ restabeleça a conexão de saída. Isso é comportamento esperado, não corrupção — só significa que os runbooks de restart para um ambiente B2Bi com Perimeter Servers remotos precisam considerar os dois lados voltando, não só o motor central.\nOnde isso se encaixa na série # O Perimeter Server é a peça do diagrama de topologia da Parte 1 que recebeu uma menção de um parágrafo e nada mais até agora. É a primeira coisa que a conexão de um parceiro toca — antes do Adapter, antes do Business Process, antes de o arquivo sequer chegar a uma Mailbox. Toda peça daquele diagrama original agora genuinamente tem seu próprio post por trás dela.\nFontes e leituras complementares # Perimeter servers in Sterling B2B Integrator — Documentação IBM Perimeter Server overview — Documentação IBM (6.1.2) Need more information about remote_perimeter.properties parameters — Suporte IBM Perimeter Server connection fails with CloseCode.NO_AVAILABLE_PORT — Suporte IBM What Parameter Server needs to be installed with IBM Sterling Secure Proxy? — Suporte IBM What is IBM Sterling Perimeter Server? — Pronteff Como no resto desta série: as definições e os parâmetros documentados são da IBM (e do Suporte IBM), o enquadramento, o diagrama e os cenários operacionais são meus.\nO que vem a seguir # A seguir: O Map Editor — a camada de tradução sinalizada lá na Parte 1, e a origem de alguns dos bugs mais complicados que já persegui em produção.\n","date":"08/09/2026","externalUrl":null,"permalink":"/pt-br/posts/sterling-b2bi-06-perimeter-servers/","section":"Posts","summary":"A conexão roda ao contrário do que você imaginaria # A primeira suposição da maioria das pessoas sobre uma caixa na DMZ é que a sua rede interna e confiável é quem alcança ela — o lado seguro inicia, o lado exposto escuta. Um Perimeter Server faz o oposto. O motor central do B2Bi, seguro dentro da sua rede, nunca abre uma conexão para fora, em direção à DMZ. Em vez disso, o Perimeter Server — a caixa que de fato está de frente para os parceiros e a internet — disca de volta para o motor central e mantém essa conexão aberta. O tráfego do parceiro chega primeiro na caixa da DMZ, e só então é encaminhado para dentro por um canal que o próprio lado da DMZ estabeleceu.\n","title":"Perimeter Servers no IBM Sterling B2B Integrator: Por Que a Caixa na DMZ Liga para Casa, e Não o Contrário","type":"posts"},{"content":"","date":"08/09/2026","externalUrl":null,"permalink":"/pt-br/tags/perimeter-server/","section":"Tags","summary":"","title":"Perimeter-Server","type":"tags"},{"content":"","date":"07/09/2026","externalUrl":null,"permalink":"/pt-br/tags/file-gateway/","section":"Tags","summary":"","title":"File-Gateway","type":"tags"},{"content":" A confusão que sinalizei lá na Parte 1 # Mencionei isso na Parte 1 e prometi voltar ao assunto: o File Gateway não é um produto separado concorrendo com o B2Bi. É uma camada de UI e roteamento construída especificamente por cima da estrutura de mailbox e adapters do B2Bi, feita justamente para que a troca de arquivos com parceiros possa ser gerenciada sem que ninguém precise mexer diretamente em BPML. Ainda vejo gente que roda Sterling há anos falando dos dois como se fossem alternativas entre as quais você escolhe. Não são — um é a fundação, o outro é uma forma de trabalhar com essa fundação sem escrever um Business Process à mão.\nUma observação sobre nomenclatura antes de mais nada, porque causa confusão de verdade em vagas de emprego, chamados e conversas casuais: o File Gateway é quase sempre chamado de \u0026ldquo;SFG\u0026rdquo; — Sterling File Gateway — seu nome de produto de fato, distinto de \u0026ldquo;B2Bi\u0026rdquo; (Sterling B2B Integrator), mesmo que o SFG rode como um componente instalado por cima de um ambiente B2Bi em vez de um sistema independente. Quando alguém diz \u0026ldquo;a gente roda SFG,\u0026rdquo; está se referindo especificamente a essa camada: o console de administração de Routes/Participants/Tools mostrado ao longo deste post, não o console de administração central do B2Bi das partes anteriores desta série. Vou usar \u0026ldquo;File Gateway\u0026rdquo; e \u0026ldquo;SFG\u0026rdquo; de forma intercambiável daqui para frente, já que você vai encontrar os dois por aí — a própria documentação da IBM, e-mails de parceiros e vagas de emprego misturam os dois.\nEste post cobre primeiro a fundação de mailbox, e depois o que o SFG realmente adiciona por cima dela.\nO que é uma Mailbox # Uma Mailbox é uma caixa de entrega segura e com permissões dentro do B2Bi — uma estrutura de pastas virtual que existe como metadados e registros de banco de dados, não arquivos literais em um diretório, mesmo que se comporte como um para qualquer coisa que interaja com ela via SFTP, HTTP ou as APIs de Mailbox. Arquivos caem em uma mailbox, são retirados de uma, e toda operação contra ela tem permissão checada e é registrada da mesma forma que qualquer outra movimentação de documento na plataforma.\nDuas coisas sobre esse enquadramento \u0026ldquo;virtual\u0026rdquo; importam na prática:\nA hierarquia de mailbox é organizacional, não física. Você constrói uma árvore — uma mailbox raiz, pontos de coleta compartilhados, mailboxes por parceiro por baixo — e é essa estrutura que parceiros e processos internos veem quando listam ou navegam mailboxes. Os bytes de fato ficam onde quer que o armazenamento de documentos do B2Bi esteja configurado para colocá-los; a hierarquia que você constrói não tem nada a ver com isso. Permissões são atribuídas por mailbox, e são genuinamente por usuário/por grupo, não só por adapter. As credenciais SFTP de um trading partner podem ser restritas para enxergar exatamente uma mailbox e nada mais na árvore acima ou ao lado dela — que é o mecanismo inteiro que permite que um único SFTP Server Adapter compartilhado sirva com segurança dezenas de parceiros sem relação entre si, distinguidos por mailbox e credenciais em vez de um adapter dedicado por parceiro. Uma hierarquia típica se parece com isto:\nflowchart TD ROOT[\"Root Mailbox\"] ROOT --\u003e DL[\"Dead Letter Mailbox\"] ROOT --\u003e EDIIN[\"EDI Inbound Collection\"] ROOT --\u003e EDIOUT[\"EDI Outbound Collection\"] ROOT --\u003e PARTNERS[\"Trading Partners\"] PARTNERS --\u003e PA[\"Mailbox do Parceiro A\"] PARTNERS --\u003e PB[\"Mailbox do Parceiro B\"] PARTNERS --\u003e PC[\"Mailbox do Parceiro C\"] PA --\u003e PAIN[\"inbound/\"] PA --\u003e PAOUT[\"outbound/\"] style DL fill:#4a1a1a,stroke:#c0392b A Dead Letter Mailbox merece um destaque à parte: é para onde os arquivos vão quando não conseguem ser roteados para lugar nenhum — um nome de arquivo malformado, uma regra de roteamento sem correspondência, uma falha de permissão no meio do processo. Eu checo ela antes de checar quase qualquer outra coisa quando um parceiro diz \u0026ldquo;eu enviei o arquivo mas nada aconteceu,\u0026rdquo; porque na maioria das vezes, ele está bem ali.\nComo um arquivo realmente entra e sai de uma mailbox # Nada na entrega de mailbox é específico de protocolo — a mesma mailbox pode receber gravação de um SFTP Server Adapter recebendo o upload de um parceiro, ser lida por um Business Process retirando um arquivo para traduzir, ou ser exposta através do próprio roteamento do File Gateway, tudo isso sem que a mailbox em si saiba ou se importe com qual caminho está sendo usado:\nsequenceDiagram participant Partner as Parceiro participant AD as SFTP Server Adapter participant MB as Mailbox participant BP as Business Process participant DB as Database Partner-\u003e\u003eAD: Envia arquivo (SFTP PUT) AD-\u003e\u003eMB: Entrega na mailbox do parceiro MB-\u003e\u003eDB: Registra chegada, checa permissões Note over MB,BP: Evento de mailbox ou polling agendado dispara a retirada MB-\u003e\u003eBP: Arquivo disponível para processamento BP-\u003e\u003eBP: Roteia, mapeia, valida BP-\u003e\u003eMB: Entrega resultado na mailbox de destino MB-\u003e\u003eDB: Registra status de entrega O que o File Gateway (SFG) realmente é # Tirando o nome de marketing, o SFG é: um motor de roteamento, uma UI de gerenciamento de parceiros, e um conjunto de Business Processes prontos que a IBM entrega para que você não precise construir manualmente o mesmo padrão \u0026ldquo;receber, validar, rotear, confirmar entrega\u0026rdquo; do zero para cada relacionamento com parceiro. Ele roda sobre o B2Bi — mesmo motor, mesmos adapters, mesmas mailboxes — só te dá uma forma diferente, de nível mais alto, de configurar a troca de arquivos com parceiros, através do próprio console dedicado, organizado em três abas: Routes, Participants e Tools.\nConcretamente, o SFG adiciona:\nPartners e Communities (a aba Participants) — uma forma estruturada de definir trading partners e agrupá-los em comunidades, em vez de permissões de mailbox e registros de trading partner gerenciados de forma independente um do outro. Aqui está a tela de gerenciamento de Groups — repare em \u0026ldquo;All Partners\u0026rdquo; como o grupo padrão, com a possibilidade de criar grupos adicionais e atribuir parceiros a eles: A aba Participants do SFG — agrupando parceiros em comunidades em vez de gerenciar registros brutos de trading partner um por um Routing Channel Templates (a aba Routes) — definições reutilizáveis de \u0026ldquo;quando um arquivo que bate com este padrão chega deste parceiro, valide desta forma, depois entregue aqui\u0026rdquo; — configuradas através de uma UI em vez de desenhadas no Graphical Process Modeler ou escritas como BPML bruto. Arrived Files / rastreamento de consumo (a aba Tools) — uma visão voltada ao parceiro (e ao administrador) do que chegou, do que foi retirado, e do que ainda está pendente, sem que ninguém precise consultar o banco de rastreamento de documentos diretamente. A tela de busca dentro de Tools permite consultar por tipo de mailbox, produtor, consumidor, nome de arquivo, status, protocolo e faixa de data/hora: A busca de Arrived File dentro de Tools — é assim que \u0026lsquo;rastreamento de consumo sem consultar o banco diretamente\u0026rsquo; se parece na prática Rodar essa busca contra atividade real retorna uma lista de resultados assim — cada arquivo chegado com seu status, produtor, nome de arquivo original e horário de descoberta:\nDois arquivos chegados, ambos Failed — exatamente o tipo de coisa que resolve a pergunta de um parceiro de \u0026quot;eu enviei, você recebeu?\u0026quot; Essa mesma aba Tools também tem uma sub-aba Reports para gerar um PDF formatado ou saída similar ao longo de uma faixa de datas, filtrado por grupo de produtor/consumidor e status (Started, Succeeded, Failed, Ignored) — útil para um relatório recorrente voltado a parceiro ou interno de SLA, em vez de consultas pontuais:\nRelatório agendado ou sob demanda sobre a atividade de arquivos chegados — essa é a ferramenta para \u0026quot;quantos arquivos falharam para este parceiro mês passado,\u0026quot; não uma busca pontual O roteamento em si ainda passa, no fim das contas, por mailboxes, e ainda dispara Business Processes — o File Gateway é a camada que gera e gerencia isso tudo para você com base nos canais de roteamento que você configura:\nflowchart LR subgraph FG[\"Camada do File Gateway\"] RC[\"Routing Channel\\nTemplates\"] PM[\"Gerenciamento de Partner\\n\u0026 Community\"] AF[\"Rastreamento de\\nArrived Files\"] end subgraph Core[\"Núcleo do B2Bi (inalterado)\"] AD[\"Adapters\"] MB[\"Mailboxes\"] BP[\"Business Processes\"] end Partner[\"Parceiro Comercial\"] --\u003e AD AD --\u003e MB RC -.configura.-\u003e BP MB \u003c--\u003e BP BP --\u003e AF PM -.governa.-\u003e RC Essa relação de linha pontilhada é o ponto central deste post: o SFG configura e gerencia as mesmas peças subjacentes das Partes 1 a 4, ele não as substitui nem as ignora. Quando algo quebra em uma troca gerenciada pelo SFG, você ainda está depurando um adapter, uma mailbox e um Business Process por baixo — a UI do SFG é só uma porta de entrada mais amigável para chegar lá, e ela até te mostra essa maquinaria subjacente diretamente quando você entra a fundo no log de eventos de um único arquivo chegado:\nCada caixa do fluxograma acima, rastreada como um único log de evento real — identificação do parceiro, entrega na mailbox, correspondência do canal de roteamento, e o ponto exato onde este falhou Lido de cima para baixo, esse log é o fluxograma: o arquivo chega (FG_0408), é entregue em uma mailbox (FG_0425), o parceiro produtor é identificado (FG_0404), a determinação de rota roda contra o Routing Channel Template correspondente (FG_0501–FG_0504), e — nesse caso — a validação contra o parceiro falha (FG_0455, em vermelho) antes que o roteamento consiga concluir. Quando a documentação do SFG ou um colega diz \u0026ldquo;confere os arrived file events,\u0026rdquo; é exatamente isso que eles querem dizer, e geralmente é a forma mais rápida de descobrir qual etapa do pipeline de fato quebrou, em vez de tentar adivinhar.\nQuando usar o File Gateway vs. uma mailbox pura # Use o File Gateway quando: o onboarding de parceiro precisa ser repetível e majoritariamente self-service para quem estiver fazendo isso, quando você quer confirmação de entrega já embutida e uma visão de arquivos chegados visível ao parceiro sem construir uma do zero, ou quando o padrão de troca é genuinamente \u0026ldquo;receber de A, validar, entregar a B\u0026rdquo; sem ramificação condicional complexa que o routing channel template não consiga expressar de forma limpa.\nVá direto para uma mailbox pura e um Business Process feito à mão (ou já existente) quando: a lógica de roteamento é complexa o suficiente para que um routing channel template fique mais estranho do que simplesmente escrever o BPML diretamente, quando você está integrando com Business Processes existentes que já fazem validação/mapeamento sob medida que não se encaixa no padrão do File Gateway, ou para uso de mailbox puramente interno que nunca foi voltado a parceiro (um ponto de EDI Outbound Collection sendo lido por um processo interno agendado, por exemplo).\nNa prática, a maioria dos onboardings de novos parceiros externos no padrão \u0026ldquo;entra por SFTP, entrega em algum lugar\u0026rdquo; passa pelo File Gateway hoje, especificamente porque só o rastreamento de Arrived Files já economiza uma quantidade relevante de idas e vindas de suporte do tipo \u0026ldquo;eles receberam?\u0026rdquo;. Qualquer coisa com lógica condicional de verdade ou histórico legado ainda vive como um Business Process direto contra mailboxes.\nCenários operacionais # \u0026ldquo;O parceiro diz que fez upload, mas nada aconteceu.\u0026rdquo; Primeiro, checa a Dead Letter Mailbox — um nome de arquivo que não bate com o padrão esperado, ou um routing channel sem regra correspondente, manda um arquivo para lá silenciosamente em vez de falhar de forma visível. Segunda parada: a busca de Arrived File na aba Tools — filtrada por esse produtor e status Failed, geralmente traz à tona exatamente esse tipo de arquivo travado em segundos, do mesmo jeito que os dois resultados Failed mostrados antes fizeram. A partir daí, entrar a fundo no log de eventos do arquivo chegado (como acima) te diz por quê — uma falha de validação, um routing channel sem correspondência, ou algo mais acima no fluxo.\nErros de escopo de permissão. Como as permissões de mailbox são genuinamente granulares, é fácil conceder às credenciais SFTP de um parceiro uma visibilidade de mailbox mais ampla do que o pretendido — especialmente em um SFTP Server Adapter compartilhado servindo muitos parceiros. Vale a pena auditar periodicamente as permissões de mailbox contra a lista de trading partners, em vez de assumir que continuaram corretamente restritas conforme a lista de parceiros cresceu.\nMudanças em routing channel template afetando tráfego ao vivo. Editar um routing channel template que está ativamente em uso não é a mesma coisa que editar um Business Process offline — canais de roteamento podem afetar arquivos em trânsito e recém-chegados imediatamente. Trate mudanças de template com a mesma disciplina de controle de mudança que você aplicaria a uma edição de BPML em produção, não como um ajuste casual de console.\nRelatórios recorrentes de SLA de parceiro. Em vez de buscar manualmente em Arrived Files toda vez que um parceiro pergunta \u0026ldquo;quantos dos nossos arquivos falharam mês passado,\u0026rdquo; a sub-aba Reports dentro de Tools gera exatamente isso como um PDF formatado, filtrado por grupo de produtor/consumidor e status — vale a pena configurar como um hábito agendado para parceiros de alto volume, em vez de consultas reativas pontuais.\nOnde isso se encaixa na série # Isso fecha o ciclo da visão geral de componentes da Parte 1: o Perimeter Server e os Adapters trazem o arquivo para dentro, Business Processes e BPML movem e transformam ele (Parte 3), SFTP é o protocolo que a maioria desses adapters de fato fala (Parte 4), e Mailboxes — com o File Gateway como uma forma opcional, de nível mais alto, de geri-las — são onde o arquivo pousa e é retirado. Uma peça do diagrama de topologia da Parte 1 ainda deve seu próprio aprofundamento: o próprio Perimeter Server, a seguir.\nFontes e leituras complementares # Sterling File Gateway — Visão Geral Criando uma Mailbox do Sterling B2B Integrator Sterling B2B Integrator — Visão Geral Como no resto desta série: as definições são da IBM, o enquadramento, o diagrama de roteamento e os cenários operacionais são meus.\nO que vem a seguir # A seguir: Perimeter Servers — o componente de DMZ que toda conexão de parceiro toca primeiro, mencionado lá na Parte 1 e nunca totalmente explicado até agora. Leia aqui: Parte 6. O Map Editor vem depois disso.\n","date":"07/09/2026","externalUrl":null,"permalink":"/pt-br/posts/sterling-b2bi-05-mailboxes-file-gateway/","section":"Posts","summary":"A confusão que sinalizei lá na Parte 1 # Mencionei isso na Parte 1 e prometi voltar ao assunto: o File Gateway não é um produto separado concorrendo com o B2Bi. É uma camada de UI e roteamento construída especificamente por cima da estrutura de mailbox e adapters do B2Bi, feita justamente para que a troca de arquivos com parceiros possa ser gerenciada sem que ninguém precise mexer diretamente em BPML. Ainda vejo gente que roda Sterling há anos falando dos dois como se fossem alternativas entre as quais você escolhe. Não são — um é a fundação, o outro é uma forma de trabalhar com essa fundação sem escrever um Business Process à mão.\n","title":"Mailboxes e File Gateway no IBM Sterling B2B Integrator: Uma Camada, Não Dois Produtos","type":"posts"},{"content":"","date":"07/09/2026","externalUrl":null,"permalink":"/pt-br/tags/sfg/","section":"Tags","summary":"","title":"Sfg","type":"tags"},{"content":"","date":"06/09/2026","externalUrl":null,"permalink":"/pt-br/tags/bpml/","section":"Tags","summary":"","title":"Bpml","type":"tags"},{"content":" O que é um Business Process # Um Business Process é o fluxo de trabalho que encadeia adapters e services em algo que de fato realiza uma tarefa: receber um arquivo, validá-lo, mapeá-lo, criptografá-lo, entregá-lo a um adapter para envio, registrando cada etapa pelo caminho. É a coisa que a Parte 1 chamou de \u0026ldquo;a coisa mais parecida com um coração que a plataforma tem\u0026rdquo; — porque quase nada relevante acontece no Sterling B2B Integrator fora da execução de um deles.\nEstruturalmente, um Business Process é apenas uma sequência de etapas com lógica de ramificação: chame este service, verifique esta condição, chame aquele adapter, trate de forma diferente se algo der errado. Nada nessa descrição exige um diagrama. E esse é exatamente o ponto.\nO que é BPML # BPML — Business Process Markup Language — é a linguagem baseada em XML na qual um Business Process é realmente escrito por baixo. Cada caixa que você arrasta no designer visual vira um elemento nesse markup; cada seta vira o aninhamento e o sequenciamento desses elementos. Não é um resumo simplificado do processo — é a definição literal e completa que o Business Process Engine executa. Nada roda que não esteja no BPML, incluindo qualquer coisa que o designer visual tenha gerado para você sem perguntar.\nGPM e BPML são a mesma coisa, vistas de formas diferentes # O Graphical Process Modeler (GPM) é a ferramenta que a maioria das pessoas aprende primeiro: arraste um ícone de service para o canvas, conecte-o à próxima etapa, e a ferramenta constrói o processo visualmente. O que é fácil de não perceber no início é que o GPM não é uma forma separada e simplificada de construir um Business Process — é um tradutor em tempo real. A própria documentação da IBM o descreve como uma ferramenta de interface gráfica implantada via web, usada para criar e modificar Business Processes (Documentação IBM), e por baixo dos panos ela converte cada modelo gráfico que você constrói diretamente em BPML — e da mesma forma converte BPML existente de volta para o diagrama, deixando você alternar entre as duas visões do mesmo processo a qualquer momento.\nEssa reversibilidade é a parte que vale a pena internalizar: nada se perde ao ir do diagrama para o código ou vice-versa. Um Business Process construído inteiramente arrastando ícones e um Business Process digitado à mão em um editor de texto são funcionalmente idênticos depois de salvos — o motor não sabe nem se importa qual dos dois você usou.\nOs elementos de BPML que você realmente vai usar # O BPML tem um vocabulário razoavelmente grande, mas um punhado de elementos cobre a esmagadora maioria do que você vai ler e escrever:\nOPERATION. O elemento cavalo de batalha — este é o componente BPML usado para chamar um service ou adapter de dentro de um Business Process (Documentação IBM). Todo ícone que você arrasta no GPM representando um service ou adapter é compilado para uma OPERATION por baixo. Se você está procurando onde um service específico é invocado, você está procurando um bloco OPERATION.\nSEQUENCE. O elemento estrutural que diz \u0026ldquo;essas etapas acontecem nesta ordem.\u0026rdquo; A maior parte de um Business Process é uma grande SEQUENCE com outros elementos aninhados dentro dela — é o esqueleto no qual tudo o mais se pendura.\nCHOICE. Ramificação condicional — faça isso se uma condição for verdadeira, faça outra coisa se não for. É aqui que normalmente mora a lógica de roteamento específica por parceiro: \u0026ldquo;se o trading partner for X, use o map A; senão, use o map B.\u0026rdquo;\nASSIGN. Move dados entre a memória de trabalho do Business Process e os parâmetros de entrada ou saída de um service. Nada glamouroso, mas é aqui que uma grande fatia dos bugs de \u0026ldquo;o map pegou o campo errado\u0026rdquo; realmente se origina — não no map em si, mas em um ASSIGN que apontou para o pedaço de dado errado.\nONFAULT. Tratamento de erros. Quando uma etapa dentro de uma SEQUENCE falha, um bloco ONFAULT permite capturar essa falha e fazer algo deliberado a respeito — tentar de novo, notificar, rotear para uma mailbox de dead-letter — em vez de deixar o processo morrer silenciosamente. Um Business Process sem tratamento ONFAULT não está exatamente errado, mas é o motivo mais comum de \u0026ldquo;o arquivo simplesmente sumiu\u0026rdquo; virar uma investigação longa.\nCenários: lendo e escrevendo BPML na prática # Cenário 1 — Construindo um novo Business Process de entrada do zero. Este é o terreno natural do GPM: arraste um ícone de adapter, arraste um service de validação, arraste um service de mapeamento, conecte tudo, salve. Para um primeiro rascunho, a ferramenta visual é mais rápida do que digitar BPML à mão, e é muito mais difícil produzir XML inválido por acidente.\nCenário 2 — O GPM está lento ou indisponível, e um processo precisa de um pequeno ajuste agora. É exatamente esse o momento que aquele engenheiro sênior estava demonstrando. Abrir o arquivo .bpml diretamente em um editor de texto, encontrar o bloco OPERATION ou ASSIGN em questão, e editá-lo à mão é totalmente válido — o motor não se importa com como o arquivo foi produzido. Estar confortável lendo BPML bruto transforma \u0026ldquo;eu preciso que o GPM carregue\u0026rdquo; em \u0026ldquo;eu preciso de um editor de texto\u0026rdquo;, o que importa mais do que parece durante um incidente de verdade.\nCenário 3 — A mesma pequena mudança precisa entrar em cinquenta Business Processes. Clicar em cinquenta processos no GPM, um de cada vez, é uma tarde ruim. Rodar um script de busca-e-substituição em cinquenta arquivos .bpml não é. Este é o cenário onde saber BPML não é só uma habilidade de debugging — é a diferença entre uma hora de trabalho e uma semana dele.\nCenário 4 — Um processo está falhando e ninguém sabe onde. Comece pelos blocos ONFAULT — ou pela falta deles. Se uma SEQUENCE não tem tratamento de erro em volta da etapa que está falhando, esse geralmente é o conserto mais rápido disponível: envolva a etapa, registre o que de fato falhou, e a próxima falha se explica sozinha em vez de exigir outra investigação do zero.\nPor que a distinção realmente importa # O GPM é a ferramenta melhor para construir e entender a forma de um processo — a visão de caixas e setas deixa o fluxo geral óbvio de um jeito que tags XML aninhadas não conseguem. O BPML bruto é a ferramenta melhor para precisão, mudanças em massa, e qualquer coisa que precise acontecer quando a ferramenta visual está lenta, indisponível, ou simplesmente é exagero para um ajuste de duas linhas.\nNenhum dos dois é o Business Process \u0026ldquo;de verdade\u0026rdquo; e o outro um atalho. São a mesma definição, e qual usar depende inteiramente do que você está tentando fazer naquele momento — construir algo novo, ou consertar algo específico, rápido.\nOnde isso se encaixa no quadro geral # Toda chamada de adapter e service da Parte 1 e da Parte 2 acontece porque o BPML de um Business Process disse ao motor para fazer isso acontecer, nessa ordem, com aquele tratamento de erro. O GPM e o BPML bruto são só duas portas para editar o mesmo arquivo:\nflowchart TB subgraph Authoring[\"Duas Formas de Entrada\"] GPM[\"Graphical Process Modeler(arrastar, conectar, alternar visão)\"] TXT[\"Editor de Texto(editar .bpml diretamente)\"] end BPML[(\"BPML(a definição de fato)\")] ENGINE[\"Business Process Engine\"] GPM \u003c--\u003e|gera / renderiza| BPML TXT \u003c--\u003e|lê / escreve| BPML BPML --\u003e ENGINE ENGINE --\u003e OP1[\"OPERATION(chama um Adapter)\"] ENGINE --\u003e OP2[\"OPERATION(chama um Service)\"] ENGINE --\u003e CH[\"CHOICE(ramificação)\"] ENGINE --\u003e OF[\"ONFAULT(trata falha)\"] Os dois caminhos de autoria convergem exatamente para o mesmo BPML, e o motor que de fato o executa não tem ideia — nem motivo para se importar — de qual porta você usou.\nFontes e leituras complementares # Graphical Process Modeler BPML Business Process Components Business Processes Add error handling to a Business Process IBM Support: Business Process does not invoke any OnFault when a service fails with error Como no resto desta série, o enquadramento, os cenários e as histórias de guerra são meus — as definições e o comportamento dos elementos de BPML são da IBM.\nO que vem a seguir # A seguir: SFTP: O Protocolo Por Trás do Adapter — um olhar mais de perto sobre o transporte, a autenticação e a mecânica de chaves por trás do SFTP Server Adapter configurado na Parte 2.\n","date":"06/09/2026","externalUrl":null,"permalink":"/pt-br/posts/sterling-b2bi-03-business-processes-bpml/","section":"Posts","summary":"O que é um Business Process # Um Business Process é o fluxo de trabalho que encadeia adapters e services em algo que de fato realiza uma tarefa: receber um arquivo, validá-lo, mapeá-lo, criptografá-lo, entregá-lo a um adapter para envio, registrando cada etapa pelo caminho. É a coisa que a Parte 1 chamou de “a coisa mais parecida com um coração que a plataforma tem” — porque quase nada relevante acontece no Sterling B2B Integrator fora da execução de um deles.\n","title":"Business Processes e BPML no IBM Sterling B2B Integrator: Duas Visões do Mesmo Motor","type":"posts"},{"content":" O que é um Adapter # Um Adapter é um service cujo trabalho inteiro é alcançar o mundo fora do Sterling B2B Integrator — conectando o Business Process Engine a \u0026ldquo;sistemas e aplicações diferentes\u0026rdquo; que vivem fora do ambiente (Documentação IBM). Um adapter SFTP abre uma conexão com o servidor SFTP de um parceiro. Um adapter AS2 fala o protocolo AS2 com o gateway de um parceiro comercial. O mecanismo por baixo é o mesmo de qualquer outro service — o Business Process Engine o chama, ele executa, retorna um resultado — mas o trabalho em si acontece em outro lugar, através de uma rede, contra um sistema que você não controla.\nO que é um Service # Um Service é a categoria ampla: qualquer conjunto de instruções que o Business Process Engine usa para realizar uma atividade dentro de um Business Process. Isso é propositalmente amplo — services cobrem desde mapear um documento de um formato para outro, validar um campo contra um schema, criptografar um payload, checar uma condição e ramificar, até pausar um processo para esperar que uma pessoa clique em \u0026ldquo;aprovar\u0026rdquo; em um formulário web.\nO fio que conecta tudo isso é que um service faz seu trabalho usando dados que o Business Process já tem, ou produz dados que o Business Process vai usar em seguida. Ele não precisa sair do sistema para fazer o seu trabalho.\nJuntando os dois você tem a distinção inteira em uma linha: todo adapter é um service, mas nem todo service é um adapter. Vale a pena parar para pensar nisso, porque isso explica quase toda conversa confusa que você vai ter sobre essa plataforma.\nExiste uma divisão em três partes que vale a pena conhecer, porque ela aparece o tempo todo assim que você começa a ler logs de Business Process: services internos processam parâmetros e produzem resultados sem nunca sair do sistema; adapters de entrada e saída são os que alcançam o mundo externo; e existe uma categoria separada, os services de interação humana, que existem puramente para pausar um processo até que uma pessoa aja, tipicamente através de um navegador web aprovando ou rejeitando uma etapa. Essa última categoria é a que mais confunde as pessoas, porque tecnicamente \u0026ldquo;é só um service\u0026rdquo;, mas se comporta de um jeito completamente diferente dos services de mapeamento e validação que as pessoas imaginam por padrão.\nUm único node em um ambiente real facilmente chega à casa das centenas de services registrados quando você conta cada adapter, tradutor e service utilitário instalado — este é um único node em uma implantação de porte produtivo:\n444 services em um único node — a maioria deles você nunca vai tocar diretamente Os adapters que você realmente vai usar # O Sterling vem com dezenas de adapters, mas na prática a maioria das implantações se apoia em um punhado deles, repetidamente, porque a maioria dos requisitos de parceiro comercial se resume a um punhado de protocolos:\nSFTP Adapter (Client e Server). A escolha padrão para novas conexões de parceiro quando ninguém está ditando o contrário. É criptografado, quase toda equipe de TI de parceiro já sabe como configurar um, e o esforço de setup é baixo comparado ao AS2. Eu recorro ao SFTP primeiro, a menos que a equipe de segurança ou compliance do próprio parceiro exija especificamente outra coisa. Aqui está uma configuração real de SFTP Client Adapter — repare como há pouca coisa nela de fato: um nome de sistema, um ambiente, uma atribuição de perimeter server e limites de threads:\nSFTP Client Adapter 2.0 — uma configuração mínima, majoritariamente com valores padrão O adapter do lado Server carrega uma superfície bem maior, porque agora é você quem está sendo conectado: porta de escuta, chave de identidade do host, preferências de cifra e MAC, requisitos de autenticação e roteamento de mailbox, tudo mora aqui:\nSFTP Server Adapter 2.0 — este é o lado da conexão contra o qual os parceiros de fato se autenticam AS2 Adapter. O que você não escolhe — é o que um parceiro impõe. O AS2 é construído em torno de mensagens assinadas e criptografadas com Message Disposition Notifications (MDNs), que dão aos dois lados um recibo criptográfico provando que um arquivo chegou intacto. Esse recibo é exatamente o motivo pelo qual grandes varejistas, redes de logística e qualquer um que rode EDI em escala tende a exigi-lo: quando surge uma disputa sobre se um pedido de compra foi realmente entregue, o MDN resolve a questão. O custo é o setup — certificados, perfis de parceiro e configuração de MDN precisam bater exatamente dos dois lados, e um certificado incompatível é, de longe, a dor de cabeça mais comum que já enfrentei em onboarding de AS2.\nConnect:Direct Adapter. Esse é o que as pessoas subestimam até precisarem dele. O Connect:Direct é construído para entrega garantida, com retomada por checkpoint, de arquivos grandes entre sistemas que não podem tolerar uma transferência falha precisando recomeçar do byte zero — pense em arquivos de batch de fim de dia entre bancos, ou arquivos de múltiplos gigabytes em logística e manufatura. Se uma transferência cai em 80%, o Connect:Direct retoma a partir de 80%, não do zero. Esse único recurso é o motivo pelo qual ele ainda é padrão em finanças e outros ambientes corporativos de alto volume, custo de licença e tudo.\nHTTP/HTTPS Client Adapter. O adapter para integrações modernas, no estilo de API — chamando o endpoint REST de um parceiro, recebendo um callback estilo webhook, ou conversando com microsserviços internos em vez de um mainframe legado. É o que mais cresceu em relevância à medida que mais ecossistemas de parceiros comerciais migram da troca pura de arquivos em batch para APIs de request/response.\nFTP Adapter. Ainda por aí, ainda funcionando, e geralmente o adapter do qual eu tento migrar os parceiros para longe quando tenho a chance — o FTP puro envia credenciais e dados sem criptografia, a menos que seja tunelado por algo. Ele sobrevive basicamente por inércia legada, não porque alguém o escolheria hoje.\nCommand Line Adapter 2 (CLA2). A válvula de escape. Quando um Business Process precisa repassar a tarefa para um script de verdade ou um executável legado anterior à plataforma, o CLA2 é a ponte — genuinamente útil, mas também geralmente um sinal de que alguma coisa upstream nunca foi devidamente re-plataformada.\nOs services que você realmente vai usar # Menos categorias aqui, mas elas aparecem em praticamente todo Business Process, independentemente de quais adapters estejam envolvidos:\nServices de Tradução / EDI (X12, EDIFACT e similares). Convertem o envelope EDI bruto de um parceiro em algo com o qual o resto do processo — e seus sistemas downstream — consegue de fato trabalhar, e de volta ao formato original na saída. Se a sua organização faz qualquer EDI, um desses roda em quase todo documento de entrada e saída.\nServices de Mapeamento, construídos no Map Editor. É onde a tradução campo a campo de fato acontece: do formato do parceiro para o seu formato interno, ou o inverso. É aqui que a maioria das investigações de \u0026ldquo;por que esse documento falhou\u0026rdquo; acaba, porque um map só lida com os formatos de dado para os quais foi construído e testado — um campo inesperado, um novo valor de código, ou um parceiro mudando silenciosamente o formato dele é um problema de map, não de conectividade.\nServices de Validação. Verificam um documento contra um schema ou um conjunto de regras de negócio antes que qualquer coisa downstream confie nele. Um seguro barato: pegar um documento malformado aqui é bem menos doloroso do que pegá-lo três sistemas adiante.\nServices de Criptografia/Descriptografia, mais comumente PGP. Muitos parceiros exigem arquivos criptografados em PGP independentemente de qual transporte os carrega, já que a criptografia de transporte (como o próprio TLS do SFTP ou do AS2) só protege o dado em trânsito — o PGP protege o arquivo em si, inclusive enquanto ele está parado em uma mailbox esperando para ser retirado.\nServices de Interação Humana. O caso fora da curva, e vale a pena se acostumar em vez de ficar confuso com ele. Eles são genuinamente um service pela própria definição da plataforma, mas o trabalho inteiro deles é pausar um processo até que uma pessoa clique em aprovar ou rejeitar em um formulário web — útil para qualquer coisa que precise de uma etapa de revisão manual, como uma fatura anormalmente grande ou o primeiro documento de um parceiro novo.\nServices operacionais que vale a pena conhecer # Nem todo service toca o documento de um parceiro comercial. Uma parte dessa lista de 444 services é pura manutenção interna da plataforma — services que mantêm o próprio sistema saudável, em vez de mover o arquivo de alguém. Dois valem a pena conhecer pelo nome:\nAlert Service. Propositalmente mínimo — o trabalho inteiro dele é checar seus workflows e disparar um alerta quando algo precisa de atenção. Geralmente é uma das primeiras coisas configuradas em um ambiente novo, porque \u0026ldquo;quebrou alguma coisa durante a noite\u0026rdquo; precisa de uma resposta que não dependa de alguém checar logs manualmente.\nAlert Service — pequeno de propósito, e geralmente um dos primeiros services configurados em um ambiente novo BackupService. Roda em um horário programado (2h da manhã na maioria dos ambientes que já vi) para arquivar dados de Business Process concluídos ou encerrados em blocos, para que o database da Parte 1 não cresça para sempre. Se você já se perguntou como o histórico de rastreamento de documentos continua consultável por meses sem o database cair, esse service — e os números de archive/purge/index naquele dashboard de Database Usage — é a resposta.\nBackupService — o motivo pelo qual seu histórico de Business Process não cresce para sempre Cenários: adapters no mundo real # Definições só te levam até certo ponto. Aqui está como a escolha de adapter realmente se desenrola em algumas situações reais:\nCenário 1 — Um novo parceiro quer te enviar arquivos planos, sem requisitos especiais. Padrão: SFTP. Configure um SFTP Server Adapter (ou reaproveite um existente — a maioria dos ambientes roda um server adapter compartilhado entre muitos parceiros, distinguidos por mailbox e credenciais em vez de um adapter para cada um), emita uma chave ou senha para o parceiro, e roteie os arquivos de entrada dele para uma mailbox dedicada. Esse é o caminho de onboarding de parceiro mais rápido de toda a plataforma, geralmente resolvido no mesmo dia.\nCenário 2 — Um parceiro varejista exige AS2 com recibos MDN no acordo de parceria comercial. Sem escolha aqui — configure um adapter AS2, troque certificados com o parceiro (os dele e os seus, nas duas direções), e garanta que as configurações de MDN (síncrono vs. assíncrono, assinado vs. não assinado) batam exatamente com o que está no acordo. Reserve tempo de verdade para isso; certificados incompatíveis são o motivo mais comum de um onboarding de AS2 estourar a estimativa.\nCenário 3 — Um banco precisa de entrega garantida de um arquivo de liquidação noturno de múltiplos gigabytes, e uma transferência falha não pode recomeçar do zero. Esse é exatamente o motivo de existir do Connect:Direct. Configure o adapter Connect:Direct com checkpoint restart habilitado, e uma transferência que cai em 2GB de um arquivo de 5GB retoma a partir de 2GB em vez de recomeçar — o que importa muito quando o arquivo precisa chegar antes que a janela de batch feche.\nCenário 4 — Parceiros ficam perguntando \u0026ldquo;meu arquivo chegou?\u0026rdquo;, e você está cansado de checar manualmente. Isso não é um adapter novo — é conectar o Alert Service aos Business Processes que importam, para que um estado de falha dispare uma notificação em vez de ficar parado silenciosamente até que alguém vá procurar. Combine isso com o rastreamento de documentos (da Parte 1) e a maioria das perguntas de \u0026ldquo;chegou?\u0026rdquo; é respondida antes mesmo de alguém precisar perguntar.\nPor que a distinção realmente importa # Aqui está a parte fácil de deixar passar até que ela te custe tempo: adapters e services falham de formas diferentes, e são diagnosticados em lugares diferentes.\nUma falha de adapter é quase sempre sobre o mundo externo — o servidor de um parceiro está fora do ar, um certificado expirou, uma regra de firewall mudou, um caminho de rede foi bloqueado. Você resolve checando conectividade, credenciais e o lado do parceiro no handshake. O Business Process em si geralmente é inocente; ele só está esperando por uma porta que não abre.\nUma falha de service é quase sempre sobre o dado. Um map engasgou em um campo inesperado. Uma regra de validação rejeitou algo que antes passava. Uma condição ramificou para um lado que ninguém esperava. Você resolve olhando para o documento real que está passando pelo processo, não para configurações de conectividade.\nConfunda os dois e você acaba fazendo exatamente o que eu fiz naquele primeiro projeto: checando configurações de rede para um problema de dado, ou destrinchando um map para um problema que na verdade era o timeout do servidor de um parceiro. A pergunta de diagnóstico mais rápida que conheço para incidentes no Sterling é simplesmente: \u0026ldquo;isso falhou tentando alcançar algo fora do sistema, ou trabalhando em um dado que já estava dentro dele?\u0026rdquo; Só essa pergunta te encaminha para a metade certa do Business Process quase sempre.\nOnde isso se encaixa no quadro geral # Adapters ficam nas duas bordas do fluxo da Parte 1 — recebendo um arquivo de um Perimeter Server na entrada, ou entregando um arquivo a um parceiro na saída. Services ficam no meio, fazendo tudo o que acontece com um arquivo depois que ele já está dentro dos muros: mapear, validar, rotear, ocasionalmente esperar por um humano. Um Business Process é, na prática, apenas uma sequência de chamadas para os dois, com lógica de ramificação costurando tudo junto.\nflowchart LR subgraph Outside[\"Fora do Sistema\"] Partner[\"Parceiro Comercial\"] end subgraph BP[\"Business Process\"] direction TB A1[\"Adapter de Entrada(SFTP / AS2 / HTTP)\"] S1[\"ServiceValidar\"] S2[\"ServiceMapear\"] S3[\"Service de Interação Humana(etapa de aprovação opcional)\"] A2[\"Adapter de Saída(SFTP / AS2 / Connect:Direct)\"] A1 --\u003e S1 --\u003e S2 --\u003e S3 --\u003e A2 end Partner --\u003e|arquivo de entrada| A1 A2 --\u003e|arquivo de saída| Partner classDef adapter fill:#0f62fe,color:#fff,stroke:#0f62fe classDef service fill:#393939,color:#fff,stroke:#393939 class A1,A2 adapter class S1,S2,S3 service Azul é \u0026ldquo;sai do sistema.\u0026rdquo; Cinza é \u0026ldquo;fica por dentro.\u0026rdquo; Quando algo quebra, essa cor é a primeira coisa que eu checo.\nFontes e leituras complementares # Sterling B2B Integrator — Services and Adapters Sterling B2B Integrator — Services and Adapters (A–L) Sterling B2B Integrator — Services and Adapters (M–Z) Business Processes Visão geral do Command Line Adapter 2 (CLA2) File transfer capabilities and integration with IBM Sterling B2B Integrator Como na Parte 1, o enquadramento, as recomendações e as histórias de guerra são minhas — as definições são da IBM, e as capturas de tela são do meu próprio ambiente.\nO que vem a seguir # A seguir: Business Processes e BPML — o motor de workflow de fato que amarra cada chamada de adapter e service, e por que o Graphical Process Modeler visual e o BPML bruto por baixo dele valem a pena serem entendidos como duas visões da mesma coisa, não duas ferramentas separadas.\n","date":"05/09/2026","externalUrl":null,"permalink":"/pt-br/posts/sterling-b2bi-02-adapters-vs-services/","section":"Posts","summary":"O que é um Adapter # Um Adapter é um service cujo trabalho inteiro é alcançar o mundo fora do Sterling B2B Integrator — conectando o Business Process Engine a “sistemas e aplicações diferentes” que vivem fora do ambiente (Documentação IBM). Um adapter SFTP abre uma conexão com o servidor SFTP de um parceiro. Um adapter AS2 fala o protocolo AS2 com o gateway de um parceiro comercial. O mecanismo por baixo é o mesmo de qualquer outro service — o Business Process Engine o chama, ele executa, retorna um resultado — mas o trabalho em si acontece em outro lugar, através de uma rede, contra um sistema que você não controla.\n","title":"IBM Sterling B2B Integrator: Adapters vs. Services — A Distinção Que Realmente Importa","type":"posts"},{"content":"A página inicial do console de administração — onde toda sessão começa O que é o IBM B2Bi # O IBM Sterling B2B Integrator faz um trabalho: mover arquivos entre a sua empresa e seus parceiros comerciais — bancos, fornecedores, transportadoras, quem quer que precise trocar documentos EDI, arquivos planos ou XML de forma confiável e rastreável — e saber exatamente o que aconteceu com cada arquivo em cada etapa. Só isso. Tudo o mais existe para sustentar esse único trabalho.\nA própria visão geral da IBM coloca isso de forma direta: o B2Bi é construído para gerenciar \u0026ldquo;as dinâmicas técnicas e humanas dos relacionamentos entre parceiros de negócio\u0026rdquo; (Documentação IBM). Na prática, \u0026ldquo;dinâmicas técnicas e humanas\u0026rdquo; significa que o software precisa tolerar parceiros que enviam arquivos malformados, mudam os dados de conexão sem aviso e, ocasionalmente, somem por uma semana durante as festas de fim de ano — enquanto a sua trilha de auditoria continua precisando se sustentar.\nComponentes do IBM B2Bi # Decorar uma lista de componentes nunca funcionou para mim, mas rastrear um arquivo do início ao fim funcionou. Para dar uma ideia da escala, aqui está a árvore completa do menu de administração — tudo abaixo é um ramo dela:\nO menu de administração completo — Business Processes, Trading Partner, Deployment, EBICS e Operations Perimeter Server # A conexão de um parceiro não chega direto ao motor principal (core engine). Ela cai em um Perimeter Server que fica na DMZ, responsável por fazer o handshake de protocolo de fato (SFTP, AS2, HTTP) e encaminhar o tráfego para dentro por um canal seguro. A maioria do material introdutório ignora isso completamente, o que é uma pena, porque é exatamente o motivo pelo qual você consegue expor endpoints voltados a parceiros sem nunca colocar o seu motor principal perto da internet pública. Se você já se perguntou por que um diagrama de implantação do Sterling tem caixas fora do firewall, é por isso — e o assunto merece um post próprio mais adiante nesta série: a Parte 6 cobre exatamente como essa caixa na DMZ conversa com o motor principal.\nAdapters # A partir daí, um Adapter assume. Adapters são propositalmente estreitos em escopo — SFTP, AS2, Connect:Direct, HTTP/S, JDBC e mais algumas dezenas — e cada um faz exatamente uma coisa: receber ou enviar um arquivo pelo seu protocolo específico, e então entregá-lo a um Business Process.\nUma lista real de adapters — é assim que \u0026rsquo;estreito por design\u0026rsquo; se parece na prática Business Process # É nessa passagem de bastão que as coisas ficam interessantes. Um Business Process é um fluxo de trabalho — modelado visualmente no Graphical Process Modeler, armazenado por baixo em BPML (Business Process Markup Language) — que encadeia etapas: validar isso, mapear aquilo, criptografar isso, rotear, avisar alguém se der errado. Praticamente tudo que importa no B2Bi acontece dentro de um Business Process. É a coisa mais parecida com um coração que a plataforma tem.\n807 Business Processes em um único ambiente — e esse é um ambiente modesto Services # Dentro desse processo, os Services fazem o trabalho interno — mapeamento, validação, extração, compressão, lógica customizada — enquanto os Adapters continuam cuidando do mundo externo. Um Business Process, resumido ao essencial, é basicamente uma sequência de chamadas de Adapter e Service, com ramificações para quando algo dá errado (e em produção, algo sempre acaba dando errado).\nOs Services são organizados em categorias assim — EDI, Translation e Transport cobrem a maior parte do que um Business Process realmente faz Map # Em algum ponto dessa sequência, um Map normalmente entra em ação. Parceiros quase nunca enviam os dados no formato que você realmente precisa — EDI para XML, arquivo plano para JSON, o que quer que o sistema downstream espere — e essa tradução acontece no Map Editor, que é profundo o suficiente para merecer seu próprio post mais adiante nesta série. Não estou exagerando quando digo que alguns dos bugs mais complicados que já persegui começaram como \u0026ldquo;o map fez alguma coisa estranha com um campo nulo\u0026rdquo;.\nUma biblioteca real de maps — só esse ambiente já tem quase mil deles Mailbox # O arquivo geralmente cai em uma Mailbox — uma caixa de entrega segura e com permissões dentro do B2Bi. É aqui que vejo mais confusão, mesmo entre quem usa o Sterling há anos: o File Gateway não é um produto separado concorrendo com o B2Bi. É uma camada de UI e roteamento construída especificamente sobre a estrutura de mailbox e adapters do B2Bi, feita justamente para que a troca de arquivos com parceiros possa ser gerenciada sem que ninguém precise mexer diretamente em BPML (vale a pena ler a visão geral do File Gateway da IBM se isso for novidade para você).\nUma árvore de mailboxes típica — pontos de coleta de EDI compartilhados mais uma mailbox por parceiro comercial Database # E por baixo de tudo isso está o Database — o estado de cada Business Process, o histórico de rastreamento de cada documento, a trilha de auditoria completa. Fácil de dar como garantido até a sua primeira interrupção real, quando os dados de rastreamento de documentos se tornam o único registro honesto do que de fato aconteceu com um arquivo. Já reconstruí mais de uma linha do tempo de incidente usando só essa tabela.\nO dashboard de uso do Database — capacidade, fila de pendências e saúde do pool de conexões em um só lugar Para ambientes de produção que não toleram indisponibilidade, o B2Bi também suporta Clustering multi-node — vale saber que existe, ainda que não seja algo que você precise no primeiro dia.\nDesenho da topologia # Aqui está a arquitetura em uma única imagem:\nflowchart TB subgraph Partners[\"Parceiros Comerciais\"] P1[\"Parceiro A\"] P2[\"Parceiro B\"] end subgraph DMZ[\"DMZ\"] PS[\"Perimeter Server\"] end subgraph Core[\"Núcleo do B2B Integrator\"] AD[\"AdaptersSFTP / AS2 / Connect:Direct / HTTP\"] BP[\"Business Processes(Motor BPML)\"] SV[\"ServicesMapeamento / Validação / Roteamento\"] MB[\"Mailboxes\"] FG[\"File Gateway(camada de UI sobre as Mailboxes)\"] end DB[(\"DatabaseRastreamento de Documentos \u0026 Estado\")] P1 --\u003e PS P2 --\u003e PS PS --\u003e AD AD --\u003e BP BP --\u003e SV SV --\u003e MB FG -.gerencia.-\u003e MB BP \u003c--\u003e DB MB \u003c--\u003e DB E aqui está a mesma ideia como uma linha do tempo, já que um diagrama estático não captura bem que tudo isso acontece como uma sequência de passagens de bastão discretas — útil quando você está tentando descobrir qual log checar primeiro:\nsequenceDiagram participant Partner as Parceiro participant PS as Perimeter Server participant AD as Adapter participant BP as Business Process participant MB as Mailbox participant DB as Database Partner-\u003e\u003ePS: Conecta (SFTP/AS2/HTTP) PS-\u003e\u003eAD: Encaminha arquivo por canal seguro AD-\u003e\u003eBP: Dispara o Business Process BP-\u003e\u003eBP: Executa Services (mapear, validar, rotear) BP-\u003e\u003eDB: Registra o estado de rastreamento do documento BP-\u003e\u003eMB: Entrega o arquivo MB-\u003e\u003eDB: Registra o status de entrega Note over Partner,DB: Cada seta acima é um pontoonde o arquivo pode falhar — e um lugaronde o rastreamento de documentos vai mostrar o motivo Essa nota no final é, na verdade, o ponto central deste post inteiro: uma vez que você consegue visualizar o caminho real do arquivo, a resolução de problemas deixa de ser tentativa e erro. Você simplesmente percorre o diagrama de trás para frente, a partir de onde o arquivo parou.\nFontes # Prefiro te direcionar para a documentação oficial da IBM do que parafraseá-la mal, então aqui está o que usei como base para este post — todas páginas oficiais da Documentação IBM, que vale a pena salvar independentemente de você acompanhar esta série:\nSterling B2B Integrator — Visão Geral Visão Geral Arquitetural Perimeter servers no Sterling B2B Integrator Business Processes Sterling File Gateway — Visão Geral Criando uma Mailbox do Sterling B2B Integrator Tudo o mais neste post — o enquadramento, o conselho de \u0026ldquo;qual log checar primeiro\u0026rdquo;, as histórias de guerra — vem de realmente operar isso em produção nos últimos anos, não de um manual.\nO que vem a seguir # A seguir nesta série: Adapters vs. Services — a distinção que confunde quase todo mundo nas primeiras semanas com o Sterling, e a que mais importa quando você está resolvendo um problema às 2 da manhã.\n","date":"04/09/2026","externalUrl":null,"permalink":"/pt-br/posts/sterling-b2bi-01-overview/","section":"Posts","summary":"A página inicial do console de administração — onde toda sessão começa O que é o IBM B2Bi # O IBM Sterling B2B Integrator faz um trabalho: mover arquivos entre a sua empresa e seus parceiros comerciais — bancos, fornecedores, transportadoras, quem quer que precise trocar documentos EDI, arquivos planos ou XML de forma confiável e rastreável — e saber exatamente o que aconteceu com cada arquivo em cada etapa. Só isso. Tudo o mais existe para sustentar esse único trabalho.\n","title":"IBM Sterling B2B Integrator: Uma Visão Geral Rápida da Arquitetura","type":"posts"},{"content":"","externalUrl":null,"permalink":"/pt-br/authors/","section":"Authors","summary":"","title":"Authors","type":"authors"},{"content":"Engenheiro sênior de Middleware \u0026amp; Infraestrutura com mais de 15 anos em TI corporativa, especializado em Managed File Transfer IBM Sterling (File Gateway, B2B Integrator, Connect:Direct), administração de sistemas Linux e infraestrutura em nuvem AWS/Azure. Nos últimos cinco anos, atuação prática sustentando ambientes de MFT críticos para o negócio de uma operadora de telecomunicações da Fortune 500, em modelos de produção 24x7 e follow-the-sun.\nMeu LinkedIn Experiência Profissional # Engenheiro Sênior de Middleware Mai 2024 – Presente DXC Technology dxc.com\nLidero o suporte de middleware para uma plataforma de Managed File Transfer crítica para o negócio, atendendo a base de clientes dos EUA de uma operadora de telecom da Fortune 500, sobre IBM Sterling File Gateway, B2B Integrator e Connect:Direct para UNIX. Atuo como líder de equipe — coordenando prioridades, escalonamentos e resposta a incidentes, conduzindo análise de causa raiz para interrupções críticas dentro do SLA. Administro onboarding de parceiros, processos de mudança/incidente no ServiceNow e recuperação de desastres. Automatizei verificações de saúde do Linux com Bash, economizando cerca de 5 horas/semana de esforço manual e reduzindo em 20% a latência de consultas. Construí dashboards em Power BI sobre volume de chamados, carga de plantão e horas extras para visibilidade da liderança, e trabalho diretamente com o Suporte IBM em investigações a nível de produto.\nAdministrador de Sistemas de Middleware Dez 2021 – Mai 2024 Kyndryl kyndryl.com\nAdministrei a mesma stack IBM Sterling File Gateway / B2B Integrator / Connect:Direct para o mesmo cliente de telecom, além da infraestrutura Azure (Máquinas Virtuais, Storage Accounts, Backup, Network Security Groups, Bastion hosts). Investiguei falhas de transferência de arquivos via logs do Sterling e diagnóstico de protocolos, conduzi análise de causa raiz em incidentes de produção e mantive 99,9% de disponibilidade por meio de exercícios de DR e cobertura de plantão 24x7. Redigi runbooks e liderei sessões de transferência de conhecimento que reduziram em 30% o tempo de onboarding de novos engenheiros.\nTécnico Sênior de Data Center Jul 2018 – Jul 2021 Amazon Web Services aws.amazon.com\nLiderei uma equipe de desativação de hardware, retirando mais de 1.000 racks legados em todas as unidades da empresa, sob procedimentos rígidos de segurança e proteção de dados, contribuindo para a expansão da infraestrutura global de nuvem da Amazon. Entreguei projetos de implantação de data center de ponta a ponta, conduzi entrevistas técnicas e construí o banco de perguntas de entrevista e o programa de treinamento de novos contratados usado nas contratações.\nTécnico de Data Center Jun 2016 – Jul 2018 Amazon Web Services aws.amazon.com\nInstalei, mantive e reparei hardware de servidores e rede de alta densidade; instalei e testei cabeamento de fibra óptica e cobre; diagnostiquei problemas de hardware em Red Hat Enterprise Linux e Amazon Linux; resolvi chamados operacionais dentro de prioridades rígidas de SLA.\nAdministrador de Redes Jun 2013 – Mai 2016 Acrisure Brasil acrisure.com.br\nAdministrei infraestrutura on-premises e AWS (EC2, RDS, S3, Route 53, VPC, Security Groups, CloudWatch, CloudFront) em 10 unidades corporativas no Brasil. Liderei uma equipe de quatro analistas de suporte e a migração do e-mail corporativo para o Google Workspace, melhorando em 25% o tempo médio de resolução de chamados.\nAnalista de Suporte Sênior Jun 2011 – Jun 2013 Acrisure Brasil acrisure.com.br\nPrestei suporte de infraestrutura em nível 2, administrei contas e permissões de Active Directory, dei suporte a ambientes Windows Server e orientei analistas juniores.\nAnalista de Suporte Técnico Nov 2009 – Jun 2011 Hypera hypera.com.br\nDei suporte a redes de escritório, switches, servidores de impressão e processos de incidentes e solicitações de serviço baseados em ITIL.\nCertificações # AWS Certified Cloud Practitioner Microsoft Certified: Azure Fundamentals Claude Certified Associate – Foundations (CCAF), Anthropic — Emitida em Set 2026 Ver todos os selos no Credly\nFormação Acadêmica # Pós-graduação em Gestão de Projetos — Gran Faculdade (Out 2024 – Mar 2026) Pós-graduação em Cloud Computing — Centro Universitário Senac (Jan 2018 – Dez 2019) Tecnólogo em Redes de Computadores — Centro Universitário UniSant\u0026rsquo;Anna (Fev 2008 – Dez 2010) Idiomas # Português (nativo) · Inglês (fluente) · Espanhol (intermediário)\n","externalUrl":null,"permalink":"/pt-br/resume/","section":"Newton Rocha","summary":"Engenheiro sênior de Middleware \u0026 Infraestrutura com mais de 15 anos em TI corporativa, especializado em Managed File Transfer IBM Sterling (File Gateway, B2B Integrator, Connect:Direct), administração de sistemas Linux e infraestrutura em nuvem AWS/Azure. Nos últimos cinco anos, atuação prática sustentando ambientes de MFT críticos para o negócio de uma operadora de telecomunicações da Fortune 500, em modelos de produção 24x7 e follow-the-sun.\n","title":"Currículo","type":"page"}]