Guia Definitivo CCA-F: Tudo sobre a Primeira Certificação Oficial da Anthropic

# Guia Definitivo CCA-F: Tudo sobre a Primeira Certificação Oficial da Anthropic

O que é a CCA-F e por que ela importa

A Claude Certified Architect – Foundations (CCA-F) é a primeira certificação oficial lançada pela Anthropic, a empresa criadora dos modelos Claude. Diferente das certificações tradicionais que testam conhecimento teórico superficial, a CCA-F foi projetada para validar algo muito mais valioso: a capacidade de tomar decisões de arquitetura informadas em aplicações reais com Claude.

Em vez de perguntar "o que é um LLM?", o exame pergunta: dado este cenário de produção com 14 arquivos modificados e feedback inconsistente, como você reestrutura o pipeline de revisão de código? Essa distinção muda tudo. A CCA-F testa julgamento prático, não memorização de conceitos.

Para quem está construindo com as APIs da Anthropic, o Agent SDK, Claude Code ou o Model Context Protocol (MCP), esta certificação representa a primeira chance de demonstrar competência reconhecida oficialmente. Para empresas, é um sinal de qualidade técnica mensurável.

Este guia consolida tudo que você precisa saber: a estrutura exata do exame, os 5 domínios com os 35 task statements detalhados, as 12 questões oficiais com gabarito comentado, os 4 exercícios práticos recomendados pela Anthropic e um mapa de estudo de 4 semanas. A fonte primária é o CCA-F Exam Guide oficial v0.1 (Anthropic, fevereiro de 2025) — o mesmo documento de 40 páginas fornecido pela Anthropic aos candidatos.

Por que a Anthropic criou esta certificação?

A Anthropic não cria produtos por criação. A CCA-F nasceu de uma necessidade real no mercado.

Com Claude sendo adotado em escala por engenheiros e arquitetos para construir sistemas agenticos complexos, surgiu uma lacuna: não havia forma objetiva de distinguir quem entende profundamente as nuances de arquitetura — quando usar hooks vs. instruções de prompt, como passar contexto entre agentes sem perder atribuição, por que tool descriptions importam mais que few-shot examples na seleção de ferramentas — de quem tem apenas familiaridade superficial com a API.

A certificação valida seis áreas de experiência prática:

1. Construção de aplicações agenticas com o Claude Agent SDK, incluindo orquestração multi-agente, delegação a subagentes, integração de ferramentas e lifecycle hooks
2. Configuração e personalização do Claude Code para workflows de equipe usando arquivos CLAUDE.md, Agent Skills, integrações com servidores MCP e modo de planejamento
3. Design de interfaces de ferramentas e recursos MCP (Model Context Protocol) para integração com sistemas backend
4. Engenharia de prompts que produzem saída estruturada confiável, usando JSON schemas, exemplos few-shot e padrões de extração
5. Gerenciamento eficiente do context window em documentos longos, conversas multi-turno e handoffs multi-agente
6. Integração do Claude em pipelines CI/CD para code review automatizado, geração de testes e feedback em pull requests

A versão atual do guia é 0.1, lançada em fevereiro de 2025. É a versão inaugural — estar entre os primeiros certificados tem valor de posicionamento significativo no mercado.

Perfil do Candidato Ideal

Antes de investir no estudo, avalie se você está no perfil certo. A Anthropic descreve o candidato ideal como um arquiteto de soluções que projeta e implementa aplicações de produção com Claude, com 6+ meses de experiência prática construindo com:

• Claude APIs e Agent SDK
• Claude Code
• Model Context Protocol (MCP)
• Entendimento das capacidades E limitações dos LLMs em ambientes de produção

Isso significa: se você usou Claude apenas via interface web ou construiu apenas um chatbot simples com a API, a CCA-F provavelmente vai exigir estudo significativo. Se você já orquestrou agentes, configurou CLAUDE.md, escreveu tool descriptions, ou usou `stop_reason` para controlar loops agenticos, você está próximo do perfil.

O que o exame NÃO exige

Um detalhe importante que elimina ansiedade desnecessária: o exame não testa conhecimentos de fine-tuning ou treinamento de modelos, autenticação e billing da API, infraestrutura de deploy de servidores MCP, arquitetura interna do Claude, Constitutional AI ou RLHF, embedding models, vector databases, computer use, análise de imagens, Streaming API, rate limiting, OAuth ou qualquer configuração específica de cloud provider (AWS, GCP, Azure).

Estrutura do Exame: Formato, Pontuação e Domínios

Formato das Questões

Todas as questões são de múltipla escolha com exatamente 1 resposta correta e 3 distratores (respostas plausíveis para candidatos com conhecimento incompleto). Não há penalidade para resposta errada — questões sem resposta são contadas como incorretas, então sempre responda, mesmo incerto.

Pontuação

• Escala: 100 a 1.000 pontos
• Nota mínima para aprovação: 720
• Score escalado para equalizar dificuldade entre versões do exame

Os 5 Domínios

O exame distribui o conteúdo em 5 domínios com pesos diferentes. D1 tem o maior peso (27%) porque orquestração agentica é onde a maioria dos erros de arquitetura ocorre em produção — e onde as consequências são mais sérias. Implementar um loop agentico incorretamente pode resultar em ações irreversíveis, loops infinitos ou dados corrompidos.

Os Cenários do Exame

O exame usa 6 cenários realistas de produção. Durante a prova, 4 são selecionados aleatoriamente. Cada cenário contextualiza múltiplas questões relacionadas.

Os 6 Cenários Oficiais do Exame

Preparar-se para todos os 6 cenários garante que você esteja pronto para qualquer combinação de 4 que apareça na sua prova.

