# Subagentes aninhados no Claude Code: delegar uma tarefa grande
> Na v2.1.172, a Anthropic permitiu que os subagentes do Claude Code criassem os seus próprios subagentes até 5 níveis de profundidade. Saiba como delegar uma tarefa de grande dimensão.
Source: https://ailoot.ai/blog/pt-pt/claude-code-nested-subagents/
Canonical: https://ailoot.ai/blog/pt-pt/claude-code-nested-subagents/
Language: pt-PT
Publisher: Ailoot (https://ailoot.ai/)
Translation: guide-232
Revision: sha256-dc9a407689d8b1d6ac78c1c5b640c040be178a5a8d6eff4f2592170df8c377bc
[Documentação do Ailoot](https://ailoot.ai/docs/) — materiais de referência sobre a utilização do serviço.
## O que mudou no Claude Code v2.1.172?
Ideia principal
A Anthropic lançou a versão 2.1.172 e eliminou uma regra com dois anos através de uma única linha nas notas da versão. Os subagentes podem agora criar os seus próprios subagentes, até 5 níveis de profundidade. Esta funcionalidade não diz respeito à velocidade nem a mais CPU. A ideia principal é impedir que o trabalho preparatório ruidoso encha o contexto principal.
Se leu alguma coisa sobre agentes de IA no Claude Code nos últimos meses, já se deparou com a mesma frase. Está na documentação oficial, no meu guia [sobre subagentes](https://ailoot.ai/blog/pt-pt/claude-code-subagents/) e na análise de todos os concorrentes. É assim: “um subagente não pode criar outro subagente”. A 11 de junho de 2026, essa frase ainda aparece em três sítios diferentes em `code.claude.com/docs/en/sub-agents`. A Anthropic ainda não a atualizou.
A 10 de junho, às 20:44 UTC, o Claude Code v2.1.172 apareceu no GitHub Releases. O principal item das notas da versão foi uma linha:
Os subagentes podem agora criar os seus próprios subagentes, até 5 níveis de profundidade.
— Claude Code Changelog, https://github.com/anthropics/claude-code/releases/tag/v2.1.172
Esta mesma versão também corrigiu um erro que só podia acontecer com o aninhamento: um subagente em segundo plano continuava destacado como ativo no painel de agentes depois de o subagente aninhado que tinha lançado já ter sido parado.
É raro que a documentação oficial ainda contradiga a versão lançada. A seguir, explico em que difere o aninhamento dos subagentes paralelos, o que significa “profundidade 5” e os três cenários em que é realmente útil hoje.
## Em que diferem os subagentes aninhados dos paralelos e sequenciais?
Ideia principal
Se está confuso, não está sozinho. O paralelismo, o encadeamento e o aninhamento são três topologias ortogonais. O paralelismo diz respeito à velocidade, o encadeamento estabelece a ordem de execução e o aninhamento serve para algo inteiramente diferente: oculta o trabalho ruidoso da sua janela principal. Se os confundir, vai gastar tokens em poucas horas e depois não conseguirá descobrir onde está o erro.
Passei muito tempo a experimentar manualmente estas três abordagens, e é assim que as vejo: a delegação tem três dimensões. Largura, comprimento e profundidade. Cada uma resolve um problema diferente.
**Largura — subagentes paralelos.** A conversa principal lança N subagentes independentes no mesmo nível. Cada um recebe uma tarefa específica, trabalha na sua própria janela isolada e devolve apenas o resultado. A largura resolve a questão da velocidade: 5 subagentes a trabalhar em paralelo terminam no tempo que um demoraria a fazer o mesmo trabalho sequencialmente. Foi este o modelo que abordei no meu guia [sobre subagentes paralelos com worktrees](https://ailoot.ai/blog/pt-pt/claude-code-parallel-worktree-agents/).
**Comprimento — uma cadeia de subagentes.** A trabalha, entrega o resultado a B, B trabalha e entrega-o a C. Cada um vê os dados recebidos do anterior. O comprimento estabelece a ordem: B não pode começar antes de receber os dados de A. Um exemplo clássico: primeiro, um subagente de investigação reúne fontes; depois, um subagente de edição escreve um artigo com base nessas fontes; por fim, um subagente de verificação de factos verifica o artigo. É uma sequência plana; a conversa principal contém toda a narrativa.
**Profundidade — subagentes aninhados.** A lança B, B lança C, C lança D. Cada filho trabalha dentro do seu progenitor, na sua própria janela isolada, e devolve **apenas o resultado** ao progenitor. A conversa principal não vê nada do que acontece com os filhos, netos e bisnetos. É esta a novidade da v2.1.172.
A principal confusão é pensar que profundidade 5 significa “pode lançar 5 subagentes em simultâneo”. Não é assim. A profundidade é um nível vertical na árvore, não o número de filhos simultâneos. Pode haver um subagente ou cem em cada nível. Profundidade 5 significa que a cadeia de delegação pode descer 5 passos: conversa principal → neto-1 → neto-2 → neto-3 → neto-4 → neto-5. E pode haver ramificações em todos os níveis.
A versão 2.1.172 eliminou a restrição que impedia um subagente de criar outro.
Se procura velocidade, precisa de largura. Se tem uma ordem de execução rigorosa, precisa de comprimento. A profundidade é útil num caso específico: quando uma das suas tarefas contém uma **subtarefa ruidosa** (15 pedidos web, percorrer registos, ler uma dúzia de ficheiros). E não quer que esse ruído inunde a sua janela principal.
## O que significa “5 níveis de profundidade” na prática?
Ideia principal
5 níveis é a distância vertical máxima entre a conversa principal e o bisneto mais distante. É um limite do lado do servidor; não pode aumentá-lo, reduzi-lo nem desativá-lo com uma flag. E as fontes oficiais continuam sem esclarecer se a própria conversa principal conta para esses 5 níveis.
Aqui há um ponto importante de honestidade. Passei meio dia a consultar a documentação e as análises da comunidade para descobrir que a Anthropic não deu uma definição precisa. Eis o que precisa de saber.
**É um limite, não uma definição configurável.**
O limite está implementado do lado do servidor. A engenharia inversa do cliente v2.1.172 não encontrou nenhuma constante `MAX_DEPTH`. Isso significa que a verificação acontece algures na API da Anthropic, e não localmente na sua máquina. Não pode definir `--max-depth 7` para tornar a árvore mais profunda. Também não pode definir `--max-depth 2` para estabelecer um limite mais baixo e seguro. O único controlo que tem é a lista de permissões `Agent(agent_type)` no frontmatter — mas esta limita os **tipos** de agentes filhos, não a profundidade.
**A Anthropic não definiu com precisão o significado de “5”.** Esse é o segundo ponto importante:
**A Anthropic não definiu exatamente o significado de «5».** As fontes oficiais não especificam se depth=5 significa cinco níveis abaixo da raiz ou cinco agentes no total, incluindo a raiz.
As integrações de terceiros interpretam isso de forma diferente, por enquanto. A ADR-147 do projeto `ruvnet/ruflo` parte do princípio de que “5 níveis filhos abaixo da raiz = 6 agentes na cadeia”. Uso a mesma convenção nas minhas experiências: a conversa principal é o nível 0, os seus filhos diretos são o nível 1, e assim sucessivamente até ao nível 5. Mas esta convenção não está registada na documentação pública.
**O limite já está ativo, sem flags.** Não precisa de ativar nada. Depois de atualizar o Claude Code para a v2.1.172, pode adicionar `Agent` a `tools` de um agente filho, e este lançará outro subagente. O essencial é que o agente progenitor tenha de o permitir (`tools: Agent(...)`).
## Onde acontece hoje a sua delegação: largura, comprimento ou profundidade?
Ideia principal
Em projetos de vibe coding reais, quase sempre vejo largura e, ocasionalmente, comprimento. As pessoas fazem a profundidade manualmente: abrem uma nova janela, copiam um prompt e voltam com o resultado. Antes de 9 de junho, isto não estava integrado. É por isso que a maioria das pessoas nem se apercebe de que lhe falta esta funcionalidade.
Reveja os seus últimos 5 prompts. Quantas vezes fez isto: começa uma tarefa, o Claude começa a procurar ficheiros com grep, faz 10 pedidos web, despeja uma parede inteira de registos no contexto — e, 20 minutos depois, percebe que a janela está cheia. A resposta final já está a funcionar com um orçamento de tokens reduzido, porque 70 por cento do contexto foi consumido por despejos intermédios.
Esse é um cenário em que precisa de **profundidade**. Não de paralelismo, nem de uma cadeia — de profundidade. A conversa principal deve delegar a “investigação” a um subagente, que depois lança os seus próprios filhos para pesquisas web específicas, leituras de ficheiros e pesquisas com grep. Os filhos devolvem apenas conclusões destiladas. Um neto diz ao progenitor: “encontrei, confirmado” ou “não encontrei, por razão X”. O progenitor reúne tudo num único resumo e devolve-o a si. A conversa principal mantém-se limpa.
Antes de 9 de junho, simulava isto manualmente. Abri uma segunda instância do Claude Code, copiei o prompt «investiga isto», executei-o e depois transferi manualmente o resultado de volta para a janela principal. Descrevi esta configuração em pormenor no meu guia sobre delegar tarefas de programação a vários agentes de IA. Com a v2.1.172, pode descrevê-la diretamente no prompt de sistema do orquestrador — o Claude cria a árvore por si.
## Em que 3 cenários são os subagentes aninhados realmente úteis?
Ideia principal
Não servem para todas as tarefas. A profundidade justifica-se quando uma delegação inclui uma subtarefa ruidosa que não quer colocar na janela principal. Vou abordar três cenários clássicos que surgem frequentemente entre os programadores de vibe coding: investigação aprofundada com verificação de factos, análise de um grande repositório e auditoria de dependências de ponta a ponta após uma alteração de esquema ou contrato.
### Cenário 1. Investigação aprofundada com verificação de factos
Imagine que está a reunir material para um artigo ou uma proposta comercial. Primeiro, precisa de recolher 5–10 afirmações de fontes públicas e depois verificar cada uma — encontrar a fonte original, confirmar que a citação é exata e calcular os valores reais.
Antes da v2.1.172, tinha duas opções. Ou fazia tudo com um único subagente, que se arrastava por 30 pedidos web e enchia o respetivo contexto com tudo. Ou dividia o trabalho manualmente: um prompt para extrair as afirmações e, depois, um ciclo pelas afirmações, lançando um subagente separado para cada uma. A conversa principal enchia-se de paredes de listas intermédias.
Na receita abaixo, o chat principal delega em `research-orchestrator` (nível 1). O orquestrador extrai as afirmações e envia cada uma a `fact-verifier` (nível 2); cada verificador delega pesquisas focadas em `web-deep-search` (nível 3). A conversa principal recebe apenas uma lista de afirmações verificadas com fontes. Tudo o resto fica nas janelas dos filhos e nunca entra no seu contexto.
### Cenário 2. Análise de um grande repositório
Foi-lhe entregue um projeto com 200 ficheiros. Precisa de compreender a arquitetura, encontrar os módulos principais e avaliar a dívida técnica. Execute `Glob` e uma dúzia de chamadas `Read` manualmente e, em 10 minutos, a janela estará cheia.
A profundidade resolve o problema assim: a conversa principal lança um subagente “architect”. O arquiteto cria internamente três filhos — um inspeciona a estrutura de diretórios (executa `Glob` e faz um resumo), o segundo lê 5 ficheiros de configuração essenciais e o terceiro procura os principais padrões com grep. Cada um devolve um resumo conciso ao arquiteto. O arquiteto reúne a informação e dá à conversa principal um relatório final com meia página. Obtém um mapa do projeto sem inundar o contexto com uma parede de resultados de `cat` de todos os ficheiros.
### Cenário 3. Análise de dependências de ponta a ponta
Vai alterar um esquema de base de dados, um contrato de API ou um ficheiro de configuração partilhado. Precisa de perceber onde se farão sentir os efeitos. Esta tarefa consome contexto mais depressa porque há muitas dependências e cada uma tem de ser verificada no código-fonte.
Com profundidade, a conversa principal lança um “impact-analyzer” (nível 1). Este lança um `dependency-tracer` para cada ficheiro afetado (nível 2). Cada rastreador lança internamente um `consumer-finder` (nível 3), que procura no código-fonte os consumidores dessa dependência. Cada um devolve apenas a conclusão: “estes três sítios vão deixar de funcionar”. A conversa principal reúne tudo numa tabela de “ficheiros afetados → impacto” sem conhecer os resultados das pesquisas com grep.
## Como configurar subagentes aninhados em 10 minutos
Ideia principal
Não são necessárias flags nem atualizações de configuração. Basta adicionar `Agent` a `tools` de um agente filho para que possa lançar os seus próprios subagentes. Para impedir que a árvore se transforme num casino, use a lista de permissões `Agent(name1, name2)`. A seguir, apresento um modelo pronto a usar para um orquestrador de três níveis que pode copiar.
**Passo 1. Confirme que está na v2.1.172 ou superior.**
```bash
claude --version
```
Se for inferior, atualize. A principal funcionalidade da versão é uma linha nas notas da versão: “Os subagentes podem agora criar os seus próprios subagentes, até 5 níveis de profundidade” ([texto completo](https://github.com/anthropics/claude-code/releases/tag/v2.1.172)).
**Passo 2. Crie um agente progenitor que possa lançar filhos.**
Ficheiro `.claude/agents/research-orchestrator.md`:
```markdown
---
name: research-orchestrator
description: Delegates research with a deep fact-check
tools: Agent(fact-verifier), Read, WebFetch
model: opus
---
You are a research orchestrator. When you get a topic:
1. Lê o material fornecido ou obtém os URLs públicos de origem fornecidos.
Extrai tu próprio até 5 afirmações concretas. Para cada uma, regista o texto,
o URL ou ficheiro de origem e a passagem exata de suporte.
Se não houver material de origem, pede-o antes de delegar.
2. For each claim call fact-verifier - it spawns
its own child subagents for web search and cross-checking.
3. fact-verifier returns only the final verdicts to you -
do not load intermediate dumps into your context.
Final report - only an array { claim, sources[], confidence }.
```
A linha `tools` concede apenas o tipo de filho `fact-verifier`. Extrair afirmações é o primeiro passo do próprio orquestrador, pelo que não é necessário um ficheiro indefinido `claim-extractor`. Uma lista de tipos limita que filho pode ser chamado; não limita o número de lançamentos desse tipo. Mantenha a receita limitada a cinco afirmações extraídas.
**Passo 3. Crie um agente filho que possa criar netos.**
Ficheiro `.claude/agents/fact-verifier.md`:
```markdown
---
name: fact-verifier
description: Checks a claim through child web searches
tools: Agent(web-deep-search), Read
model: sonnet
---
You are a fact-checker. When you get a claim:
1. Write 2-3 search queries.
2. For each one run web-deep-search - it will do
WebSearch and WebFetch itself and return verified snippets.
3. Combine them into one verdict: { claim, sources[], confidence }.
```
Vê a parte essencial? A linha `tools` volta a indicar `Agent(web-deep-search)`. Isso significa que o fact-verifier (nível 2 na nossa árvore) pode lançar outro subagente. Antes, esta linha não tinha efeito — a documentação ainda contém a frase:
Os subagentes não podem criar outros subagentes, pelo que Agent(agent_type) não funciona nas definições de subagentes.
— Claude Code Docs, https://code.claude.com/docs/en/sub-agents
Com a v2.1.172, essa linha está desatualizada. A sintaxe é a mesma, mas agora funciona em qualquer nível da árvore.
**Passo 4. Crie um bisneto.**
Ficheiro `.claude/agents/web-deep-search.md`:
```markdown
---
name: web-deep-search
description: Runs a web search and returns snippets
tools: WebSearch, WebFetch
model: haiku
---
You received a search query. Run WebSearch, pick the top 3
relevant URLs, use WebFetch to pull verbatim confirmations
of the claim. Return an array { url, snippet, supports_claim: yes|no }.
```
O bisneto não tem `Agent` em `tools`, por isso não cria mais níveis na árvore.
**Passo 5. Execute o orquestrador.**
```bash
claude --agent research-orchestrator
```
Forneça depois o texto de origem ou URLs públicos no chat: «Extrai e verifica até 5 afirmações concretas destas fontes; devolve afirmações, fontes e confiança.» Com `--agent research-orchestrator`, a própria sessão é o orquestrador; os filhos de verificação e pesquisa acrescentam dois níveis delegados abaixo dele. Se uma sessão principal normal delegar neste orquestrador, existem três níveis delegados abaixo dessa sessão principal.
## Que 5 padrões antitécnicos desperdiçam tokens e destroem a observabilidade?
Ideia principal
A profundidade é dispendiosa. Cada nível abaixo multiplica os tokens, e essa multiplicação acumula-se. Eis cinco cenários em que o aninhamento o prejudica. Não faça isto — ou esgotará o orçamento diário numa hora e perderá o rasto do erro quatro pisos abaixo na árvore.
**Padrão antitécnico 1. A tarefa cabe numa janela.**
Se um subagente consegue tratar da tarefa sem ruído, não acrescente níveis: o aninhamento só acrescenta custos e latência.
**Padrão antitécnico 2. Procura velocidade, não isolamento.**
Se quer velocidade, precisa de **paralelismo**, não de profundidade. Lance 5 subagentes lado a lado no mesmo nível em vez de criar uma cadeia. A profundidade serve para transferir trabalho preparatório ruidoso para uma janela filha, não para acelerar o processo.
**Padrão antitécnico 3. O trabalho é intrinsecamente pouco profundo.**
“Encontra este ficheiro e mostra-mo” é um **pedido de dois passos**; não precisa de uma hierarquia de três níveis. O aninhamento compensa quando uma tarefa contém uma subtarefa ruidosa. Se não houver ruído, não acrescente subagentes.
**Padrão antitécnico 4. Prompts vagos no primeiro nível.**
Este é o cenário mais perigoso. Se der um prompt vago ao orquestrador do nível 1, a vagueza multiplica-se. Um prompt vago no nível 1 transforma-se em 4 prompts vagos no nível 2 e 16 no nível 3. Quando os netos começam a trabalhar, nem sequer sabem o que procuram.
**Padrão antitécnico 5. Crescimento geométrico dos custos.**
O principal argumento económico: o aninhamento multiplica o uso de tokens, e essa multiplicação acumula-se com a profundidade.
Uma estimativa: uma cadeia de profundidade 3 com uma ramificação de 3 em cada nível significa 27 subagentes. São, pelo menos, 27 vezes mais tokens do que um pedido simples. No plano Pro do Claude, esse cálculo esgota o limite diário em poucas horas. Se estiver num plano Max, esgotará o limite de uma semana num dia.
**Padrão antitécnico extra (da minha experiência): “50 agentes a fazer trabalho inútil”.**
Quando observo os projetos de outras pessoas, vejo isto muitas vezes: “Tenho 50 agentes a trabalhar.” Pergunto: o que estão a fazer? E esses 50 agentes estão **a fazer trabalho inútil**. Geram montes de resultados desnecessários, imensos resumos em bruto, duplicados e paredes de registos. Cada um faz algo “útil em geral”, e o resultado é um contexto afogado e uma fatura de tokens como a de uma pequena empresa. A profundidade 5 não resolve este problema — **torna-o pior**. Se já não está claro no nível 1 quem faz o quê, a profundidade 5 significa cinco níveis de confusão.
Antes de lançar qualquer subagente, responda a 4 perguntas em meio minuto:
- O que faz exatamente (numa frase)?
- Em que ficheiros mexe?
- O que devolve ao progenitor?
- Quem o verifica?
Se não conseguir responder em 30 segundos, esse subagente não devia existir. Expliquei esta regra em separado no meu guia [sobre subagentes paralelos](https://ailoot.ai/blog/pt-pt/claude-code-parallel-worktree-agents/).
## Porque é que o aninhamento sem engenharia de contexto significa 5 níveis de alucinações?
Ideia principal
A principal armadilha da delegação profunda é a falta de contexto da tarefa. Um filho não recebe automaticamente toda a conversa do pai nem todos os ficheiros lidos. Subagentes personalizados normalmente carregam as instruções CLAUDE.md aplicáveis, salvo configuração para as omitir; isso não carrega automaticamente todos os ficheiros empresariais referenciados. Passe o material de origem exato, os caminhos e o contrato do resultado em cada delegação.
É aqui que as pessoas perguntam muitas vezes: «Atualizei o Claude Code, adicionei Agent a tools, a árvore está a ser criada, mas a resposta final continua errada. Porquê?»
A resposta é simples. Todos os subagentes do Claude Code começam **do zero**. Segundo a documentação oficial:
Cada subagente começa numa janela nova e isolada. Não consegue ver o histórico da conversa, as competências que já foram utilizadas nem os ficheiros que o Claude já leu.
— Claude Code Docs, https://code.claude.com/docs/en/sub-agents
No nível 1, isto é controlável: o orquestrador transmite uma descrição breve da tarefa ao seu filho. Mas, no nível 3, o bisneto recebe uma mensagem de delegação do progenitor, que também só tinha recebido uma mensagem de delegação. Cada um transmitiu um pouco de informação. No nível 5, tem um subagente cuja janela contém a frase “verifica a afirmação X” e nada mais. Não sabe em que projeto está a trabalhar, que tarefa está a resolver nem em que se deve concentrar.
Sem [CLAUDE.md](https://ailoot.ai/blog/pt-pt/claude-md-template/), um descendente do nível cinco é como um funcionário que aparece no escritório pela primeira vez na vida sem receber qualquer orientação. Vai fazer alguma coisa porque recebeu uma tarefa. Mas não será aquilo de que o projeto precisa.
## O que mais mudou na v2.1.172 além do aninhamento?
Ideia principal
A versão é toda dedicada aos subagentes. Além da principal funcionalidade, inclui 4 correções à infraestrutura de delegação. Uma delas corrige um erro que só pode ocorrer com o aninhamento.
Abra as notas completas da v2.1.172 e verá que toda a versão é dedicada aos subagentes.
**Correção 1.** Um subagente em segundo plano deixa de ficar «preso» como ativo no painel de agentes depois de ser parado o subagente aninhado que lançou. Este erro só pode ocorrer com o aninhamento.
**Correção 2.** As restrições de `availableModels` passam agora a aplicar-se também aos subagentes. Antes, se limitasse os modelos que a equipa podia utilizar (por exemplo, proibindo o opus para poupar dinheiro), os subagentes podiam contornar a regra com uma substituição na sua própria configuração. Com a v2.1.172, a regra aplica-se em todo o lado.
**Correção 3.** A seta para cima no histórico de prompts mostra agora os prompts do separador **atual** do subagente, e não do agente principal. Um aperfeiçoamento da observabilidade.
**Correção 4.** O consumo de CPU em inatividade diminui: o indicador `/goal` deixa de redesenhar o terminal a 5 Hz quando está inativo, e a interface redesenha-se com menos frequência enquanto os subagentes paralelos estão a trabalhar.
Quero salientar que as quatro correções dizem respeito a subagentes. Isso significa que a Anthropic lançou toda a infraestrutura de aninhamento, não apenas uma linha nas notas da versão. O aninhamento já era utilizado internamente na Anthropic há algum tempo antes da publicação.
## Lista de verificação: quando o aninhamento ajuda e quando prejudica
Ideia principal
Antes de lançar cada novo subagente, avalie a tarefa com 6 verificações. Se pelo menos 3 respostas forem “sim, usar profundidade”, faça-o. Caso contrário, opte pelo paralelismo ou por um único subagente. Assim, poupará tokens, dores de cabeça e algumas horas a tentar perceber o que fazia uma cadeia de 27 lançamentos aninhados.
Use o aninhamento se:
- A tarefa contém uma subtarefa com um grande volume de pedidos web, pesquisas com grep ou leituras de ficheiros.
- É aceitável perder essa subtarefa (se o bisneto responder “não encontrei nada”, o orquestrador pode continuar).
- **Não precisa** dos resultados intermédios na janela principal.
- Tem um `CLAUDE.md` e contexto do projeto organizado em que o subagente pode confiar.
- Consegue descrever claramente o que cada nível irá devolver (entrada, saída, formato).
- Está num plano Max ou tem margem para ×27 tokens.
Não use o aninhamento se:
- Um subagente consegue resolver a tarefa sem ruído.
- Precisa dos resultados intermédios na janela principal (isso significa que pretende paralelismo).
- O projeto não tem `CLAUDE.md` ou só tem pouco contexto empresarial.
- Os prompts do nível 1 são vagos (a vagueza multiplicar-se-á exponencialmente pela árvore).
- Precisa de velocidade — o paralelismo é mais rápido do que a profundidade para um resultado comparável.
- Está no plano Pro e trabalha o dia inteiro — esgotará o limite em poucas horas.
Há mais materiais disponíveis no [Ailoot](https://ailoot.ai/).
## Perguntas frequentes
### Preciso de criar claim-extractor para a receita copiada?
Não. O research-orchestrator corrigido extrai pessoalmente até cinco afirmações do material fornecido. Crie os três ficheiros apresentados — research-orchestrator, fact-verifier e web-deep-search — e forneça depois o texto ou URLs de origem.
### Permitir apenas fact-verifier limita o número de filhos lançados?
Não. A lista de tipos limita qual o tipo que pode ser invocado, não quantas invocações ocorrem. A receita limita separadamente a extração inicial a cinco afirmações; acompanhe as chamadas reais e os tokens usados.
## Ailoot · A empresa e a sua carteira de projetos
A Ailoot assenta numa experiência operacional consolidada, numa ampla base de clientes, num serviço estável e no acompanhamento contínuo dos KPI.
A empresa e a sua carteira de projetos: milhões de clientes; vendas mensais na ordem dos milhares de milhões.
A Ailoot aplica essa experiência operacional ao acesso por API a funcionalidades de IA nos produtos dos clientes, agentes, aplicações e automatizações.