Imagine dar um comando e o Claudio Code montar sozinho uma força tarefa de dezenas de agentes todos trabalhando ao mesmo tempo e entregar o resultado pronto. Parece mágica e também é a forma mais rápida de esgotar a sua assinatura inteira sem você perceber. E esse recurso se chama Dynamic Workfalls.
E nesse vídeo você vai aprender o que é quando vale a pena usar com exemplos práticos, sem ter uma surpresa na sua conta. Com o Clude Opus 4. 8 surgiu esse recurso e logo de início ele confunde muita gente.
Já existiam subagentes agent teams/G, então para que mais um? E a diferença é uma virada de chave. Normalmente é o cloud do chat que mantém o plano e conversa com você passo a passo.
Já no workflow, não. O cloud para escreve um script em JavaScript e é esse script que assumo. Dispara os agentes, organiza em fases e coordena tudo.
Você só faz uma coisa, descreve o objetivo em uma única frase e o resto ele monta sozinho. Podem ser 10 agentes ou centenas de agentes cada um na sua janela em paralelo. E como é um script de verdade, ele fica salvo e você executa novamente quando quiser.
Deixou de ser uma conversa e tornou-se uma linha de montagem. Para ficar mais fácil de você entender, pense numa redação de jornal. Um repórter sozinho cobre uma pauta de cada vez.
Esse é o Cloud comum. Já o Workflow é o editor chefe. Ele escala 20 repórteres de uma vez, cada um em uma rua diferente e junta tudo em uma única edição.
E essa é a virada de Charm. Antes de seguir, eu tenho um recado importante que tem tudo a ver com o que você está vendo aqui. Tudo isso, workflows, agentes, skills, nós ensinamos dentro da comunidade maestros da IA em um curso dedicado ao plode.
Lá você encontra um guia, scripts prontos, prompts prontos para copiar e colar e uma rede de pessoas construindo automações com inteligência artificial de verdade. E se você também quer aplicar na prática e ter uma base sólida de verdade, além de lives ao vivo toda semana comigo e com Artur e suporte técnico diariamente, é só clicar no link na descrição desse vídeo para saber mais e se inscrever na comunidade. Cada degrau te dá mais poder, mas também cobra mais caro.
No primeiro degrau é você direto com Cloud, ele raciocina, busca na web, chama API, mais simples e barato. Um exemplo prático seria: corrija esse bug no login ou resuma esse relatório em cinco tópicos, uma tarefa, uma resposta, isso já resolve o problema da grande maioria. No segundo degrau, nós temos a skill.
É como uma receita reaproveitável, é o como fazer. Exemplo, uma skill, gerar carrossel de Instagram. Ela guarda o passo a passo, as cores da marca, o formato, você chama e ela executa igual todas as vezes.
No terceiro degrau, nós temos o subagente. Ele roda em paralelo sem poluir a conversa. Observação: subagentes não conversam entre si, eles respondem apenas ao cloud central.
Um exemplo prático seria: Pesquise três concorrentes ao mesmo tempo. Três suagentes partem juntos e retornam cada um com uma ficha e a sua conversa principal permanece lim. No quarto degrau, nós temos o aged team, uma equipe de verdade.
Eles conversam entre si como um grupo que debate, por isso é mais caro. Um exemplo prático seria um dev, um revisor e um tester discutindo uma mesma funcionalidade. O revisor aponta um erro, o dev responde, o tester confirma.
é útil quando o resultado precisa de debate. No quinto degrau, nós temos os Workflows. É o trabalho gigante em paralelo, com dezenas de agentes trabalhando ao mesmo tempo, tudo costurado no fim.
Um exemplo prático seria: traduz os meus 80 artigos do blog para o inglês. 80 agentes, um por artigo, todos de uma vez. O que levaria um dia inteiro é concluído em alguns minutos.
Então aqui nós temos a escada dos recursos. Quanto mais alto você sobe, mais risco, mais tokens. Só suba até onde o problema existe.
E existe uma pergunta chave que facilita a identificação de até qual degrau você deve subir, que é os agentes conversam entre si, sobentes, não. Workflows não. Agent teams sim.
Um exemplo prático, pense num exame médico. No workflow, cada laboratório realiza o exame isolado e envia o laudo. No agent team, os médicos se reúnem e discutem o diagnóstico.
E uma skill cabe no workflow? Cabe. Ela também usa seus MCPs e chaves de API.
Guarde isso. A skill é o como e o workflow é o quantos. Agora vamos falar sobre profundidade versus largura.
O barra go é profundidade. Um agente que repete o ciclo, verifica se já atingiu o objetivo, vai fundo em um ponto. Um exemplo de barra G.
Continue refinando este texto até passar de nota nove no meu checklist. Ele tenta, avalia, tenta novamente, sozinho, até atingir o critério. Mas não confunda com o comando barra loop.
O barra loop repete por tempo e o barra go repete por condição. Exemplo de barra loop. Barra loop por 5 minutos.
Verifique se o deploy caiu. Ele repete a cada 5 minutos pelo relógio. Já o barra gol para quando o objetivo é atingido e não quando o tempo passa.
O workflow é largura. Muitos agentes lado a lado, cada um numa tarefa de uma vez, costurados no fim. Fazendo uma analogia, o barra go é cavar um poço bem profundo e o workflow é arar um campo inteiro de uma vez.
Agora sobre o custo, é aqui que muitos usuários se prejudicam. Cada agente do workflow é uma chamada completa do cloud, janela própria, contexto do zero. Multiplica por dezenas e o consumo expode milhões de tokens em poucos minutos.
Fazendo as contas, um agente equivale a uma conversa. Um workflow com 50 agentes é como abrir 50 conversas do zero ao mesmo tempo. Imagine a fatura.
A boa notícia é que a maior parte é token de entrada, o que é mais barato, mas isso não o protege de um pedido vago. Um pedido vago seria melhore o meu site, workfolds para agentes sem direção. Otimize apenas as imagens das 12 páginas de produto.
Escopo fechado, custo previsível. E aqui vai uma dica de ouro. Delimite o escopo no meio entregável e rode agentes no modelo haiku.
Na prática seria use o Raiku nos agentes de busca e só o óculos na síntese final. Assim você paga caro só onde precisa de cérebro e mais barato no volume. E como utilizar a ferramenta?
Peça de forma explícita. Um exemplo prático seria: configure um dynamic workflow que audita 200 produtos da minha loja e lista os que estão sem descrição. Um workflow nunca roda sozinho, o cloud sempre confirma antes e você pode ver o script bruto.
Enquanto o dynamic workflows roda, você pode digitar o comando barraworkflows para ver as fases, os agentes e os tokens. E é possível interromper a qualquer momento. Se você percebeu que já gastou mais de 800.
000 1000 tokens e o resultado está saindo errado, abra o barra workflows e interrompa na hora. Assim você está sempre no comando. Por padrão, ele salva o script no espaço pessoal.
Paracionar com a equipe, salve na pasta ponto cloud do projeto. Um exemplo prático. Salvou o workflow gerar relatório semanal dentro de ponto clod.
Toda a equipe do repositório executa o mesmo workflow sem reinventar. Um exemplo prático de marketing gera 30 variações de cópia de anúncio. Um agente por ângulo, dor, desejo, prova social, urgência, tudo de uma vez.
Um exemplo para conteúdo. Transcreva e resuma 40 episódios do meu podcast. Paralelismo puro, o trabalho de uma semana em uma única tarde.
E aqui vai um bônus. O comando/deep research é um workflow. Vários agentes pesquisam, cruzam fontes, votam em cada afirmação e entregam um relatório com fontes citadas.
Um exemplo prático, deep research sobre o mercado de cafés especiais no Brasil. Uns buscam dados, outros tentam derrubar cada afirmação e no final só sobra o que é fato checado. Outra code combina o raciocínio mais alto com workflows ligados por padrão.
É o mais inteligente e de longe o mais caro. E é um controle para ajustar o quanto o cloud reflete antes de responder com o comando barra effort. Ele regula o esforço de raciocínio.
Quanto mais alto, mais o modelo reflete antes de agir. Dessa maneira você tem mais qualidade em problemas difíceis, mas também mais gastos de tokens. Eu vou mostrar para você aqui na prática como funciona o comando barra effort e depois o dynamic workflow.
Você vai digitar barrae effort no cloud e apertar enter. Aqui nós temos o nível de raciocínio do cloud. Então, nós temos o low, o medium, o high, o extra high, o max e o ultra code.
O ultra code é aquele que eu mencionei anteriormente. É para quando você precisa de uma tarefa que exige muito raciocínio, muito refinamento, tanto na execução quanto na resposta. Então eu recomendo que você utilize ultra code só quando for realmente necessário.
Eu normalmente deixo no high ou no medium quando a tarefa não exige tanto pensamento, tanta complexidade. Então agora você já sabe como ajustar o nível de raciocínio do cloud. E recapitulando, o barra effort low é pra tarefa mais simples e rápida.
E o effort high quando o problema é complexo e você quer o melhor raciocínio. Então só pague mais caro quando você realmente precisar. E uma pergunta que pode facilitar para você a identificação de quando você precisa de mais ou menos raciocínio é a seguinte: isso se quebra em vários pedaços que rodam independentes ao mesmo tempo?
Se sim, Code base inteiro, aouditar dezenas de itens, migração de centenas de arquivos, o workflow brilha. Senão, edição pontual, dúvida rápida, trabalho comum é desproporcional ao problema. Um recurso novo não significa que ele é obrigatório.
E aqui eu vou fazer um teste rápido com você. Pensa comigo. Se eu precisar renomear uma variável, você acha que eu utilizo o comando workflow ou não?
Se você respondeu não, você acertou. Eu não preciso do comando workflow para isso. Agora, se eu precisar renomear uma variável específica em 300 arquivos do meu projeto, você acha que eu utilizo o comando ou não?
Se você disse que sim, você acertou. E o erro mais comum que muita gente comete é pensar que o comando barraworkflow pode ser usado para tudo, para qualquer coisa. Numa tarefa simples, ele só vai consumir mais os seus tokens e demorar muito para te trazer uma resposta.
Então, comece sempre pelo degrau mais baixo. O segundo erro que muita gente comete é deixar o escopo muito aberto. Organize a minha vida.
Isso não é um objetivo. Agora, categorize esses 90 arquivos em quatro pastas. é um escopo fechado.
E o terceiro erro mais comum é não acompanhar. Deixou em execução e se ausentou, abra o barra workflows e monitore o consumo enquanto ele trabalha. Agora eu vou te mostrar na prática como funciona o comando dynamic workflows.
Eu criei aqui um prompt simples apenas para ilustrar para você o funcionamento desse recurso. Então eu coloquei aqui rod workflow que audite todas as minhas skills do cloud code em dois lugares. No meu caso, eu criei um repositório para rodar esse comando para ilustrar para você.
Primeiro, minhas skills de nível de usuário globais em barra. clod/skills. do clod/skills.
Segundo, as skills deste projeto em Cloud/Skills. Faça globe dos dois diretórios atrás dos arquivos skill. m.
Distribua um agente por arquivo de skill e use o highol nestes agentes trabalhadores para manter o custo baixo. Cada trabalhador lê o seu skill. m MD e dá nota para clareza de 1 a C.
As instruções estão claras e sem ambiguidade. Front matter passa barra falha e válido com ambos os campos name e description. De um a cinco.
A descrição diz claramente quando usar a skill com frases gatilho concretas. A única correção de maior valor. Depois, um agente final ranqueia todas as skills da pior para melhor, rotula em qual pasta cada uma vive, global versus projeto, coloca a mais fraca no topo e aponta quaisquer padrões que apareçam no conjunto todo.
Salve o resultado como um scorecard em Markuditreport. m. E nós vamos rodar esse comando dentro do cloud e ver o funcionamento do dynamic workflows.
Agora que eu já coloquei o comando no cloud, eu vou apertar enter e ele já vai começar a acionar os agentes. Aqui, como eu tinha mencionado anteriormente, ele sempre confirma com você se você quer utilizar esse recurso. E aí eu vou confirmar que sim.
Bom, ele finalizou e utilizou cinco agentes para essa tarefa. utilizou o Highol para fazer a auditoria, como eu tinha solicitado, né, para ele utilizar apenas o Opus para fazer a finalização. E aqui ele trouxe, né, o ranking das minhas skills, né, são skills que eu coloquei aqui dentro desse repositório para ilustrar para você e trouxe aqui uma nota para cada uma delas, né, com relação à clareza.
É tudo aquilo que eu tinha pedido no prompt que eu mostrei anteriormente. Bom, eu digitei o comando barraworkflows para ver exatamente o quanto de recurso ele utilizou, né? Então ele usou realmente cinco agentes e consumiu 155.
3. 000 tokens. Bom, resumo rápido do que mencionamos nesse vídeo.
Algo rápido, pergunte. Repete, skill. Em paralelo, subagente, equipe que conversa, agent team.
até atingir um critério barra go, um trabalho gigante, dynamic workflows. Em todos eles, MCPs, CLI e APIs podem ser utilizados. Eles se conectam por baixo para integrar os seus sistemas e dados.
E eu criei esse mapa mental sobre o dynamic workflows do cloud code. E aqui você tem um resuminho de tudo o que foi dito de uma maneira organizada, facilitando o seu aprendizado. E eu também criei um guia ilustrativo para te facilitar na hora de decidir quando utilizar o dynamic workflow e lembrar de tudo o que foi dito neste vídeo.
Nossa escada dos recursos, como eles conversam entre si, barrago versus workflow, o custo, como invocar na prática, um bônus, quando usar, tudo isso vai estar disponível dentro da comunidade maestros da IA. Nesse vídeo nós esclarecemos o que são workflows, a escada, a profundidade versus largura, exemplos reais e como não ter uma surpresa na sua conta. Se você gostou desse vídeo, eu quero te pedir para se inscrever nesse canal, deixar o seu like e compartilhar com seus amigos.
Obrigada por ter assistido, um grande abraço e até o próximo vídeo.