Cenário 1: Agente de Resolução de Suporte ao Cliente. Você constrói um agente com o Claude Agent SDK que lida com devoluções, disputas de cobrança e problemas de conta. O agente tem acesso a ferramentas MCP customizadas: `get_customer`, `lookup_order`, `process_refund`, `escalate_to_human`. Objetivo: 80%+ de resolução no primeiro contato. Domínios testados: D1, D2, D5.

Cenário 2: Geração de Código com Claude Code. Você usa Claude Code para geração de código, refatoração, debugging e documentação. Integra ao workflow com slash commands customizados e configurações CLAUDE.md. Domínios testados: D3, D5.

Cenário 3: Sistema Multi-Agente de Pesquisa. Você constrói um sistema onde um coordenador delega para subagentes especializados: busca web, análise de documentos, síntese de descobertas e geração de relatórios. Domínios testados: D1, D2, D5.

Cenário 4: Produtividade do Desenvolvedor. Você constrói ferramentas usando o Claude Agent SDK para explorar codebases desconhecidos, entender sistemas legados e automatizar tarefas repetitivas. Usa ferramentas nativas (Read, Write, Bash, Grep, Glob) e servidores MCP. Domínios testados: D2, D3, D1.

Cenário 5: Claude Code para CI/CD. Você integra Claude Code em pipelines de integração contínua. O sistema roda code reviews automatizados, gera casos de teste e fornece feedback em pull requests. Domínios testados: D3, D4.

Cenário 6: Extração de Dados Estruturados. Você constrói um sistema de extração usando Claude que processa documentos não-estruturados, valida output com JSON schemas e mantém alta acurácia. Domínios testados: D4, D5.

Domínio 1: Agentic Architecture & Orchestration (27%)

Este é o domínio mais pesado e o que mais distingue arquitetos experientes de iniciantes. Com 7 task statements, D1 exige compreensão profunda de como os LLMs tomam decisões em ambientes agenticos.

1.1 — Loops Agenticos: O Ciclo Fundamental

O ciclo de vida de um loop agentico correto:

1. Enviar requisição ao Claude
2. Inspecionar `stop_reason` na resposta
3. Se `stop_reason == "tool_use"`: executar ferramentas solicitadas, adicionar resultados ao histórico, repetir
4. Se `stop_reason == "end_turn"`: apresentar resposta final

Anti-padrões a evitar (aparecem como distratores no exame): parsear sinais em linguagem natural para terminar o loop, definir número arbitrário máximo de iterações como mecanismo primário de parada, verificar conteúdo de texto do assistant como indicador de conclusão.

A regra é simples: `stop_reason` é a única fonte de verdade sobre quando o loop termina.

1.2 — Orquestração Multi-Agente: Padrão Hub-and-Spoke

Responsabilidades do Coordenador:

• Decomposição de tarefas: analisar a query e dividir em subtarefas independentes


• Delegação dinâmica: selecionar quais subagentes invocar com base na complexidade da query — não executar sempre o pipeline completo


• Roteamento de informações: garantir que cada subagente receba o contexto necessário


• Aggregação de resultados: combinar outputs de múltiplos subagentes em resposta unificada


• Tratamento de erros: lidar com falhas de subagentes sem terminar o workflow

Risco crítico: Decomposição muito estreita pelo coordenador. Se a query é "impacto da IA em indústrias criativas" e o coordenador decompõe apenas em arte digital, design gráfico e fotografia, ele cobre apenas artes visuais e ignora música, escrita e cinema. Bug de cobertura, não bug dos subagentes — os subagentes executaram corretamente dentro do escopo atribuído.

1.3 — Invocação de Subagentes: Task Tool e Contexto

Para que um coordenador invoque subagentes: `allowedTools` deve incluir `"Task"`. Cada subagente recebe um `AgentDefinition` com description, system prompt e restrições de ferramentas. Contexto deve ser passado explicitamente no prompt do subagente — subagentes não herdam automaticamente o contexto do coordenador.

Execução paralela: O coordenador pode spawnar múltiplos subagentes em paralelo emitindo múltiplas chamadas à Task tool em uma única resposta, em vez de chamadas em turnos separados. Isso é fundamental para desempenho em pesquisas complexas.

`fork_session`: Cria branches independentes a partir de uma baseline de análise compartilhada, permitindo explorar abordagens divergentes.

1.4 — Workflows Multi-Etapa com Enforcement

Quando a sequência de operações é crítica para segurança do negócio (ex: verificar identidade do cliente antes de processar reembolso), instruções de prompt têm taxa de falha não-zero. Apenas programatic enforcement garante compliance determinístico.

Hierarquia de confiabilidade:

• Hooks programáticos (maior confiabilidade) → garante que `lookup_order` só funciona após `get_customer` retornar ID verificado


• Instruções de prompt (menor confiabilidade) → pode ser ignorado pelo modelo em 12% dos casos

Para escalação, o handoff estruturado deve incluir: ID do cliente, causa raiz do problema, valor envolvido e ação recomendada — pois o agente humano que recebe a escalação não tem acesso ao transcript da conversa.

1.5 — Agent SDK Hooks: PostToolUse e Interceptação

`PostToolUse`: Intercepta resultados de ferramentas antes do modelo processá-los. Use para normalizar dados heterogêneos vindos de diferentes fontes MCP — converter timestamps Unix, ISO 8601 e datas em formato local para um formato padronizado.

Hook de interceptação outbound: Bloqueia ações que violam políticas antes de serem executadas. Exemplo: bloquear `process_refund` quando valor excede $500 e redirecionar para escalação humana.

