# Alejandro Rioja — PT > Alejandro Rioja — AI agent systems for founders. Plus posts on growth, marketing, sales, ops, and business from inside live P&Ls. Site: https://alejandrorioja.com/pt/ Author: Alejandro Rioja Language: pt --- ## Primeiras impressões do Claude Fable 5: a visão de um operador Source: https://alejandrorioja.com/pt/claude-fable-5-first-impressions/ Published: 2026-06-12 Updated: 2026-06-12 Tags: AI Agents TL;DR: O Fable 5 é o modelo mais capaz da Anthropic e isso fica evidente em trabalho de agente difícil e de longo horizonte — mas não é a atualização padrão. Custa mais por token, usa um novo tokenizer que infla suas contagens de tokens em cerca de 30%, roda thinking sempre ativo que você não consegue desligar e pode recusar requisições no nível do classificador. Para a maioria das cargas de trabalho, o Opus 4.8 ainda é a escolha certa. Use o Fable 5 quando a tarefa for de fato difícil. ## Índice _Atualizado em junho de 2026._ **TL;DR:** O Fable 5 é o modelo mais capaz da Anthropic e isso fica evidente em trabalho de agente difícil e de longo horizonte — mas não é a atualização padrão. Custa mais por token, usa um novo tokenizer que infla suas contagens de tokens em cerca de 30%, roda thinking sempre ativo que você não consegue desligar e pode recusar requisições no nível do classificador. Para a maioria das cargas de trabalho, o Opus 4.8 ainda é a escolha certa. Use o Fable 5 quando a tarefa for de fato difícil. **[Leitura do operador]** Eu opero mais de 30 agentes em produção, entre uma marca de consultoria e uma quadra de pickleball, então um novo modelo de ponta não é um benchmark para mim — é uma linha de custo e uma migração. Aqui está o que mudou quando eu de fato liguei o Fable 5 a alguns deles, e onde mantive o Opus 4.8 no lugar. ## O que o Fable 5 realmente é O [Claude](/recommends/claude) Fable 5 é o modelo mais capaz que a Anthropic já lançou de forma ampla. Ele mira a ponta mais exigente do espectro: raciocínio profundo e trabalho agêntico de longo horizonte — as execuções em que um agente precisa manter um plano ao longo de dezenas de chamadas de ferramenta sem perder o fio da meada. A superfície da API é quase idêntica à do Opus 4.7/4.8, o que facilitou os testes. Janela de contexto de 1M tokens por padrão, até 128K tokens de saída por requisição. Se você construiu qualquer coisa sobre a linha recente do Opus, o formato da requisição é familiar. As diferenças estão nos detalhes, e é nos detalhes que moram o dinheiro e as surpresas. Uma observação sobre nomes para você não se confundir: **Mythos 5** é o mesmo modelo — mesmas capacidades, mesmo preço, mesmo comportamento — disponível apenas através do programa Project Glasswing da Anthropic. Se você não está nesse programa, o modelo que você quer é o `claude-fable-5`. Tudo abaixo se aplica aos dois. ## Onde ele é genuinamente melhor Joguei minha tarefa de agente mais difícil nele primeiro: uma execução de pesquisa-e-síntese em várias etapas que lê uma pilha de fontes, faz a verificação cruzada de afirmações e escreve um resumo com citações. É o tipo de trabalho em que modelos mais fracos derrapam — eles perdem o controle de qual afirmação veio de qual fonte umas dez chamadas de ferramenta adiante. O Fable 5 manteve o fio da meada. A síntese ficou mais coesa, as citações permaneceram coladas às afirmações certas e ele pegou duas contradições entre fontes que a minha versão com Opus 4.8 vinha silenciosamente nivelando. Em raciocínio longo e estruturado, é um salto real — não um avanço marginal de benchmark. Esse é o argumento honesto a favor dele. Se o modo de falha do seu agente é "desmorona nos 10% difíceis", o Fable 5 estreita essa lacuna. Se o seu agente resume newsletters ou escreve posts para redes sociais, você não vai sentir a diferença — e vai pagar por capacidade que não está usando. ## A pegadinha de custo que ninguém avisa Aqui está a que vai te pegar se você passar os olhos por cima das notas de versão. O Fable 5 vem com um **novo tokenizer**, e o mesmo conteúdo é tokenizado em cerca de **30% mais tokens** do que na linha do Opus. Leia isso de novo, porque compõe com o preço. O Fable 5 já é mais caro do que o nível Opus de partida (US$ 10 por milhão de tokens de entrada, US$ 50 por milhão de saída). Agora some uma inflação de tokens de cerca de 30% sobre cada prompt e cada resposta. Uma carga de trabalho inalterada — mesmos prompts, mesmas saídas — pode custar significativamente mais depois da migração, antes de você mudar uma única coisa no que o agente faz. Então não reutilize seus números antigos. Suas configurações de `max_tokens`, seus orçamentos de janela de contexto, suas estimativas de custo por execução — todos foram medidos em um tokenizer diferente. A boa notícia: o endpoint de contagem de tokens retorna as contagens sob **ambos** os tokenizers quando você passa `model: "claude-fable-5"`, então você pode medir o delta nos seus prompts reais antes de virar qualquer chave. ```bash # Measure the tokenizer delta on YOUR prompt before migrating. # The response includes input_tokens (new) AND input_tokens_prior_tokenizer (old). curl https://api.anthropic.com/v1/messages/count_tokens \ -H "x-api-key: $ANTHROPIC_API_KEY" \ -H "anthropic-version: 2023-06-01" \ -H "content-type: application/json" \ -d '{ "model": "claude-fable-5", "messages": [{"role":"user","content":""}] }' ``` Rodei isso nos meus prompts mais pesados primeiro. O delta não foi uniforme — varia conforme o conteúdo — mas "reserve cerca de 30% a mais e depois acrescente o prêmio de preço" foi o modelo mental certo. ## O thinking está sempre ativo — e você não consegue desligá-lo No Fable 5, o thinking adaptativo está sempre rodando. A única nova mudança que quebra compatibilidade em relação à linha do Opus: se você enviar um `thinking: {type: "disabled"}` explícito, recebe um 400. A correção é simples — basta omitir o parâmetro `thinking` por completo — mas se você tinha código que desabilitava explicitamente o thinking para chamadas baratas e rápidas, esse código agora dá erro. Você também não recebe de volta a cadeia de raciocínio bruta. O Fable 5 a protege: você recebe blocos `thinking` normais e pode pedir um resumo legível com `display: "summarized"`, mas o raciocínio sem filtro nunca é exposto. Para a maioria dos apps isso é irrelevante — leia o resumo se precisar de visibilidade. Onde importa é em **agentes multi-turno**: quando você continua uma conversa no mesmo modelo, precisa devolver os blocos de thinking **sem alterações**. Descarte-os ou edite-os e o turno quebra. Se você está construindo loops de agente, trate os blocos de thinking como tokens opacos que você carrega adiante na íntegra. ## As recusas agora são um problema de fluxo de controle Essa é a mudança que mais afeta a forma como você escreve o código em volta do modelo. O Fable 5 roda classificadores de segurança nas requisições recebidas, mirando principalmente conteúdo de biologia de pesquisa e a maior parte de cibersegurança. Quando uma requisição é recusada, você recebe um **HTTP 200 bem-sucedido** com `stop_reason: "refusal"` — não um erro, não uma exceção. O array `content` pode estar vazio. Se o seu código faz `response.content[0].text` sem checar o `stop_reason` antes, ele vai quebrar no dia em que uma requisição for recusada. E trabalho benigno e adjacente — ferramentas legítimas de segurança, tarefas de ciências da vida — pode ocasionalmente disparar um falso positivo, então isso não é só problema de quem faz coisas duvidosas. A regra é: **ramifique com base em `stop_reason`, nunca em `stop_details`.** ```typescript const res = await client.messages.create({ model: "claude-fable-5", max_tokens: 1024, messages, }); if (res.stop_reason === "refusal") { // classifiers declined — content is empty or partial. Don't read content[0]. await handleRefusal(res); } else { console.log(res.content[0].text); } ``` Para produção, há um caminho mais limpo: um parâmetro `fallbacks` do lado do servidor (em beta) que reexecuta automaticamente uma requisição recusada no `claude-opus-4-8` na mesma viagem de ida e volta, com reprecificação em estilo de crédito aplicada. Se você roda agentes sem supervisão, configure isso para que uma única recusa por falso positivo não trave uma execução inteira. Essa é a mesma lição que continuo reaprendendo sobre agentes que [continuam falhando em produção](/blog/why-your-ai-agent-keeps-failing-in-production-and-how-to-fix-it): o modelo ficar mais inteligente não elimina a necessidade de tratar seus casos extremos — apenas desloca esses casos extremos de lugar. ## Mais dois detalhes de migração Algumas coisas menores que me custaram tempo, para que não custem o seu: - **Sem prefill do assistant.** Se você direcionava a saída fazendo prefill do último turno do assistant, esse padrão acabou. Use saídas estruturadas (`output_config.format`) ou instruções no prompt de sistema no lugar. - **Retenção de dados de 30 dias é obrigatória.** O Fable 5 não está disponível sob zero retenção de dados. Se você está em ZDR por motivos de conformidade, o Fable 5 está fora de cogitação e o Opus 4.8 continua sendo o seu teto. Verifique isso *antes* de planejar uma migração, não depois. ## Você deve mesmo migrar? Aqui está minha avaliação de operador depois de conviver com ele. **O Fable 5 não é o alvo padrão de "atualizar para o modelo mais recente" — o Opus 4.8 é.** Isso surpreende as pessoas, mas é o enquadramento certo. O Opus 4.8 é uma troca de model-ID em relação ao 4.7, sem novas mudanças que quebrem compatibilidade, é mais barato e, para a esmagadora maioria do trabalho de agente, é indistinguível na qualidade da saída. O Fable 5 conquista seu lugar nas tarefas genuinamente difíceis: agentes de longo horizonte que precisam manter a coerência ao longo de muitas etapas, raciocínio profundo com múltiplas fontes, as execuções em que a falha que você está tentando eliminar é sutil. Para essas, a capacidade é real e vale o prêmio. Para todo o resto — redação de conteúdo, classificação, roteamento, resumo — você está pagando mais tokens a um preço mais alto por uma qualidade que não consegue perceber. Acabei rodando os dois. Meu agente de pesquisa-e-síntese passou para o Fable 5. Todo o resto ficou no Opus 4.8. Essa divisão é o ponto central: escolha o modelo por trabalho, não por moda. Se você opera uma frota de agentes, vale a mesma disciplina sobre a qual escrevi no [meu stack de operador de 2026](/blog/the-5-ai-tools-i-actually-use-to-run-my-business-2026-operator-stack) — direcione o trabalho difícil ao modelo caro e pare de pagar demais pelo trabalho fácil. ## A conclusão do operador Teste o Fable 5 na sua única tarefa mais difícil antes de tocar em qualquer outra coisa — é aí que ele compensa, e se não mover o ponteiro ali, não vai mover em lugar nenhum. Rode o contador de tokens contra seus prompts reais para que a inflação de cerca de 30% do tokenizer e o prêmio de preço não te surpreendam na fatura. Adicione uma checagem de `stop_reason: "refusal"` (ou o fallback do lado do servidor para o Opus 4.8) onde quer que o Fable 5 toque a produção. Depois roteie deliberadamente: Fable 5 para os 10% difíceis, Opus 4.8 para o resto. O melhor modelo não é o mais capaz — é o que está ajustado ao trabalho. --- ## O guia definitivo para iniciantes sobre agentes de IA: Cowork, Codex e as ferramentas que realmente fazem o trabalho Source: https://alejandrorioja.com/pt/ai-agents-for-beginners-cowork-codex-guide/ Published: 2026-06-11 Updated: 2026-06-11 Tags: Productivity, AI TL;DR: Agentes de IA são o próximo passo além dos chatbots: você dá a eles um objetivo em português simples e eles fazem o trabalho — leem seus arquivos, redigem, organizam, escrevem e executam código. Cowork é a rampa de entrada sem código; Codex e Claude Code são para quem mexe com uma base de código. A habilidade que importa é escrever uma instrução clara e bem delimitada, não aprender a programar. ## Table of contents _Atualizado junho de 2026._ **TL;DR:** Agentes de IA são o próximo passo além dos chatbots: você dá a eles um objetivo em linguagem simples e eles fazem o trabalho — leem seus arquivos, redigem, organizam, escrevem e executam código, e verificam seus próprios resultados. **Cowork** é a rampa de entrada sem código para pessoas não técnicas; **Codex** e **Claude Code** são para quem mexe com uma base de código. A única habilidade que importa é escrever uma instrução clara e bem delimitada — não aprender a programar. **[Nota do autor]** Gerencio mais de 30 agentes com código no dia a dia, mas a maioria das pessoas não precisa de código para capturar 80% do valor. Elas precisam de uma instrução clara e de um lugar para executá-la. Este guia é a introdução que eu daria a um amigo inteligente que nunca escreveu uma linha de código. ## O que é realmente um "agente de IA" Um chatbot responde uma pergunta. Um **agente** completa uma tarefa. A diferença é que um agente pode executar ações em um loop — ler um documento, decidir o que fazer em seguida, escrever um arquivo, executar um comando, verificar o resultado, corrigir o que está errado — sem que você precise conduzir cada etapa. Na prática: você não pergunta "como eu limpo essa planilha?" Você diz "aqui está a planilha — remova duplicatas, corrija os formatos de data e sinalize linhas com e-mails faltando", e o agente faz isso e te entrega o arquivo limpo. Essa mudança — de *conselho* para *trabalho concluído* — é exatamente o ponto. ## As duas famílias de ferramentas Há duas portas de entrada neste mundo, e você só precisa da que corresponde ao seu trabalho. ### Porta 1: Agentes sem código (comece aqui se você não programa) **Claude Cowork** é um espaço de trabalho onde você dá ao Claude um objetivo mais os materiais — arquivos, links, anotações — e ele produz o resultado que você revisa e usa: um rascunho, um resumo, um plano, uma planilha limpa. Você escreve instruções, não código. Pense em "um assistente muito capaz que lê rápido e nunca se cansa", não em "uma ferramenta de programação". Este é o ponto de partida certo para profissionais de marketing, fundadores, operadores, escritores, analistas — qualquer pessoa cujo trabalho é principalmente documentos, pesquisa e decisões. ### Porta 2: Agentes de programação (use quando houver uma base de código envolvida) **OpenAI Codex** e **Claude Code** são agentes que vivem onde o software é construído — um terminal, uma IDE ou a nuvem. Você descreve uma mudança ("adicione um botão de modo escuro", "corrija esse teste que está falhando", "migre esse arquivo para a nova API") e o agente edita o código, o executa e itera até funcionar. Você ainda revisa tudo; o agente faz a digitação. Você não precisa ser um engenheiro sênior para usá-los. Muitos não-desenvolvedores usam agentes de programação para lançar sites pequenos, automatizar planilhas como scripts e corrigir bugs em ferramentas que não escreveram. Mas há uma curva de aprendizado real, então a maioria dos iniciantes se beneficia mais começando pela Porta 1 e passando pela Porta 2 quando se deparar com uma tarefa que genuinamente precisa de código. ## Seu primeiro resultado (faça isso hoje) Escolha uma tarefa pequena e chata que você faz com frequência. Bons primeiros candidatos: - Transformar uma transcrição de reunião bagunçada em notas limpas mais uma lista de pontos de ação. - Resumir um PDF longo em 5 tópicos e 3 perguntas que valem a pena fazer. - Reescrever um rascunho de e-mail para que seja claro, acolhedor e com menos de 120 palavras. Depois, use a estrutura que torna os agentes confiáveis em vez de imprevisíveis — **papel → entrada → instrução exata → restrição → uma verificação**: > Você é meu assistente. Aqui está uma [transcrição de reunião / PDF / rascunho de e-mail] colada abaixo. Faça isso: [transforme em notas limpas com uma lista em negrito de \"Pontos de ação\" / resuma em 5 tópicos + 3 perguntas de acompanhamento / reescreva para ser claro, acolhedor e com menos de 120 palavras]. Mantenha minha voz. Faça-me uma pergunta se algo for ambíguo antes de começar. > > [cole seu conteúdo aqui] É isso. Você acabou de delegar uma tarefa. A estrutura é o jogo inteiro — e funciona de forma idêntica no Cowork, ChatGPT ou em um agente de programação. ## O prompt de quatro partes que torna os agentes confiáveis Iniciantes acham que o segredo é uma frase mágica. Não é. É a especificidade. Toda instrução confiável para um agente tem quatro partes: 1. **Papel** — quem é o agente para essa tarefa ("Você é meu assistente de pesquisa"). 2. **Contexto** — os materiais e o *porquê* ("Estou me preparando para uma ligação de vendas com um fundador fintech"). 3. **Tarefa** — a ação exata e delimitada ("Extraia três fatos recentes sobre rodadas de financiamento e escreva duas perguntas de abertura"). 4. **Restrições + uma verificação** — formato, extensão, tom e uma instrução para perguntar antes de supor ("Apenas marcadores, cite fontes, faça-me uma pergunta de esclarecimento se a empresa for ambígua"). Vago na entrada, vago na saída. Quanto mais um agente pode *fazer*, mais sua clareza importa — um chatbot que entende errado desperdiça uma frase; um agente que entende errado desperdiça uma tarde de trabalho que você precisa desfazer. ## Erros de iniciante para evitar - **Tratá-lo como um buscador.** Não faça perguntas de uma linha. Dê a ele trabalho real com arquivos reais. - **Pular a restrição.** "Escreva-me um plano" te dá uma parede de texto. "Escreva-me um plano de uma página com três fases e um responsável por tarefa" te dá algo utilizável. - **Não pedir uma verificação.** Adicione "faça-me uma pergunta se algo for ambíguo" e você vai capturar mal-entendidos *antes* de o agente começar, não depois. - **Deixar agentes de programação rodarem sem supervisão em código importante.** Revise o diff. Agentes são rápidos e geralmente corretos, mas "geralmente" está fazendo trabalho nessa frase — mantenha um humano no loop em tudo que for para produção. - **Pular para a Porta 2 cedo demais.** Se sua tarefa envolve documentos e decisões, você nunca precisa abrir um terminal. ## Como escolher sua primeira ferramenta - **Seu trabalho envolve documentos, pesquisa e escrita** → comece com **Cowork** (ou o produto de chat que você já paga, usado no modo agente). - **Você quer construir ou corrigir software** → **Claude Code** ou **OpenAI Codex**. - **Você quer trabalho recorrente sem intervenção** (um digest diário, um relatório semanal) → avance para **[tarefas programadas](https://alejandrorioja.com/how-to-use-claude-scheduled-tasks/)** depois de dominar o prompt manualmente. ## Agentes de IA para iniciantes — FAQ 2026 ### Preciso saber programar para usar agentes de IA? Não. Agentes sem código como Claude Cowork são criados para usuários não técnicos — você escreve instruções em linguagem simples. Agentes de programação como Codex e Claude Code envolvem uma curva de aprendizado, mas mesmo eles são cada vez mais usados por pessoas que não se consideram programadores. Comece sem código, passe para código só quando uma tarefa exigir. ### Qual é a diferença entre um chatbot e um agente de IA? Um chatbot responde perguntas; um agente completa tarefas. O agente pode executar uma sequência de ações — ler, decidir, agir, verificar, corrigir — em um loop, produzindo trabalho concluído em vez de conselhos. Na prática, o mesmo produto frequentemente faz os dois; o "modo agente" é o comportamento de agente. ### Cowork é melhor que Codex? Eles são para trabalhos diferentes, não melhores ou piores. Cowork é um espaço de trabalho sem código para documentos, pesquisa e operações. Codex (e Claude Code) são agentes de programação para construir e corrigir software. Escolha o que corresponde à sua tarefa. ### Como obter bons resultados de um agente de IA? Especificidade. Use a estrutura de quatro partes: papel, contexto, tarefa exata e restrições mais uma verificação. Dê a ele materiais reais, informe o formato que você quer e peça que ele sinalize ambiguidades antes de começar. Instruções claras importam mais do que qualquer "prompt mágico". ### É seguro deixar agentes de IA rodarem sozinhos? Para tarefas de baixo risco e reversíveis (redigir, resumir, organizar), sim — revise o resultado e siga em frente. Para qualquer coisa que mude sistemas reais (publicar código, enviar mensagens, deletar dados), mantenha um humano no loop e revise antes de agir. A reversibilidade é o teste correto: quanto mais fácil for desfazer algo, mais autonomia o agente pode ter com segurança. **Leituras relacionadas:** [Como ser citado nas respostas do ChatGPT](https://alejandrorioja.com/how-to-get-cited-in-chatgpt-answers/) · [O manual do llms.txt](https://alejandrorioja.com/llms-txt-playbook/) · [Como usar as tarefas programadas do Claude](https://alejandrorioja.com/how-to-use-claude-scheduled-tasks/) --- **Quer ajuda para colocar agentes para trabalhar no seu negócio?** Eu construo sistemas de agentes de IA para equipes operacionais — [entre em contato](https://alejandrorioja.com/contact/) ou leia mais sobre [como penso sobre isso](https://alejandrorioja.com/seo-tips/). --- ## Como a Anthropic Ganha Dinheiro? O Modelo de Negócio do Claude Explicado Source: https://alejandrorioja.com/pt/how-does-anthropic-make-money/ Published: 2026-06-11 Updated: 2026-06-11 Tags: Business, AI TL;DR: A Anthropic vende acesso aos seus modelos de IA Claude por meio de cinco canais principais: uma API baseada em uso (você paga por token), assinaturas para consumidores (Claude Pro e Max), planos empresariais (licenças Team e Enterprise), Claude Code para desenvolvedores e distribuição via marketplaces cloud como Amazon Bedrock e Google Vertex. A API e o negócio empresarial — não o app para consumidores — são os maiores geradores de receita. ## Table of contents _Atualizado junho de 2026._ **TL;DR:** A Anthropic vende acesso aos seus modelos de IA Claude por meio de cinco canais principais: uma **API baseada em uso** (você paga por token), **assinaturas para consumidores** (Claude Pro e Max), **planos empresariais** (licenças Team e Enterprise), **Claude Code** para desenvolvedores e **distribuição via marketplaces cloud** como Amazon Bedrock e Google Vertex AI. A API e o negócio empresarial — não o app de chat para consumidores — são os maiores geradores de receita. **[Nota do operador]** Eu desenvolvo na API da Anthropic todos os dias, então vejo o negócio de dentro do medidor. O que precisa ser entendido: a Anthropic é uma empresa B2B com uma porta de entrada para consumidores. O app de chat que você usa é marketing e uma linha de receita; o dinheiro de verdade está nos desenvolvedores e empresas que medem tokens pela API e pagam por licenças em escala. ## O que é a Anthropic A Anthropic é uma empresa de segurança e pesquisa em IA, fundada em 2021, que desenvolve a família de grandes modelos de linguagem **Claude**. Ela vende esses modelos — e as ferramentas ao redor deles — para consumidores, desenvolvedores e empresas. É uma empresa privada, fortemente apoiada por investidores estratégicos, incluindo Amazon e Google, que também atuam como parceiros de cloud e distribuição. O produto é inteligência como serviço: você não compra um software em caixa, você aluga o acesso a um modelo que lê, escreve, raciocina e age em seu nome. Cada canal abaixo é um invólucro diferente em torno do mesmo ativo central. ## Como a Anthropic ganha dinheiro? ### 1. A API (baseada em uso, o motor central) A base do negócio. Desenvolvedores e empresas chamam o Claude por meio de uma API e pagam **por token** — grosso modo, por fragmento de texto de entrada e saída. O preço escala com a capacidade do modelo: - **Claude Opus** (o nível mais capaz) tem o preço mais alto — na ordem de alguns dólares por milhão de tokens de entrada e várias vezes isso para a saída. - **Claude Sonnet** (o modelo equilibrado) fica no meio. - **Claude Haiku** (o nível rápido e barato) é o mais acessível, para tarefas simples de alto volume. Os tokens de saída custam mais do que os de entrada, e recursos como contexto longo, cache de prompts e processamento em lote têm sua própria precificação. A dinâmica-chave: **a receita escala diretamente com o uso**. Uma startup que integra o Claude ao seu produto e cresce para milhões de usuários gera mais receita de API a cada mês sem que a Anthropic precise assinar um novo contrato. Esse modelo baseado em uso é a razão pela qual os laboratórios de IA falam sobre "receita recorrente" crescendo tão rápido — ela se multiplica com o próprio crescimento dos clientes. ### 2. Assinaturas para consumidores (Claude Pro e Max) Os apps Claude (web, desktop, mobile) são gratuitos para testar, com níveis pagos para quem os usa intensamente: - **Claude Pro** — uma mensalidade fixa para limites de uso mais altos, acesso aos melhores modelos e recursos como contexto mais amplo e acesso prioritário. - **Claude Max** — um nível de preço mais alto para usuários avançados que atingem os limites do Pro, com muito mais margem de uso. Esta é a parte mais visível da Anthropic, mas, para uma empresa cujos clientes são principalmente outras empresas, é uma fatia menor do que as linhas de API e enterprise. Seu valor estratégico é tanto como funil e superfície de marca quanto como fonte de receita. ### 3. Enterprise (licenças Team e Enterprise) Onde está grande parte da receita duradoura. As empresas compram o Claude para seus funcionários com base em **licenças por usuário**, com planos construídos para organizações: - **Team** — para empresas menores: uso agrupado, faturamento centralizado, recursos de colaboração. - **Enterprise** — para grandes organizações: maior segurança e conformidade, login único, janelas de contexto maiores, controles de administrador e garantias de uso. Os contratos empresariais são recorrentes, expandem ao longo do tempo (mais licenças, mais uso) e vêm com o tipo de custos de troca que tornam a receita previsível. Esse é o movimento SaaS clássico sobreposto ao modelo. ### 4. Claude Code (ferramentas para desenvolvedores) **Claude Code** é a ferramenta de codificação agêntica da Anthropic — um agente que escreve, edita e executa código no seu terminal, IDE ou na nuvem. É monetizado pelos mesmos trilhos de assinatura e uso (está incluído nos níveis Pro/Max/Team/Enterprise e conta contra o seu plano). Estrategicamente, faz duas coisas: é uma linha de receita por si só e gera muito uso de tokens de alto valor, já que agentes de codificação consomem uma grande quantidade de capacidade do modelo. ### 5. Distribuição via marketplaces cloud (AWS, Google e mais) A Anthropic não vende apenas Claude diretamente — também distribui pelas grandes plataformas cloud: - **Amazon Bedrock** e **Claude Platform on AWS** — clientes que já estão na AWS acessam o Claude por meio da infraestrutura e faturamento da Amazon. - **Google Vertex AI** e **Microsoft Foundry** — a mesma ideia no Google Cloud e na plataforma da Microsoft. Esses canais alcançam as empresas onde seus gastos em cloud e processos de compra já existem, o que reduz o atrito para adotar o Claude. A receita é compartilhada com a plataforma, mas o alcance é enorme — e os investimentos profundos da Amazon e do Google tornam essas parcerias estratégicas, não apenas comerciais. ### 6. A plataforma de agentes emergente Cada vez mais, a Anthropic vende não apenas chamadas de modelo brutas, mas **infraestrutura de agentes** — serviços gerenciados onde a Anthropic executa o loop do agente e hospeda o ambiente em que os agentes realizam tarefas. À medida que mais clientes passam de "fazer uma pergunta ao modelo" para "ter um agente fazendo o trabalho", essa camada de nível superior se torna um novo lugar para capturar valor além do núcleo de pagamento por token. ## A Anthropic é lucrativa? A Anthropic é privada e não publica demonstrações financeiras auditadas, mas o quadro público é o mesmo dos seus pares: **a receita está crescendo extremamente rápido**, enquanto a empresa gasta somas enormes em computação (treinamento e inferência de modelos) e talentos de pesquisa. Como outros laboratórios de IA de fronteira, está numa fase de investimento intenso onde o crescimento da linha superior, não o lucro atual, é o destaque. A aposta que os investidores fazem é que a receita baseada em uso continua se multiplicando à medida que a IA é incorporada em mais softwares, eventualmente superando o custo da computação. ## Como se compara com a OpenAI As estruturas são semelhantes — ambas monetizam por meio de assinaturas para consumidores, uma API baseada em uso, licenças enterprise e ferramentas para desenvolvedores. As diferenças estão na ênfase e nas parcerias: a Anthropic aposta fortemente na API de desenvolvedores/enterprise e é apoiada pela Amazon e pelo Google; a OpenAI tem uma presença maior no mercado consumidor e uma profunda parceria com a Microsoft. Se você quiser o outro lado da comparação, veja [como a OpenAI ganha dinheiro](https://alejandrorioja.com/how-does-openai-make-money/). ## Modelo de receita da Anthropic — FAQ 2026 ### Qual é a principal fonte de receita da Anthropic? A **API baseada em uso** e os **contratos empresariais** são os maiores impulsionadores. Desenvolvedores e empresas pagam por token para chamar o Claude, e organizações compram planos por usuário para suas equipes. A assinatura Claude para consumidores é o produto mais visível, mas uma fatia menor da receita do que as linhas de negócio. ### Como funciona a precificação da API do Claude? Você paga por token — entrada e saída medidas em fragmentos de texto. Modelos mais capazes (Opus) custam mais por token do que os equilibrados (Sonnet) ou rápidos (Haiku), e os tokens de saída custam mais do que os de entrada. Recursos como contexto longo, cache de prompts e processamento em lote têm sua própria precificação. A receita escala diretamente com o quanto os clientes usam os modelos. ### A Anthropic tem capital aberto? Não. A Anthropic é uma empresa privada apoiada por investidores estratégicos e de capital de risco, incluindo Amazon e Google. Suas ações não estão disponíveis em bolsas de valores públicas e não há confirmação de abertura de capital. ### A Anthropic ganha dinheiro com o app gratuito do Claude? Não diretamente com usuários gratuitos — o nível gratuito é um funil. O dinheiro chega quando usuários gratuitos fazem upgrade para **Pro** ou **Max**, quando equipes compram **licenças enterprise** e especialmente quando desenvolvedores constroem sobre a **API**. O trabalho do app gratuito é alcance e marca; os níveis pagos e a API são onde converte. ### Quem são os maiores clientes da Anthropic? Principalmente outras empresas: empresas de software que integram o Claude em seus produtos via API, e empresas que implantam o Claude para seus funcionários. A distribuição via marketplaces cloud pela AWS, Google e Microsoft também atrai grandes clientes empresariais que compram pelos seus provedores cloud existentes. **Leitura relacionada:** [Como a OpenAI ganha dinheiro](https://alejandrorioja.com/how-does-openai-make-money/) · [O guia para iniciantes sobre agentes de IA](https://alejandrorioja.com/ai-agents-for-beginners-cowork-codex-guide/) · [Como ser citado nas respostas do ChatGPT](https://alejandrorioja.com/how-to-get-cited-in-chatgpt-answers/) --- ## A versão resumida A Anthropic aluga o acesso aos seus modelos Claude. Os desenvolvedores pagam por token pela API, os consumidores pagam mensalmente pelo Pro e Max, as empresas pagam por licença pelo Team e Enterprise, os engenheiros usam o Claude Code nesses mesmos planos, e os gigantes da nuvem (AWS, Google, Microsoft) revendem o Claude para empresas por meio dos seus marketplaces. É um negócio B2B com uma porta de entrada para consumidores — e o medidor, não o app de chat, é onde está o dinheiro. --- ## Como a OpenAI ganha dinheiro? O modelo de negócios do ChatGPT e da API Source: https://alejandrorioja.com/pt/how-does-openai-make-money/ Published: 2026-06-11 Updated: 2026-06-11 Tags: Business, AI TL;DR: A OpenAI ganha dinheiro de quatro formas principais: assinaturas do ChatGPT (Plus, Pro, Team, Enterprise, Edu), uma API baseada em uso onde desenvolvedores pagam por token, grandes contratos corporativos e sua parceria com a Microsoft (distribuição mais um acordo de compartilhamento de receita). Ao contrário da maioria dos laboratórios de IA, o negócio de assinaturas de consumidores da OpenAI é sua maior linha de receita — a escala do ChatGPT é o motor. ## Table of contents _Atualizado em junho de 2026._ **TL;DR:** A OpenAI ganha dinheiro de quatro formas principais: **assinaturas do ChatGPT** (Plus, Pro, Team, Enterprise, Edu), uma **API baseada em uso** onde desenvolvedores pagam por token, grandes **contratos corporativos** e sua **parceria com a Microsoft** (distribuição mais um acordo de compartilhamento de receita). Ao contrário da maioria dos laboratórios de IA, o negócio de assinaturas de consumidores da OpenAI é sua maior linha de receita — a enorme escala do ChatGPT é o motor. **[Leitura para operadores]** A OpenAI é o inverso de uma empresa típica de IA corporativa: primeiro construiu um fenômeno de consumo e depois um negócio para desenvolvedores e empresas. Os centenas de milhões de usuários do ChatGPT são tanto a marca quanto a máquina de gerar receita. Todos os outros nesse espaço gostariam de ter esse nível de aquisição no topo do funil. ## O que é a OpenAI? A OpenAI é a empresa de pesquisa em IA por trás do **ChatGPT** e da família de modelos **GPT**, além de produtos como o modelo de vídeo Sora, geração de imagens e o agente de programação Codex. Fundada em 2015, alcançou notoriedade ampla quando o ChatGPT foi lançado no final de 2022 e se tornou um dos produtos de consumo de crescimento mais rápido da história. Sua estrutura é incomum: começou como uma organização sem fins lucrativos e criou um braço com fins lucrativos limitados para captar o enorme capital que o treinamento de modelos de ponta exige. Não é de capital aberto e mantém uma parceria profunda e plurianual com a **Microsoft** que fornece computação, distribuição e capital. O produto, como o de qualquer laboratório de IA, é inteligência como serviço — vendida pelos canais de consumidores, desenvolvedores e corporativo. ## Como a OpenAI ganha dinheiro? ### 1. Assinaturas do ChatGPT (a maior linha de receita) É isso que diferencia a OpenAI de seus pares. O ChatGPT é gratuito, com níveis pagos que convertem uma fatia de sua enorme base de usuários em receita recorrente: - **ChatGPT Plus** — uma mensalidade fixa para acesso aos melhores modelos, limites mais altos e recursos premium. O nível para o mercado de massa. - **ChatGPT Pro** — um nível de preço mais alto para usuários avançados que desejam uso máximo e as configurações de modelo mais capazes. - **ChatGPT Team** — planos por assento para pequenas empresas, com espaços de trabalho compartilhados e ferramentas de administração. - **ChatGPT Enterprise** — para grandes organizações: segurança avançada, conformidade, SSO, contexto maior e garantias de uso. - **ChatGPT Edu** — uma versão adaptada para universidades e escolas. Como o ChatGPT alcança centenas de milhões de usuários semanais, mesmo uma taxa de conversão de um único dígito baixo para planos pagos gera um negócio de assinaturas enorme. Essa escala de consumidores é a vantagem definidora da OpenAI, e as assinaturas são reportadas como sua maior fonte de receita. ### 2. A API (baseada em uso, para desenvolvedores) Desenvolvedores e empresas integram os modelos da OpenAI em seus próprios produtos e pagam **por token** — por fragmento de texto (ou imagem ou áudio) processado. O preço escala com a capacidade do modelo: os modelos de raciocínio principais custam mais por token do que os menores, mais rápidos e mais baratos, e a saída tem preço maior do que a entrada. A API transforma cada empresa que desenvolve sobre o GPT em um cliente medido cuja conta cresce com seu próprio uso. É a mesma dinâmica de composição com que todo laboratório de IA conta: uma startup que integra a OpenAI e escala para milhões de usuários gera mais receita de API a cada mês sem nenhum novo contrato. ### 3. Contratos corporativos Além da API de autoatendimento e dos planos Team, a OpenAI assina grandes acordos personalizados com empresas de grande porte — uso em volume, capacidade dedicada, suporte personalizado e compromissos de segurança e conformidade. Esses contratos são recorrentes, expandem com o tempo e se tornam difíceis de substituir quando uma empresa constrói fluxos de trabalho críticos sobre os modelos. Esse movimento corporativo coexiste com o negócio de consumidores e é uma importante área de crescimento. ### 4. A parceria com a Microsoft A Microsoft é a maior parceira estratégica da OpenAI. O relacionamento funciona em vários eixos: - **Computação** — A nuvem Azure da Microsoft fornece grande parte da infraestrutura na qual a OpenAI treina e serve modelos. - **Distribuição** — Os modelos da OpenAI são oferecidos por meio das plataformas da Microsoft (serviços de IA do Azure, produtos Copilot), colocando o GPT diante da gigantesca base de clientes corporativos da Microsoft. - **Compartilhamento de receita** — As duas empresas compartilham receita sob seu acordo comercial, e a Microsoft investiu pesadamente na OpenAI. Essa parceria é parte capital, parte entrada no mercado: dá à OpenAI acesso a empresas que levariam anos para vender diretamente. ### 5. Produtos novos e adjacentes A OpenAI continua expandindo a superfície que pode monetizar: - **Codex** — sua ferramenta de programação agêntica, monetizada por assinaturas e uso de API (e um motor de consumo intenso de tokens). - **Sora** — geração de vídeo, oferecida dentro dos níveis pagos e como produto independente. - **Geração de imagens e outras modalidades** — incluídas nas assinaturas e medidas via API. - **Um ecossistema de desenvolvedores e agentes** — GPTs personalizados, uma plataforma de agentes e ferramentas que permitem que empresas construam sobre os modelos da OpenAI. Cada um desses é mais um invólucro em torno do mesmo ativo central, com o objetivo de capturar mais do que usuários e desenvolvedores estão dispostos a pagar. ## A OpenAI é lucrativa? A OpenAI é privada e não publica demonstrações financeiras auditadas. O panorama amplamente reportado: **a receita é muito grande e cresce rapidamente**, mas os custos também — treinar modelos de ponta e servir centenas de milhões de usuários consome quantidades impressionantes de computação. Como seus pares, a OpenAI está em uma fase de investimento intenso onde a prioridade é crescimento e capacidade, e não lucro de curto prazo. A aposta é que a escala mais a adoção corporativa crescente eventualmente supere os custos de computação. ## Como se compara à Anthropic? Os blocos de construção são semelhantes — assinaturas de consumidores, uma API baseada em uso, acordos corporativos, ferramentas de programação — mas a ênfase difere. A vantagem definidora da OpenAI é a **escala de consumidores** (ChatGPT) e sua parceria com a **Microsoft**; a Anthropic aposta mais na **API para desenvolvedores e corporativa** e é apoiada pela Amazon e pelo Google. Para o outro lado da comparação, veja [como a Anthropic ganha dinheiro](https://alejandrorioja.com/how-does-anthropic-make-money/). ## Modelo de receita da OpenAI — FAQ 2026 ### Qual é a maior fonte de receita da OpenAI? **Assinaturas do ChatGPT.** Como o ChatGPT alcança centenas de milhões de usuários, seus níveis pagos (Plus, Pro, Team, Enterprise, Edu) constituem a maior linha de receita da OpenAI — um perfil incomum para um laboratório de IA, a maioria dos quais ganha mais com APIs e corporativo do que com consumidores. ### Como a API da OpenAI gera receita? Desenvolvedores pagam **por token** para usar os modelos da OpenAI em seus próprios aplicativos — por fragmento de texto, imagem ou áudio processado. Modelos mais capazes custam mais por token, e a saída tem preço maior do que a entrada. A receita cresce automaticamente conforme o uso dos clientes aumenta. ### A OpenAI tem capital aberto? Posso comprar ações da OpenAI? Não. A OpenAI é de capital fechado e suas ações não estão disponíveis em bolsas públicas. A maioria das pessoas não pode investir diretamente. A Microsoft detém uma participação importante por meio de sua parceria, mas isso não é o mesmo que a OpenAI ser pública. ### Como a parceria com a Microsoft gera dinheiro para a OpenAI? A Microsoft fornece computação Azure, distribui os modelos da OpenAI por seus produtos e nuvem para uma enorme base corporativa, e as duas empresas compartilham receita sob seu acordo comercial. A Microsoft também investiu pesadamente na OpenAI. É tanto uma fonte de financiamento quanto um canal de distribuição. ### A OpenAI ganha dinheiro com usuários gratuitos do ChatGPT? Não diretamente — o nível gratuito é um funil. A receita vem quando usuários gratuitos fazem upgrade para **Plus** ou **Pro**, quando empresas compram assentos **Team** ou **Enterprise**, e quando desenvolvedores constroem sobre a **API**. O papel do produto gratuito é alcance; os níveis pagos e a API convertem esse alcance. **Leitura relacionada:** [Como a Anthropic ganha dinheiro](https://alejandrorioja.com/how-does-anthropic-make-money/) · [Como a SpaceX ganha dinheiro](https://alejandrorioja.com/how-does-spacex-make-money/) · [O guia para iniciantes em agentes de IA](https://alejandrorioja.com/ai-agents-for-beginners-cowork-codex-guide/) --- ## A versão resumida A OpenAI converte a enorme base de usuários do ChatGPT em receita de assinaturas (Plus, Pro, Team, Enterprise), cobra desenvolvedores por token através de sua API, assina grandes contratos corporativos e depende da Microsoft para computação, distribuição e receita compartilhada. Sua característica definidora é a escala de consumidores — a maioria dos laboratórios de IA monetiza desenvolvedores primeiro; a OpenAI construiu um fenômeno de consumidores e um negócio por trás dele. --- ## Como a SpaceX Ganha Dinheiro? Lançamentos, Starlink e a Questão do IPO Source: https://alejandrorioja.com/pt/how-does-spacex-make-money/ Published: 2026-06-11 Updated: 2026-06-11 Tags: Business TL;DR: A SpaceX ganha dinheiro de três formas: serviços de lançamento (venda de viagens à órbita em foguetes Falcon reutilizáveis), Starlink (internet via satélite para consumidores, empresas, marítimo/aviação e governo) e contratos governamentais (tripulação e carga NASA, módulos de pouso lunar, lançamentos de segurança nacional). O Starlink é agora o maior motor de receita. A SpaceX permanece privada; um IPO da SpaceX em si não é iminente, embora um futuro spin-off do Starlink há muito seja cogitado. ## Table of contents _Atualizado junho de 2026._ **TL;DR:** A SpaceX ganha dinheiro de três formas: **serviços de lançamento** (venda de viagens à órbita em foguetes Falcon reutilizáveis), **Starlink** (internet via satélite para consumidores, empresas, marítimo/aviação e governo) e **contratos governamentais** (tripulação e carga NASA, módulos de pouso lunar, lançamentos de segurança nacional). O Starlink é agora o maior motor de receita. A SpaceX permanece privada; um IPO da SpaceX em si não é iminente, embora um futuro spin-off do Starlink há muito seja cogitado e repetidamente arrefecido. **[Leitura do operador]** A SpaceX é o exemplo moderno mais claro de uma empresa que usou um fosso de tecnologia de hardware (foguetes reutilizáveis) para construir um negócio de economia de software (internet via satélite) sobre ele. O negócio de lançamento conquista o direito de existir; o Starlink é onde está o dinheiro recorrente e escalável. Essa é toda a história em uma frase. ## O que é a SpaceX A SpaceX (Space Exploration Technologies Corp.) projeta, constrói e opera foguetes e naves espaciais, e opera a rede de internet via satélite Starlink. Fundada em 2002 com o objetivo de longo prazo de tornar a humanidade multiplanetária, tornou-se o principal provedor de lançamentos do mundo fazendo algo que ninguém mais fez em escala: pousar e reutilizar o primeiro estágio de um foguete orbital, o que derrubou o custo de chegar ao espaço. Essa vantagem de custo é o motor por trás de tudo o mais. Lançamentos baratos, frequentes e confiáveis são o que torna economicamente possível uma constelação de mais de 7.000 satélites — e a constelação é o que transforma um negócio de lançamento irregular e baseado em projetos em um de receita recorrente. ## Como a SpaceX ganha dinheiro? ### 1. Serviços de lançamento O negócio original. A SpaceX vende lançamentos para três tipos de clientes: - **Operadores de satélites comerciais** — empresas que precisam de uma carga útil em órbita pagam por um lançamento dedicado ou uma vaga em uma missão de **rideshare** (muitos satélites pequenos em um único foguete, com preço por quilograma). - **Governo e militares** — cargas úteis de segurança nacional e missões científicas, geralmente com um prêmio por confiabilidade e garantia. - **Outras empresas espaciais** — incluindo, cada vez mais, concorrentes que ainda dependem da SpaceX porque é a carona mais barata e disponível. A economia unitária funciona por causa da **reutilizabilidade**: o mesmo propulsor de primeiro estágio voa muitas vezes, portanto o custo marginal de um lançamento fica muito abaixo do preço. O Falcon 9 é o carro-chefe; o Falcon Heavy lida com as cargas úteis mais pesadas. ### 2. Starlink (a máquina de receita recorrente) O Starlink é uma constelação de milhares de satélites em órbita baixa terrestre que fornece internet de alta velocidade para lugares que a banda larga terrestre não consegue alcançar ou atender. É agora a parte da SpaceX que parece um negócio de assinatura real, com várias camadas: - **Consumidor** — residências pagam por um dish (hardware) mais uma assinatura mensal. - **Empresa e mobilidade** — planos com preços mais altos para empresas, setor marítimo (navios, iates) e **aviação** (acordos de Wi-Fi a bordo com companhias aéreas). - **Governo** — incluindo **Starshield**, a variante orientada à defesa vendida para clientes militares e governamentais. - **Direto para celular** — parcerias com operadoras móveis para fornecer conectividade via satélite diretamente para telefones comuns em zonas mortas. O Starlink combina vendas de hardware (o terminal) com receita mensal recorrente (a assinatura) entre milhões de assinantes — o formato clássico de barbeador e lâminas, em escala planetária. É por isso que a maioria das estimativas agora coloca o Starlink à frente dos lançamentos como a maior linha de receita da SpaceX. ### 3. Contratos governamentais Um segmento distinto e muito grande que se sobrepõe aos lançamentos, mas merece ser separado: - **NASA** — a SpaceX transporta astronautas para a Estação Espacial Internacional no âmbito do programa **Commercial Crew** (Crew Dragon) e a reabastece com **Cargo Dragon**. Também ganhou um contrato para construir um sistema de pouso lunar baseado em **Starship** para as ambições lunares da NASA. - **Segurança nacional** — contratos recorrentes de lançamento para cargas úteis de defesa e inteligência. Esses contratos são de alto valor, plurianuais e financiam grande parte do desenvolvimento que beneficia o setor comercial. ### 4. Starship (o motor do futuro, ainda não um centro de lucro) O Starship é o veículo de lançamento super-pesado totalmente reutilizável da SpaceX — o substituto de longo prazo do Falcon e a chave tanto para missões lunares/a Marte quanto para a próxima geração maior de satélites Starlink. Hoje é um centro de custos financiado pelos outros três negócios. Se atingir voos de rotina, reduz drasticamente o custo de lançamento novamente e viabiliza uma implantação muito maior do Starlink — essa é a aposta que os investidores estão realmente fazendo. ## A SpaceX é lucrativa? A SpaceX é privada e não publica demonstrações financeiras auditadas, portanto qualquer coisa precisa é uma estimativa. O panorama amplamente reportado: os lançamentos são lucrativos por missão graças à reutilizabilidade, e o Starlink cruzou para território de fluxo de caixa positivo à medida que sua base de assinantes cresceu. A empresa reinveste enormes somas no desenvolvimento do Starship, portanto o "lucro" depende muito de como se trata esse P&D. A direção de marcha — crescente receita recorrente do Starlink sobre um negócio de lançamento dominante — é o que sustenta a enorme avaliação privada da empresa. ## A questão do IPO Esta é a parte que todos perguntam, então aqui está a versão honesta. **Não se espera que a SpaceX faça um IPO em breve.** Elon Musk disse repetidamente que prefere manter a SpaceX privada enquanto o Starship e o programa a Marte são intensivos em capital e de longo horizonte — a pressão trimestral do mercado público não se encaixa em uma missão de décadas. Em vez disso, a SpaceX oferece liquidez a funcionários e investidores iniciais por meio de **ofertas de venda periódicas** (a empresa facilita a venda de ações a um preço fixo), o que permite que as pessoas realizem lucros sem uma listagem pública. Essas vendas secundárias são o que produz os números de avaliação nas manchetes — a SpaceX foi avaliada em centenas de bilhões de dólares em rodadas recentes. **Um IPO de spin-off do Starlink há muito é cogitado** — o próprio Musk sugeriu anos atrás que o Starlink poderia eventualmente abrir o capital uma vez que sua receita fosse estável e previsível. Mas ele também esfriou repetidamente as expectativas de prazo próximo. A partir de 2026, o Starlink não fez IPO e não há data confirmada. Trate qualquer manchete de "data de IPO do Starlink" com ceticismo a menos que venha da própria empresa. ## Conclusão O modelo da SpaceX é uma pilha: o lançamento reutilizável cria um fosso de custo, esse fosso torna o Starlink economicamente possível, o Starlink transforma tudo em um negócio de receita recorrente, e os contratos governamentais financiam o trabalho de fronteira (Starship) que redefine a curva de custos novamente. Ela permanece privada por escolha, usando ofertas de venda em vez de um IPO — e o caminho mais provável para os mercados públicos é uma futura listagem do Starlink, não da SpaceX como um todo, quando a empresa decidir que é o momento certo. ## Modelo de Receita da SpaceX — FAQ 2026 ### Qual é a maior fonte de receita da SpaceX? A maioria das estimativas agora coloca o **Starlink** à frente dos serviços de lançamento como a maior linha de receita da SpaceX, impulsionado por milhões de assinaturas de consumidores, empresas, mobilidade e governo, além de vendas de hardware de terminais. Os serviços de lançamento permanecem grandes e altamente lucrativos por missão, mas o modelo recorrente do Starlink escala mais rápido. ### A SpaceX é negociada em bolsa? Posso comprar ações da SpaceX? Não. A SpaceX é uma empresa privada e suas ações não estão disponíveis em bolsas públicas. A maioria das pessoas não pode investir diretamente; o acesso é geralmente limitado a funcionários e investidores credenciados que participam de rodadas privadas ou ofertas de venda. Cuidado com ofertas de "ações da SpaceX" que sugiram o contrário. ### A SpaceX ou o Starlink farão IPO? Não se espera que a SpaceX abra o capital no curto prazo — Musk disse que quer mantê-la privada durante a fase intensiva em capital do Starship/Marte. Um IPO do **Starlink** tem sido discutido há anos como uma possibilidade quando sua receita for previsível, mas a partir de 2026 não há data confirmada. Qualquer afirmação específica de "data de IPO" deve ser tratada com ceticismo a menos que venha da empresa. ### Como o Starlink ganha dinheiro? O Starlink cobra dos clientes por um dish de satélite (hardware) mais uma assinatura mensal, em níveis de consumidor, empresarial, marítimo, aviação e governo — incluindo o Starshield orientado à defesa e parcerias com operadoras de direto para celular. É um modelo de barbeador e lâminas: hardware na frente, receita recorrente depois. ### Como a reutilizabilidade ajuda os lucros da SpaceX? Pousar e revoar o mesmo propulsor de foguete muitas vezes reduz o custo marginal de cada lançamento muito abaixo do preço cobrado. Essa vantagem de custo é o que torna a SpaceX o provedor de lançamento mais barato e o que torna economicamente viável implantar uma constelação Starlink de vários milhares de satélites. **Leitura relacionada:** [Como o Uber ganha dinheiro](https://alejandrorioja.com/how-does-uber-make-money/) · [Como a Shopify ganha dinheiro](https://alejandrorioja.com/how-shopify-makes-money/) · [Como o PayPal ganha dinheiro](https://alejandrorioja.com/how-does-paypal-make-money/) --- ## A versão resumida A SpaceX vende viagens à órbita de forma barata porque reutiliza seus foguetes, depois usa essa vantagem de custo para operar o Starlink — um negócio de assinatura de internet via satélite que agora é seu maior gerador de receita — enquanto contratos governamentais financiam o Starship de próxima geração. Ela permanece privada propositalmente; um IPO do Starlink, não da SpaceX, é o caminho eventual mais provável para os mercados públicos. --- ## Como usar as tarefas agendadas do Claude: automatize trabalhos recorrentes com cron Source: https://alejandrorioja.com/pt/how-to-use-claude-scheduled-tasks/ Published: 2026-06-11 Updated: 2026-06-11 Tags: Productivity, AI TL;DR: As tarefas agendadas transformam um prompt pontual do Claude em um trabalho recorrente: ele dispara em um cronograma tipo cron, faz o trabalho e entrega o resultado. Use o app Claude para prompts pessoais recorrentes (um digest matinal, um resumo semanal) e as rotinas do Claude Code ou os deployments de Managed Agents para automação de desenvolvedores que roda na nuvem. O ganho vem de automatizar o trabalho que você faria à mão todo dia ou toda semana. ## Table of contents _Atualizado junho de 2026._ **TL;DR:** As tarefas agendadas transformam um prompt pontual do Claude em um trabalho recorrente: ele dispara em um cronograma tipo cron, faz o trabalho e entrega o resultado. Use o **app Claude** para prompts pessoais recorrentes (um digest matinal, um resumo semanal) e as **rotinas do Claude Code** ou os **deployments de Managed Agents** para automação de desenvolvedores que roda na nuvem. O ganho vem de automatizar o trabalho que você faria à mão todo dia ou toda semana. **[Leitura para operadores]** As automações de maior alavancagem não são espetaculares — são os pequenos trabalhos recorrentes que consomem silenciosamente 20 minutos por dia. Uma tarefa agendada é a forma de entregá-los ao Claude uma única vez e nunca mais pensar nisso. Eu rodo várias: um scan matinal de concorrentes, uma verificação noturna do status dos PRs, um rascunho semanal do pipeline de conteúdo. Nenhuma levou mais de dez minutos para configurar. ## O que é uma tarefa agendada Uma sessão normal do Claude é síncrona: você digita, ele responde, você está lá. Uma **tarefa agendada** é assíncrona e recorrente: você define um prompt (ou um workflow completo de agente) mais um cronograma, e o Claude o executa por conta própria — às 7h em cada dia útil, toda segunda-feira, a cada hora — e entrega o resultado quando termina. Por baixo dos panos é um cron job com um LLM no centro. Você não está escrevendo código para colar APIs; está descrevendo o resultado em linguagem natural e deixando o agente descobrir os passos a cada disparo. ## Os três lugares onde você vai configurá-las Não existe um único botão — existem três superfícies, adequadas ao seu perfil. ### 1. O app Claude (para todos) Os apps Claude para consumidores suportam tarefas recorrentes: você salva um prompt e uma cadência, o Claude o executa no cronograma e te notifica com o resultado. Este é o caminho sem código — ideal para um briefing diário, uma pesquisa recorrente, um trabalho de "resuma meus newsletters não lidos toda manhã". Se você não é desenvolvedor, é por aqui que começa. ### 2. Rotinas do Claude Code (para quem vive no terminal) Se você usa o **Claude Code**, pode agendar um prompt ou um slash command para rodar em cadência cron como um agente na nuvem — uma "rotina". Ela roda no lado do servidor no seu repositório ou workspace, então funciona mesmo com o notebook fechado. Usos típicos: monitorar pull requests abertos, rodar uma passagem noturna de lint-e-correção, gerar um rascunho de post toda manhã para revisão. Você define o cronograma e a tarefa; o Claude Code cuida do disparo e do registro de execuções. ### 3. Deployments de Managed Agents (para desenvolvedores que constroem produtos) Para equipes que desenvolvem na Claude API, os **deployments agendados** rodam um agente em um cronograma cron recorrente — cada disparo cria uma sessão que faz o trabalho de forma autônoma (um scan de conformidade noturno, um relatório semanal, um monitor por hora). Você recebe um registro de execução por disparo para auditar sucessos e falhas. Esta é a versão programática e de nível produção da mesma ideia. ## Como pensar o cronograma Os três usam o mesmo modelo mental — **qual tarefa, com que frequência, o que fazer com o resultado**: 1. **A tarefa** — escreva como você escreveria qualquer bom prompt de agente: papel, contexto, ação exata, restrições e uma verificação. Uma tarefa agendada não pode fazer uma pergunta de esclarecimento no meio da execução, então precisa ser *totalmente especificada de antemão*. Esta é a maior diferença em relação ao uso interativo. 2. **A cadência** — diária, semanal, por hora, apenas dias úteis, um horário específico no seu fuso horário. Alinhe-a com a velocidade com que a coisa subjacente realmente muda; um digest "diário" de uma fonte atualizada semanalmente são execuções desperdiçadas. 3. **A entrega** — onde o resultado vai parar (uma notificação, um arquivo, uma mensagem, um rascunho). Decida isso com antecedência para que o resultado seja útil no momento em que chega. ## Padrões que realmente valem a pena - **O digest matinal.** "Todo dia útil às 7h, busque o que há de mais recente sobre [tópicos], resuma as três coisas que importam e me envie um briefing de 5 bullets." Substitui 20 minutos de varredura manual. - **O relatório semanal.** "Toda segunda-feira, compile [métricas] em um resumo de uma página com o que mudou e por quê." Transforma uma tarefa recorrente em uma revisão. - **O trabalhador noturno.** Uma rotina de código que executa um trabalho longo e bem especificado enquanto você dorme — um refactor, uma varredura de testes, uma limpeza de dados — para que você acorde com um resultado para revisar. - **O monitor.** "A cada hora, verifique [coisa]; só me avise se [condição] for verdadeira." As melhores automações são em sua maioria silenciosas e falam apenas quando importa. ## Dicas de configuração baseadas em uso em produção - **Sobre-especifique o prompt.** Nenhuma pergunta de esclarecimento é possível no meio da execução. Indique o formato, as fontes, as restrições e o que fazer em casos extremos. - **Comece com um teste manual.** Execute o prompt exato uma vez à mão. Se ele produz o que você quer de forma interativa, agende. Se não, corrija o prompt primeiro — agendar um prompt ruim só produz resultados ruins de forma confiável. - **Alinhe a cadência à taxa de mudança.** Não rode por hora algo que se atualiza semanalmente. - **Mantenha os resultados como rascunhos quando os riscos são altos.** Para qualquer coisa que sai para o mundo — um post publicado, um e-mail enviado — faça a tarefa produzir um *rascunho* para sua revisão, não uma ação ao vivo. Reserve o "apenas faça" totalmente autônomo para trabalhos de baixo risco e reversíveis. - **Monitore as primeiras execuções.** Trabalhos agendados desviam — uma fonte muda de formato, um feed fica em silêncio. Verifique os primeiros registros de execução, depois confie. ## Tarefas agendadas Claude — FAQ 2026 ### O que são as tarefas agendadas do Claude? São trabalhos recorrentes: você define um prompt ou workflow de agente mais um cronograma tipo cron, e o Claude o executa automaticamente — diariamente, semanalmente, a cada hora — entregando o resultado sem que você esteja no teclado. Existem nos apps Claude para consumidores (para prompts pessoais recorrentes), no Claude Code (como rotinas na nuvem) e na Claude API (como deployments de Managed Agents). ### Preciso ser desenvolvedor para usá-las? Não. O app Claude suporta tarefas recorrentes sem código — apenas um prompt salvo e uma cadência. As rotinas do Claude Code e os deployments de Managed Agents são as versões voltadas para desenvolvedores que automatizam workflows de código e produto. ### Como uma tarefa agendada difere de um chat normal do Claude? Um chat normal é interativo — você está lá para responder perguntas de acompanhamento. Uma tarefa agendada é autônoma e recorrente, então o prompt precisa ser totalmente especificado de antemão; o Claude não pode pausar para fazer uma pergunta no meio da execução. Ela dispara no cronograma, conclui o trabalho e entrega o resultado. ### Qual é uma boa primeira tarefa agendada? Um digest matinal. "Todo dia útil às 7h, resuma o que há de mais recente sobre [seus tópicos] em cinco bullets." É de baixo risco, fácil de verificar e substitui imediatamente uma tarefa manual recorrente — o modelo perfeito para aprender o workflow antes de automatizar algo maior. ### Uma tarefa agendada pode tomar ações reais, como enviar e-mails? Sim, mas seja deliberado. Para trabalhos reversíveis e de baixo risco, deixe-a agir. Para qualquer coisa voltada ao exterior ou difícil de desfazer, faça a tarefa produzir um rascunho que você aprova em vez de disparar automaticamente — especialmente em execuções sem supervisão. Reversibilidade é o teste correto para quanto de autonomia conceder. **Leitura relacionada:** [O guia do iniciante em agentes de IA](https://alejandrorioja.com/ai-agents-for-beginners-cowork-codex-guide/) · [Como a Anthropic ganha dinheiro](https://alejandrorioja.com/how-does-anthropic-make-money/) · [Como ser citado nas respostas do ChatGPT](https://alejandrorioja.com/how-to-get-cited-in-chatgpt-answers/) --- **Quer um sistema de agentes agendados gerenciando seu trabalho recorrente?** É exatamente isso que eu construo — [entre em contato](https://alejandrorioja.com/contact/). --- ## A Matemática de Custo dos Agentes de IA: Quando o Haiku Vence o Sonnet (e Quando Não) Source: https://alejandrorioja.com/pt/ai-agent-cost-math-when-haiku-beats-sonnet/ Published: 2026-06-08 Tags: AI Agents, Operations TL;DR: Escolher o Claude Haiku em vez do Sonnet pode reduzir drasticamente o custo por chamada, mas só quando a tarefa tolera uma taxa de sucesso menor. A métrica real não é o custo por chamada — é o custo por resultado bem-sucedido, incluindo retentativas e limpeza humana. Eu roteio por tarefa, não por padrão. ## Índice _Atualizado junho 2026._ **TL;DR:** Escolher o Claude Haiku em vez do Sonnet pode reduzir o custo por chamada em uma ordem de grandeza, mas só quando a tarefa tolera a taxa de sucesso menor do Haiku. A métrica que importa é o **custo por resultado bem-sucedido** — custo da chamada mais retentativas mais limpeza humana — não o preço de tabela por token. Eu roteio por tarefa, e uma parcela significativa dos meus passos de alto volume roda no Haiku enquanto as decisões de julgamento ficam no Sonnet. **Leitura do operador:** Eu rodo mais de 100 agentes, e a inferência é um item de custo real. Mas já vi times "economizarem" forçando tudo no modelo mais barato e depois pagarem a conta em retentativas, escalonamentos e clientes irritados. A matemática de custo só funciona quando você mede o funil inteiro. O modelo mais barato não é o que tem o menor preço por token. É o que tem o menor custo total para fazer o trabalho direito. Esses são números diferentes, e a diferença entre eles é exatamente onde a maioria das decisões de custo de agentes dá errado. ## A economia dos tokens, dita sem rodeios A Anthropic cobra pelo Claude por milhão de tokens, com entrada e saída faturadas separadamente, e a saída custando várias vezes mais que a entrada. Os números exatos mudam com o tempo, então confira os preços atuais da Anthropic — mas é a **estrutura** que orienta a decisão: - **Haiku** é o nível barato e rápido — de longe o menor custo por token da família. - **Sonnet** fica no meio — notavelmente mais caro que o Haiku, notavelmente mais barato que o Opus. - **Opus** é o nível premium para o raciocínio mais difícil. Duas coisas decorrem daí. Primeiro, os tokens de saída dominam o custo em tarefas generativas, então um modelo verboso custa mais mesmo com o mesmo preço por token. Segundo, a diferença de preço por token entre Haiku e Sonnet é grande o suficiente para que, num passo de alto volume, ela apareça com certeza na fatura. Esse é o argumento *a favor* do Haiku. Agora o argumento contra. ## A métrica que realmente importa: custo por resultado bem-sucedido O custo por chamada é um número de vaidade. Esta é a fórmula que de fato uso: ``` custo_por_sucesso = (custo_chamada × tentativas) + custo_limpeza ÷ taxa_de_sucesso ``` Onde `tentativas` contabiliza as retentativas, e `custo_limpeza` é o custo esperado de um humano corrigir as falhas que escapam. Veja o que isso faz com a comparação. Suponha que o Haiku custe cerca de um décimo do Sonnet por chamada. Se o Haiku acerta 80% das vezes numa tarefa e o Sonnet acerta 98%, a economia por chamada parece enorme. Mas se cada falha do Haiku dispara uma retentativa e 1 a cada 10 ainda precisa de um humano que custa dinheiro de verdade, o termo de limpeza pode engolir a economia de tokens. Numa tarefa de baixo risco e alto volume, a matemática favorece o Haiku de forma esmagadora. Numa tarefa em que uma falha envia um e-mail ao cliente errado, ela pode se inverter completamente. Você não consegue tomar essa decisão sem medir a taxa de sucesso por modelo — que é exatamente o que um [harness de avaliação](/the-eval-harness-i-use-to-ship-ai-agents/) te dá. Rode o mesmo conjunto de avaliação contra os dois modelos e leia as taxas de sucesso na mesma régua. ## Onde o Haiku vence de forma decisiva O Haiku é a escolha certa quando a tarefa é **estreita, estruturada e verificável**: - **Classificação e roteamento** — "esta mensagem recebida é uma reserva, uma reclamação ou spam?" Três categorias, fácil de verificar, roda o tempo todo. Haiku o dia inteiro. - **Extração com um esquema** — tirar uma data, um nome, um valor de um texto, validado com Zod. Se a saída faz parse, está quase certamente correta. - **Reescritas curtas e formatação** — ajustes de tom, resumir uma entrada sabidamente boa, normalizar dados. - **Filtragem de primeira passagem** — o Haiku faz a triagem, e só os casos ambíguos são escalonados para o Sonnet. Esse é o padrão de maior alavancagem. O fio condutor: o custo de um erro do Haiku é baixo e o erro é barato de detectar. Quando a verificação é barata e o risco é baixo, o modelo barato vence. ## Onde o Sonnet ganha o seu preço O Sonnet (e às vezes o Opus) vale a pena quando a tarefa é **aberta, de múltiplos passos ou cara de errar**: - **Loops de agente com várias ferramentas** onde uma chamada errada de ferramenta gera uma cascata. Maior confiabilidade de raciocínio se acumula ao longo dos passos — os padrões de orquestração que abordo em [orquestração multiagente](/multi-agent-orchestration-patterns-queues-state-handoffs/) dependem de o modelo não perder o fio da meada. - **Geração voltada ao cliente** onde uma saída ruim custa confiança, não apenas uma retentativa. - **Qualquer coisa em que a verificação seja em si difícil.** Se você não consegue dizer de forma barata se a saída está correta, não pode se dar ao luxo de um modelo que erra com frequência. Uma falha aqui não custa uma retentativa — custa um reembolso, um cliente perdido, ou o meu tempo. Diante disso, o adicional por token é erro de arredondamento. ## A regra de roteamento que de fato coloco em produção Eu não escolho um modelo por agente. Eu roteio por **tarefa** dentro do agente, geralmente com um classificador barato decidindo qual modelo a jusante cuida do trabalho: ```typescript function pickModel(task: Task): string { // Barato, verificável, alto volume → Haiku if (task.type === "classify" || task.type === "extract") { return "claude-haiku"; } // Aberto ou voltado ao cliente → Sonnet if (task.customerFacing || task.steps > 2) { return "claude-sonnet"; } return "claude-sonnet"; // por padrão, a escolha segura } ``` Dois princípios codificados aqui. **Por padrão, o modelo seguro**, não o barato — você otimiza o custo *para baixo* a partir de uma base que funciona, nunca a confiabilidade *para cima* a partir de uma quebrada. E **escale, não aposte**: deixe o Haiku cuidar dos 80% fáceis e entregue os 20% difíceis ao Sonnet. Esse híbrido quase sempre vence rodar tudo em qualquer um dos modelos sozinho. Há também o cache de prompt para colocar por cima: se o seu prompt de sistema é grande e reutilizado, o cache reduz substancialmente o custo de entrada independentemente do nível, o que às vezes torna o Sonnet barato o suficiente para que a questão do Haiku se torne irrelevante. ## Um exemplo trabalhado do meu próprio stack Pegue um passo de triagem de mensagens recebidas de alto volume. Ele roda milhares de vezes, a tarefa é uma classificação de três vias, e um erro só significa que o item cai numa fila de revisão — barato de detectar, baixo risco. Essa é uma tarefa de manual para o Haiku, e tirá-la do Sonnet reduziu significativamente o custo desse passo sem impacto mensurável no resultado que importava. Agora pegue o passo que redige a resposta de fato ao cliente. Volume menor, aberto, e um rascunho ruim saindo custa confiança. Esse fica no Sonnet. Mesmo agente, dois modelos, roteados por risco. Acompanho o custo por execução e as métricas de sucesso dos dois, do jeito que descrevo em [como meço se um agente de IA está realmente funcionando](/how-i-measure-whether-an-ai-agent-is-actually-working/) — e só rebaixo um passo de nível depois que a avaliação diz que o modelo mais barato mantém a taxa de sucesso. ## FAQ ### O Claude Haiku é sempre mais barato que o Sonnet na prática? Por token, sim — por larga margem. Por resultado bem-sucedido, nem sempre. Se a taxa de sucesso menor do Haiku dispara retentativas e limpeza humana, o custo total pode superar o do Sonnet em tarefas onde os erros são caros de detectar ou corrigir. ### Como decido entre Haiku e Sonnet para uma dada tarefa? Pontue a tarefa em dois eixos: quão verificável é a saída e quão custoso é um erro. Trabalho barato de verificar, de baixo risco e alto volume vai para o Haiku; trabalho aberto, voltado ao cliente ou difícil de verificar vai para o Sonnet. Roteie por tarefa, não por agente. ### Qual é a única métrica de custo que devo acompanhar? Custo por resultado bem-sucedido — custo da chamada vezes tentativas mais custo de limpeza esperado, dividido pela taxa de sucesso. O preço por chamada sozinho esconde retentativas e tempo humano, que é onde os modelos baratos ficam caros sem você perceber. ### Posso usar os dois modelos em um agente? Sim, e geralmente você deveria. O padrão mais forte é uma primeira passagem barata (Haiku classifica ou filtra) que escalona só os casos ambíguos para o Sonnet. Esse híbrido normalmente vence rodar tudo em um único nível. --- ## Como Depurar um Agente de IA em Produção (Um Guia de Campo) Source: https://alejandrorioja.com/pt/how-to-debug-an-ai-agent-in-production/ Published: 2026-06-08 Tags: AI Agents, Operations TL;DR: Depurar um agente de IA em produção é principalmente sobre isolar qual camada falhou — prompt, ferramenta, modelo ou orquestração. Registro cada passo com um ID de rastreamento, reproduzo as entradas exatas e biseco. Nos meus agentes, ~70% dos 'bugs de IA' acabam sendo bugs de encanamento, não do modelo. ## Índice _Atualizado junho de 2026._ **TL;DR:** Depurar um agente de IA em produção é principalmente sobre isolar qual camada falhou — prompt, chamada de ferramenta, saída do modelo ou orquestração. Registro cada passo com um ID de rastreamento, reproduzo as entradas exatas e biseco a partir daí. Nos meus agentes, cerca de 70% do que parece um "bug de IA" acaba sendo encanamento: um resultado de ferramenta malformado, uma entrada truncada, uma exceção silenciosamente engolida. **Leitura do operador:** Opero mais de 100 agentes em produção — fluxos de reserva para a Pickleland, pipelines de conteúdo, triadores de caixa de entrada. Eles quebram do jeito que todo software quebra, mais algumas formas novas. Este é o guia de campo que eu gostaria de ter tido: como encontrar a camada que falha sem ficar encarando uma parede de tokens. Quando um agente se comporta mal em produção, o instinto é culpar o modelo. "O Claude alucinou." Às vezes é verdade. Geralmente não. O modelo é uma camada em uma pilha de cinco ou seis, e o bug está muito mais frequentemente na camada que você escreveu do que na que a Anthropic entregou. Este post é a forma sistemática como eu o encontro. ## Torne cada execução rastreável antes de depurar qualquer coisa Você não pode depurar o que não pode ver. A coisa de maior alavancagem que você pode fazer — antes de qualquer bug específico aparecer — é anexar um ID de rastreamento a cada execução do agente e registrar cada passo que ele dá. Um "passo" é qualquer coisa que cruza uma fronteira: o gatilho de entrada, cada chamada ao modelo (com o array completo de mensagens), cada chamada de ferramenta (com argumentos), cada resultado de ferramenta e a saída final. Registre-os como JSON estruturado indexado pelo ID de rastreamento. ```typescript function logStep(traceId: string, step: string, payload: unknown) { console.log(JSON.stringify({ traceId, step, // "trigger" | "model_call" | "tool_call" | "tool_result" | "output" ts: Date.now(), payload, })); } ``` No Cloudflare Workers eu os envio para uma fila e para uma tabela; localmente vão para o stdout. A regra é absoluta: se um passo não está registrado, ele não aconteceu no que diz respeito à depuração. Isso espelha a instrumentação que descrevo na [stack de agentes que uso](/the-agent-stack-i-use-to-run-30-production-agents-no-python/) — o ID de rastreamento é a espinha dorsal da qual tudo o mais depende. ## Isole a camada: prompt, ferramenta, modelo ou orquestração Uma vez que você tem um rastreamento, a depuração vira uma bisseção. Há quatro camadas e o bug vive em exatamente uma delas na maior parte do tempo. ### 1. A camada de entrada (o culpado mais comum) Extraia o array `messages` exato que entrou na chamada ao modelo que falhou. Não uma reconstrução — o payload literal do log. Depois leia-o como um estranho leria. Metade dos meus bugs de "o modelo ignorou as instruções" são na verdade: - Um resultado de ferramenta que voltou como `"[object Object]"` porque algo foi convertido errado em string. - Uma entrada truncada no meio da frase porque estourou a janela de contexto e um corte ingênuo a cortou. - Uma variável que foi interpolada como `undefined` e envenenou silenciosamente o prompt. Se a entrada está errada, o modelo fez seu trabalho perfeitamente sobre lixo. Conserte o encanamento. ### 2. A camada de ferramentas Se a entrada parece limpa, verifique se uma ferramenta retornou um erro que o agente tratou como sucesso. Um clássico: uma API retorna `200` com um corpo de `{ "error": "rate limited" }`, seu wrapper de ferramenta não verifica o corpo, e o agente age com confiança sobre uma mensagem de erro. Registre os resultados de ferramenta crus e verifique sua forma. ### 3. A camada do modelo Só depois de descartar 1 e 2 é que suspeito do modelo. Mesmo então, "bug do modelo" geralmente significa "meu prompt é ambíguo." Pegue a entrada exata que falhou, jogue-a num script avulso contra o mesmo modelo e temperatura, e veja se reproduz. Se reproduzir, a correção é trabalho de prompt ou uma [eval mais rigorosa](/the-eval-harness-i-use-to-ship-ai-agents/), não uma troca frenética de modelo. ### 4. A camada de orquestração Se um único passo está bem isoladamente mas a execução de múltiplos passos falha, o bug está no repasse — estado perdido entre passos, uma condição de corrida, um retry que reexecutou uma ação não idempotente. Estes são os mais cruéis e eu cubro os padrões em [padrões de orquestração multiagente](/multi-agent-orchestration-patterns-queues-state-handoffs/). ## Reproduza o não-determinismo em vez de combatê-lo O que faz os agentes parecerem impossíveis de depurar é o não-determinismo: a mesma entrada produz saídas diferentes entre execuções. Você pode domá-lo. Primeiro, **fixe o que puder.** Defina `temperature: 0` durante a depuração. Não vai tornar o Claude totalmente determinístico, mas estreita bastante a variância para que você consiga distinguir um bug real do ruído de amostragem. Segundo, **execute N vezes.** Se uma falha reproduz 1 em cada 20 execuções, repita a entrada exata 50 vezes e capture cada saída. Agora você tem uma amostra, não um anedota. Um bug que dispara 5% das vezes é um bug real — você só precisa de volume para vê-lo. ```bash for i in $(seq 1 50); do node replay.mjs --trace=abc123 >> runs.jsonl done # então conte as falhas grep -c '"status":"fail"' runs.jsonl ``` Terceiro, **compare as execuções que passam e as que falham.** Com a temperatura fixada e a mesma entrada, uma diferença na saída significa uma diferença na entrada que você ainda não notou — um timestamp no prompt, um resultado de ferramenta que varia, um documento recuperado que mudou. ## Construa um harness de replay para parar de depurar em produção Depurar reacionando o agente ao vivo é lento e arriscado — ele envia e-mails reais, reserva quadras reais. Em vez disso, capture o rastreamento e reproduza-o offline. O harness de replay carrega um rastreamento registrado, reconstrói as entradas exatas de qualquer passo e reexecuta apenas aquele passo contra o modelo. Como você registrou o array completo `messages`, não precisa do sistema upstream de jeito nenhum. Isso transforma uma ida e volta de 10 minutos em produção num loop local de 2 segundos, e é a maior aceleração no meu fluxo de depuração. Um bom harness de replay também permite **mutar e reexecutar**: mude uma linha do prompt de sistema, reproduza os mesmos 50 rastreamentos que falharam e veja quantos passam agora. Essa é a ponte da depuração para a eval — uma vez que você tem um corpus de rastreamentos que falham, você tem o começo de uma suíte de regressão. ## Observe as métricas que realmente predizem quebras Algumas falhas nunca lançam uma exceção. O agente roda, retorna algo plausível e silenciosamente faz a coisa errada. Para pegar essas você observa métricas comportamentais, não apenas taxas de erro: - **Taxa de sucesso de chamadas de ferramenta** por ferramenta. Uma queda aqui frequentemente precede uma falha visível. - **Validade do schema de saída** — qual % das saídas faz parsing contra a estrutura esperada. Valido cada saída com Zod e alerto quando a validade cai. - **Comprimento do loop** — número médio de passos por execução. Um pico repentino geralmente significa que o agente está preso tentando novamente. - **Custo por execução** — um loop descontrolado aparece como um pico de custo antes de aparecer como uma reclamação. (Quando o custo importa, vale conhecer a [matemática de Haiku vs Sonnet](/ai-agent-cost-math-when-haiku-beats-sonnet).) Eu acompanho essas do mesmo jeito que acompanho tudo o mais — veja [como eu meço se um agente de IA está realmente funcionando](/how-i-measure-whether-an-ai-agent-is-actually-working/). A métrica que pega uma falha silenciosa vale dez que pegam as barulhentas. ## A checklist de triagem de 5 minutos Quando um agente quebra e estou contra o relógio, eu rodo isto em ordem: 1. **Obtenha o ID de rastreamento** da execução que falhou. 2. **Leia a entrada exata** do passo que falhou. Está bem formada? (Resolve ~50% dos casos aqui.) 3. **Verifique os resultados de ferramenta** naquele rastreamento por erros disfarçados de sucesso. 4. **Reproduza o passo offline** em `temperature: 0`. Reproduz? 5. **Se reproduz,** é um problema de prompt/modelo — conserte e reexecute o corpus de rastreamentos. **Se não,** é não-determinismo ou um bug de estado/orquestração — repita 50× para caracterizá-lo. Isolamento disciplinado vence prompting esperto toda vez. O modelo raramente é o problema; o sistema ao redor dele geralmente é. ## FAQ ### Como eu depuro um agente de IA que falha só às vezes? Capture a entrada exata de um rastreamento registrado e reproduza-a mais de 50 vezes em temperatura 0. Falhas intermitentes são bugs reais com baixas taxas de disparo — o volume transforma a anedota numa amostra reproduzível que você pode comparar e corrigir. ### O bug costuma estar no modelo ou no meu código? Nos meus agentes de produção, cerca de 70% dos aparentes "bugs de IA" são encanamento: resultados de ferramenta malformados, entradas truncadas, exceções engolidas ou estado perdido entre passos. Descarte as camadas de entrada e de ferramenta antes de suspeitar do modelo. ### Qual é o mínimo de logging que eu preciso para depurar agentes? Um ID de rastreamento em cada execução, mais logs estruturados do gatilho, cada chamada ao modelo (array completo de mensagens), cada chamada de ferramenta e seu resultado cru, e a saída final. Se um passo não está registrado, você não consegue depurá-lo. ### Como eu paro de depurar contra a produção ao vivo? Construa um harness de replay que carregue um rastreamento registrado e reexecute qualquer passo isolado offline usando as entradas capturadas. Ele transforma uma ida e volta lenta e arriscada em produção num loop local rápido e se torna a semente da sua suíte de regressão. --- ## Como Medir se a Busca com IA Está Realmente te Enviando Tráfego Source: https://alejandrorioja.com/pt/how-to-measure-ai-search-traffic/ Published: 2026-06-08 Tags: GEO, Analytics TL;DR: A maior parte do tráfego de busca com IA aparece como um filete de referências de chatgpt.com, perplexity.ai e claude.ai — mas o efeito maior é escuro: as pessoas leem a resposta da IA e nunca clicam. Eu meço os dois, usando os referenciadores para os cliques e o aumento das buscas por marca para a influência. ## Índice _Atualizado em junho de 2026._ **TL;DR:** A maior parte do tráfego de busca com IA chega como um fluxo fino de referências de `chatgpt.com`, `perplexity.ai` e `claude.ai` — fácil de contar uma vez que você sabe onde olhar. Mas o efeito maior é **escuro**: as pessoas leem a resposta da IA, absorvem sua marca e nunca clicam. Eu rastreio os cliques com segmentos de referenciador e a influência com o aumento das buscas por marca, as mudanças no tráfego direto e o monitoramento de citações. Contar apenas os cliques subestima gravemente a busca com IA. **Leitura do operador:** Eu opero um motor de conteúdo e acompanho suas análises diariamente. A pergunta "a busca com IA está enviando tráfego?" tem uma resposta frustrante: sim, mas a maior parte do valor não aparece no seu relatório de sessões. Eis como eu meço a parte que aparece e infiro a que não aparece. Todo mundo quer um único número: "quanto tráfego o ChatGPT está me enviando?". A resposta honesta é que a busca com IA produz dois efeitos muito diferentes, e você precisa de duas medições distintas. Confunda-os e ou você entrará em pânico (os cliques parecem minúsculos) ou se enganará (você perderá o impacto real). ## Efeito 1: Referências diretas — contáveis, e menores do que você gostaria Quando alguém clica numa citação dentro do ChatGPT, Perplexity ou numa resposta do Claude, sua análise registra um referenciador. São sessões reais e atribuíveis. No GA4 ou em qualquer ferramenta de análise, construa um segmento que capture os motores de IA: ``` session source matches any of: chatgpt.com chat.openai.com perplexity.ai claude.ai gemini.google.com copilot.microsoft.com ``` Salve isso como um canal de "Busca com IA" e observe-o ao longo do tempo. Algumas ressalvas que pegam as pessoas: - **Os referenciadores vazam.** Algumas superfícies de IA removem ou distorcem o referenciador, então uma parte dos cliques genuínos de IA acaba em "Direto". Sua contagem de referências é um piso, não a verdade. - **O volume é baixo em relação às impressões da resposta.** Os motores de IA respondem à pergunta na página; só a minoria curiosa clica. Um punhado de referências diárias pode corresponder a muito mais pessoas que viram você citado. Então o segmento de referências é necessário mas insuficiente. Ele diz que a busca com IA está enviando *algum* tráfego. Subestima gravemente a influência. ## Efeito 2: Influência escura — a metade maior e mais difícil de ver A verdadeira ação é de zero clique. Alguém faz uma pergunta ao ChatGPT, sua marca aparece na resposta como fonte recomendada, e ele nunca clica — apenas se lembra de você. Isso aparece mais tarde como uma **busca por marca** ou uma **visita direta**, atribuída a nada. É a mesma dinâmica que tornava os featured snippets frustrantes de medir, amplificada. Você não pode medir a influência escura diretamente, mas pode triangulá-la: 1. **Volume de buscas por marca.** Rastreie as buscas pelo seu nome/marca no Google Search Console ao longo do tempo. Se você começa a ser citado por motores de IA e suas impressões de marca sobem sem uma campanha correspondente, esse aumento é uma impressão digital da influência da IA. 2. **Tendência do tráfego direto.** Um aumento sustentado nas sessões "Direto" que não acompanha nenhuma campanha muitas vezes reflete referências de IA despojadas de seu referenciador, mais pessoas que digitam você após uma menção da IA. 3. **Conversões assistidas.** Veja se as sessões de busca com IA, mesmo quando raras, aparecem como o *primeiro* contato em jornadas que convertem. Um canal minúsculo no último clique pode ser significativo no primeiro toque. Nenhum desses é um número limpo. Juntos, eles dizem se a metade escura está se movendo. ## Rastreie citações, não apenas cliques Eis a métrica que mais me importa para a busca com IA, e ela não está na sua análise de jeito nenhum: **estou sendo citado, e para quais consultas?** Mantenha uma lista das 20-40 consultas que importam para o seu negócio e passe-as pelo ChatGPT, Perplexity e Claude de forma programada — semanalmente é mais que suficiente. Registre, para cada consulta e motor: você está citado, e em que posição? Este é o equivalente GEO do rastreamento de posições, e é o indicador antecipado. As citações se movem *antes* do tráfego subsequente e do aumento de marca, então é aqui que você vê se o seu [trabalho de GEO para negócios locais](/geo-for-local-business-getting-a-brick-and-mortar-cited-by-ai-search/) está dando resultado. Construí um pequeno agente que executa essas verificações e registra os resultados — o tipo de coisa que se torna trivial uma vez que você tem uma stack de agentes. Se você preferir fazer à mão, uma planilha e uma passada semanal de 30 minutos funciona bem para começar. A metodologia espelha o meu [teste de citações ChatGPT vs Google](/chatgpt-search-vs-google-50-term-test/), só que executado continuamente em vez de uma única vez. ## Construa o painel: quatro números, semanalmente Eu não me afogo em métricas. Para a busca com IA acompanho quatro coisas e as reviso semanalmente: 1. **Sessões de referência de IA** — os cliques contáveis do segmento de referenciador. Tendência, não valor absoluto. 2. **Cobertura de citações** — % das minhas consultas rastreadas onde sou citado nos três motores. O indicador antecipado. 3. **Impressões de busca por marca** — do Search Console, como proxy da influência escura. 4. **Conversões originadas pela IA** — mesmo que pequenas, se as sessões de IA chegam a iniciar uma jornada que converte. Se a cobertura de citações está subindo enquanto as sessões de referência permanecem estáveis, isso *não* é um fracasso — geralmente significa que a metade escura está crescendo e o número de buscas por marca deve seguir. Se a cobertura de citações está caindo, isso é um aviso antecipado para agir antes que qualquer número de tráfego se mova. É a mesma disciplina de "medir o indicador antecipado" que aplico aos agentes em [como eu meço se um agente de IA está realmente funcionando](/how-i-measure-whether-an-ai-agent-is-actually-working/). ## O que fazer com os números A medição só é útil se mudar o que você faz. O manual de jogadas: - **Cobertura de citações baixa para uma consulta que te importa?** Isso é um problema de conteúdo + [schema](/schema-markup-for-ai-engines-the-types-that-punch-above-their-weight/). A página ou não existe, ou não está estruturada para extração, ou não é autoritativa o suficiente para ser puxada para a resposta. - **Citado mas sem tráfego de referência?** Esperado e tudo bem — a busca com IA está fazendo trabalho de marca, não de clique. Não "conserte" isso perseguindo cliques; aposte em ser a fonte citada. - **Referências de um motor mas não de outros?** Os motores divergem bastante nas fontes (medi ~40% de sobreposição entre ChatGPT e Google). Ser citado por um não te garante os outros — trabalhe a cobertura de cada motor separadamente. ## Uma nota sobre honestidade na atribuição Resista à vontade de reivindicar uma precisão que você não tem. A medição da busca com IA em 2026 é triangulação, não atribuição. Quem te vender um número limpo do tipo "o ChatGPT te trouxe X dólares" está exagerando o que é conhecível, porque os referenciadores vazam e o maior efeito é de zero clique por design. A postura certa: conte o que você pode contar, observe os proxies para o que não pode, e tome decisões pela tendência. A tendência é confiável mesmo quando o número absoluto não é. ## Perguntas frequentes ### Como vejo o tráfego do ChatGPT ou Perplexity no GA4? Construa um canal/segmento correspondente aos domínios dos motores de IA — chatgpt.com, chat.openai.com, perplexity.ai, claude.ai, gemini.google.com, copilot.microsoft.com — como origem da sessão. Isso captura as referências de clique, embora algumas sejam reduzidas a "Direto", então trate a contagem como um piso. ### Por que o meu tráfego de referência de busca com IA é tão baixo? Porque a busca com IA é majoritariamente de zero clique — o motor responde na página e só uma minoria clica. Contagens baixas de referência muitas vezes coincidem com impressões de citação muito maiores. Meça as citações e o aumento das buscas por marca para ver a parte que as referências perdem. ### Qual é o melhor indicador antecipado para a busca com IA? A cobertura de citações: a porcentagem das suas consultas críticas para o negócio, rastreadas, onde você é citado no ChatGPT, Perplexity e Claude. Ela se move antes do tráfego e do aumento de marca, então te diz cedo se o seu trabalho de GEO está dando resultado. ### Posso obter atribuição exata de receita da busca com IA? Não, não de forma confiável em 2026. Os referenciadores vazam para Direto e a maior parte do impacto é de zero clique por design. Trate a medição da busca com IA como triangulação — conte os cliques, observe os proxies de busca por marca e tráfego direto, e decida pela tendência, não por uma cifra em dólares de falsa precisão. --- ## Padrões de Orquestração Multiagente: Filas, Estado e Handoffs Source: https://alejandrorioja.com/pt/multi-agent-orchestration-patterns-queues-state-handoffs/ Published: 2026-06-08 Tags: AI Agents, Operations TL;DR: Sistemas multiagente confiáveis não dependem de prompts engenhosos — dependem da chata disciplina de sistemas distribuídos: filas duráveis entre agentes, estado mantido fora do modelo e handoffs idempotentes que sobrevivem às retentativas. O modelo é o trabalhador; a fila é a espinha dorsal. ## Índice _Atualizado junho de 2026._ **TL;DR:** Sistemas multiagente confiáveis não se ganham com prompts engenhosos — ganham-se com a chata disciplina de sistemas distribuídos. Coloque uma **fila** durável entre os agentes, mantenha o **estado fora do modelo** e torne cada **handoff idempotente** para que uma retentativa não possa agir duas vezes. O modelo é o trabalhador; a fila é a espinha dorsal. Acerte nesses três pontos e a orquestração deixa de ser assustadora. **Leitura do operador:** A maioria dos meus mais de 100 agentes é de etapa única. Os que não são — os pipelines que classificam, depois enriquecem, depois agem — só se tornaram confiáveis quando parei de pensar em "cadeia de prompts" e comecei a pensar em "fila de jobs com trabalhadores LLM". Isto é arquitetura, não engenharia de prompts. "Multiagente" soa como se os agentes conversassem entre si. Na prática, a versão confiável é o oposto: os agentes não se comunicam diretamente de jeito nenhum. Eles deixam mensagens numa fila e pegam trabalho de uma fila, e a orquestração vive no encanamento entre eles. Aqui estão os padrões que se sustentam em produção. ## Padrão 1: Coloque uma fila durável entre cada agente O primeiro instinto é chamar o agente B diretamente de dentro do agente A. Não faça isso. Chamadas diretas acoplam os dois: se B é lento, A bloqueia; se B falha, o trabalho de A é perdido; se você precisa escalar B, não consegue sem mexer em A. Em vez disso, A termina seu trabalho e **enfileira uma mensagem** para B. B é um trabalhador separado que esvazia a fila no próprio ritmo. ```typescript // O agente A termina e faz o handoff via fila — sem chamada direta a B await env.ENRICH_QUEUE.send({ traceId, type: "enrich", payload: classifierResult, }); // O trabalho de A está concluído. B vai pegá-lo de forma independente. ``` No Cloudflare uso Workers Queues exatamente para isso — as mesmas primitivas por trás [da stack de agentes que eu uso](/the-agent-stack-i-use-to-run-30-production-agents-no-python/). A fila te dá quatro coisas de graça: **buffering** (B pode estar fora do ar sem perder trabalho), **retentativas** (mensagens com falha são reentregues), **contrapressão** (um pico se enfileira em vez de derrubar) e **desacoplamento** (escale ou reimplante B sem mexer em A). Cada uma dessas é algo que, de outra forma, você teria que construir na mão e errar. ## Padrão 2: Mantenha o estado fora do modelo, sempre O bug multiagente mais comum é supor que o modelo lembra de qualquer coisa entre as etapas. Ele não lembra. Cada chamada ao modelo é stateless; a única memória é o que você coloca no prompt. Então a fonte da verdade para "onde está este job no pipeline" precisa viver num banco de dados, não numa conversa. Mantenho um único registro de job que cada agente lê e atualiza: ```typescript interface JobState { traceId: string; stage: "classified" | "enriched" | "acted" | "done" | "failed"; data: Record; attempts: number; updatedAt: number; } ``` Cada agente faz o mesmo loop: **ler** o estado do job, fazer seu trabalho, **escrever** o novo estado, enfileirar a próxima etapa. O modelo nunca mantém o estado — ele recebe a fatia relevante como entrada e devolve um resultado. É isso que torna o sistema reiniciável: se um trabalhador morre no meio de um job, o registro de estado ainda diz exatamente onde as coisas estavam, e a mensagem de fila reentregue retoma a partir dali. Também torna a depuração tratável, porque a tabela de estado é um registro consultável da jornada de cada job — a mesma mentalidade de instrumentação de [como meço se um agente está funcionando](/how-i-measure-whether-an-ai-agent-is-actually-working/). ## Padrão 3: Torne cada handoff idempotente Filas garantem entrega *pelo menos uma vez*, não exatamente uma vez. Isso significa que uma mensagem pode ser entregue duas vezes — quedas de rede, retentativas, reimplantações. Se a ação do seu agente não é idempotente, uma entrega dupla age duas vezes: dois e-mails de confirmação, duas reservas, duas cobranças. Essa é a classe mais traiçoeira de bug de orquestração, e é a que as equipes descobrem em produção. A correção é tornar as ações idempotentes com uma chave: ```typescript async function handleEnrich(msg: QueueMessage, env: Env) { const job = await getJob(env, msg.traceId); if (job.stage !== "classified") { // Já processado além desta etapa — é uma entrega duplicada. Pular. return; } const result = await enrich(job.data); await advanceJob(env, msg.traceId, "enriched", result); await env.ACT_QUEUE.send({ traceId: msg.traceId, type: "act" }); } ``` A verificação de etapa torna a operação segura para executar duas vezes: a segunda entrega vê que o job já avançou e não faz nada. Para efeitos colaterais externos (enviar um e-mail, cobrar um cartão), passe uma chave de idempotência para a API a jusante para que *ela* também deduplique. Suponha que cada mensagem será entregue duas vezes e projete de modo que isso seja inofensivo — porque, mais cedo ou mais tarde, vai acontecer. ## Padrão 4: Orquestrador vs coreografia — escolha deliberadamente Há duas maneiras de conectar o fluxo, e a escolha certa depende da complexidade. **Coreografia** (o que uso por padrão): cada agente conhece apenas a próxima etapa e a enfileira. O fluxo emerge da cadeia. Simples, descentralizada, fácil de estender — adicione uma etapa inserindo uma fila. A desvantagem é que nenhum lugar único descreve o fluxo inteiro, então um pipeline complexo pode ficar difícil de raciocinar. **Orquestração** (um coordenador central): um orquestrador é dono do fluxo, chama cada agente por vez e decide o que vem em seguida com base nos resultados. O fluxo inteiro vive em um único lugar legível e a lógica de ramificação é explícita. O custo é um componente central que precisa ser, ele próprio, durável — se o estado próprio do orquestrador não for externalizado (Padrão 2), ele se torna o ponto único de falha. Minha regra: **coreografia até a ramificação ficar complexa, depois um orquestrador durável.** Um pipeline linear de três etapas é coreografia. Um fluxo com roteamento condicional, fan-out paralelo e joins quer um orquestrador cujo estado vive no banco de dados para que possa retomar após uma queda. ## Padrão 5: Fan-out, fan-in sem perder pedaços Quando um job gera N subtarefas paralelas (enriquecer 50 registros, resumir 20 documentos) e você precisa esperar por todas antes de continuar, você precisa de um **join**. O truque é um contador no estado do job: 1. O pai enfileira N mensagens filhas e escreve `expected: N, completed: 0` no registro do job. 2. Cada filho faz seu trabalho e **incrementa atomicamente** `completed`. 3. O filho que leva `completed` a igualar `expected` enfileira a próxima etapa. O incremento atômico é essencial — sem ele, dois filhos terminando simultaneamente podem ambos achar que não são o último, e o join nunca dispara. Use um contador que o datastore possa incrementar atomicamente, ou uma transação. Esse padrão permite paralelizar o caro miolo de um pipeline (muitas vezes trabalho barato para Haiku — veja a [matemática de custo Haiku vs Sonnet](/ai-agent-cost-math-when-haiku-beats-sonnet)) mantendo um join limpo no final. ## O que eu pularia Você não precisa de um framework de agentes pesado para fazer nada disso. Filas, uma tabela de estado e chaves de idempotência são primitivas que toda plataforma já tem. Já vi equipes recorrerem a elaborados frameworks multiagente para obter recursos que uma fila dá de graça, e herdarem uma caixa-preta mais difícil de depurar do que o encanamento que substituiu. Comece com as chatas primitivas. Recorra a um framework só quando tiver sentido uma dor específica que ele resolve. O resumo: agentes são trabalhadores stateless, filas são a espinha dorsal durável, o estado vive num banco de dados e cada handoff é seguro para executar duas vezes. Esse é o jogo todo. ## Perguntas frequentes ### Os agentes devem chamar uns aos outros diretamente ou passar por uma fila? Por uma fila. Chamadas diretas acoplam os agentes — a falha ou lentidão de um se propaga para o outro, e você não consegue escalar nem reimplantar de forma independente. Uma fila durável te dá buffering, retentativas, contrapressão e desacoplamento de graça. ### Onde o estado multiagente deve viver? Fora do modelo, num banco de dados, como um registro de job que cada agente lê e atualiza. Chamadas ao modelo são stateless, então a fonte da verdade para o progresso do pipeline precisa ser externa — é isso que torna o sistema reiniciável após uma queda. ### Como impeço um agente de agir duas vezes no mesmo job? Torne os handoffs idempotentes. Verifique a etapa do job antes de agir e não faça nada se ele já avançou, e passe chaves de idempotência para as APIs externas. Filas entregam pelo menos uma vez, então suponha que cada mensagem pode chegar duas vezes e projete de modo que duplicatas sejam inofensivas. ### Preciso de um framework multiagente? Geralmente não. Filas duráveis, uma tabela de estado e chaves de idempotência cobrem a maioria das necessidades de produção com primitivas que sua plataforma já fornece. Adote um framework só quando esbarrar num problema concreto que ele resolve de forma única, não por padrão. --- ## O Harness de Avaliação que Uso para Lançar Agentes de IA Sem Medo Source: https://alejandrorioja.com/pt/the-eval-harness-i-use-to-ship-ai-agents/ Published: 2026-06-08 Tags: AI Agents, Operations TL;DR: Lançar agentes sem medo vem de uma única coisa: um harness de avaliação. Um conjunto fixo de casos de teste avaliados, pontuados automaticamente (asserções mais um juiz LLM), executado antes de cada mudança de prompt ou modelo. Se a pontuação se mantém, você lança. O conjunto de testes é construído a partir de falhas reais de produção. ## Índice _Atualizado em junho de 2026._ **TL;DR:** A razão pela qual consigo mudar um prompt ou trocar um modelo em um agente ao vivo sem prender a respiração é uma única coisa: um **harness de avaliação**. Um conjunto fixo de casos de teste avaliados, pontuados automaticamente — asserções rígidas onde consigo escrevê-las, um juiz LLM onde não consigo — executado antes de cada mudança. A pontuação se mantém, eu lanço. A pontuação cai, eu não lanço. O conjunto de testes não é sintético; é construído a partir de falhas reais de produção, então cada bug vira um teste de regressão permanente. **Leitura do operador:** Ao longo de mais de 100 agentes, a diferença entre os que toco com confiança e os que me dão medo é se eles têm avaliações. Sem harness de avaliação, cada ajuste de prompt é uma aposta. Um harness de avaliação transforma "acho que isto está melhor" em "isto está mensuravelmente 4 pontos melhor e não quebrou nada". É todo o destravamento. Você não lançaria código sem testes. As pessoas lançam agentes sem avaliações o tempo todo e depois se perguntam por que um "minúsculo ajuste de prompt" quebrou a produção. Um harness de avaliação é a suíte de testes para software não determinístico. Aqui está o que eu realmente executo. ## Comece com um conjunto de testes construído a partir de falhas reais O harness só é tão bom quanto seus casos de teste, e os melhores casos de teste vêm da produção, não da sua imaginação. Toda vez que um agente falha no mundo real, capturo a entrada exata (registro cada execução com um trace ID — veja [como depurar um agente em produção](/how-to-debug-an-ai-agent-in-production)) e a transformo em um caso de avaliação: ```typescript interface EvalCase { id: string; input: AgentInput; // a entrada exata de produção expected?: string; // verdade de referência, quando há uma assertions: Assertion[]; // checagens rígidas que devem passar rubric?: string; // para o juiz LLM, quando a saída é aberta } ``` Duas práticas importam aqui. **Puxe da produção**, para que suas avaliações testem o que realmente quebra, não o que você imaginou que poderia. E **cubra o leque** — o caminho feliz, os casos extremos, as entradas adversariais e as entradas vazias/malformadas que causam falhas silenciosas. Um conjunto de testes de 30 a 50 casos bem escolhidos pega muito mais do que 500 preguiçosos. Prefiro ter 40 casos que representem cada um um modo de falha real do que mil que testem todos o mesmo caminho fácil. ## Pontue primeiro com asserções, depois com um juiz LLM Nem toda saída precisa de um modelo para avaliá-la. Recorro ao avaliador mais barato que funcione. **Asserções rígidas** para tudo o que é estruturado. A saída faz parse como JSON válido? Contém o campo obrigatório? A data extraída está dentro do intervalo? Chamou a ferramenta certa com os argumentos certos? Essas são determinísticas, gratuitas e inequívocas — escreva quantas conseguir. ```typescript const assertions: Assertion[] = [ (out) => isValidJSON(out), (out) => parse(out).category in ALLOWED_CATEGORIES, (out) => parse(out).confidence >= 0 && parse(out).confidence <= 1, ]; ``` **Um juiz LLM** para o resto aberto — tom, utilidade, "isto realmente respondeu à pergunta". Aqui você dá a um modelo a entrada, a saída e uma rubrica, e pede que ele pontue. Duas regras mantêm o juiz honesto: torne a rubrica **específica** (uma escala de 1 a 5 com âncoras descritas vence "avalie a qualidade"), e use um **modelo forte como juiz** — julgar é uma tarefa de raciocínio, então este é um lugar onde pago com prazer pelo Sonnet mesmo quando o próprio agente roda no Haiku conforme a [matemática de custos](/ai-agent-cost-math-when-haiku-beats-sonnet). Uma rubrica vaga ou um juiz fraco te dá ruído que parece sinal. ## Execute o harness antes de cada mudança O harness existe para responder a uma pergunta: *esta mudança tornou o agente melhor ou pior?* Então o executo antes de cada edição de prompt, troca de modelo ou mudança de ferramenta. ```bash # baseline na main npm run eval -- --suite=booking-agent > baseline.json # faça a mudança, depois reexecute npm run eval -- --suite=booking-agent > candidate.json # compare npm run eval:diff baseline.json candidate.json ``` O diff mostra a pontuação agregada, o passa/falha por caso e — crucialmente — **quais casos específicos regrediram.** Um agregado que sobe enquanto três casos quebram silenciosamente não é uma melhoria; é uma troca que quero ver e aprovar, não uma que passa despercebida. Vigiar o diff por caso é como você evita "consertei uma coisa, quebrei outras duas", o modo de falha que faz as pessoas terem medo dos próprios prompts. ## Defina um portão de regressão e deixe-o bloquear Assim que você confia no harness, ligue-o ao caminho para a produção como um portão. Minha regra é direta: **uma mudança que derruba a pontuação abaixo do limiar da baseline não é lançada.** Não "vou ver isso depois" — está bloqueada, igual a um teste de CI que falha. ```typescript const PASS_THRESHOLD = 0.90; // 90% dos casos devem passar if (candidate.passRate < PASS_THRESHOLD || candidate.passRate < baseline.passRate) { throw new Error(`Eval regression: ${candidate.passRate} < ${baseline.passRate}`); } ``` É isso que converte as avaliações de um luxo opcional naquilo que permite você se mover rápido. O portão é o que torna "lançar sem medo" literalmente verdadeiro: o pior cenário para uma mudança ruim é uma execução de avaliação em vermelho, não um incidente de produção. E como o conjunto de testes cresce toda vez que algo quebra, o portão fica mais rígido e mais protetor ao longo do tempo, por conta própria. ## Considere o não determinismo na pontuação Uma sutileza que faz as pessoas tropeçarem: a mesma entrada pode pontuar de forma diferente entre execuções porque o modelo amostra de modo distinto. Se você executa cada caso uma única vez, verá regressões fantasma — um caso que "quebrou" e que na verdade é só ruído de amostragem. Duas mitigações. Execute as avaliações a **`temperature: 0`** para reduzir a variância (não a eliminará por completo). E para os casos que você viu oscilar, **execute-os N vezes e pegue a taxa de aprovação**, não um único passa/falha. Um caso que passa 9 de 10 está em melhor forma do que um que passa 5 de 10, mesmo que ambos possam mostrar uma única execução verde. É o mesmo princípio de volume-sobre-anedota que uso ao [depurar falhas intermitentes](/how-to-debug-an-ai-agent-in-production) — uma execução é uma opinião, cinquenta execuções são dados. ## Feche o ciclo com monitoramento de produção O harness de avaliação testa contra casos conhecidos. A produção lança casos inéditos. Então o ciclo é: monitore o comportamento ao vivo, capture um novo modo de falha, transforme-o em um caso de avaliação, conserte-o, e agora ele está permanentemente protegido. O lado do monitoramento — rastrear a taxa de sucesso, a validade da saída e o custo por execução no tráfego ao vivo — é o que abordo em [como meço se um agente de IA está realmente funcionando](/how-i-measure-whether-an-ai-agent-is-actually-working/). Avaliações e monitoramento são duas metades do mesmo sistema: o monitoramento encontra os bugs, as avaliações garantem que eles permaneçam mortos. Esse ciclo de feedback é o verdadeiro produto. Qualquer conjunto de avaliação isolado fica obsoleto; um *processo* que converte cada falha de produção em um teste permanente fica mais forte a cada semana. É assim que um agente passa de "assustador de tocar" para algo que vou refatorar numa tarde de sexta-feira sem pestanejar. ## Perguntas frequentes ### O que entra em um conjunto de avaliação para um agente de IA? Entradas reais de produção transformadas em casos avaliados — caminho feliz, casos extremos, entradas adversariais e malformadas — cada um com asserções rígidas e, para saídas abertas, uma rubrica de juiz LLM. De 30 a 50 casos extraídos de falhas reais vencem centenas de sintéticos que testam todos o caminho fácil. ### Devo usar um LLM para avaliar as saídas do agente? Use asserções rígidas sempre que a saída for estruturada (JSON válido, campo correto, chamada de ferramenta certa) — são gratuitas e determinísticas. Reserve um juiz LLM para qualidades abertas como tom e utilidade, com uma rubrica específica e um modelo juiz forte para obter sinal, não ruído. ### Como impeço uma mudança de prompt de quebrar a produção silenciosamente? Execute o harness de avaliação antes de cada mudança e faça o diff contra uma baseline, observando as regressões por caso, não apenas a pontuação agregada. Depois condicione os deploys ao resultado para que qualquer mudança que caia abaixo do limiar da baseline seja bloqueada como um teste que falha. ### Como lido com o não determinismo nas avaliações? Execute a temperatura 0 para reduzir a variância e, para os casos que oscilam, execute-os várias vezes e pontue a taxa de aprovação em vez de uma única execução. Um caso que passa 9 de 10 vezes é mais saudável do que um que passa 5 de 10, mesmo que uma única execução mostre ambos verdes. --- ## Como Automatizar sua Newsletter com um Agente de IA Source: https://alejandrorioja.com/pt/how-to-automate-your-newsletter-with-an-ai-agent/ Published: 2026-06-06 Updated: 2026-06-06 Tags: AI Agents, Growth TL;DR: Um agente Claude lê minha fila de conteúdo, escolhe o ângulo mais forte da semana, rascunha uma newsletter na minha voz, segmenta a lista por nível de engajamento e agenda o envio via API do Kit — tudo sem que eu abra um editor. Reviso uma prévia renderizada e clico em aprovar. O trabalho criativo difícil é meu; a execução mecânica é do agente. ## Índice _Atualizado junho de 2026._ **TL;DR:** Um agente Claude lê minha fila de conteúdo, escolhe o ângulo mais forte da semana, rascunha uma newsletter na minha voz, segmenta a lista por nível de engajamento e agenda o envio via API do Kit — tudo sem que eu abra um editor. Reviso uma prévia renderizada e clico em aprovar. O trabalho criativo difícil é meu; a execução mecânica é do agente. **[Leitura do operador]** Uma newsletter que envia consistentemente supera uma que é "melhor" mas que vai quando a inspiração aparece. A restrição era a sobrecarga de execução, não as ideias. Eu tinha ideias; não tinha largura de banda para formatá-las, agendá-las e segmentá-las toda semana. O agente eliminou essa lacuna. ## O verdadeiro gargalo na maioria dos workflows de newsletter A maioria dos conselhos de automação de newsletter foca na coisa errada: sequências de boas-vindas, automações, lógica de tags. Isso é bom, mas não resolve o problema de criação semana a semana. O verdadeiro obstáculo é este: você sabe o que quer dizer, mas sentar para formatá-lo, escrever as variantes da linha de assunto, escolher o segmento certo e agendá-lo no momento certo custa 2-3 horas de troca de contexto por semana. Multiplique por 52 semanas e você terá passado uma semana inteira de trabalho apenas *enviando* newsletters. O agente lida com cada etapa após "eu sei qual é o ângulo desta semana." ## O stack que estou usando - **[Kit](/recommends/convertkit)** (anteriormente ConvertKit) — a plataforma de email. Excelente API, sólida marcação de assinantes, análises limpas. A API compatível com agentes foi o que me convenceu. - **Claude (Anthropic SDK)** — a camada de geração - **Cloudflare Workers** — gatilho agendado (executa toda terça-feira às 8h CT) - **Airtable** — fila de conteúdo e caixa de entrada de aprovação Se você não está no Kit, o mesmo padrão funciona com qualquer plataforma que tenha uma API REST para criar e agendar transmissões. ## Passo 1: A fila de conteúdo O agente precisa de uma fonte de verdade sobre "sobre o que estamos escrevendo." A minha é uma tabela [Airtable](/recommends/airtable) com colunas: - `Topic` — o ângulo ou a pergunta - `Status` — Queue / Approved / Sent - `Tier` — se isso é para todos os assinantes ou apenas para os mais engajados - `Notes` — quaisquer restrições (evitar este tom, incluir este link, etc.) Cada semana, passo 10 minutos adicionando 2-3 tópicos à fila. Essa é minha contribuição criativa. O resto é trabalho do agente. ## Passo 2: O agente de rascunho ```typescript // workers/newsletter-agent/index.ts import Anthropic from "@anthropic-ai/sdk"; import Airtable from "airtable"; const client = new Anthropic(); const VOICE_SYSTEM = `You are writing a weekly newsletter for Alejandro Rioja's subscribers. His audience: founders and operators interested in AI agents, SEO, and growing a one-person business. Voice: direct, first-person, practitioner. No hype, no "exciting times," no excessive bullet lists. Structure every newsletter as: 1. One-sentence hook (the problem or observation) 2. The core insight (3–5 paragraphs, no headers, conversational) 3. One concrete action the reader can take this week 4. A short sign-off (2 sentences max) Subject line: specific, outcome-oriented, under 50 chars. No clickbait. Return JSON: { "subject": "...", "preheader": "...", "body": "..." }`; async function getNextTopic(): Promise<{ id: string; topic: string; notes: string; tier: string }> { const base = new Airtable({ apiKey: process.env.AIRTABLE_API_KEY }).base(process.env.AIRTABLE_BASE_ID!); const records = await base("Newsletter Queue") .select({ filterByFormula: "{Status} = 'Queue'", sort: [{ field: "Created", direction: "asc" }], maxRecords: 1 }) .firstPage(); if (!records.length) throw new Error("Queue is empty. Add topics."); const r = records[0]; return { id: r.id, topic: r.get("Topic") as string, notes: (r.get("Notes") as string) ?? "", tier: (r.get("Tier") as string) ?? "all" }; } async function draftNewsletter(topic: string, notes: string): Promise<{ subject: string; preheader: string; body: string }> { const msg = await client.messages.create({ model: "claude-sonnet-4-6", max_tokens: 2048, system: VOICE_SYSTEM, messages: [{ role: "user", content: `Write this week's newsletter on: "${topic}". Additional notes: ${notes || "none"}` }], }); const text = (msg.content[0] as any).text.replace(/```json\n?/, "").replace(/```/, "").trim(); return JSON.parse(text); } async function scheduleWithKit(draft: { subject: string; preheader: string; body: string }, tier: string): Promise { const segmentId = tier === "engaged" ? process.env.KIT_ENGAGED_SEGMENT_ID : null; const sendAt = new Date(); sendAt.setDate(sendAt.getDate() + ((4 - sendAt.getDay() + 7) % 7)); // next Thursday sendAt.setHours(9, 0, 0, 0); // 9am CT const payload: any = { broadcast: { subject: draft.subject, content: draft.body, description: draft.preheader, send_at: sendAt.toISOString(), email_layout_template: "minimal", }, }; if (segmentId) payload.broadcast.segment_id = segmentId; const res = await fetch("https://api.kit.com/v4/broadcasts", { method: "POST", headers: { "Content-Type": "application/json", "X-Kit-Api-Key": process.env.KIT_API_KEY! }, body: JSON.stringify(payload), }); const data = await res.json(); return data.broadcast?.id ?? ""; } export default { async scheduled(_event: ScheduledEvent, env: Env) { // Inject env vars Object.assign(process.env, env); const { id, topic, notes, tier } = await getNextTopic(); const draft = await draftNewsletter(topic, notes); const broadcastId = await scheduleWithKit(draft, tier); // Mark as Approved in Airtable (not Sent — human reviews the Kit preview before confirm) const base = new Airtable({ apiKey: env.AIRTABLE_API_KEY }).base(env.AIRTABLE_BASE_ID); await base("Newsletter Queue").update(id, { Status: "Approved", KitBroadcastId: broadcastId }); console.log(`Scheduled broadcast ${broadcastId} for topic: ${topic}`); }, }; ``` ## Passo 3: A etapa de aprovação O agente cria a transmissão no estado de rascunho do Kit e marca o registro do Airtable como "Approved." O Kit me envia uma notificação com um link de prévia. Clico nele, leio, e se parecer certo, confirmo o envio. Se quiser mudanças, edito diretamente no Kit. Este é o portão que impede o agente de se tornar totalmente autônomo no email de saída. Confio nos rascunhos aproximadamente 90% das vezes. Os 10% que detecto na revisão — um tom ligeiramente errado, uma estatística que quero verificar, um link que quero adicionar — valem os 3 minutos de revisão. ## O que o agente lida e que nunca mais quero fazer - Escrever variantes de linha de assunto e escolher a melhor - Formatar o texto do pré-cabeçalho - Calcular o tempo de envio certo (meu público abre quinta-feira de manhã; o agente sabe disso) - Segmentar corretamente com base no nível do tópico - Registrar tudo no Airtable para ter um histórico ## O que ainda é meu A *ideia*. O tópico na fila é meu. O ângulo é meu. O agente é um ótimo executor de um briefing claro; não é uma camada estratégica. Se eu colocar um tópico ruim na fila, obtenho uma newsletter bem escrita sobre um tópico ruim. Também: o portão de primeira revisão. Cada envio passa pelos meus olhos antes de sair. Isso não vai mudar. ## A conclusão do operador Se você está gastando mais de uma hora por semana em mecânicas de newsletter — formatação, agendamento, segmentação — você deveria automatizar. A API do Kit é limpa, o gatilho cron do Worker é sólido como rocha, e a qualidade do rascunho do Claude é alta o suficiente para que eu aprove ~90% dos primeiros rascunhos sem alterações. Construa a fila no Airtable, conecte o Worker e volte a criar ideias em vez de executar envios. --- ## Como Posicionar-se na Pesquisa de IA sem Escrever uma Única Publicação Nova Source: https://alejandrorioja.com/pt/how-to-rank-in-ai-search-without-writing-a-single-new-blog-post/ Published: 2026-06-06 Updated: 2026-06-06 Tags: GEO, SEO TL;DR: Os motores de IA citam conteúdo que responde perguntas diretamente, reivindica autoria clara e estrutura o conhecimento de uma forma que facilita a recuperação. A maioria das publicações de blog existentes pode ser adaptada para cumprir os três critérios com edições, não reescritas. O plano: adicionar um TL;DR direto, reforçar sinais de entidade, adicionar esquema FAQ e submeter ao llms.txt. O novo conteúdo é opcional; a reestruturação não é. ## Índice _Atualizado junho 2026._ **TL;DR:** Os motores de IA citam conteúdo que responde perguntas diretamente, reivindica autoria clara e estrutura o conhecimento de uma forma que facilita a recuperação. A maioria das publicações de blog existentes pode ser adaptada para cumprir os três critérios com edições, não reescritas. O plano: adicionar um TL;DR direto, reforçar sinais de entidade, adicionar esquema FAQ e submeter ao llms.txt. O novo conteúdo é opcional; a reestruturação não é. **[Leitura do operador]** Executei este processo em 341 publicações existentes antes de escrever um único artigo novo orientado para GEO. As citações no ChatGPT e Perplexity aumentaram. O novo conteúdo acelerou os ganhos — mas a auditoria de conteúdo existente foi onde comecei, e compensou mais rápido do que esperava. ## Por que os motores de IA não citam o teu conteúdo existente Antes de escrever qualquer coisa nova, pergunta: por que o que já tenho não está a ser citado? A resposta quase nunca é "o conteúdo não existe." Geralmente é uma destas: 1. **Sem resposta direta no topo** — a publicação enterra a resposta no parágrafo 6 2. **Sinais de autoria fracos** — sem entidade de autor clara, sem credenciais no conteúdo 3. **Ruído estrutural** — introduções longas, secções irrelevantes, sem hierarquia de cabeçalhos clara 4. **Sem Q&A legível por máquinas** — os motores de IA preferem pares de pergunta-resposta estruturados; a maioria das publicações de blog não os tem 5. **Não está em nenhum índice legível por IA** — sem llms.txt, sem sitemaps que os rastreadores encontrem Os cinco são corrigíveis em conteúdo existente. Nenhum requer uma nova publicação. ## O processo de retrofit em quatro passos ### Passo 1: Adicionar um TL;DR direto nas primeiras 100 palavras Os motores de IA fazem algo análogo ao que fazes quando estás a ler por alto — procuram a resposta direta antes de ir mais fundo. Se a tua publicação começa com uma história, uma pergunta ou estabelecimento de contexto, o modelo pode nunca ler o suficiente para encontrar a tua resposta real. Solução: Adiciona um bloco **TL;DR** nas primeiras 100 palavras. Formato: conclusão → porquê → restrição ou ressalva. De duas a quatro frases. Sem preenchimento. Exemplo antes: > *Alguma vez te perguntaste por que alguns negócios parecem dominar os resultados de pesquisa do Google? Nesta publicação, exploraremos as estratégias que os sites melhor posicionados usam...* Exemplo depois: > **TL;DR:** Três coisas movem a agulha para o SEO local em 2026: completude do Perfil de Empresa do Google, consistência de citações nos diretórios e esquema estruturado para os teus dados NAP. Táticas como "publicar todos os dias" e "conseguir 100 avaliações rápido" são secundárias em relação a essas três. O teto é a precisão do teu GBP — corrige isso primeiro. A reescrita não é mais longa. Está apenas carregada para a frente. ### Passo 2: Reforçar os teus sinais de entidade Os motores de IA constroem um grafo de conhecimento. Querem saber: quem escreveu isto, sobre o que é e o autor é credível neste tópico? Para a entidade de autor: certifica-te de que a tua página Sobre está ligada de cada publicação, o teu esquema de autor inclui links `sameAs` para LinkedIn e Twitter, e a tua bio de autor em cada publicação menciona credenciais específicas (não "profissional de marketing" — "geriu SEO para três empresas SaaS de 0 a 100K visitantes mensais"). Para a entidade de tópico: usa os termos exatos que o teu público pesquisa. Se estás a cobrir "GEO" (otimização de motor generativo), diz "otimização de motor generativo" algures, não apenas a abreviação. Os modelos usam a co-ocorrência de termos para classificar o conteúdo. ### Passo 3: Adicionar esquema FAQ a cada publicação que responde perguntas O esquema FAQPage é o tipo de esquema de maior influência para citação GEO porque mapeia explicitamente pergunta para resposta num formato que os modelos podem analisar diretamente. Pega nas 3–5 perguntas que a tua publicação implicitamente responde e torna-as explícitas: ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "How long does it take to rank in AI search?", "acceptedAnswer": { "@type": "Answer", "text": "Most sites see initial citation improvements within 4–8 weeks of restructuring existing content for direct answers and adding FAQ schema. Brand-new domains take longer — expect 3–6 months before consistent citations appear." } } ] } ``` Adiciona isto ao `` da tua publicação ou através do campo de esquema do teu CMS. Cada motor de IA principal rastreja e analisa isto. ### Passo 4: Submeter ao llms.txt e ao índice de IA da tua plataforma `llms.txt` é um padrão emergente — um ficheiro de texto simples em `teusitio.com/llms.txt` que diz aos rastreadores de IA qual o conteúdo de alta qualidade e como priorizá-lo. É análogo ao `robots.txt` mas para LLMs. Um llms.txt básico: ``` # llms.txt # alejandrorioja.com — AI agents and GEO for operators ## Priority content - /blog/geo-for-local-business (definitive guide, updated monthly) - /blog/schema-markup-for-ai-engines (technical reference) - /blog/how-to-get-cited-by-chatgpt (step-by-step) ## Author Alejandro Rioja — operator, AI agent builder, GEO practitioner. LinkedIn: https://linkedin.com/in/alejandrorioja ``` Combina isto com um sitemap limpo que inclua marcas de tempo `lastmod`. Os rastreadores de IA desprioritizam conteúdo que parece desatualizado. ## Como priorizar quais publicações adaptar Nem todas as publicações valem a pena adaptar. Concentra o teu primeiro passe em: 1. **Publicações que já se posicionam na página 1 para uma palavra-chave em formato de pergunta** — estas estão mais perto de serem citadas; apenas precisam da correção de estrutura 2. **Publicações sobre tópicos nos quais és verificavelmente credível** — os motores de IA pesam muito a autoria; uma publicação onde as tuas credenciais são relevantes obtém um impulso de citação dos sinais de entidade 3. **Publicações que respondem diretamente uma pergunta vs. publicações que informam** — "Como fazer X" e "O que é X" adaptam-se melhor do que listicles ou peças de opinião Usa os teus dados do Search Console: filtra para consultas que são perguntas (como, o que, por que, melhor forma de). Publicações com posição 5–15 para essas consultas são as tuas melhores candidatas de retrofit — são relevantes mas ainda não suficientemente perto do topo para serem citadas. ## O erro que a maioria das pessoas comete Escrevem uma nova publicação otimizada para pesquisa de IA antes de adaptar o seu arquivo existente. O novo conteúdo ajuda, mas as publicações existentes têm idade, backlinks e histórico de rastreamento do seu lado. Uma publicação de três anos bem estruturada superará uma nova publicação sobre o mesmo tópico durante meses. Faz o retrofit primeiro. Escreve novo conteúdo onde há lacunas genuínas — perguntas que as tuas publicações existentes não respondem de todo. É aí que o novo é melhor que o antigo. ## A conclusão do operador Se tens mais de 20 publicações de blog existentes, o teu trabalho de GEO começa com auditoria e retrofit, não com um calendário de conteúdo. Adiciona TL;DRs, reforça sinais de entidade, adiciona esquema FAQ e submete ao llms.txt. Faz isso nas tuas 20 melhores publicações antes de escrever qualquer coisa nova. Verás melhorias nas citações em semanas, não meses — e terás uma linha de base mais limpa para medir se o novo conteúdo realmente move a agulha. --- ## Criei uma habilidade do Claude que gerencia meus anúncios do Facebook — aqui está o código Source: https://alejandrorioja.com/pt/i-built-a-claude-skill-that-runs-my-facebook-ads-heres-the-code/ Published: 2026-06-06 Updated: 2026-06-06 Tags: AI Agents TL;DR: Criei uma habilidade do Claude que lê minha conta Meta Ads via Graph API, identifica os de baixo desempenho, reescreve o copy na minha voz de marca e cria novos conjuntos de anúncios sem eu precisar tocar no Gerenciador de Anúncios. O projeto todo tem menos de 300 linhas de TypeScript. O retorno foi imediato: reduzi o tempo semanal de gestão de anúncios de ~3 horas para cerca de 20 minutos. ## Índice _Atualizado junho de 2026._ **TL;DR:** Criei uma habilidade do Claude que lê minha conta Meta Ads via Graph API, identifica os de baixo desempenho, reescreve o copy na minha voz de marca e cria novos conjuntos de anúncios sem eu precisar tocar no Gerenciador de Anúncios. O projeto todo tem menos de 300 linhas de TypeScript. O retorno foi imediato: reduzi o tempo semanal de gestão de anúncios de ~3 horas para cerca de 20 minutos. **[Leitura do operador]** Gerencio anúncios para a Pickleland e para minha marca de consultoria. Duas contas, públicos diferentes, fadiga criativa constante. Eu passava os domingos à tarde no Gerenciador de Anúncios fazendo coisas que um modelo deveria fazer. Então automatizei. ## Por que parei de gerenciar anúncios do Facebook manualmente O trabalho real de gerenciar anúncios no Facebook se divide em três tarefas: 1. **Monitoramento** — verificar quais conjuntos de anúncios estão queimando dinheiro vs. gerando 2. **Diagnóstico** — descobrir *por que* algo está com baixo desempenho (fadiga criativa? segmentação ruim? página de destino?) 3. **Iteração** — escrever novo copy, criar novos conjuntos de anúncios, ajustar orçamentos A tarefa 1 é mecânica. A tarefa 3 é principalmente mecânica (com uma restrição de voz). A tarefa 2 requer julgamento — e é a única que se beneficia de ter um humano no ciclo. Uma habilidade do Claude pode fazer o 1 e o 3. Eu reviso os resultados da tarefa 2 antes de qualquer coisa ser publicada. Essa é a arquitetura em que me decidi. ## A configuração da Meta Graph API (esta é a parte chata) Antes de qualquer código: você precisa de uma conta Meta Business, um Usuário do Sistema e um token de acesso permanente. O portal de desenvolvedores do Facebook é hostil, mas o caminho é: 1. Criar um **Meta App** em developers.facebook.com (tipo: Business) 2. Adicionar o produto **Marketing API** 3. No seu Portfólio de Negócios → Configurações → Usuários → Usuários do Sistema, criar um usuário do sistema e dar a ele o papel `ADVERTISER` na sua conta de anúncios 4. Gerar um token com essas permissões: `ads_read`, `ads_management`, `business_management` Armazene o token como `META_ACCESS_TOKEN` e o ID da sua conta de anúncios (formato: `act_XXXXXXXX`) como `META_AD_ACCOUNT_ID` no seu `.env`. ## A estrutura de arquivos da habilidade ``` .claude/skills/fb-ads/ SKILL.md ← instruções que o Claude lê index.ts ← a implementação real da ferramenta types.ts ← tipos compartilhados ``` O `SKILL.md` é o que diz ao Claude quando e como usar a habilidade. O meu diz: ```markdown # Facebook Ads Manager Skill Use this skill when the user says "check my ads", "run ads report", "pause underperformers", or "write new ad copy". Never run this without explicit user instruction — it touches live ad spend. ## What it can do - Pull performance data for all active ad sets (last 7 or 30 days) - Flag ad sets with ROAS < 1.5 or CTR < 0.8% as underperformers - Rewrite ad copy for flagged creatives in Ale's voice - Create new ad sets with revised copy (PAUSED by default — you approve before activating) ## What it will NOT do - Change budgets on live ad sets without explicit confirmation - Activate new ad sets automatically - Delete anything ``` A restrição de "nunca ativar automaticamente" é inegociável. Esta habilidade cria coisas no estado PAUSADO. Eu reviso e ativo manualmente. Qualquer coisa que toque nos gastos com anúncios ao vivo precisa de um ponto de controle humano. ## O código TypeScript principal (Blocos de código permanecem em inglês — apenas o texto ao redor é traduzido.) ## Como uso no dia a dia A habilidade é invocada do Claude Code (minha ferramenta diária). Uma sessão típica de segunda-feira de manhã: ``` > check my ads from the last 7 days ``` O Claude executa `runAdsReport(7)`, formata os resultados como uma tabela, sinaliza os de baixo desempenho e pergunta se quero reescritas. Digo que sim. Ele gera novo copy, me mostra as duas versões lado a lado e cria conjuntos de anúncios PAUSADOS com o novo criativo. Eu os reviso no Gerenciador de Anúncios, ativo os que gosto e arquivos os perdedores. Tempo total: 20 minutos. Zero domingos à tarde no Gerenciador de Anúncios. ## O que isso não substitui A habilidade não pode me dizer se um problema de ajuste produto-mercado está se disfarçando de problema de copy. Se o ROAS está ruim em geral, é um problema de funil ou oferta, não de título. O Claude fielmente reescreverá o copy em um funil quebrado — e as reescritas não vão salvá-lo. A etapa de diagnóstico ainda é minha. Leio o relatório, olho os dados do funil e decido se estamos iterando o criativo ou resolvendo algo mais acima. O agente é rápido em tudo *exceto* nesse julgamento. ## A conclusão do operador Se você está gerenciando anúncios manualmente e tocando no Gerenciador de Anúncios mais de duas vezes por semana, você está fazendo operações que um script deveria fazer. A Graph API é bem documentada e o fluxo de permissões da Meta, embora chato, é uma configuração única. Construa a habilidade em uma tarde. O retorno em tempo recuperado aparece na primeira semana. --- ## As 5 Ferramentas de IA que Realmente Uso para Gerir o Meu Negócio (2026) Source: https://alejandrorioja.com/pt/the-5-ai-tools-i-actually-use-to-run-my-business-2026-operator-stack/ Published: 2026-06-06 Updated: 2026-06-06 Tags: AI Agents, Growth TL;DR: Cinco ferramentas: Claude (camada de operador + programação), Cursor (desenvolvimento TypeScript), Airtable (espinha dorsal de dados para todos os agentes), Kit (newsletter + automação de email) e Cloudflare Workers (hospedagem de agentes). Tudo o mais que experimentei foi substituído por uma destas ou cortado completamente. Este é o stack que eu reconstruiria se tivesse que começar do zero hoje. ## Índice _Atualizado junho 2026._ **TL;DR:** Cinco ferramentas: Claude (camada de operador + programação), Cursor (desenvolvimento TypeScript), [Airtable](/recommends/airtable) (espinha dorsal de dados para todos os agentes), [Kit](/recommends/convertkit) (newsletter + automação de email) e Cloudflare Workers (hospedagem de agentes). Tudo o mais que experimentei foi substituído por uma destas ou cortado completamente. Este é o stack que eu reconstruiria se tivesse que começar do zero hoje. **[Leitura do operador]** Giro dois negócios: uma marca pessoal de consultoria em IA (alejandrorioja.com) e Pickleland, uma instalação de pickleball em Pflugerville, TX. Contextos diferentes, públicos diferentes, operações diferentes. Estas cinco ferramentas gerem ambos. Não as listo porque estão na moda; listo-as porque eliminei os seus substitutos. ## 1. Claude — a camada de operador Claude (via Claude Code e o Anthropic SDK) é o cérebro de tudo o que se move. Uso-o em três modos: **Claude Code** é a minha ferramenta diária de desenvolvimento. Escrevo TypeScript, construo agentes, faço debug de problemas de infraestrutura e giro conteúdo — tudo a partir da interface do Claude Code. Não é apenas autocompletar; é um colaborador que pode ler um ficheiro de 500 linhas, compreender a intenção e propor uma refatoração que eu não tinha considerado. **O Anthropic SDK** alimenta cada agente que construí. O meu agente de newsletter, a minha habilidade de anúncios no Facebook, o meu pipeline de conteúdo, o meu gerador de cartões OG — tudo Claude no backend. A qualidade do modelo é suficientemente alta para que confie nos primeiros rascunhos cerca de 85% das vezes. **O julgamento de voz e marca do Claude** é subestimado. Quando escrevo algo que precisa de soar como eu, descobri que Claude + um system prompt detalhado supera todos os outros modelos que testei. O truque é um system prompt específico e com opiniões — não "escreve num tom casual" mas "escreve como Alejandro: direto, praticante, sem hype, numerado, primeira pessoa, com ressalvas honestas." Pago pelo Claude Max. É a assinatura mais usada que tenho, e o ROI não tem comparação. ## 2. Cursor — onde o TypeScript é escrito Cursor é o IDE. Mudei do VS Code há cerca de um ano e não olhei para trás. A completação por tab é rápida o suficiente para mudar genuinamente como escrevo código — penso numa altitude mais elevada e deixo o Cursor tratar do boilerplate sintático. A vista de diff para sugestões de IA é limpa. A janela de contexto multi-ficheiro significa que posso pedir-lhe para atualizar uma função e também atualiza os chamadores. Não uso o Cursor para decisões de arquitetura. Ainda esboço essas em papel ou no Claude. Mas uma vez que o design é claro, Cursor é o caminho mais rápido do design para TypeScript a funcionar. O maior desbloqueio: Cursor + Claude Code em paralelo. Uso o Claude Code para planeamento de alto nível e orquestração de agentes; uso o Cursor para o trabalho de detalhe de implementação. Não entram em conflito — cobrem altitudes diferentes. ## 3. Airtable — a espinha dorsal de dados Cada agente de IA que giro precisa de um lugar para ler e escrever. Esse lugar é o [Airtable](/recommends/airtable). Eis para o que o uso em ambos os negócios: - **Fila de conteúdo** — publicações e tópicos de newsletter em andamento, com rastreamento de status - **Registos de reservas** — reservas de campos do Pickleland sincronizadas do sistema de reservas - **Catálogo de links de afiliados** — mais de 105 slugs com metadados que o agente de conteúdo lê no momento da geração - **Log de auditoria do agente** — o que correu, quando, o que produziu, quaisquer erros A API é limpa e rápida. Airtable não é uma base de dados para cargas de trabalho de alto rendimento — mas para tabelas auxiliares de agentes, filas de revisão e fluxos de trabalho de aprovação com intervenção humana, é exatamente a ferramenta certa. A interface visual significa que posso inspecionar qualquer tabela sem escrever uma consulta. A alternativa que experimentei: bases de dados do Notion. A API do Notion é mais lenta e o modelo de dados é mais pesado para leituras de agentes. Airtable vence para dados adjacentes a agentes. ## 4. Kit — newsletter e automação de email Mudei para o [Kit](/recommends/convertkit) (anteriormente ConvertKit) por uma razão: a API é realmente boa. A maioria das plataformas de email trata a sua API como uma reflexão tardia. O Kit trata-a como um produto de primeira classe. Posso criar transmissões, agendar envios, segmentar por tag e ler análises — tudo programaticamente. O meu agente de newsletter faz tudo isso sem eu tocar no compositor. Coisas específicas do Kit que uso: - **API de Transmissões** — o meu agente cria transmissões agendadas programaticamente todas as semanas - **Etiquetagem de subscritores** — etiqueto subscritores por comportamento (abriu os últimos 5 envios = "envolvido"; não abriu em 60 dias = "em risco") e o meu agente direciona segmentos em conformidade - **Formulários + páginas de destino** — limpos, de carregamento rápido, sem código. Não os manipulo programaticamente; simplesmente funcionam. Se estás no Mailchimp ou numa plataforma legada: a migração vale a pena. A API do Mailchimp requer três chamadas extras para fazer o que o Kit faz em uma. ## 5. Cloudflare Workers — onde os agentes vivem Cada agente agendado corre no Cloudflare Workers. O argumento: implantação global no edge, zero arranques a frio no nível gratuito e um sistema de gatilho cron que realmente funciona. Os meus agentes não precisam de um servidor. Precisam de uma função agendada que corra de forma fiável, possa fazer chamadas de API externas e custe quase nada na minha escala. Workers é a resposta. O que tenho a correr no Workers: - **Pipeline de conteúdo** — gera publicação EN, distribui para 12 traduções, gera cartão OG - **Agente de newsletter** — redige e agenda o envio semanal - **Monitor de anúncios do Facebook** — lê desempenho, sinaliza subdesempenhos, notifica-me - **Repórter de ocupação do Pickleland** — lê dados de reservas, envia-me um resumo diário Custo mensal total por tudo isso: ~$5. Esse é o plano Workers pago. Os agentes correm de forma fiável no agendamento cron; tive uma falha em seis meses (um problema de DNS no lado da Meta, não no meu). ## O que cortei e porquê **Zapier** — substituído por Workers + as respetivas APIs de plataforma diretamente. Zapier adiciona latência, custa mais à escala e tem um teto que Workers não tem. **ChatGPT** — a janela de contexto, uso de ferramentas e qualidade do system prompt do Claude são melhores para o caso de uso do operador. Mantenho um separador do ChatGPT para pesquisas rápidas na web mas não construo sobre ele. **Webflow** — movi o meu site para Astro + Cloudflare Pages. Mais controlo, melhor desempenho, processo de build contra o qual posso programar. **Grammarly** — Claude faz tudo o que o Grammarly faz e preserva melhor a minha voz. ## A conclusão do operador As cinco ferramentas acima não são as mais recentes nem as mais discutidas. São as que resistiram ao uso diário em produção em dois negócios diferentes. Antes de adicionar uma nova ferramenta ao teu stack, pergunta: qual destas cinco poderia fazer este trabalho? Ficarás surpreendido com a frequência com que a resposta é "uma delas já pode." --- ## Por Que o Teu Agente de IA Continua a Falhar em Produção (E Como Corrigir) Source: https://alejandrorioja.com/pt/why-your-ai-agent-keeps-failing-in-production-and-how-to-fix-it/ Published: 2026-06-06 Updated: 2026-06-06 Tags: AI Agents TL;DR: A maioria das falhas de agentes em produção vem de cinco causas: prompts frágeis que não lidam com casos extremos, lógica de retry em falta para erros de API transitórios, sem observabilidade para ver o que está a falhar, loops descontrolados sem condição de saída e definições de ferramentas suficientemente ambíguas para que o modelo escolha a errada. Os cinco são corrigíveis sem mudar modelos ou frameworks. ## Índice _Atualizado junho 2026._ **TL;DR:** A maioria das falhas de agentes em produção vem de cinco causas: prompts frágeis que não lidam com casos extremos, lógica de retry em falta para erros de API transitórios, sem observabilidade para ver o que está a falhar, loops descontrolados sem condição de saída e definições de ferramentas suficientemente ambíguas para que o modelo escolha a errada. Os cinco são corrigíveis sem mudar modelos ou frameworks. **[Leitura do operador]** Tenho mais de 30 agentes em produção. Já tive todas estas falhas. As que queimaram mais tempo não foram as exóticas — foram as falhas de infraestrutura chatas que pensei ter tratado. ## Falha 1: Prompts frágeis que quebram em entradas de casos extremos Um prompt que funciona nos teus casos de teste vai falhar em entradas que não antecipaste. Isso não é uma limitação do modelo — é um problema de escrita de instruções. **Sintomas:** O agente produz output sem sentido, chama a ferramenta errada ou devolve JSON malformado quando a entrada é ligeiramente diferente do que testaste. **Causa raiz:** O teu system prompt descreve apenas o caminho feliz. Não diz ao modelo o que fazer quando os dados estão em falta, malformados ou ambíguos. **Correção:** Adiciona tratamento explícito de casos extremos ao teu system prompt: ``` If the input data is missing a required field, return: { "status": "error", "reason": "missing_field", "field": "" } Do NOT attempt to infer or hallucinate missing values. If you are uncertain which tool to call, call no tool and return: { "status": "clarification_needed", "question": "..." } ``` O modelo segue instruções explícitas para casos extremos de forma fiável. O erro é assumir que vai generalizar as instruções do caminho feliz para tratar os casos confusos. ## Falha 2: Sem lógica de retry para erros de API transitórios Cada API externa que o teu agente chama vai falhar em algum momento. A API do Claude, a Meta Graph API, a tua base de dados — todas devolvem erros 5xx, fazem timeout ou limitam a taxa. Se o teu agente não tem lógica de retry, um erro transitório mata toda a execução. **Sintomas:** As execuções do agente falham aleatoriamente em diferentes passos. Os logs mostram um 503 ou 429 sem tentativa de seguimento. **Correção:** Envolve cada chamada externa num retry com backoff exponencial: ```typescript async function withRetry(fn: () => Promise, retries = 3, baseDelayMs = 500): Promise { for (let attempt = 0; attempt <= retries; attempt++) { try { return await fn(); } catch (err: any) { const isTransient = err.status === 429 || err.status >= 500 || err.code === "ECONNRESET"; if (!isTransient || attempt === retries) throw err; const delay = baseDelayMs * Math.pow(2, attempt) + Math.random() * 100; await new Promise((r) => setTimeout(r, delay)); } } throw new Error("unreachable"); } // Usage const result = await withRetry(() => client.messages.create({ ... })); ``` Três retries com backoff exponencial trata ~99% das falhas transitórias. Adiciona isto a cada chamada externa e metade das tuas falhas aleatórias desaparece. ## Falha 3: Sem observabilidade — não consegues ver o que está a falhar Este é o modo de falha mais comum em produção e o que custa mais tempo a depurar: o agente falha silenciosamente ou produz output errado, e não tens ideia de onde na cadeia correu mal. **Sintomas:** Sabes que algo está errado mas não consegues identificar o passo. Adds declarações `console.log` e reexecutas manualmente tentando reproduzir. **Correção:** Logging estruturado em cada passo, com um ID de execução que rastreia toda a execução: ```typescript function createLogger(runId: string, agentName: string) { return { step: (step: string, data: object) => console.log(JSON.stringify({ runId, agent: agentName, step, ts: new Date().toISOString(), ...data })), error: (step: string, err: unknown) => console.error(JSON.stringify({ runId, agent: agentName, step, error: String(err), ts: new Date().toISOString() })), }; } const log = createLogger(crypto.randomUUID(), "newsletter-agent"); log.step("fetch_topic", { topicId: topic.id, topic: topic.name }); // ... do work ... log.step("draft_complete", { subject: draft.subject, wordCount: draft.body.split(" ").length }); ``` Se estás no Cloudflare Workers, estes logs vão para Logpush ou Workers Tail. Se estás a correr localmente ou num VPS, envia-os para um agregador de logs. O JSON estruturado significa que podes filtrar por `runId` para ver exatamente o que aconteceu numa única execução. ## Falha 4: Loops descontrolados sem condição de saída Loops agênticos — onde o modelo chama ferramentas e itera até que uma condição seja cumprida — podem correr para sempre se essa condição nunca for cumprida ou o modelo a identificar mal. **Sintomas:** O agente gasta centenas de dólares em custos de API antes de fazer timeout. Ou executa a mesma chamada de ferramenta repetidamente sem progredir. **Correção:** Tem sempre um limite de iteração rígido e uma verificação de progresso: ```typescript const MAX_ITERATIONS = 10; let iterations = 0; let lastToolCallName = ""; let sameToolCallCount = 0; while (true) { iterations++; if (iterations > MAX_ITERATIONS) { log.error("loop", { reason: "exceeded_max_iterations" }); break; } const response = await client.messages.create({ ... }); // Detect stuck loops: same tool called 3x in a row const toolCall = response.content.find(b => b.type === "tool_use"); if (toolCall?.name === lastToolCallName) { sameToolCallCount++; if (sameToolCallCount >= 3) { log.error("loop", { reason: "stuck_loop", tool: toolCall.name }); break; } } else { sameToolCallCount = 0; lastToolCallName = toolCall?.name ?? ""; } if (response.stop_reason === "end_turn") break; } ``` Isto captura tanto o modo de falha de "correu demasiado tempo" como o de "girou no lugar". O limite deve ser generoso o suficiente para o caminho feliz mas apertado o suficiente para limitar o raio de explosão. ## Falha 5: Definições de ferramentas ambíguas que o modelo resolve mal Se deres ao modelo duas ferramentas com descrições sobrepostas, às vezes vai chamar a errada. Isto é especialmente comum com ferramentas como `search_database` vs `get_record` ou `send_email` vs `create_draft`. **Sintomas:** O modelo chama a categoria certa de ferramenta mas escolhe a específica errada. Ou chama uma ferramenta no contexto errado (usando uma ferramenta de escrita quando apenas a leitura era apropriada). **Correção:** Torna as descrições de ferramentas mutuamente exclusivas e adiciona explicitamente "quando NÃO usar isto": ```typescript const tools = [ { name: "get_subscriber", description: "Fetch a single subscriber record by email. Use ONLY when you have a specific email address. Do NOT use for searching or listing subscribers.", input_schema: { ... } }, { name: "search_subscribers", description: "Search subscribers by tag, segment, or status. Use when you need to find subscribers matching a criteria — NOT when you have a specific email address.", input_schema: { ... } } ]; ``` A cláusula "NÃO usar quando X" é a parte que a maioria das pessoas ignora. É a parte mais importante. Os modelos são melhores a seguir restrições negativas explícitas do que a inferi-las de descrições positivas. ## Mais uma coisa: testa os teus agentes com entradas más A maioria dos agentes é testada apenas em entradas limpas de caminho feliz. A produção tem entradas sujas: strings vazias, campos nulos, casos extremos de Unicode, respostas de API que devolvem 200 mas com um esquema inesperado. Adiciona uma suite de testes que exercita explicitamente: - Entradas vazias ou nulas - Entradas no comprimento máximo que esperarias - Entradas com caracteres especiais ou texto não-ASCII - APIs externas a devolver formas de resposta inesperadas Se o teu agente quebrar com alguma destas, corrige-o antes de ir ao ar. O ambiente de produção vai encontrar cada suposição que fizeste. ## A conclusão do operador A maioria das falhas de agentes em produção são problemas de infraestrutura a fazer-se passar por problemas de modelo. Antes de mudar modelos, adiciona retries, logging estruturado, limites de loop e tratamento explícito de casos extremos aos teus prompts. Corrige as definições de ferramentas ambíguas. Depois testa com entradas más. Faz tudo isso antes de culpar o modelo — na minha experiência, o modelo é geralmente a última coisa que precisa de mudar. --- ## Como Construir Seu Primeiro Agente de IA em 15 Minutos Source: https://alejandrorioja.com/pt/how-to-build-your-first-ai-agent-in-15-minutes/ Published: 2026-06-02 Updated: 2026-06-02 Tags: AI Agents TL;DR: Você não precisa de um framework, um curso ou um doutorado. Você precisa do Node.js, do SDK da Anthropic e de 25 linhas de TypeScript. Este tutorial constrói um agente real e funcional — um resumidor de conteúdo estruturado que você pode publicar na Cloudflare na mesma sessão. O único pré-requisito é uma chave de API gratuita. ## Índice _Atualizado em junho de 2026._ **TL;DR:** Você não precisa de um framework, um curso ou um doutorado. Você precisa do Node.js, do SDK da Anthropic e de 25 linhas de TypeScript. Este tutorial constrói um agente real e funcional — um resumidor de conteúdo estruturado que você pode publicar na Cloudflare na mesma sessão. O único pré-requisito é uma chave de API gratuita. **[Leitura do operador]** A coisa mais comum que ouço de fundadores que querem automatizar com IA é "primeiro preciso aprender mais". Não precisa. O padrão de agente é simples, e a forma mais rápida de entendê-lo é construir um. Aqui está o caminho exato que eu seguiria se começasse do zero hoje. ## Por que a maioria dos tutoriais de "construa um agente de IA" te decepciona Eles usam Python (ótimo para engenheiros de ML, atrito para todos os outros), escondem o código real por trás de um framework como o LangChain, ou constroem algo abstrato demais para conectar ao seu trabalho real. Este tutorial faz três coisas de forma diferente: 1. **Só TypeScript** — se você já escreveu JavaScript, consegue seguir isto 2. **Sem framework** — você verá cada linha de código que toca o modelo 3. **Um resultado útil** — você construirá um resumidor estruturado que realmente pode usar em e-mails de clientes, avaliações ou notas de reuniões ## O que você vai construir Um **agente resumidor de conteúdo**: cole qualquer bloco de texto e receba de volta um resumo estruturado em um formato consistente. Uma requisição HTTP de entrada, um resumo limpo de saída. Por que este como primeiro projeto: o padrão — prompt de sistema + entrada do usuário → saída estruturada — é a base de cada agente que eu rodo. Troque o prompt de sistema e você tem um respondedor de perguntas, um reescritor de tom, um classificador ou um gerador de rascunhos. Aprenda isto uma vez e você terá aprendido 80% do que os agentes em produção realmente fazem. ## Pré-requisitos (2 minutos) - **Node.js 18+** — verifique com `node --version`. Instale a partir de nodejs.org se precisar. - **Uma chave de API da Anthropic** — cadastre-se no [Claude](/recommends/claude), pegue uma chave no console. O plano gratuito funciona. - Um terminal e um editor de texto. Sem Docker. Sem ambiente virtual. Sem `pip install` de nada. ## Passo 1: Criar o projeto (2 minutos) ```bash mkdir my-first-agent && cd my-first-agent npm init -y npm install @anthropic-ai/sdk npm install -D tsx typescript ``` Adicione um script ao `package.json` para conseguir rodar o agente facilmente: ```json { "scripts": { "agent": "tsx agent.ts" } } ``` ## Passo 2: Escrever o agente (5 minutos) Crie `agent.ts` e cole isto: ```typescript import Anthropic from "@anthropic-ai/sdk"; const client = new Anthropic({ apiKey: process.env.ANTHROPIC_API_KEY, }); const SYSTEM_PROMPT = `You are a precise content summarizer. When given any block of text, return a structured summary in this exact format: **One-line summary:** **Key points:** - - - **Action item (if any):** Be specific. No filler. Under 150 words total.`; async function summarize(text: string): Promise { const message = await client.messages.create({ model: "claude-haiku-4-5", max_tokens: 512, system: SYSTEM_PROMPT, messages: [{ role: "user", content: text }], }); const block = message.content[0]; if (block.type !== "text") throw new Error("Unexpected response type"); return block.text; } const sample = ` Hey team — following up on the Q2 review meeting. We agreed to push the launch to July 15th instead of June 30th due to the payment integration delay. Marketing needs the new landing page copy by June 20th or we can't start the email campaign. Budget for the launch campaign is confirmed at $8,000. Please confirm receipt. `; const result = await summarize(sample); console.log(result); ``` ## Passo 3: Executá-lo (1 minuto) ```bash ANTHROPIC_API_KEY=sk-ant-... npm run agent ``` Saída esperada: ``` **One-line summary:** Launch pushed to July 15th due to payment delay; landing page copy needed by June 20th to unblock email campaign. **Key points:** - Launch date moved from June 30th to July 15th - Landing page copy deadline: June 20th (blocks email campaign) - Campaign budget confirmed at $8,000 **Action item (if any):** Confirm receipt and deliver landing page copy by June 20th. ``` Isso é um agente de IA funcionando. Entrada real, prompt de sistema personalizado, saída estruturada. A coisa toda tem 30 linhas de código. ## Passo 4: Personalize para o seu caso de uso O prompt de sistema é a única coisa que torna este agente seu. Aqui estão três alternativas prontas para usar: **Classificador de avaliações de clientes:** ```text Classify this customer review as POSITIVE, NEGATIVE, or MIXED. Then extract the main complaint or praise in one sentence. Format: SENTIMENT: