FALA INTEGRAL · TEXTO REVISADO

Bem-vindo à formação Agentic Pro. Ao longo dos próximos módulos, o objetivo é que você olhe para uma tarefa do seu trabalho e saiba transformá-la em um processo com IA: um processo que recebe uma entrada, executa etapas e entrega algo que você consegue conferir.

Vamos construir essa lógica em cima de um exemplo. Imagine que uma reunião com um cliente termina. A IA organiza o que o cliente pediu, prepara uma proposta e deixa o documento no lugar certo, aguardando a sua aprovação. Você continua responsável por confirmar o escopo e aprovar a entrega. O que muda é que você deixa de conduzir cada passagem, copiando e colando informações de um lugar para outro.

Esse é o ponto de chegada da formação. Para chegar lá, primeiro vamos conhecer o ambiente em que o trabalho acontece. Depois, você vai aprender a ensinar um procedimento para a IA, conectar ferramentas e coordenar as etapas.

FALA INTEGRAL · TEXTO REVISADO

Cada aula tem três momentos: uma explicação curta, uma demonstração e a conferência do resultado. Quando chegar a hora de você fazer, pause o vídeo. O tempo da sua prática é seu, e pode ser maior do que o da aula.

Vamos começar pelo Claude e, depois, levar um caso para o Codex. Assim, você vê o que muda de uma ferramenta para outra e o que permanece no processo. Você pode começar sem conhecer todas as telas.

Os exemplos de cliente, preços e pedidos são fictícios. Eles permitem que você repita a sequência sem mexer nos dados do seu negócio. Quando o percurso estiver claro, você adapta a entrada, as regras e a saída para o seu trabalho.

Se alguma tela estiver diferente da que aparece aqui, procure a função que estamos usando. O que vale guardar é o que precisa acontecer e como verificar. O nome do botão pode mudar.

FALA INTEGRAL · TEXTO REVISADO

Para começar, escolha uma tarefa pequena que você repete. Pode ser organizar informações, preparar um documento ou consultar um sistema. Pause o vídeo e escreva três coisas: o que chega, o que você faz com isso e o que precisa sair no final.

A tarefa não precisa ser o processo mais importante da empresa. Escolha uma que você conheça bem o bastante para perceber quando a IA acertou e quando deixou algo de fora. Essa conferência vai acompanhar você até o fim da formação.

Na próxima aula, vamos ver por que usar um ambiente que executa tarefas e como isso muda o tipo de pedido que você faz.

FALA INTEGRAL · TEXTO REVISADO

Quando você usa uma IA, pode pedir uma resposta ou pedir um trabalho que envolve ações. Essa diferença ajuda a escolher o ambiente.

Para discutir uma ideia, uma conversa costuma bastar. Mas se eu quero ler arquivos de uma pasta, organizar dados, usar uma ferramenta e salvar uma entrega, preciso conferir se o ambiente oferece esses recursos. Nesta formação, vamos concentrar o trabalho no Claude Code, pelo aplicativo desktop. Com um ambiente principal, você aprende o processo com menos troca de contexto.

Isso não quer dizer que o chat nunca execute ações, nem que o Code seja o único caminho para trabalhar com agentes. Os recursos mudam e dependem das ferramentas disponíveis. A escolha aqui é de método.

Abra agora um chat e uma sessão Code de teste, sem dados pessoais, e observe qual dos dois tem acesso a pasta e a ferramentas.

FALA INTEGRAL · TEXTO REVISADO

Veja a diferença entre dois pedidos. O primeiro é: “Como posso organizar uma lista de pedidos?”. Aqui eu peço orientação. O segundo é: “Leia esta lista, separe os pedidos por situação e salve um resumo na pasta de saída”. Agora existe uma entrada, uma ação e um arquivo para conferir.

Antes de executar, eu mostro qual pasta pode ser usada e qual resultado espero. Depois, confiro o arquivo que foi salvo. Se recebo só uma explicação de como fazer, o segundo pedido ainda não foi concluído.

Faça os dois pedidos com uma lista fictícia de pedidos e compare: um devolve orientação, o outro deve deixar um arquivo para você abrir.

Você vai ouvir a expressão modo agêntico. Aqui, ela descreve um trabalho em que a IA escolhe e usa ferramentas para avançar na tarefa, observa o resultado e decide o próximo passo, dentro do acesso que recebeu. A qualidade depende também da clareza do objetivo, das instruções e da conferência.

FALA INTEGRAL · TEXTO REVISADO

O Claude pode aparecer no navegador, no aplicativo desktop, no celular, em uma extensão do Chrome e no terminal, que é a janela de comandos do computador. Com a mesma conta, o trabalho pode continuar entre alguns desses lugares, mas recursos e acessos variam. Uma sessão pode ter acesso à sua pasta local e outra não.

As capacidades que antes apareciam como Cowork foram incorporadas ao Claude. Em vez de decorar uma divisão antiga entre nomes, pergunte o que aquela sessão consegue acessar e executar.

Também vamos abandonar a ideia de uma instrução gigante para tudo. Você pode ter procedimentos especializados, chamados skills, usar um por vez e depois coordená-los. Agora vamos preparar o ambiente em que faremos isso.

FALA INTEGRAL · TEXTO REVISADO

O setup precisa permitir apenas três coisas: abrir o ambiente, trabalhar na pasta certa e executar os recursos que o exemplo usa. É essa base que vamos montar agora, antes de instalar qualquer coleção de ferramentas.

O primeiro passo é baixar o aplicativo oficial do Claude, na versão para o seu sistema. Depois, entre na sua conta e procure o Code, que é o recurso para trabalhar com os arquivos de uma pasta. Confira se ele aparece no seu plano e no seu ambiente. Planos, requisitos e versões mudam com o tempo, então use a página oficial como referência.

Se aparecer algum bloqueio durante a instalação, pare e olhe três coisas: de onde veio o instalador, o que o aviso diz e o que o fornecedor orienta. Desativar o antivírus não é o caminho. Instalar sem entender o alerta é um mau ponto de partida.

FALA INTEGRAL · TEXTO REVISADO

Agora, a pasta. Crie uma pasta só para os exercícios da formação e abra essa pasta no Code. Coloque nela o arquivo de exemplo. Em seguida, peça que a IA liste os arquivos da pasta e diga a ela onde pode salvar o resultado. Com isso você confere o acesso, e o exercício fica separado dos seus outros projetos.

Duas dependências costumam gerar confusão. A primeira: Git e GitHub não são a mesma coisa. O Git registra as versões do seu trabalho. O GitHub é um serviço que guarda e compartilha repositórios. Para uma tarefa local, você não precisa de conta no GitHub. Vamos usá-lo quando o projeto pedir.

A segunda: Node e npm. Eles também entram só quando o exemplo exigir. Algumas ferramentas que instalam skills usam o npx, que faz parte desse ecossistema. Já a instalação nativa do Claude Code é outro caminho. Quando um exemplo precisar de uma dependência, vamos dizer qual é e testar se ela funciona. Não vamos instalar tudo por precaução.

FALA INTEGRAL · TEXTO REVISADO

O teste do setup tem quatro pontos: o aplicativo abre, a conta está conectada, a sessão acessa a pasta escolhida e o resultado aparece onde você pediu. Se algum deles falhar, resolva esse ponto antes de acrescentar outra ferramenta.

Uma observação sobre o celular. O aplicativo pode ajudar a acompanhar o trabalho, mas isso não faz da sessão um acesso remoto ao seu computador. Esse uso depende do recurso e das condições de execução.

Agora é com você. Pause o vídeo, siga os passos e confira os quatro pontos, inclusive o arquivo de saída. Com a pasta preparada e o primeiro arquivo conferido, você tem um ambiente de exercício. Na próxima aula, vamos dar nome às peças que vão trabalhar dentro dele.

FALA INTEGRAL · TEXTO REVISADO

Nas próximas aulas vamos usar cinco nomes: modelo, agente, skill, MCP e plugin. Para cada um, vou usar o mesmo exemplo: resumir uma conversa.

O modelo é o recurso que interpreta o pedido e produz o raciocínio e as respostas. O agente é o sistema que conduz o trabalho, usando o modelo e as ferramentas disponíveis. A skill guarda um procedimento que pode ser reutilizado. O MCP, sigla de Model Context Protocol, é um padrão para acessar ferramentas e dados externos. E o plugin pode reunir vários desses recursos num pacote, para facilitar a instalação e o uso.

Por que separar assim? Porque cada peça responde por uma parte do trabalho. Se a resposta saiu ruim, talvez falte critério na instrução. Se a ferramenta nem chegou a ser acessada, o problema pode estar na conexão ou na permissão. Trocar o modelo nem sempre resolve.

FALA INTEGRAL · TEXTO REVISADO

Pense numa pessoa nova entrando na equipe. Você explica o que ela precisa fazer e também dá acesso às ferramentas de que ela precisa. Manual e acesso são coisas diferentes.

No nosso exemplo, o arquivo de conversa é a entrada. A skill é o manual: orienta como identificar decisões, responsáveis e pendências, e como apresentar o resumo. Agora, se eu quiser buscar essa conversa em um serviço externo, preciso de um meio de acesso.

Esse acesso pode vir de um conector. Quando o conector usa MCP, as operações ficam disponíveis de um jeito padronizado. Mas conectar não decide qual conversa escolher, o que extrair ou quando pedir aprovação. Essas decisões fazem parte do processo que vamos desenhar.

Um detalhe importante: o agente também pode agir por outros caminhos, como ferramentas locais e navegador. A ponte ajuda a entender o MCP, mas ele é um dos caminhos possíveis, não o único.

FALA INTEGRAL · TEXTO REVISADO

Quando você instala um plugin, pode receber skills, conectores e outros recursos de uma vez. Por isso, olhe o que o pacote inclui de fato antes de assumir que o nome cobre tudo de que você precisa.

Fique com esta pergunta: o que está faltando para a tarefa acontecer? Pode ser capacidade de execução, procedimento, acesso ou um critério para conferir o resultado. Ao longo da formação, você vai aprender a identificar essas partes e combiná-las.

Antes de construir o procedimento, vamos entender como escolher os recursos de modelo e acompanhar o consumo.

FALA INTEGRAL · TEXTO REVISADO

Você não precisa usar o recurso mais caro em toda tarefa para trabalhar bem com IA. Precisa escolher um recurso adequado ao problema e conferir se ele entregou a qualidade necessária.

Dois controles definem esse recurso. O primeiro é o modelo, o sistema que lê o seu pedido e produz a resposta. O segundo é o esforço, que indica o quanto esse modelo trabalha antes de responder. Mais esforço pode significar mais tempo e mais consumo.

Os modelos vêm em famílias: Fable, Opus, Sonnet e Haiku. Quais delas aparecem para você depende da sua conta e do provedor. Como regra de bolso para começar: Opus ou Fable podem ser considerados para planejar algo complexo ou longo; Sonnet, para executar etapas bem definidas; Haiku, para uma tarefa simples. São critérios iniciais para testar, não uma hierarquia que vale sempre.

Um cuidado com o Fable: ele pode exigir créditos. Confira a cobrança antes de selecioná-lo.

Nomes, níveis de esforço e disponibilidade mudam. Por isso, vamos olhar o que aparece na conta usada na demonstração e consultar a referência atual, sem transformar uma lista de hoje numa regra permanente.

FALA INTEGRAL · TEXTO REVISADO

Considere dois pedidos. No primeiro, quero separar pedidos aprovados e pendentes de uma planilha. Eu já defini a regra e a saída. Esse é um bom candidato a um recurso mais simples, com esforço baixo ou médio. No segundo, quero desenhar o processo que vai transformar uma reunião em proposta, com acesso a sistemas e aprovação. Aqui existem escolhas que precisam ser examinadas antes da execução, e vale testar mais capacidade.

Uma estratégia possível é planejar com mais capacidade e executar etapas claras com um recurso mais econômico. Mas essa é uma escolha de trabalho, não uma garantia de economia. Se a execução exigir muitas correções, a conta pode mudar.

Agora, localize onde a ferramenta mostra o uso e os limites. No Claude Code, quando estiver disponível, o comando /usage é um exemplo dessa consulta. Diferencie três coisas: o que está incluído na assinatura, o que é consumo de API e o que usa créditos adicionais. São regras de cobrança diferentes, então não compare um número com o outro como se fossem a mesma conta. E não ative uma cobrança extra sem entender qual é a regra e como acompanhar o gasto.

Pause o vídeo e faça isso na sua conta. Você terminou quando conseguir dizer onde vê o seu uso e qual cobrança vale para o recurso que escolheu.

FALA INTEGRAL · TEXTO REVISADO

Depois de uma tarefa, pergunte: o resultado ficou correto? Quanto retrabalho houve? O recurso usado fazia sentido para aquela dificuldade? Essa comparação é mais útil do que escolher um modelo só pelo nome.

Também não basta trocar o modelo se o pedido continua vago ou se a entrada está errada. Primeiro, deixe o objetivo verificável. Depois, ajuste a capacidade quando houver motivo.

Na próxima aula, vamos cuidar de três coisas que influenciam esse trabalho: o que a IA pode fazer, quais informações ela recebe e o que você precisa guardar para continuar depois.

FALA INTEGRAL · TEXTO REVISADO

Antes de deixar a IA executar uma tarefa, defina três coisas: o que ela pode acessar, o que pode alterar e em que momento ela precisa parar para você decidir.

Isso muda conforme a tarefa. Se o trabalho ainda está mal definido, peça primeiro um plano, sem nenhuma alteração. Se já existe uma etapa pequena e clara, você pode autorizar a execução só dentro dessa etapa, por exemplo, editar arquivos da pasta de teste. Mexer em um arquivo de exercício tem um impacto bem diferente de enviar uma proposta a um cliente ou apagar uma base. Quanto maior o impacto, mais cedo você quer ser consultado.

Os modos de permissão ajudam a controlar esse comportamento, mas quem define o limite é o escopo que você escreve. Automático e bypass não são a mesma coisa, então confira na sua ferramenta o que cada um libera antes de ativar. Nenhum modo serve para toda situação. Se a dúvida é sobre uma ação importante, peça que a IA explique o que vai fazer antes de seguir.

O controle remoto é outro ponto de acesso. Ele depende de ativação, de acesso à sua conta e do ambiente onde a sessão está rodando. Trate como um recurso específico, que você confere e liga por conta própria. Instalar o aplicativo no celular não liga esse recurso sozinho.

FALA INTEGRAL · TEXTO REVISADO

Contexto é o conjunto de informações que a IA tem disponível naquela tarefa: a conversa, os arquivos lidos e as ferramentas usadas. Memória persistida e arquivos de instrução são outro caminho, porque levam informações para trabalhos futuros. São coisas diferentes, e vale saber em qual delas cada informação está.

Dependendo da versão que você usa, existem comandos como /context e /compact. O primeiro permite inspecionar o que está ocupando o contexto, e o segundo compacta a conversa atual. Eles agem sobre a sessão em andamento. Não gravam nada em arquivo persistente.

No exemplo, vou usar um arquivo de contexto mínimo na pasta do exercício, com apenas o que ajuda o trabalho: qual é o processo, quais arquivos usamos, quais decisões já foram tomadas e o que falta. Para resumir uma reunião, a IA não precisa de mais do que isso.

Se você vem do ChatGPT, pode pedir lá um resumo das informações úteis para este trabalho. Revise o texto e traga para o contexto só o necessário. Nada é importado automaticamente, e dados sensíveis ficam de fora.

Agora, uma pasta real do computador é diferente de um grupo de conversas na interface. Organizar chats em um grupo não prova que os arquivos foram colocados naquela pasta. Para conferir, abra o caminho no computador e veja o que foi salvo.