Por que hooks > prompt: Uma instrução de prompt "nunca processe reembolsos acima de $500" tem probabilidade de ser seguida, mas não é determinística. Um hook que verifica o valor e bloqueia a chamada é determinístico — não pode ser contornado pelo modelo.

1.6 — Task Decomposition: Prompt Chaining vs. Dynamic Adaptive

Prompt chaining (sequencial previsível): Quebra reviews em etapas fixas. Exemplo: analisar cada arquivo individualmente, depois executar passe de integração cross-file. Use quando o pipeline tem etapas bem definidas.

Dynamic adaptive decomposition: Gera subtarefas com base no que é descoberto em cada etapa. Use para tarefas open-ended como "adicionar testes abrangentes a um codebase legado" — primeiro mapeia estrutura, identifica áreas de alto impacto, cria plano priorizado que se adapta conforme dependências são descobertas.

Atenção para code reviews grandes: Analisar 14 arquivos de uma vez causa "attention dilution" — feedback detalhado para alguns arquivos, superficial para outros, e achados contraditórios (flagrar padrão como problemático num arquivo enquanto aprova código idêntico em outro). Solução: passes por arquivo (análise local) + passe de integração (cross-file data flow).

1.7 — Session Management: Resumption e Forking

`--resume ` continua uma sessão nomeada anterior. Útil quando investigação se estende por múltiplas sessões de trabalho.

Quando retomar vs. começar do zero:

• Retomar: quando contexto anterior ainda é válido e relevante


• Fresh com sumário injetado: quando tool results anteriores estão desatualizados (código foi modificado após a análise)

Importante ao retomar: Informe explicitamente sobre mudanças em arquivos previamente analisados — o agente não detecta automaticamente o que mudou.

Domínio 2: Tool Design & MCP Integration (18%)

2.1 — Tool Descriptions: O Mecanismo Primário de Seleção

Tool descriptions são o mecanismo primário que LLMs usam para seleção de ferramentas. Descriptions mínimas levam a seleção não-confiável entre ferramentas similares.

Uma boa tool description inclui: propósito específico e quando usar vs. alternativas, formatos de entrada esperados com exemplos, formato da saída, edge cases e diferenciação explícita de ferramentas similares.

Anti-padrão: `analyze_content` e `analyze_document` com descriptions quase idênticas. Correção: renomear para `extract_web_results` (focada em resultados de busca web) e `summarize_document` (focada em documentos carregados). Descriptions distintas eliminam ambiguidade.

2.2 — Respostas de Erro Estruturadas

Respostas de erro uniformes ("Operation failed") impedem recovery inteligente.

Schema de erro recomendado:

```
errorCategory: "transient" | "validation" | "permission" | "business"
isRetryable: true | false
description: mensagem legível
attempted: o que foi tentado
```

Tipos:

• `transient` + retryable: timeout → agente pode tentar novamente


• `validation` + não-retryable: input inválido → agente deve corrigir


• `business` + não-retryable: violação de política → explicar ao usuário sem retry

Distinção crítica: falha de acesso (timeout, serviço indisponível) ≠ resultado vazio válido (query bem-sucedida sem matches). Confundir os dois faz o coordinator tomar decisões erradas de recovery.

2.3 — Distribuição de Ferramentas por Agente

Dar a um agente acesso a 18 ferramentas degrada a confiabilidade de seleção. Princípio: cada agente deve ter apenas as ferramentas necessárias para sua função.

`tool_choice` options:

• `"auto"`: modelo decide se usa ferramenta (pode retornar texto em vez de chamar ferramenta)


• `"any"`: modelo deve chamar uma ferramenta — garante output estruturado


• `{"type": "tool", "name": "X"}`: força ferramenta específica

Ferramenta scoped cross-role: Para o caso onde 85% das verificações do synthesis agent são fact-checks simples — dê ao synthesis agent uma ferramenta `verify_fact` limitada, enquanto verificações complexas continuam delegando ao coordinator. Menor latência sem sacrificar separação de responsabilidades.

2.4 — Configuração de Servidores MCP

Escopo de projeto vs. usuário:

• `.mcp.json` (projeto): ferramentas compartilhadas pela equipe, versionadas no repositório


• `~/.claude.json` (usuário): ferramentas pessoais ou experimentais

Expansão de variáveis no `.mcp.json`:
```
{ "env": { "GITHUB_TOKEN": "${GITHUB_TOKEN}" } }
```
Permite versionar o arquivo sem commitar secrets.

MCP Resources vs. Tools: Resources expõem catálogos de conteúdo (sumários de issues, schemas de banco) — reduzem chamadas exploratórias. Tools executam ações.

2.5 — Ferramentas Nativas: Seleção Correta

| Ferramenta | Use quando |
|-----------|-----------|
| `Grep` | Buscar conteúdo dentro de arquivos |
| `Glob` | Encontrar arquivos por padrão de nome/extensão |
| `Read` | Carregar conteúdo completo de arquivo |
| `Write` | Criar ou sobrescrever arquivo completo |
| `Edit` | Modificação cirúrgica com anchor text único |
| `Bash` | Comandos de sistema sem ferramenta dedicada |

Quando `Edit` falha: Se o texto âncora não é único, Edit falha. Solução: usar `Read` + `Write` como fallback.

Exploração incremental: Comece com `Grep` para encontrar entry points, depois use `Read` para seguir imports — não leia todos os arquivos de uma vez.

Domínio 3: Claude Code Configuration & Workflows (20%)

3.1 — Hierarquia de CLAUDE.md

Hierarquia de três níveis:

1. Usuário (`~/.claude/CLAUDE.md`): aplica apenas ao usuário local — NÃO é compartilhado via version control
2. Projeto (`CLAUDE.md` na raiz ou `.claude/CLAUDE.md`): compartilhado por toda a equipe
3. Diretório (CLAUDE.md em subdiretórios): aplica quando o Claude trabalha naquele diretório

`@import` syntax: Mantém CLAUDE.md modular via imports: `@api-conventions.md`, `@testing-standards.md`.

`.claude/rules/`: Organiza regras por tópico — `testing.md`, `api-conventions.md`, `deployment.md`.

Diagnóstico: Use `/memory` para verificar quais arquivos de memória estão carregados e diagnosticar comportamento inconsistente entre sessões.

3.2 — Slash Commands e Skills

Commands do projeto (`.claude/commands/`): disponíveis para toda a equipe ao clonar o repositório. Versionados via git.

Skills (`.claude/skills/` com `SKILL.md`): Suportam frontmatter YAML:

• `context: fork`: executa em subagente isolado — output não "polui" o contexto principal


• `allowed-tools`: restringe ferramentas disponíveis durante a skill


• `argument-hint`: texto exibido quando invocada sem argumentos

Skills vs. CLAUDE.md:

• CLAUDE.md: carregado sempre, padrões universais


• Skills: invocação sob demanda para workflows específicos

3.3 — Regras Path-Specific

O arquivo `.claude/rules/` suporta YAML frontmatter com campo `paths`:

```yaml

---

paths: ["**/*.test.tsx"]

---

# Convenções de Teste
```

Vantagem sobre subdirectory CLAUDE.md: um padrão `**/*.test.tsx` aplica a arquivos em qualquer localização — crucial quando test files ficam ao lado do código que testam.

3.4 — Plan Mode vs. Execução Direta

Plan mode é obrigatório para: reestruturação de monolito em microserviços, migração de biblioteca afetando 45+ arquivos, decisões arquiteturais com múltiplas abordagens válidas.

Execução direta é adequada para: bug fix em arquivo único com stack trace claro, adicionar validação condicional simples, renomear variável com escopo óbvio.

Combinação ideal: plan mode para investigação → execução direta para implementação.

3.5 — Iterative Refinement

Input/output examples: Para transformações ambíguas, 2-3 exemplos concretos de input → output são muito mais eficazes que descrições em prosa.

Test-driven iteration: Escreva a test suite primeiro (comportamento esperado, edge cases), depois compartilhe as falhas para guiar implementação progressiva.

Interview pattern: Peça ao Claude para fazer perguntas antes de implementar em domínios desconhecidos. Revela considerações que o desenvolvedor não antecipou.

3.6 — Claude Code em CI/CD

Flag `-p` (ou `--print`): Roda Claude Code em modo não-interativo. Sem esta flag, o job de CI trava indefinidamente aguardando input.

```bash
claude -p "Analise este pull request para problemas de segurança"
```

Output estruturado para CI:
```bash
claude -p "..." --output-format json --json-schema schema.json
```

Instâncias de revisão independentes: A mesma instância que gerou código é menos eficaz em revisá-lo — retém o raciocínio da geração. Use instância independente para code review.

Domínio 4: Prompt Engineering & Structured Output (20%)

4.1 — Critérios Explícitos para Reduzir Falsos Positivos

Instruções vagas como "seja conservador" ou "reporte apenas achados de alta confiança" NÃO melhoram precisão. Em vez de "verifique se os comentários são precisos", use: "Flagrar comentários APENAS quando o comportamento descrito contradiz o comportamento real do código. NÃO flagrar: comentários de intenção, TODO comments, documentação de API."

O impacto dos falsos positivos vai além do inconveniente: quando desenvolvedores veem muitos falsos positivos em uma categoria, passam a ignorar todos os achados daquela categoria — incluindo os verdadeiros.

4.2 — Few-Shot Prompting para Consistência

Few-shot examples são a técnica mais eficaz para output consistentemente formatado quando instruções detalhadas sozinhas produzem resultados inconsistentes.

Para cenários ambíguos, crie 2-4 exemplos targeted que mostram: o raciocínio de por que uma ação foi escolhida em vez de alternativas, o formato exato de output esperado, como distinguir padrões aceitáveis de problemas reais.

Para extração: Quando documentos têm estrutura variada e o modelo está deixando campos vazios, few-shot examples mostrando extração de diferentes formatos resolvem melhor que instruções adicionais.

4.3 — Structured Output via Tool Use

`tool_use` com JSON schema é a abordagem mais confiável para output schema-compliant — elimina erros de sintaxe JSON.

`tool_choice` para output garantido:

• `"auto"`: pode retornar texto — NÃO garante output estruturado


• `"any"`: deve chamar ferramenta — garante estrutura quando múltiplos schemas existem


• `{"type": "tool", "name": "X"}`: força ferramenta específica

Design de schema:

• Campos `nullable` para informações que podem não existir — previne alucinação de valores fabricados


• Enum com `"other"` + campo de detalhe para categorias extensíveis


• `"unclear"` como valor enum para casos ambíguos

Limite: JSON schema elimina erros de sintaxe mas NÃO previne erros semânticos (line items que não somam ao total, valores em campos errados).

4.4 — Loops de Validação e Retry

Retry com feedback: Em vez de simplesmente retentar, inclua no follow-up: o documento original, a extração que falhou e os erros de validação específicos. Permite auto-correção estruturada.

Quando retry é ineficaz: Se a informação simplesmente não existe no documento fonte, nenhum número de retries produz o valor correto. Identifique se o erro é de formato (retry funciona) ou ausência de informação (retry desperdiça tokens).

4.5 — Batch Processing com Message Batches API

| Característica | Valor |
|---------------|-------|
| Economia de custo | ~50% |
| Tempo de processamento | até 24 horas |
| SLA de latência | Nenhum |
| Multi-turn tool calling | Não suportado |
| Correlação | `custom_id` |

Use batch para: relatórios técnicos overnight, análises semanais, geração de testes noturna. NÃO use para: pre-merge checks bloqueantes, qualquer workflow que exige resposta síncrona.

Cálculo de frequência: Se seu SLA é 30 horas e processamento leva até 24h, submeta com 6+ horas de antecedência — permita janelas a cada 4-6 horas.

4.6 — Multi-Instância e Multi-Pass Review

Limitação de auto-revisão: Um modelo retém o raciocínio de geração e é menos propenso a questionar suas próprias decisões. Use instância independente para review.

Multi-pass para reviews grandes: Review em passagem única de 14 arquivos produz attention dilution. Estrutura correta:
1. Passa por arquivo (análise local)
2. Passe de integração separado (data flow cross-file, inconsistências entre módulos)

Domínio 5: Context Management & Reliability (15%)

5.1 — Preservação de Informação em Interações Longas

"Lost in the middle": Modelos processam informação de forma mais confiável no início e fim de inputs longos. Coloque key findings no início e resumos no final dos inputs agregados.

Bloco de "case facts" persistente: Para conversas de suporte multi-turno, extraia fatos transacionais (valores, datas, números de pedido, status) em bloco estruturado separado incluído em cada prompt — fora do histórico resumido, que pode condensar e perder valores numéricos precisos.

Acumulação de tool results: Faça trim dos outputs verbosos para manter apenas campos relevantes antes que se acumulem no contexto.

5.2 — Padrões de Escalação

Escalar IMEDIATAMENTE (sem tentar resolver):

• Cliente solicita explicitamente agente humano


• Política é ambígua ou silenciosa sobre a solicitação específica


• Impossibilidade de fazer progresso meaningful

Anti-padrões:

• Escalação baseada em sentimento (frustração ≠ complexidade)


• Escalação baseada em confidence score auto-reportado (mal calibrado)

Múltiplos matches: Quando ferramenta retorna múltiplos clientes com o mesmo nome, peça identificadores adicionais — não faça seleção heurística.

5.3 — Propagação de Erros em Sistemas Multi-Agente

Subagentes implementam recovery local para falhas transientes. Apenas erros não-resolvíveis localmente são propagados ao coordinator, com contexto estruturado:

```
failureType: "timeout"
attemptedQuery: "AI impact on creative industries 2023-2025"
partialResults: ["Source 1...", "Source 2..."]
alternativeApproach: "Tente buscar com janela temporal menor"
```

Cobertura anotada no output de síntese: Identifique explicitamente quais áreas têm suporte bem-fundamentado vs. gaps por indisponibilidade de fontes.

5.4 — Contexto em Exploração de Codebase

Context degradation: Em sessões estendidas, modelos começam a dar respostas inconsistentes e referenciam "padrões típicos" em vez das classes descobertas anteriormente.

Soluções:

• Scratchpad files: Key findings persistidos em arquivo, referenciados em perguntas subsequentes


• Delegação a subagentes: Para investigações específicas enquanto agente principal coordena


• `/compact`: Reduz uso de contexto durante exploração estendida


• Crash recovery com manifests: Cada agente exporta estado; coordinator carrega manifest no resume

5.5 — Human Review Workflows

Risco de métricas agregadas: 97% de acurácia geral pode mascarar desempenho ruim em tipos específicos de documento ou campos específicos.

Amostragem estratificada: Para extrações de alta confiança, amostras aleatórias detectam taxa de erro real e padrões de erro novos.

Calibração: Confidence scores do modelo devem ser calibrados com labeled validation sets antes de serem usados para roteamento. Confiança não-calibrada é ruído.

5.6 — Proveniência e Síntese Multi-Fonte

Perda de atribuição em summarização: Quando subagentes comprimem descobertas sem preservar mapeamentos claim-source, a atribuição se perde.

Dados conflitantes de fontes confiáveis: Não selecione arbitrariamente um valor. Anote ambos com atribuição de fonte. Estruture o relatório com seção explícita distinguindo achados bem-estabelecidos de contestados.

Dados temporais: Requeira datas de publicação/coleta nos outputs estruturados — para que diferenças temporais não sejam mal-interpretadas como contradições.

12 Questões Oficiais com Gabarito Comentado

Todas as 12 questões de prática do guia oficial, com análise completa.

---

Questão 1 — Customer Support Agent

Problema: Em 12% dos casos, o agente ignora `get_customer` e chama `lookup_order` diretamente com o nome do cliente, levando a contas mal identificadas e reembolsos incorretos. Qual mudança resolveria?

A) Adicionar prerequisite programático que bloqueia `lookup_order` e `process_refund` até que `get_customer` retorne ID verificado.
B) Melhorar system prompt declarando que verificação via `get_customer` é mandatória.
C) Adicionar few-shot examples mostrando o agente sempre chamando `get_customer` primeiro.
D) Implementar classificador de roteamento que habilita apenas subconjunto de ferramentas por tipo de solicitação.

✅ Resposta: A

Enforcement programático fornece garantias determinísticas que abordagens baseadas em prompt não conseguem. B e C dependem de compliance probabilístico do LLM — insuficiente quando erros têm consequências financeiras. D endereça disponibilidade de ferramentas, não ordenamento.

---

Questão 2 — Customer Support Agent

Problema: O agente frequentemente chama `get_customer` quando usuários perguntam sobre pedidos (ex: "verifique meu pedido #12345"), em vez de `lookup_order`. Ambas têm descriptions mínimas e aceitam identificadores similares. Qual é o primeiro passo mais eficaz?

