Como escrever um documento de escopo para agentes de IA

Publicado em agosto de 2026.

TL;DR: Um documento de escopo é o que transforma “quero um agente de IA para o meu negócio” em um número que você pode cotar e que o cliente pode aprovar. Ele precisa de seis partes: o gatilho, as entradas, as saídas, as ferramentas que ele toca, o que fica explicitamente excluído, e uma lista escrita de testes de aceitação. Escreva-o antes de cotar uma taxa de construção, não depois. Eu cobro o meu como um entregável de auditoria de preço fixo, entre $500 e $1.000, separado da construção.

[Perspectiva do operador] Gerencio mais de 30 agentes em produção para uma marca de consultoria e para o Pickleland, uma instalação de pickleball em Pflugerville, TX, e defini o escopo de construções de agentes para clientes com base nessa experiência. O motivo mais comum pelo qual um projeto de agente dá errado não é o código — é ninguém ter escrito o que “pronto” significava antes da fatura sair. Um documento de escopo resolve isso em uma única sessão. É o entregável menos glamouroso que eu produzo e o que evita mais discussões.

Índice

Por que um documento de escopo, não um e-mail de proposta

Um e-mail de proposta descreve o que você vai fazer. Um documento de escopo define como é “pronto” — de forma específica o suficiente para que você e o cliente possam comparar com o agente finalizado e concordar, sem precisar conversar, se ele passou.

Essa distinção importa porque a precificação de agentes de IA só funciona se a taxa de construção estiver amarrada a algo fixo. Cote um preço fixo contra um escopo indefinido e você cotou um número que não consegue realmente entregar — o modelo mental do cliente de “um agente de IA para o meu negócio” continua se expandindo de graça até você contestar, e contestar depois do sinal pago é uma conversa pior do que definir o limite antes.

Eu escrevo um para cada construção, inclusive as pequenas. Um agente de fluxo único recebe uma versão de meia página. Um sistema multiagente recebe o documento completo. O formato não muda — só o tamanho.

As seis coisas que um documento de escopo precisa ter

1. O gatilho. O que inicia a execução do agente — o envio de um formulário, um horário agendado, um e-mail recebido, um webhook de outra ferramenta. Nomeie o gatilho exato, não uma categoria de gatilho. “Roda quando um formulário de lead é enviado” é escopo. “Lida com leads recebidos” não é.

2. As entradas. Quais dados o agente recebe e de onde vêm. Liste os campos, não só a origem — “nome, e-mail, tamanho da empresa e o campo de texto livre do envio do Typeform”, não “os dados do formulário”.

3. As saídas. O que o agente produz e para onde vai. Mesma regra: nomeie o destino e o formato. “Posta uma resposta rascunho no canal #leads do Slack para aprovação humana” é escopo. “Responde aos leads” não é.

4. As ferramentas e integrações que ele toca. Toda API, banco de dados ou plataforma que o agente chama. É também onde você anota tudo que você explicitamente não está integrando — um cliente que presume que o CRM dele está incluído porque mencionou isso uma vez na chamada de descoberta é a fonte mais comum de desvio de escopo que já vi.

5. O que fica excluído. Uma lista curta e explícita de coisas que o agente não vai fazer, mesmo que pareçam relacionadas. Se você está construindo um agente de classificação de leads, escreva “não envia mensagens de saída” mesmo que isso pareça óbvio — óbvio para você não é óbvio para um cliente que nunca definiu escopo de software antes.

6. A lista de testes de aceitação. A lista real de casos que o agente finalizado precisa passar antes do pagamento final ser devido. Não “funciona bem” — casos específicos e verificáveis: “classifica corretamente 9 de 10 leads de amostra do conjunto de dados fornecido”, “posta com sucesso no canal do Slack conectado sem intervenção manual”, “lida com um envio malformado (campo de e-mail ausente) sem travar”. Essa é a seção mais importante do documento, porque é a que ambos os lados podem apontar depois sem precisar rediscutir o que foi combinado.

O modelo

Essa é a estrutura real que eu uso. Copie, preencha as seis seções, e você tem um documento contra o qual pode colocar um preço.

AGENT SCOPE DOCUMENT — [Client name] / [Project name]
Date: [date]

1. TRIGGER
   [What starts this agent running]

2. INPUTS
   [Exact data fields and their source]

3. OUTPUTS
   [What the agent produces, in what format, sent where]

4. TOOLS & INTEGRATIONS
   Included: [every API/platform/database touched]
   Explicitly excluded: [anything adjacent that is NOT built]

5. EXCLUSIONS
   [What this agent will not do, even if related]

6. ACCEPTANCE TESTS
   [ ] [Specific, checkable test case]
   [ ] [Specific, checkable test case]
   [ ] [Specific, checkable test case]
   ...

BUILD FEE: $[amount], due [payment terms]
MAINTENANCE RETAINER: $[amount]/month, starting [date]
CHANGE REQUESTS: priced separately, quoted before work starts

Signed: _______________  Date: _______

As linhas de taxa de construção e retenção existem para que o preço fique ancorado diretamente no escopo acima delas — veja como eu dimensiono os dois números se você ainda não precificou uma construção antes. Um cliente que assina esse documento está aprovando o escopo e o preço no mesmo movimento, que é o objetivo.

Como eu conduzo a chamada que produz esse documento

Eu cobro a própria sessão de definição de escopo como uma auditoria de preço fixo entre $500 e $1.000, separada da taxa de construção — nunca embutida nela, mesmo quando o cliente segue em frente. Dois motivos: isso evita que a etapa de definição de escopo vire trabalho de venda não pago, e faz o cliente levar a chamada a sério em vez de tratá-la como uma consultoria gratuita.