Conversas longas e muitas ferramentas carregadas aumentam o contexto. Existem cache e compactação, mas eles não tornam todo o histórico gratuito, nem garantem que cada detalhe seja preservado. Decisões importantes ficam melhor em arquivos que você consegue revisar.

FALA INTEGRAL · TEXTO REVISADO

Quando for retomar um trabalho, informe quatro coisas: o objetivo, o estado atual, os arquivos relevantes e o próximo passo. Se pedir um resumo de passagem para abrir uma nova conversa, abra o arquivo e confira se ele guardou as decisões que realmente importam antes de seguir.

Faça também uma visita às configurações de privacidade. Veja quais controles existem na sua conta e o que cada um permite. Senhas e tokens não entram na conversa, porque uma configuração depois não resolve esse problema.

A missão deste módulo é deixar uma pasta de exercício funcionando e escrever um contexto mínimo do processo que você escolheu. Ao final, você deve conseguir explicar o que entra, o que deve sair e em que ponto precisa de uma decisão sua.

Agora vamos transformar uma parte desse processo em uma skill.

FALA INTEGRAL · TEXTO REVISADO

Se você explica a mesma tarefa a cada nova conversa, essa explicação pode virar uma skill.

Uma skill é uma pasta com as instruções de um procedimento e, quando necessário, arquivos de apoio. Ela pode dizer quando deve ser usada, que entrada precisa receber, quais critérios seguir e como entregar o resultado. Com isso, o agente reconhece a tarefa e parte de um padrão, em vez de começar do zero. A variação diminui, mas o resultado continua pedindo a sua conferência.

Pense num resumo de reunião. “Faça um resumo bom” deixa muita coisa em aberto. O que é importante? A decisão aparece junto de quem ficou responsável? Como registrar um prazo que ninguém definiu? Uma skill útil responde a essas perguntas antes da execução.

Agora, veja na tela a pasta e o arquivo de uma skill de exemplo.

FALA INTEGRAL · TEXTO REVISADO

Skills prontas ficam em diretórios e repositórios. Vamos usar o skills.sh para ver como procurar e inspecionar uma opção. O objetivo é aprender a escolher e instalar uma só.

Antes de instalar, leia de onde a skill vem, o que ela orienta e quais recursos usa. Ela executa scripts? Acessa a rede? Depende de uma conta ou de outra ferramenta? O nome e o número de instalações não respondem a nada disso. Popularidade não é garantia de confiança.

Depois, escolha o escopo. Dependendo do agente e do local de instalação, a skill fica restrita a um projeto ou disponível em outros trabalhos. Para um procedimento específico de um cliente, comece pelo projeto: fica mais fácil de organizar. Para algo de uso frequente, vale avaliar uma instalação mais ampla.

Depois de instalar, vamos conferir a pasta e o arquivo SKILL.md e ver se o agente reconhece a skill. Isso mostra que ela está instalada e visível. O teste só termina quando executamos uma entrada de exemplo.

FALA INTEGRAL · TEXTO REVISADO

Ao ler uma skill, procure quatro coisas. O nome identifica a skill. A descrição ajuda o agente a perceber quando usá-la. O corpo apresenta o procedimento. E os arquivos extras, se existirem, guardam exemplos, referências ou scripts, quando a tarefa realmente precisa deles.

Uma pasta cheia não é melhor por isso. O que importa é se o material ajuda a executar a tarefa sem deixar decisões importantes ao acaso.

Agora é com você. Pause o vídeo, escolha uma skill relacionada ao processo que você anotou e explique, com suas palavras, o que ela recebe e o que entrega. Se, lendo o material, você não consegue responder, ainda falta clareza. E isso vem antes de instalar.

Na próxima aula, vamos ver o que acontece quando uma skill pronta encontra uma necessidade específica.

FALA INTEGRAL · TEXTO REVISADO

Uma skill pode parecer ótima na descrição e, mesmo assim, não servir para o seu trabalho. Para descobrir, use uma entrada que você já conhece e compare o resultado com um critério claro.

Neste exercício, a entrada é uma conversa fictícia e curta. Nela existem quatro elementos que eu conheço de antemão: uma decisão, uma pessoa responsável, uma pendência e um prazo que ninguém definiu. Como sei o que está no texto, consigo conferir se o resumo manteve cada um deles.

Antes de executar, escreva o que você espera encontrar no resultado. Assim você não avalia só pela aparência ou pelo tamanho da resposta. Um resumo bem organizado ainda pode omitir uma decisão ou transformar uma sugestão em compromisso.

E use sempre esta mesma conversa, em todas as comparações. Se a entrada muda, você deixa de saber o que causou a diferença.

FALA INTEGRAL · TEXTO REVISADO

Execute a skill com a conversa e confira o resultado com quatro perguntas. A decisão apareceu? O responsável é a pessoa certa? A pendência continua como pendência? E o prazo, que ninguém definiu, aparece como não informado, e não como uma data inventada?

Se alguma resposta for não, olhe o procedimento da skill. Por exemplo: uma skill que ordena tudo por urgência, sem explicar o que é urgente, esconde uma decisão dentro do procedimento. No nosso trabalho, pode ser mais útil separar decisões, ações e perguntas abertas. Esse ajuste muda a utilidade da saída.

Mude um critério por vez e repita o teste com a mesma conversa. Assim você liga a mudança à diferença no resultado. Se trocar a entrada, o formato e a regra ao mesmo tempo, não dá para saber o que melhorou.

Antes de alterar, guarde uma cópia do procedimento original. Se o resultado piorar, você compara e volta para a regra anterior.

FALA INTEGRAL · TEXTO REVISADO

Uma skill pronta é um ponto de partida. Ela foi feita para um conjunto de situações que pode ser diferente do seu. Você pode aproveitar a estrutura e adaptar o procedimento, desde que saiba o que está mudando.

Agora escolha um ajuste que faria diferença no seu processo: uma informação obrigatória, uma regra de prioridade ou um formato de entrega. Escreva por que ele importa e como você vai conferir se a skill o respeitou. Descrever o ajuste em palavras já basta.

Na próxima aula, deixamos a adaptação pontual e criamos um procedimento nosso, com entrada, regras, saída e exemplos de teste.

FALA INTEGRAL · TEXTO REVISADO

Para criar uma skill, comece pelo processo, não pelo arquivo. Skill é uma instrução reutilizável: você escreve uma vez como o trabalho deve ser feito, e o assistente passa a consultar essa instrução quando o pedido combina com ela. Antes de escrever, responda quatro perguntas. Quando ela deve ser usada? O que ela precisa receber? O que deve fazer com essa entrada? E como alguém vai conferir a saída?

Nosso exemplo é resumir uma conversa de trabalho. A entrada é o texto da conversa. A saída separa três coisas: decisões, ações com responsáveis e perguntas abertas. Se uma informação não aparece na conversa, ela fica marcada como não informada. Por exemplo: se ninguém falou o prazo, a skill não escolhe um só para o resumo parecer completo.

Esse é o manual que vamos construir. A ferramenta ajuda a montar o arquivo, mas o critério vem de quem conhece o trabalho. Por isso vamos usar o arquivo de critérios do exercício e dois textos: uma conversa completa e outra com informações faltando.

FALA INTEGRAL · TEXTO REVISADO

Agora vou passar esse procedimento ao Skill Creator, o recurso que ajuda a montar skills e que está disponível no nosso ambiente. O pedido é: criar uma skill de resumo com os critérios do exercício, usando a conversa de exemplo e a conversa com informações incompletas.

Seja específico no pedido. Diga qual problema a skill resolve, quando ela deve ser chamada, qual é o formato da entrada e o que precisa aparecer na saída. Diga também o que ela não deve inventar e o que fazer quando uma informação faltar.

Quando a skill for criada, confira três coisas: o nome, a descrição e as instruções. A descrição deve ajudar a reconhecer pedidos reais, como “organize as decisões desta reunião”. As instruções devem deixar claro como analisar o conteúdo e como apresentar o resultado.

Confira também os arquivos que foram criados. Arquivos de referência e scripts só entram se ajudarem o procedimento. Para um resumo simples, uma estrutura com muitas partes só atrapalha a leitura. Se o processo crescer, dá para separar quem pesquisa, quem redige e quem entrega. Isso vai fazer mais sentido quando montarmos o time.

FALA INTEGRAL · TEXTO REVISADO

Agora vamos rodar os dois exemplos e olhar o que a skill produz. No texto completo, conferimos decisões, responsáveis e perguntas abertas. No texto incompleto, o teste é ver se a skill mantém a informação como não informada, em vez de inventar uma resposta.

Pedir a um modelo que avalie o arquivo pode ajudar na revisão, mas isso não vale como teste. O teste é o que a skill entrega com uma entrada do exercício. Anote o resultado de cada rodada.

Se aparecer um erro, descreva o erro e a regra que precisa mudar. Ajuste essa regra e rode de novo a mesma entrada, para comparar antes e depois. Em seguida, repita também a outra entrada, porque a melhoria em um caso pode estragar o outro.

A missão do módulo é criar uma skill para uma tarefa repetitiva do seu trabalho e testá-la com pelo menos uma entrada normal e uma incompleta. Com o procedimento claro, o próximo passo é dar à skill acesso às ferramentas que esse trabalho exige.

FALA INTEGRAL · TEXTO REVISADO

Até aqui, trabalhamos com informações que entregamos à IA. Mas muitos processos dependem de dados que estão em outro lugar: uma agenda, uma pasta compartilhada, uma ferramenta de trabalho.

Para a IA chegar a esses dados, entram os conectores. MCP significa Model Context Protocol. É um padrão para um sistema disponibilizar recursos e ferramentas que um agente pode usar. Você não precisa decorar a sigla; precisa entender o que a conexão permite fazer.

Uma comparação ajuda: o USB-C é um encaixe padronizado, e o MCP busca algo parecido. A ideia é reduzir a necessidade de criar uma ligação diferente para cada combinação de sistema e agente. Mesmo com o padrão, continuam valendo a autenticação, as permissões e os limites do serviço.

FALA INTEGRAL · TEXTO REVISADO

Vamos começar pelos conectores que o próprio ambiente oferece, e o nosso exemplo é o Notion. Abra a lista de conectores, encontre o Notion e confira quais operações ele disponibiliza. Se você usa outro serviço, o caminho é o mesmo.

Antes de autorizar, veja qual conta será conectada e qual acesso está sendo pedido. Depois de conectar, faça uma consulta de leitura a uma página de exercício. Um pedido possível é: "Busque no Notion a página do exercício e me mostre o título e os principais tópicos." Use o título que a página tiver no seu Notion. O pedido precisa dizer o que buscar e que a operação é só de leitura.

Quando a resposta chegar, compare com a página aberta no próprio Notion. Essa comparação é importante. Ter o conector listado não prova que a conta tem acesso à página certa. A consulta pode não encontrar nada, trazer outro documento ou mostrar só parte dos dados. Se isso acontecer, confira conta, permissão e identificação da entrada antes de alterar a skill.

Para criar ou alterar informações, diga também o destino e o que está autorizado. Excluir dados ou executar uma ação de impacto pede uma decisão explícita. A conexão não é uma autorização geral para qualquer operação.

FALA INTEGRAL · TEXTO REVISADO

Agora fica mais fácil separar as funções. O conector dá acesso às operações do serviço. A skill orienta quando usá-las, quais informações procurar e como organizar a entrega. A consulta que fizemos no Notion pode ser relacionada aos critérios da skill de resumo, sem montar outro fluxo.

Um conector pode rodar em um serviço remoto ou depender de um processo local. Isso muda onde ele pode ser usado: uma sessão na nuvem não recebe automaticamente os recursos instalados no seu computador.

Seu exercício é fazer uma consulta pequena de leitura no Notion e conferir a resposta na origem. Na conferência, olhe a conta conectada, a permissão, a identificação da entrada e se o retorno bate com o conteúdo da página. Quando essa base funciona, podemos explorar conectores que não estavam no catálogo inicial.

FALA INTEGRAL · TEXTO REVISADO

Nem todo serviço aparece no catálogo inicial de conectores. Alguns publicam o próprio servidor MCP, o endereço pelo qual o agente consulta e usa o serviço, e explicam como ligá-lo ao seu agente.

Vamos usar o Higgsfield como exemplo. Primeiro, procuro a orientação oficial do serviço e vejo qual caminho vale para o ambiente que estou usando. Esse passo importa porque conectar pelo aplicativo, pelo terminal ou em outro agente são configurações diferentes.

Quando o ambiente aceita conector por URL, a documentação traz o endereço do servidor. Você usa a URL oficial, autoriza no próprio serviço e volta para conferir se o acesso apareceu.

FALA INTEGRAL · TEXTO REVISADO

Com a conexão feita, peça algo que só o serviço consegue responder. Aqui, uma boa escolha é consultar o catálogo de modelos disponíveis. É uma leitura: mostra se houve uma chamada real ao Higgsfield, sem iniciar a geração de imagem ou vídeo.

Isso importa porque a IA pode dizer que conhece o Higgsfield usando apenas conhecimento geral. Por isso, na demonstração, vamos olhar duas coisas: o uso da ferramenta e o retorno da consulta.

Vale separar também acesso e consumo. Consultar o catálogo é diferente de gerar mídia, que pode usar créditos e depende das condições da conta. Antes de gerar, confira qual operação você está pedindo e como ela é cobrada.

Se você usa outro ambiente, siga a integração indicada para ele. Colar a mesma URL em qualquer tela nem sempre cria a mesma conexão. O caminho para levar daqui tem quatro passos: documentação oficial, ambiente compatível, autorização e uma chamada de conferência.

FALA INTEGRAL · TEXTO REVISADO

Como segundo exemplo, vamos usar o Apify. Em vez de gerar mídia, ele oferece ferramentas para encontrar e executar automações de coleta de dados, chamadas Actors.

Aqui vamos fazer só a descoberta: uma consulta pública que localiza um Actor e a documentação dele. Executar o Actor é outra etapa, que depende de acesso e pode ter custo. Deixamos essa parte para a aula em que ligamos uma skill de prospecção ao serviço.

Para acompanhar, você não precisa conectar dois serviços novos. Escolha um que faça sentido no seu processo e prove o acesso com uma ação pequena, como uma consulta. Na próxima aula, vamos ver como procurar uma alternativa quando você ainda não sabe qual conector usar.

FALA INTEGRAL · TEXTO REVISADO

Ao procurar um MCP, comece pela tarefa. “Preciso consultar estes dados” é um ponto de partida melhor do que “quero instalar um conector interessante”.

Primeiro, veja se o próprio serviço oferece uma integração, no site ou na documentação. Se não houver, aí sim procure em diretórios e repositórios. Eles ajudam a descobrir opções, mas não avaliam por você a origem nem o funcionamento.

Para avaliar uma opção, olhe cinco pontos: quem mantém o projeto; quais operações ele expõe; como autentica; de quais dependências precisa; e se a documentação explica a instalação. Estrelas e atualizações são sinais úteis, mas não garantem segurança, qualidade nem continuidade.

FALA INTEGRAL · TEXTO REVISADO

Vamos usar o MCP Brasil, do repositório Mcp-Brasil/mcp-brasil, para consultar dados cadastrais públicos. É um projeto independente. O nome não significa que seja um serviço oficial do governo.

O pedido leva um CNPJ de exemplo e limita a saída aos campos que queremos conferir: razão social, situação cadastral, município, a fonte da informação e o que não veio na resposta.

Se uma fonte falhar, a resposta precisa dizer isso. Se um campo estiver ausente, ele continua ausente. E não vamos pedir ao modelo uma conclusão jurídica sobre a empresa.