A) Adicionar 5-8 few-shot examples de seleção correta de ferramenta.
B) Expandir description de cada ferramenta com formatos de input, exemplos de queries, edge cases e limites.
C) Implementar camada de roteamento que parseia input e pré-seleciona ferramenta por keywords.
D) Consolidar ambas em uma `lookup_entity` que aceita qualquer identificador.

✅ Resposta: B

Tool descriptions são o mecanismo primário de seleção. B endereça a causa raiz com baixo esforço e alto impacto. Few-shot (A) adiciona overhead sem corrigir o problema. Roteamento (C) é over-engineered. Consolidar (D) requer mais esforço do que o "primeiro passo" justifica.

---

Questão 3 — Customer Support Agent

Problema: Agente atinge 55% de resolução (meta: 80%). Escala casos simples e tenta resolver autonomamente situações complexas. Como melhorar calibração de escalação?

A) Adicionar critérios explícitos de escalação ao system prompt com few-shot examples demonstrando quando escalar vs. resolver.
B) Fazer o agente auto-reportar confidence score (1-10) e escalar automaticamente quando cai abaixo de threshold.
C) Deploy de classificador treinado em tickets históricos para prever escalação.
D) Implementar análise de sentimento para detectar frustração e escalar quando negativo.

✅ Resposta: A

Critérios explícitos com few-shot endereça a causa raiz: fronteiras de decisão pouco claras. B falha porque confidence score auto-reportado é mal-calibrado. C é over-engineered. D resolve problema diferente — sentimento não correlaciona com complexidade.

---

Questão 4 — Code Generation with Claude Code

Problema: Você quer criar slash command `/review` compartilhado com todos ao clonar o repositório. Onde criar o arquivo?

A) No diretório `.claude/commands/` no repositório.
B) Em `~/.claude/commands/` no diretório home de cada desenvolvedor.
C) No arquivo `CLAUDE.md` na raiz do projeto.
D) Em `.claude/config.json` com array de commands.

✅ Resposta: A

Commands de projeto ficam em `.claude/commands/`. São versionados e automaticamente disponíveis ao clonar. B é para commands pessoais. C é para instruções e contexto. D descreve mecanismo que não existe no Claude Code.

---

Questão 5 — Code Generation with Claude Code

Problema: Você vai reestruturar aplicação monolítica em microserviços. Mudanças em dezenas de arquivos, decisões sobre fronteiras de serviço. Qual abordagem?

A) Entrar em plan mode para explorar o codebase e projetar implementação antes de fazer mudanças.
B) Começar com execução direta, incrementalmente, deixando implementação revelar fronteiras naturais.
C) Execução direta com instruções upfront abrangentes detalhando cada serviço.
D) Execução direta, mudar para plan mode apenas se encontrar complexidade inesperada.

✅ Resposta: A

Plan mode é projetado para tarefas complexas com mudanças em larga escala e decisões arquiteturais. B arrisca retrabalho custoso. C assume que você já sabe a estrutura certa sem explorar o código. D ignora que a complexidade já está declarada nos requisitos.

---

Questão 6 — Code Generation with Claude Code

Problema: Codebase com áreas distintas: React componentes, API handlers, database models — cada um com convenções diferentes. Test files espalhados ao lado do código (ex: `Button.test.tsx` ao lado de `Button.tsx`). Como garantir que Claude aplique convenções corretas automaticamente?

A) Criar arquivos em `.claude/rules/` com YAML frontmatter e glob patterns por file path.
B) Consolidar todas as convenções no CLAUDE.md raiz sob headers por área.
C) Criar skills em `.claude/skills/` para cada tipo de código.
D) Colocar CLAUDE.md separado em cada subdiretório.

✅ Resposta: A

`.claude/rules/` com glob patterns (ex: `**/*.test.tsx`) aplica convenções por file path independente de diretório — essencial para test files espalhados. B usa inferência em vez de matching explícito. C requer invocação manual. D não consegue lidar com arquivos espalhados.

---

Questão 7 — Multi-Agent Research System

Problema: O sistema pesquisa "impacto da IA em indústrias criativas". Cada subagente completa com sucesso. Mas os relatórios cobrem apenas artes visuais, ignorando música, escrita e cinema. Os logs do coordenador mostram decomposição em: "IA em arte digital", "IA em design gráfico" e "IA em fotografia". Qual é a causa raiz?

A) O agente de síntese não tem instruções para identificar gaps de cobertura.
B) A decomposição de tarefas do coordenador é muito estreita, cobrindo apenas artes visuais.
C) As queries do agente de busca não são abrangentes o suficiente.
D) O agente de análise está filtrando fontes de indústrias não-visuais.

✅ Resposta: B

Os logs do coordenador revelam a causa raiz diretamente: decomposição apenas em artes visuais. Os subagentes executaram corretamente dentro do escopo atribuído. A, C e D culpam incorretamente agentes downstream.

---

Questão 8 — Multi-Agent Research System

Problema: Subagente de busca entra em timeout. Como o erro deve fluir para o coordenador para habilitar recovery inteligente?

A) Retornar contexto estruturado incluindo tipo de falha, query tentada, resultados parciais e abordagens alternativas.
B) Retry automático com backoff, retornando status genérico "search unavailable" após exaurir retries.
C) Capturar timeout e retornar conjunto de resultados vazio marcado como bem-sucedido.
D) Propagar exceção para handler de nível superior que termina todo o workflow.

✅ Resposta: A

Contexto estruturado dá ao coordenador informações para recovery — retentar com query modificada, tentar alternativa, ou prosseguir com resultados parciais. B esconde contexto valioso. C suprime o erro mascarando falha como sucesso. D termina desnecessariamente o workflow.