A chamada em si dura de 30 a 45 minutos, estruturada em torno das seis seções acima, em ordem. Eu não deixo a conversa se perder em “o que um agente de IA poderia teoricamente fazer pelo seu negócio” — essa é uma conversa diferente e mais cara, e é a que produz documentos que ninguém consegue precificar. Eu pergunto pelo gatilho primeiro, porque um cliente que não consegue nomear o que inicia o processo geralmente ainda não tem um fluxo de trabalho estável o suficiente para automatizar — o que vale a pena revelar antes de qualquer um dos dois se comprometer com uma construção.

Entregue o prompt, não a página em branco

Eu não escrevo o primeiro rascunho do documento à mão. Pego minhas anotações da chamada — muitas vezes só um parágrafo bagunçado de bullet points — e colo isso no Claude:

Here are my raw notes from a scoping call for an AI agent build. Turn them
into a scope document with exactly these six sections: Trigger, Inputs,
Outputs, Tools & Integrations, Exclusions, Acceptance Tests. For each
section, flag anything the notes don't specify clearly enough to build
against, rather than guessing or filling the gap yourself. The acceptance
tests need to be specific and checkable — reject vague criteria like
"works correctly" and either sharpen them into a concrete test case or
flag them for me to clarify with the client.

[paste raw notes]

Essa última instrução — sinalizar as lacunas em vez de preenchê-las — é a parte que importa. Um modelo vai inventar de bom grado um teste de aceitação que soa plausível para completar o documento, e um teste que soa plausível mas não corresponde ao que o cliente realmente quis dizer é pior do que um espaço em branco sobre o qual você precisa perguntar.

Erros comuns que ainda vejo as pessoas cometerem

Escrever a seção de exclusões por último, ou pular ela. A seção de exclusões é a que a maioria das pessoas trata como opcional. É a que evita mais disputas. Escreva-a antes dos testes de aceitação, não depois.

Testes de aceitação que descrevem comportamento em vez de resultados. “O agente deve entender o tom do cliente” é comportamento. “A resposta rascunho do agente é aprovada sem edições em 7 de 10 casos de amostra” é um resultado. Só resultados são verificáveis.

Definir escopo a partir de uma única conversa sem anotações escritas. Se o documento de escopo é o primeiro artefato escrito do projeto, você está reconstruindo a chamada de memória dias depois. Faça anotações durante a chamada, na ordem das seis seções, e o documento praticamente se escreve sozinho.

Deixar o cliente escrever o escopo. Um cliente descrevendo o que quer com suas próprias palavras é insumo para o documento, não o documento em si. A linguagem dele costuma ter forma de funcionalidade (“quero que ele cuide dos meus leads”), não forma de teste. Traduzir isso em critérios de aceitação verificáveis é o valor real da sessão de definição de escopo — é por isso que ela é um entregável pago, e não um formulário que o próprio cliente preenche.

As ferramentas que uso para conduzir isso

Claude redige o documento a partir das anotações brutas da chamada usando o prompt acima, e sinaliza lacunas em vez de tentar adivinhar.

Notion é onde o documento de escopo finalizado fica, compartilhado com o cliente antes de qualquer sinal ser cobrado — o mesmo lugar onde guardo o restante do histórico do projeto.

Airtable rastreia quais projetos estão em definição de escopo, assinados ou em construção, uma linha por cliente, para que um documento de escopo nunca fique semanas sem assinatura sem que ninguém perceba.

Perguntas frequentes

Quão longo deve ser um documento de escopo?

O tanto que for preciso para tornar cada teste de aceitação verificável, e nem um pouco mais. Um agente de fluxo único pode ter meia página. Um sistema multiagente com várias integrações pode chegar a duas ou três páginas. O tamanho não é o objetivo — o objetivo é que um cliente e um desenvolvedor, lendo os testes de aceitação de forma independente, concordem se eles passaram.

E se o cliente quiser mudar o escopo depois de assinar?

Isso é uma solicitação de mudança, precificada separadamente e cotada antes do trabalho começar — escreva esse termo no próprio documento, como no modelo acima. Um documento de escopo que pode ser silenciosamente expandido depois da assinatura não é, na prática, um documento de escopo.

Preciso de um documento de escopo para automações bem pequenas?

Sim, só que curto. O valor não está no tamanho — está em ter uma lista de testes de aceitação escrita antes de começar a construir, para que “pronto” seja uma checklist em vez de uma sensação. Já tive projetos pequenos e definidos informalmente que se estenderam mais do que projetos grandes e devidamente escopados, exatamente por esse motivo.

De quem é o documento de escopo em si — ele faz parte do entregável?

Eu trato como algo que pertence ao cliente para guardar, independentemente de ele seguir para a construção ou não, já que ele pagou pela auditoria que o produziu. O que eu retenho é o modelo e o prompt subjacentes, da mesma forma que retenho estruturas reutilizáveis entre projetos — a estrutura do documento é minha, o conteúdo preenchido sobre o negócio específico do cliente é dele.

Próximos passos: Meu curso de agentes de IA para iniciantes aborda a construção dos agentes que um documento de escopo como esse descreve. O programa cowork é para operadores que querem um ambiente estruturado para praticar a definição de escopo e a construção desse tipo de trabalho. Se preferir ter o documento de escopo escrito para você, agende uma sessão de 30 minutos.