Depois da consulta, comparamos cada campo com a fonte de dados usada. Assim você separa três coisas: o que o conector devolveu, o que a IA interpretou e o que foi verificado de forma independente.

Se a consulta funcionar no navegador e falhar no conector, os dois resultados não valem o mesmo. O navegador mostra que a fonte respondeu por aquele caminho. Falta descobrir por que o cliente, ou a operação escolhida, não conseguiu consultar.

FALA INTEGRAL · TEXTO REVISADO

Ao pedir que a IA instale um MCP a partir de um repositório, peça antes que ela explique o que será instalado e qual acesso será usado. Você não precisa ler cada linha de código para começar, mas precisa entender a função e o alcance.

Agora, o exercício. Escolha uma ferramenta ligada ao seu processo e registre três itens: a origem do conector, a operação que ele resolve e uma consulta de teste.

Confira assim: a origem diz quem mantém o projeto; a operação corresponde à tarefa que você tem; e a consulta de teste pode ser comparada com a fonte. Se a documentação ou a autenticação não estiver clara, anote como pendência real. Não trate como detalhe.

E se o serviço tem uma API, mas não existe um MCP adequado? Esse é o próximo passo.

FALA INTEGRAL · TEXTO REVISADO

Criar um MCP faz sentido quando você precisa que o agente use um sistema e não existe uma integração adequada. Antes de construir, procure saber se o próprio serviço já mantém uma, ou se outra opção cobre a operação de que você precisa.

Neste exemplo, vamos usar um sistema de demonstração, com dados fictícios. Ele publica uma especificação OpenAPI: um documento que descreve as operações disponíveis, os parâmetros, a autenticação e as respostas. É esse documento que vamos entregar à ferramenta que cria o conector.

Dois termos, para não confundir. API é a interface pela qual um programa conversa com outro. O MCP expõe operações, como as de uma API, de um jeito que o agente consegue descobrir e usar. Os dois estão relacionados, mas não são a mesma coisa.

FALA INTEGRAL · TEXTO REVISADO

Não vamos expor todas as operações do sistema. Vamos começar por uma consulta pequena: a taxa de reembolso em um período definido. A documentação já traz essa operação, então não precisamos buscar todas as vendas e refazer a conta por conta própria.

Os dados deste ambiente são fictícios e têm datas fixas. Por isso, o intervalo será de treze de julho a onze de agosto de dois mil e vinte e seis. Se pedíssemos “últimos trinta dias” em outra data, a consulta poderia cair fora do período que a base cobre.

Agora, o pedido ao criador de MCP. Ele precisa dizer quatro coisas: qual documentação ler, qual operação disponibilizar, onde o MCP vai rodar e como a credencial será recebida. O token entra fora do chat. Ele não aparece no texto da skill, numa captura de tela da aula, nem em arquivo que você vá distribuir.

Com o conector preparado, conferimos duas coisas: os parâmetros que ele envia e a resposta que recebe. Uma ferramenta gerada sem erro não prova que a consulta está certa. E o número final precisa vir da fonte, não de um cálculo ou de um palpite do modelo.

FALA INTEGRAL · TEXTO REVISADO

Para concluir, o teste tem três verificações: o agente encontrou a ferramenta, usou o período certo e devolveu os dados que vieram da API. Compare a resposta com a operação de referência. Depois, teste também o caso sem credencial: o resultado deve explicar a falha, sem inventar um número.

Sobre rodar local ou remoto: a escolha depende de onde você precisa usar o conector. Não vamos construir os dois agora. Faça um caminho funcionar e anote do que ele depende.

Seu exercício: escolha uma operação de leitura em um sistema que você usa e encontre a documentação dela. Antes de criar qualquer coisa, escreva a entrada, a saída esperada e como você vai conferir a resposta. Pause o vídeo e faça isso.

Na próxima aula, vamos combinar esse acesso com um procedimento de trabalho.

FALA INTEGRAL · TEXTO REVISADO

Vamos juntar duas peças. O MCP dá acesso a operações em outro serviço. A skill define um procedimento. Juntas, elas formam uma unidade de trabalho: chega uma entrada, as ferramentas são usadas e sai uma entrega que você confere por critérios.

Vamos aplicar isso a uma pesquisa de empresas para prospecção. O objetivo é montar uma lista pequena, que dê para conferir. Não vamos enviar mensagens nem montar campanha.

A skill pergunta que tipo de empresa procurar e qual região considerar. Depois consulta o Apify, uma plataforma que oferece programas de coleta de dados, e organiza o resultado com a origem de cada informação. Se um dado não veio da fonte, ele fica em branco. A skill não completa a lista com informação inventada.

FALA INTEGRAL · TEXTO REVISADO

No Apify, o primeiro passo é conferir o Actor escolhido, que é um desses programas de coleta, e o formato de entrada que ele aceita. Isso vem antes de executar. Encontrar um Actor no catálogo não quer dizer que a pesquisa já foi feita.

Na demonstração, a amostra precisa ser pequena. A entrada pode ter um campo de quantidade, e ele ajuda a limitar os resultados. Mas não trate esse campo como teto de cobrança. Os limites da execução ficam nas opções de chamada do MCP, os callOptions. Por exemplo: máximo de itens, gasto total máximo e tempo limite, que no contrato aparecem como maxItems, maxTotalChargeUsd e timeout. Confira no contrato atual quais existem e o que cada um controla. E deixe desligados os enriquecimentos e as coletas que o exercício não precisa.

Terminada a execução, falta uma etapa: buscar o dataset de saída, que é a tabela com os resultados, e conferir. Um ID de execução, ou uma resposta dizendo que a tarefa começou, ainda não é a lista pronta.

A skill organiza empresa, site quando houver, origem e observações de verificação. Depois, abrimos alguns resultados e comparamos com a fonte. Duplicatas, empresas fora da região e dados ausentes são problemas do resultado. Registre cada um deles. A formatação da lista não deve escondê-los.

FALA INTEGRAL · TEXTO REVISADO

Repare no que mudou: você não orientou cada chamada nem copiou respostas para montar a lista. O procedimento diz quando consultar, o que aproveitar e como conferir a entrega.

Isso ainda não é o time completo do próximo módulo. Aqui, uma skill usa uma ferramenta para fazer uma tarefa. Depois, vamos coordenar várias skills, cada uma com sua responsabilidade e seus pontos de aprovação.

A missão deste módulo é esta: una uma skill a uma consulta que faça sentido para o seu processo e mostre onde está a prova do resultado. Para ensaiar, você pode usar dados ilustrativos, desde que diga que são ilustrativos. Só uma execução real comprova que o serviço foi consultado. Com essa base, no próximo módulo vamos desenhar o processo de ponta a ponta.

FALA INTEGRAL · TEXTO REVISADO

Você já sabe ensinar uma tarefa à IA e dar acesso a uma ferramenta. Agora vamos coordenar etapas. Antes de criar um time, precisamos desenhar o processo que esse time vai executar.

Nosso caso é o Ateliê Horizonte, um prestador de serviço fictício. Uma reunião com o cliente termina, e é preciso preparar a proposta. Entre a conversa e o documento pronto, existem decisões: o que o cliente pediu, o que entra no escopo, ou seja, no que será entregue, qual é a referência de preço e quem precisa aprovar.

Se essas decisões ficarem escondidas, o time só vai automatizar a confusão. Por isso, vamos começar com cinco perguntas. Usaremos este mesmo exemplo até o fim do módulo.

FALA INTEGRAL · TEXTO REVISADO

Primeira pergunta: o que dispara o processo? No nosso caso, uma reunião termina e a transcrição fica disponível.

Segunda: o que entra e o que sai? Entram a transcrição, o modelo de proposta e a tabela de serviços. Sai uma proposta salva para aprovação, com os dados de origem identificados.

Terceira: quais são as etapas, na ordem? Buscar a transcrição, organizar o pedido, confirmar o entendimento, preparar a proposta e entregar no destino.

Quarta: onde precisamos de uma ferramenta de fora? O Zoom é a origem da transcrição, e o Google Drive é o destino do documento. O acesso a cada serviço precisa ser configurado e conferido.

Quinta: onde uma pessoa precisa decidir? Em dois pontos: antes de tratar como escopo um entendimento que pode estar errado, e antes de enviar a proposta ao cliente. Essas aprovações fazem parte do desenho do processo.

Com as cinco respostas, as responsabilidades ficam visíveis. Analisar a reunião, montar a proposta e entregar para aprovação podem ser três habilidades, as skills, separadas. Cada uma recebe uma entrada e entrega uma saída para a próxima.

FALA INTEGRAL · TEXTO REVISADO

Nem todo clique precisa virar uma skill. Separe uma etapa quando ela tem uma responsabilidade clara e pode ser testada sem depender do processo inteiro.

Compare dois passos. “Cuidar de propostas” é amplo demais para conferir. “Extrair da reunião o pedido, as entregas, o prazo citado e as perguntas abertas” diz o que entra, o que a IA faz e o que sai. E permite comparar o resultado com a transcrição.

Agora é com você. Escolha um processo seu e responda às cinco perguntas antes de montar qualquer automação. Depois, confira: cada passo tem uma entrada, uma ação e um resultado que você consegue comparar com a fonte? Se você não sabe qual deve ser a saída, a IA também não tem um critério confiável de conclusão.

Na próxima aula, vamos aplicar esse desenho e testar as três habilidades separadamente. Primeiro, fazemos cada peça funcionar. Depois, tiramos de você o trabalho de passar o resultado de uma para outra.

FALA INTEGRAL · TEXTO REVISADO

Nesta aula, vamos levar um caso da reunião até a proposta pronta para aprovação. O trabalho se divide em três responsabilidades: resumir o pedido, montar o documento e entregar para aprovação.

O cliente do exercício é o Ateliê Horizonte, um negócio fictício. Ele quer organizar pedidos numa planilha, importar até cem registros e receber uma orientação de uma hora. O teto de investimento citado é de mil e oitocentos reais, e o prazo desejado é de dez dias corridos depois do recebimento dos dados.

Cliente, valores e prazo são fictícios e existem só para o exercício. No Zoom, você vai selecionar a reunião de teste e conferir se a transcrição corresponde a este caso. A cópia em texto, na pasta de apoio, serve para consultar o conteúdo.

Além da reunião, vamos usar uma tabela de serviços e um modelo de proposta, também fictícios. Eles dizem à skill qual é o escopo e como o documento deve ser montado. Se algum desses arquivos faltar, a skill precisa apontar a referência ausente e pedir esclarecimento antes de seguir.

FALA INTEGRAL · TEXTO REVISADO

Vamos criar cada skill com o Skill Creator, usando os exemplos e critérios já preparados, e testar uma de cada vez.

A primeira skill busca a transcrição da reunião indicada e extrai necessidade, entregas, prazo, orçamento e perguntas abertas. A saída precisa separar o que foi dito do que está faltando. Se não houver transcrição, ou se não for a reunião correta, ela para e avisa.

Depois, eu confiro esse entendimento. O teto de investimento não é automaticamente o preço da proposta. Na tabela do exercício, a planilha custa novecentos reais, a importação custa trezentos e a orientação custa trezentos. O total dos serviços é de mil e quinhentos reais, abaixo do teto de mil e oitocentos.

A segunda skill recebe o entendimento confirmado, o modelo e a tabela, e monta a proposta dentro desse escopo. Um aplicativo, um site ou uma cobrança automatizada ficam de fora, porque não fazem parte do pedido. E uma estimativa continua sendo estimativa: ela não vira um compromisso novo.

A terceira skill entrega o documento na pasta de aprovação do Drive. A saída deve identificar o arquivo e informar que ele aguarda revisão. Eu abro a pasta, confiro o documento e comparo o conteúdo com o que foi aprovado na etapa anterior.

Cada peça roda sozinha por um motivo. Se o escopo vier errado, eu sei onde corrigir. Se o documento não estiver no Drive, não preciso refazer a análise da reunião.

FALA INTEGRAL · TEXTO REVISADO

Uma proposta com boa aparência não encerra o teste. Precisamos conferir os serviços, o total, o prazo e as exclusões. Depois, verificar se o arquivo está na pasta correta e se continua aguardando aprovação.

Agora vamos testar uma reunião em que o orçamento não foi informado. O resultado correto preserva essa ausência e pede a informação necessária. Um valor inventado só para a proposta parecer completa é um erro.

Por enquanto, a passagem entre as três skills é feita por você. Chama a primeira, confere a saída, entrega à segunda e depois aciona a terceira. Esse caminho serve para testar as peças, mas deixa a coordenação na sua mão.

Na próxima aula, vamos transformar essa sequência em um time orquestrado, mantendo os pontos em que a decisão continua sendo humana.

FALA INTEGRAL · TEXTO REVISADO

Já temos as três skills do caso, e cada uma tem entrada e saída definidas. Até aqui, quem levava o resultado de uma para a outra era você: chamava uma skill, lia o que ela entregou e passava para a seguinte. Esse é o fluxo manual, e vamos usá-lo como ponto de comparação.

Agora vamos criar mais uma skill, que cuida do percurso inteiro: a orquestradora.

Ela recebe o objetivo, chama a skill adequada para cada etapa, confere o que veio e repassa para a etapa seguinte. E ela sabe quando precisa parar para uma decisão sua.

Isso é diferente de escrever “faça tudo sozinho” no começo de um pedido. Aqui, a autonomia se apoia em responsabilidades e critérios que você já definiu. Se faltar uma dependência, ou se um resultado não puder ser conferido, o processo mostra esse ponto. Ele não segue em frente como se estivesse tudo certo.

FALA INTEGRAL · TEXTO REVISADO

Vamos ao pedido inicial. Ele identifica a reunião e pede a proposta pronta para revisão.

A orquestradora começa buscando e analisando a transcrição. Em seguida, apresenta o entendimento do escopo e pede a sua confirmação. Essa é a primeira parada.

Com o escopo confirmado, ela chama a skill de proposta, que usa o modelo e a tabela. A etapa seguinte entrega o documento no Drive e devolve a referência para você abrir. O estado final é “aguardando aprovação”. Essa é a segunda parada: a proposta espera a sua revisão, e este fluxo não tem autorização para enviar nada ao cliente.

Repare que a IA não pede decisão sobre cada detalhe operacional. Ela pede as decisões que você reservou. E a confirmação do escopo vale só para o escopo: não é também aprovação de preço, do documento ou do envio.

No teste, vamos usar a mesma reunião do exercício anterior. Assim, você compara o percurso manual com o orquestrado. Confira três pontos: o escopo e os valores se mantiveram? Houve as duas paradas? Existe um único arquivo de proposta?

E se uma etapa falhar? Identifique onde ela parou e o que já foi concluído. Antes de repetir, confira se o documento já existe. Uma retomada não deve criar outra proposta só porque perdeu a referência do arquivo anterior.

FALA INTEGRAL · TEXTO REVISADO

Você continua podendo usar cada skill separadamente. A orquestradora não tira essa possibilidade. Ela organiza o uso conjunto, quando o objetivo pede a sequência completa.

No futuro, pode haver extensões, como preparar um e-mail ou uma notificação. Cada extensão precisa de uma função e de uma autorização próprias. Um fluxo que funciona não é motivo para acrescentar canais.

Agora, o seu exercício. Explique, com as suas palavras, três coisas: o que a orquestradora decide, o que ela confere e onde ela deve parar. Se você consegue apontar esses três pontos, consegue avaliar se o time está trabalhando como foi combinado.

Na próxima aula, vamos ver a diferença entre acionar esse time por uma conversa e deixá-lo começar por uma rotina.

FALA INTEGRAL · TEXTO REVISADO