---

Questão 9 — Multi-Agent Research System

Problema: Synthesis agent frequentemente precisa verificar afirmações. Cada verificação adiciona 2-3 round trips via coordinator + search agent, aumentando latência em 40%. 85% das verificações são fact-checks simples; 15% requerem investigação profunda. Qual abordagem reduz overhead?

A) Dar ao synthesis agent uma ferramenta `verify_fact` com escopo limitado para lookups simples; complexas continuam via coordinator.
B) Synthesis agent acumula verificações e retorna em batch ao coordinator no final.
C) Dar ao synthesis agent acesso a todas as ferramentas de busca web.
D) Search agent cacheia contexto extra proativamente antecipando o que synthesis precisará.

✅ Resposta: A

Aplica principle of least privilege — synthesis agent recebe apenas o necessário para 85% dos casos comuns. Batching (B) cria dependências bloqueantes pois etapas de síntese podem depender de fatos verificados anteriormente. C over-provisiona violando separação de responsabilidades. D depende de caching especulativo.

---

Questão 10 — Claude Code for CI/CD

Problema: Pipeline executa `claude "Analise este pull request"` mas o job trava indefinidamente aguardando input interativo. Qual abordagem correta?

A) Adicionar flag `-p`: `claude -p "Analise este pull request"`
B) Definir `CLAUDE_HEADLESS=true` antes de executar
C) Redirecionar stdin de /dev/null
D) Adicionar flag `--batch`

✅ Resposta: A

A flag `-p` (ou `--print`) é a forma documentada de rodar Claude Code em modo não-interativo. Processa o prompt, produz resultado no stdout e sai sem aguardar input. As outras opções referenciam features que não existem (`CLAUDE_HEADLESS`, `--batch`) ou workarounds que não endereçam adequadamente.

---

Questão 11 — Claude Code for CI/CD

Problema: Dois workflows: (1) pre-merge check bloqueante, (2) relatório de débito técnico overnight. Manager propõe mudar ambos para Message Batches API (50% economia). Como avaliar?

A) Batch apenas para relatórios overnight; manter real-time para pre-merge checks.
B) Mudar ambos para batch com status polling.
C) Manter real-time para ambos para evitar problemas de ordenação.
D) Mudar ambos para batch com fallback para real-time se demorar muito.

✅ Resposta: A

Batch API tem processamento até 24h sem SLA de latência — inadequada para pre-merge checks bloqueantes, ideal para jobs overnight. B não é aceitável para workflows bloqueantes. C reflete equívoco — `custom_id` resolve correlação. D adiciona complexidade desnecessária.

---

Questão 12 — Claude Code for CI/CD

Problema: PR com 14 arquivos produz resultados inconsistentes em passagem única: feedback detalhado para alguns, superficial para outros, bugs óbvios ignorados, feedback contraditório no mesmo PR. Como reestruturar?

A) Dividir em passes: analisar cada arquivo individualmente para issues locais, depois passe separado focado em data flow cross-file.
B) Exigir que developers dividam PRs grandes em submissões de 3-4 arquivos.
C) Mudar para modelo com context window maior para dar atenção adequada em uma passagem.
D) Executar três passes independentes e flagrar apenas issues que aparecem em pelo menos dois dos três.

✅ Resposta: A

Passes focados endereçam a causa raiz: attention dilution. Análise arquivo-por-arquivo garante profundidade consistente; passe de integração captura issues cross-file. B transfere ônus para developers. C confunde que context windows maiores não resolvem qualidade de atenção. D suprimiria bugs reais ao requerer consenso.

4 Exercícios Práticos de Preparação

A Anthropic fornece 4 exercícios hands-on como preparação oficial.

Exercício 1: Agente Multi-Tool com Escalation Logic

Objetivo: Praticar agentic loop, integração de ferramentas, erros estruturados e escalação.

Passos:
1. Defina 3-4 ferramentas MCP com descriptions detalhadas que diferenciam claramente cada uma. Inclua pelo menos duas com funcionalidade similar.
2. Implemente agentic loop que verifica `stop_reason` para determinar continuar execução ou apresentar resposta final.
3. Adicione respostas de erro estruturadas: `errorCategory` (transient/validation/permission), booleano `isRetryable` e descriptions legíveis. Teste cada tipo de erro.
4. Implemente hook programático que intercepta chamadas para enforçar regra de negócio (ex: bloquear operações acima de threshold), redirecionando para escalação.
5. Teste com mensagens multi-concern e verifique que o agente decompõe, trata cada concern e sintetiza resposta unificada.

*Domínios: D1, D2, D5*

Exercício 2: Claude Code para Workflow de Equipe

Objetivo: Praticar CLAUDE.md hierarchies, slash commands, path-specific rules e integração MCP.

Passos:
1. Crie CLAUDE.md de nível projeto com padrões universais. Verifique que são aplicados consistentemente.
2. Crie `.claude/rules/` com YAML frontmatter e glob patterns para diferentes áreas (ex: `paths: ["src/api/**/*"]`, `paths: ["**/*.test.*"]`). Teste que regras carregam apenas para arquivos correspondentes.
3. Crie skill com `context: fork` e `allowed-tools`. Verifique isolamento de contexto.
4. Configure servidor MCP em `.mcp.json` com expansão de variável de ambiente. Adicione servidor pessoal em `~/.claude.json`.
5. Teste plan mode vs. execução direta em tarefas de complexidade variada.

*Domínios: D3, D2*

Exercício 3: Pipeline de Extração Estruturada

Objetivo: JSON schemas, `tool_use`, validation-retry loops, batch processing.

Passos:
1. Defina ferramenta de extração com JSON schema contendo campos required/optional, enum com `"other"` + detail string e campos nullable. Verifique que modelo retorna null em vez de fabricar valores.
2. Implemente validation-retry loop: falha → follow-up com documento + extração que falhou + erro específico. Rastreie erros resolvíveis vs. não.
3. Adicione few-shot examples demonstrando extração de documentos com formatos variados.
4. Design de batch: submeta 100 documentos via Message Batches API, trate falhas por `custom_id`, resubmeta com modificações.
5. Implemente revisão humana: confidence scores por campo, roteamento de baixa confiança.

*Domínios: D4, D5*

Exercício 4: Pipeline Multi-Agente de Pesquisa

Objetivo: Orquestração, passagem de contexto, propagação de erros, proveniência.

Passos:
1. Construa coordinator que delega para dois subagentes. Certifique-se que `allowedTools` inclui `"Task"` e contexto é passado explicitamente no prompt.
2. Implemente execução paralela com múltiplas chamadas Task tool em única resposta. Meça melhora de latência.
3. Design output estruturado separando conteúdo de metadados: afirmação, trecho de evidência, source URL, data de publicação.
4. Implemente propagação de erros: simule timeout, verifique que coordinator recebe contexto estruturado. Teste com resultados parciais.
5. Teste com dados conflitantes de fontes diferentes. Verifique que síntese preserva ambos com atribuição.

*Domínios: D1, D2, D5*

Mapa de Estudo: 4 Semanas para a CCA-F

Com 1-2 horas por dia, 4 semanas são suficientes para candidatos com experiência prática adequada.

Tópicos Fora do Escopo: O que Não Cai na Prova

Conhecer o que está fora do escopo economiza horas de estudo:

Fine-tuning ou treinamento de modelos customizados — Autenticação, billing ou gerenciamento de contas da API — Implementação detalhada de linguagens ou frameworks específicos — Deploy ou hospedagem de servidores MCP (infraestrutura, redes, containers) — Arquitetura interna do Claude, processo de treinamento ou pesos do modelo — Constitutional AI, RLHF ou methodologias de safety training — Embedding models ou implementação de vector databases — Computer use (automação de browser, interação com desktop) — Análise de visão/imagem — Streaming API ou server-sent events — Rate limiting, quotas ou cálculo de preços da API — OAuth, rotação de API keys ou protocolos de autenticação — Configurações específicas de cloud provider (AWS, GCP, Azure) — Benchmarking de performance ou comparação de modelos — Implementação de prompt caching — Algoritmos de token counting ou tokenização.

Dicas Finais, Armadilhas e Recursos

As 5 Armadilhas Mais Comuns

1. Probabilístico vs. Determinístico. O exame frequentemente apresenta opções que dependem de compliance probabilístico do LLM (instruções de prompt, few-shot) vs. opções com garantias determinísticas (programmatic hooks, prerequisites). Quando o cenário envolve segurança de negócio ou prevenção de erros financeiros — a resposta determinística quase sempre é a correta.

2. Over-engineering como distrator. Quando o exame pergunta "qual é o primeiro passo mais eficaz?", a resposta é frequentemente a solução mais simples que ataca a causa raiz — não a arquitetura mais elaborada.

3. Escopo do coordinator, não dos subagentes. Em questões sobre gaps de cobertura, o reflexo é culpar o agente que produziu output incompleto. O exame frequentemente testa que a causa raiz é task decomposition insuficiente pelo coordinator.

4. Batch API para tudo que é "volume". A Message Batches API tem 50% de economia — atraente. Mas qualquer workflow bloqueante (pre-merge checks) não pode usar batch.

5. `tool_choice: "auto"` não garante output estruturado. Se você precisa de JSON garantido, use `"any"` ou forçe uma ferramenta específica.

Recursos Oficiais

• Documentação do Agent SDK: docs.anthropic.com — seção de Agents
• Documentação do Claude Code: docs.anthropic.com/claude-code
• Documentação do MCP: modelcontextprotocol.io
• Practice Exam Oficial: link fornecido pela Anthropic ao se registrar
• Guia do Exame v0.1: Anthropic, fevereiro de 2025 — fonte primária deste artigo

Registro e Logística

A certificação é oferecida pela Anthropic em parceria com provedores de exame. Verifique o site oficial da Anthropic para preço, disponibilidade, modalidades (presencial ou online proctored), política de retake e validade.

Conclusão e Próximos Passos

A CCA-F é a primeira certificação que valida conhecimento prático com os produtos core da Anthropic: Claude API, Agent SDK, Claude Code e MCP. Com 5 domínios cobrindo desde loops agenticos básicos até gerenciamento avançado de contexto em sistemas multi-agente, o exame testa julgamento de arquitetura — não memorização.

Os candidatos bem preparados entendem os tradeoffs — quando hooks > prompts, quando plan mode > execução direta, quando batch API > API síncrona — e reconhecem anti-padrões.

Se você tem 6+ meses de experiência com Claude em produção e seguiu este guia, você tem o que precisa para passar. A nota mínima é 720 em 1.000 — não é uma barreira impossível, mas exige compreensão dos conceitos, não reconhecimento superficial.

Construa os 4 exercícios práticos. Analise todas as 12 questões oficiais com atenção ao raciocínio dos distratores. Complete o Practice Exam oficial antes da prova. Boa sorte.

---

*Guia elaborado com base no CCA-F Exam Guide oficial v0.1 (Anthropic, fevereiro de 2025). Todos os nomes de domínios, task statements, questões e respostas são derivados do documento oficial da Anthropic.*