Até aqui, você chamava o time sempre que precisava. Uma rotina muda só isso: ela inicia o trabalho por um horário ou por uma frequência, e você deixa de acionar o time a cada vez.

Só que agendar o início não resolve o resto. A rotina não garante que o time tenha acesso às ferramentas, que a entrada seja boa nem que alguém aprove a saída.

Então, antes de criar uma rotina, responda a três perguntas. Qual processo ela vai iniciar? Onde esse processo roda? E como você vai perceber que deu certo? O time que acabamos de construir é o procedimento. A rotina é só mais uma forma de acioná-lo.

No nosso caso comercial, a rotina vai verificar se existe uma nova reunião de teste pronta para análise. Se existir, ela prepara o material para aprovação, com as mesmas decisões humanas que já definimos. Vamos usar apenas origem e destino de teste, sem criar uma agenda de produção.

FALA INTEGRAL · TEXTO REVISADO

Vamos começar pelo local. Se a tarefa depende de uma pasta ou de um navegador do seu computador, ela precisa rodar num ambiente que alcance esses recursos. Uma rotina na nuvem não recebe sozinha os arquivos e as sessões que estão no seu desktop.

Uma tarefa local também tem as suas condições: o aplicativo precisa estar aberto e o computador, ativo. Por isso, escolha o ambiente pelas dependências do processo, e não só porque existe um botão de agendamento à mão.

Agora vamos configurar a rotina com o recurso de agendamento que a versão desta gravação oferece. Depois de configurar, use a opção de executar agora, se ela existir, para testar sem esperar o horário.

E então vem a conferência. O que precisamos ver é a reunião certa analisada e a saída no destino combinado. Uma notificação de que a execução aconteceu não prova isso. Abra o destino e confira.

Falta combinar o que acontece quando não há reunião nova. Nesse caso, o processo registra que não havia trabalho e termina, sem gerar uma proposta vazia. E, se a reunião já foi processada, ele não repete a entrega sem motivo.

FALA INTEGRAL · TEXTO REVISADO

Agora, uma conferência importante: o horário não muda a autorização. A proposta deve continuar aguardando revisão, porque agendar a preparação não autoriza enviar o documento ao cliente. Olhe o histórico e a saída para confirmar que nenhum envio aconteceu.

Para concluir o exercício, confira três coisas: a primeira execução, o estado final e onde você acompanharia uma falha. Depois, desative a rotina de teste, se ela não precisa continuar rodando. Não deixe uma repetição ativa só para mostrar que sabe criá-la.

Com isso, temos procedimento, ferramentas, coordenação e uma forma de iniciar o trabalho. No próximo módulo, vamos levar esse mesmo raciocínio para o ecossistema da OpenAI e separar o que dá para reaproveitar do que precisa ser adaptado.

FALA INTEGRAL · TEXTO REVISADO

Até aqui, você aprendeu a definir uma tarefa, guardar um procedimento numa skill, conectar ferramentas e conferir a entrega. Esse raciocínio não depende de uma interface específica.

Agora vamos levá-lo para o ecossistema da OpenAI. Dá para reaproveitar a intenção do processo, os critérios, os arquivos de exemplo e parte das instruções. O que precisa ser conferido é como o novo ambiente encontra essas instruções e como ele acessa as ferramentas.

Por isso, migrar não é copiar uma pasta e presumir que tudo funciona. Vamos usar um mapa de equivalências: para cada peça, ele mostra o que ela faz e qual é o caminho correspondente do outro lado.

FALA INTEGRAL · TEXTO REVISADO

O mapa se resume a quatro perguntas. Onde ficam as instruções que valem para o trabalho? Onde a skill é encontrada? Como a ferramenta externa é conectada? E como a execução vai ser conferida ou agendada?

Começando pelas instruções. CLAUDE.md e AGENTS.md são arquivos que podem orientar agentes, mas quais deles são lidos, e qual vale mais, dependem da ferramenta e da configuração. Então peça para a ferramenta dizer quais instruções carregou e confira no contexto disponível.

Agora, as skills. Cada ambiente tem seus locais e sua forma de distribuição. Um formato parecido não garante que referências, caminhos, scripts e permissões vieram junto. Vamos inspecionar essas partes antes da primeira execução.

No lado da OpenAI, diferencie Chat, Work e Codex pela tarefa e pelos recursos disponíveis. Work e Codex podem compartilhar conceitos e integrações, mas as telas e os recursos não são idênticos. Nesta formação, vamos demonstrar o projeto no Codex.

Planos, preços e nomes mudam com o tempo. Por isso, a referência atual fica separada do procedimento: se a tarifa mudar, a lógica da aula continua clara.

Pause o vídeo e faça a busca no seu ambiente: localize as instruções do projeto, as skills e as conexões, e peça para a ferramenta informar qual arquivo de instruções ela carregou. Confira a resposta e deixe as configurações globais como estão.

FALA INTEGRAL · TEXTO REVISADO

A transferência fica mais simples quando os critérios estão escritos. Neste caso, a proposta precisa usar os mesmos serviços, preservar o prazo citado, consultar a tabela e terminar aguardando aprovação. Esses pontos continuam valendo, qualquer que seja a interface.

O que vamos testar é se o novo ambiente consegue percorrer o caminho cumprindo esses critérios. Se uma ferramenta não estiver disponível, reconecte ou adapte só aquela parte e registre o que ficou pendente. O projeto inteiro não precisa recomeçar.

Antes da próxima aula, pause e faça duas coisas: percorra os itens do checklist e prepare uma cópia isolada dos arquivos fictícios do caso.

Na próxima aula, vamos rodar o caso com a mesma entrada e comparar a entrega.

FALA INTEGRAL · TEXTO REVISADO

Nesta aula, você leva o mesmo caso do Ateliê Horizonte para o Codex e confere se o processo continua de pé. Por isso, mantemos a transcrição, o modelo, a tabela e os critérios exatamente como estavam. Com a entrada igual, uma diferença no resultado fica mais fácil de investigar.

O objetivo não é obter uma proposta qualquer. É preservar o processo: selecionar a reunião, organizar o pedido, confirmar o entendimento, preparar o documento e entregar para revisão.

Vou começar pela pasta do caso. Primeiro, vejo o que o Codex reconheceu: os arquivos, as instruções e as habilidades. Depois, verifico as conexões de que o processo precisa. Uma skill pode citar uma ferramenta no próprio texto, mas isso não quer dizer que a ferramenta esteja disponível neste ambiente.

FALA INTEGRAL · TEXTO REVISADO

Agora acionamos o mesmo objetivo no Codex. Na confirmação de entendimento, conferimos quatro pontos: as três entregas, o limite de cem registros, a orientação de uma hora e o prazo que veio da reunião.

Na proposta, comparamos os serviços com a tabela de exercício. O cliente citou um teto de mil e oitocentos reais, e os três serviços somam mil e quinhentos. Essa diferença importa: o teto é um limite do cliente, não um preço. A IA só pode usá-lo como preço se houver uma regra que autorize isso.

Depois, abrimos o documento no destino de teste e conferimos o conteúdo e o estado de aprovação. Se o texto apareceu só na conversa, a entrega ainda não foi concluída.

Em seguida, repetimos o caso incompleto, sem orçamento informado. O esperado é que o processo registre essa ausência e peça esclarecimento quando precisar. Se a migração só funciona quando todas as informações chegam completas, ela ainda não está validada.

Se aparecer uma diferença, procure a causa: instrução não carregada, caminho de arquivo, ferramenta, permissão ou interpretação. Corrija essa parte e repita o teste afetado, mantendo o restante igual para que a comparação continue valendo.

FALA INTEGRAL · TEXTO REVISADO

Você não precisa escolher uma ferramenta por preferência permanente. Pode avaliar qual ambiente atende melhor à tarefa, ao acesso de que ela precisa, à qualidade e ao custo do trabalho.

O que dá continuidade é um processo que você entende e critérios que consegue conferir. A interface pode mudar, mas você sabe o que procurar e o que não pode se perder.

Seu exercício é registrar uma diferença concreta encontrada na migração e mostrar como você conferiu a entrega. Com isso, terminamos o núcleo da formação. No bônus, vamos acrescentar um canal de comunicação a um processo, sem confundir o canal com o time que faz o trabalho.

FALA INTEGRAL · TEXTO REVISADO

Até aqui, cada trabalho começou dentro de um ambiente de IA e terminou numa entrega para você conferir. Em alguns processos, porém, faz sentido receber um pedido ou mandar um aviso pelo WhatsApp.

Mas o WhatsApp é só o canal. Quem define o que acontece quando uma mensagem chega é o processo. Se essa regra ainda não existe, o canal só cria mais uma porta de entrada para organizar.

Vamos usar um exemplo pequeno: avisar que um documento foi preparado e está aguardando revisão. O documento fica no destino combinado, e a aprovação continua sendo uma decisão de uma pessoa.

FALA INTEGRAL · TEXTO REVISADO

Dois casos ajudam a ver o papel do canal. No primeiro, um assistente financeiro recebe um comprovante, extrai as informações e prepara um registro para conferência. No segundo, um apoio de projetos avisa sobre uma pendência e recebe uma atualização da equipe. Nos dois, o WhatsApp é a conversa. O procedimento é que define como interpretar, registrar e confirmar.

Casos assim podem pedir outras integrações, revisão humana e regras sobre os dados. Por isso, vamos apenas descrevê-los. O nosso exercício será menor: uma mensagem de teste, com uma finalidade clara.

Antes de conectar qualquer canal, responda a três perguntas. O que a pessoa precisa receber ou informar? Quem pode participar da conversa? E o que o processo faz se a mensagem não for entregue? Se o canal não melhora uma etapa concreta, talvez ele ainda não precise entrar.

FALA INTEGRAL · TEXTO REVISADO

Para o bônus, vamos trabalhar com uma instância de teste e um destino de teste. A mensagem será a atualização de um exercício fictício, e nada será enviado a um cliente real.

O critério de conferência é separar três situações: o que foi preparado, o que foi enviado ao serviço e o que chegou ao destino. Essa separação importa porque clicar em enviar não prova que a comunicação aconteceu.

Na próxima aula, vamos escolher o caminho de integração e entender seus limites antes de conectar.

FALA INTEGRAL · TEXTO REVISADO

Para trabalhar com WhatsApp, existem dois tipos de caminho: o oficial, oferecido pela plataforma, e as integrações não oficiais. Nesta formação, o exercício prático usa a UazAPI, a opção escolhida para o curso.

Essa escolha não elimina o risco de bloqueio, de desconexão ou de falha na entrega. E usar pouco volume também não garante que uma integração não oficial funcione sem problemas. Por isso, o exemplo começa em um ambiente de teste, sem depender de um número importante para o atendimento do seu negócio.

O que você precisa levar desta aula é saber o que está conectando e o que precisa conferir. A conveniência do caminho não é garantia de funcionamento.

FALA INTEGRAL · TEXTO REVISADO

Agora vamos separar duas coisas: o que você paga e em que estado a mensagem está.

Primeiro, a cobrança. As regras da plataforma oficial e o preço cobrado por um provedor são referências diferentes. Categoria da mensagem, mercado e condições de gratuidade podem mudar a conta. Por isso, não vamos usar uma tarifa única por mensagem enviada ou recebida. Antes de usar em produção, consulte a documentação atual de preços dos dois lados.

Na parte técnica, a separação é entre conexão, envio, entrega e leitura. Uma instância conectada, que é a conexão do seu número com o serviço, está autenticada para operar. Isso não quer dizer que uma mensagem específica já foi aceita, entregue ou lida.

Quando você pede um envio, o serviço pode devolver uma identificação da mensagem. Use essa referência para acompanhar o estado. Se o pedido terminar por tempo esgotado, sem resposta, não repita o envio às cegas: a primeira tentativa pode ter sido processada. Antes de reenviar, confira o que aconteceu com ela.

No exercício, vamos tratar uma falha como informação para o processo. Se a entrega depende de uma comunicação, o processo precisa saber o que fazer quando o canal não está disponível, em vez de continuar dizendo que deu tudo certo.

FALA INTEGRAL · TEXTO REVISADO

O token é uma credencial de acesso. Ele não aparece na fala, em um print, no arquivo de exemplo nem em uma instrução que será distribuída. Configure o acesso pelo caminho apropriado do seu ambiente e, antes de compartilhar qualquer coisa, confira o que entra nos arquivos e nos registros.

Na UazAPI, vamos usar o endereço do servidor da sua conta e o token da instância necessária ao exercício. A credencial administrativa tem outro alcance e não é a chave do dia a dia.

Com o canal escolhido, o escopo limitado e os critérios de conferência definidos, podemos preparar a conexão. Os critérios são os quatro estados: conexão, envio, entrega e leitura, cada um conferido separadamente. Na próxima aula, seguimos esse caminho com um exemplo pequeno, de ponta a ponta.

FALA INTEGRAL · TEXTO REVISADO

Nesta aula, vamos conectar um exemplo no WhatsApp usando a UazAPI. Para isso, você precisa de três coisas: uma instância de teste, o endereço do servidor dessa instância e um número reservado para o exercício.

Um ponto pede atenção. O site da documentação não é o endereço do seu servidor. O que vale é a Server URL, que é a base de todas as chamadas da sua instância. O token da instância é o que autoriza essas chamadas, e só vale no servidor a que pertence. Uma credencial de outro servidor não comprova acesso nesse endereço.

Antes de avançar, confira duas coisas: onde o procedimento vai rodar e como ele recebe a configuração sem expor o token. Os dados de acesso ficam fora da skill e fora de qualquer material que você vá compartilhar.

FALA INTEGRAL · TEXTO REVISADO

Vamos começar consultando o estado da instância. Se ela ainda não estiver conectada, iniciamos a conexão e concluímos o pareamento conforme o serviço indicar. Nessa etapa, não deixe token nem material de pareamento aparecer numa gravação que vá ser distribuída.

Depois, consultamos o estado de novo. Aqui, o que queremos confirmar é a conexão, e só isso. Com a conexão confirmada, passamos para a mensagem de teste.

Para enviá-la, o agente precisa de uma ferramenta que chame a API. A skill guarda o procedimento; o acesso acontece pela integração configurada no ambiente. Escrever o endereço da API numa instrução não cria a conexão.

O pedido é enviar uma atualização fictícia ao destino de teste que você definiu. Depois da chamada, guarde a identificação da mensagem e consulte o estado dela. Uma mensagem na fila, ou marcada como enviada, ainda não é evidência de entrega.

Se a integração usar eventos de atualização, relacione cada evento à mensagem certa. Um recibo não é uma mensagem nova do usuário, então não deve disparar resposta automática. E mantenha o exercício numa conversa individual, para não somar a complexidade dos recibos de grupo.

FALA INTEGRAL · TEXTO REVISADO

Agora temos três conferências: a instância estava conectada, a operação de envio foi aceita e a mensagem chegou ao destino. A leitura é outro estado, com condições próprias, e não é sinônimo de entrega.

Se algo falhar, anote em que parte o processo parou. Antes de tentar de novo, verifique a conexão, a resposta da operação e a referência da mensagem. Um erro de acesso ou um número incorreto não se resolve com várias tentativas de envio.

O exercício termina quando você consegue mostrar o resultado e explicar o caminho que usou. Depois, aplique a mesma lógica a um processo seu: entrada clara, procedimento definido, ferramentas com o acesso adequado e uma saída que alguém consiga conferir.

É isso que liga toda a formação. Sua autonomia cresce na medida em que você entende o processo e consegue observar o que foi feito. Comece pequeno, com um caso que você conhece, e amplie o time conforme consiga conferir cada nova responsabilidade.