# 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 --- ## Agentes de IA com Supervisão Humana: Quando Criar um Portão de Aprovação (e Quando Não) Source: https://alejandrorioja.com/pt/human-in-the-loop-ai-agents-when-to-build-an-approval-gate/ Published: 2026-07-23 Tags: AI Agents, Operations TL;DR: Um portão de aprovação faz sentido quando um erro é caro, irreversível ou voltado ao cliente — e quando um humano pode detectá-lo a tempo. Não faz sentido quando o volume é alto demais para revisar, o erro é barato de corrigir ou humanos aprovam sem ler. Uso quatro perguntas para decidir, e a maioria dos meus 30+ agentes em produção não tem nenhum portão de aprovação. ## Sumário _Publicado em julho de 2026._ **TL;DR:** Um portão de aprovação faz sentido quando um erro é caro, irreversível ou voltado ao cliente — e quando um humano pode detectá-lo a tempo. Não faz sentido quando o volume é alto demais para revisar, os erros são baratos de corrigir ou humanos aprovam sem ler. Uso quatro perguntas para decidir, e a maioria dos meus 30+ agentes em produção funciona de forma totalmente automatizada. **Nota do operador:** Gerencio agentes em dois negócios — uma marca de consultoria e Pickleland, uma instalação de pickleball em Pflugerville, TX. No início, coloquei portões de aprovação em todo lugar porque parecia "seguro." Em semanas, tinha um canal do Slack cheio de notificações que ninguém lia, e agentes tecnicamente supervisionados mas praticamente sem supervisão. Isso é pior que nenhum portão: a ilusão de supervisão sem a substância. Este artigo explica como raciocino sobre essa decisão agora. ## O que é realmente um portão de supervisão humana Na forma mais simples, um portão de aprovação é uma pausa no fluxo de trabalho de um agente onde um humano deve confirmar antes de o agente continuar. O agente cria um rascunho de e-mail — um humano aprova antes de enviar. O agente sinaliza uma transação — um humano revisa antes de o reembolso ser processado. O portão pode ser síncrono (o agente bloqueia até alguém aprovar) ou assíncrono (o agente coloca a ação na fila, envia uma notificação, e um humano aprova de um painel ou mensagem do Slack no seu ritmo). Assíncrono é quase sempre melhor para qualquer coisa que não seja crítica no tempo, pois portões síncronos criam contrapressão na fila e quebram as garantias de confiabilidade do agente. O que um portão não é: um loop de nova tentativa, um limiar de confiança ou um fallback para um modelo mais simples. Esses são mecanismos de tratamento de erros dentro do agente. Um portão de aprovação é sobre o julgamento humano entrando no loop — deliberadamente, em um ponto específico, por um motivo. ## As quatro perguntas que faço Antes de adicionar um portão, percorro quatro perguntas. Um "sim" em qualquer uma é um sinal para considerar um. Um "sim" em todas as quatro significa que o portão é estrutural. **1. A ação é irreversível (ou cara de reverter)?** Enviar um e-mail para 10.000 pessoas não pode ser desfeito. Submeter um pagamento não pode ser facilmente recuperado. Excluir um registro de banco de dados sem backup é permanente. A irreversibilidade é o argumento mais forte para um portão, porque o agente não pode desfazer o que fez. Compare isso com: etiquetar uma consulta recebida com uma categoria. Se a etiqueta estiver errada, você a corrige em dois cliques. Sem portão necessário. **2. Se o agente errar, quem paga?** Um rótulo interno errado — passo alguns segundos corrigindo. Um e-mail voltado ao cliente errado — o cliente paga com uma experiência ruim, e eu pago com uma perda de confiança. Uma transação financeira errada — pago com dinheiro real e possivelmente risco de conformidade. Agentes que afetam apenas sistemas internos podem tolerar mais erro sem um portão. Agentes que tocam clientes ou dinheiro precisam ganhar o direito de funcionar sem supervisão. **3. Um humano pode realmente detectar o erro antes que importe?** Esta é a pergunta que a maioria das pessoas pula, e é a que elimina mais portões do que qualquer outra. Se um agente processa 500 itens por hora e você recebe uma notificação do Slack por item, ninguém vai ler os 500. Você está criando fadiga de alertas, não supervisão. A matemática é simples: um portão só adiciona valor se um humano puder realisticamente revisar o item sinalizado dentro da janela de tempo disponível. Se o agente é de alto volume e rápido, o portão precisa ser altamente seletivo (sinalizando apenas casos extremos) ou removido. **4. Os humanos leem de forma confiável o que o agente apresenta?** Se sua fila de aprovação encher e as pessoas aprovarem sem ler, o portão é pior que nenhum portão — cria falsa confiança de que um humano verificou o trabalho. Já passei por essa situação. A solução não é pressionar mais as pessoas; é repensar se o portão pertence ao lugar. ## Quando portões claramente fazem sentido Estes são os padrões onde sempre adiciono um portão, sem exceções: - **Comunicações externas irreversíveis** — e-mails, SMS, publicações em redes sociais indo para pessoas reais. O agente rascunha; um humano envia. De acordo com o volume. - **Ações financeiras acima de um limite** — qualquer coisa que mova dinheiro recebe um portão se estiver acima de um piso em reais que estabeleço por contexto. - **Novos padrões que o agente não viu antes** — se o classificador do agente sinaliza algo como "desconhecido" ou fora de sua distribuição de treinamento, isso é uma escalação forçada. - **Saídas sensíveis à conformidade** — qualquer coisa que toque HIPAA, PCI, avisos legais ou conteúdo financeiro regulamentado é revisada por uma pessoa. ## Quando portões silenciosamente matam o produto Estes são os padrões onde um portão parece seguro, mas quebra silenciosamente a adoção: - **Operações de alto volume e reversíveis** — se você pode desfazê-lo em dois cliques e acontece 200 vezes por dia, a fadiga de revisão vencerá. Sem portão; bons logs de auditoria em vez disso. - **Fluxos de trabalho sensíveis ao tempo** — um agente que responde a consultas de clientes recebidas em 30 segundos não deveria ter um portão síncrono. - **Tarefas onde o humano tem menos contexto que o agente** — se o agente leu 50 páginas de contexto para fazer uma classificação e o revisor recebe um resumo de uma linha, a revisão é teatro. - **Enriquecimento e etiquetamento interno** — etiquetar registros de CRM, categorizar despesas, resumir notas de reuniões. As apostas não justificam a interrupção. ## Os três padrões de portão que realmente implemento Quando um portão é justificado, escolho uma de três implementações: **1. Aprovação assíncrona via Slack/e-mail** O agente completa seu rascunho, posta uma mensagem em um canal Slack designado com a ação proposta e um botão aprovar/rejeitar, e pausa. Uso Cloudflare Queues para reter a ação pendente, e um Worker separado que ouve o webhook de aprovação antes de retomar. Funciona bem para: rascunhos de e-mail, conteúdo de redes sociais, atualizações significativas de CRM. **2. Escalação baseada em confiança** O agente funciona totalmente automatizado para saídas de alta confiança (digamos, ≥0,85 de confiança em um esquema estruturado) e encaminha itens de baixa confiança para uma fila humana. O humano vê apenas os casos extremos ambíguos. Funciona bem para: classificação, roteamento, triagem. **3. Revisão em painel com aprovação em lote** Em vez de um portão por item, todas as saídas do agente chegam a um painel de revisão. Um humano revisa em lote — por exemplo, toda manhã — e aprova ou corrige em grupo. Funciona bem para: geração de conteúdo, elaboração de relatórios, resumos agendados. ## A armadilha da fadiga de alertas Cada portão que você adiciona é um imposto permanente sobre a atenção de alguém. O risco não é apenas que um portão seja ignorado — é que três portões criem um canal Slack barulhento, que treina as pessoas a dispensar todas as notificações. A disciplina que construí: cada portão tem um proprietário explícito e um SLA explícito. Se ninguém revisa consistentemente dentro do SLA, o portão é removido e substituído por uma trilha de auditoria. Faço uma auditoria mensal de todas as filas de aprovação. ## Conectando à confiabilidade do agente Um portão é uma camada de uma pilha de confiabilidade, não a pilha inteira. Minha pilha de confiabilidade completa para um agente em produção: 1. **Eval harness** — confirma saídas corretas antes de implantar. 2. **Saídas estruturadas com validação de esquema** — a saída do agente está restrita a um esquema tipado. 3. **Limiar de confiança** — saídas de baixa confiança vão para revisão humana. 4. **Log de auditoria** — cada ação do agente é registrada. 5. **Portão de aprovação humana** — apenas para ações onde o acima não é suficiente. ## Minha regra geral Se eu não gostaria que um funcionário júnior fizesse isso sem me consultar primeiro, o agente precisa de um portão. Se eu deixaria um funcionário júnior fazer sem pensar duas vezes, o agente deve funcionar sem supervisão. ## FAQ ### Como lidar com um agente que precisa de aprovação mas roda em alto volume? Mude a arquitetura: não exija aprovação por item — exija aprovação por padrão. Deixe o agente rodar, mas faça-o apresentar anomalias estatísticas para revisão humana. ### E se um erro pudesse causar danos graves, mas não posso me dar ao luxo de uma revisão humana completa? Isso geralmente é um sinal para não implantar o agente para essa ação ainda. Alternativamente, use um limiar de confiança. Se você usa [Claude](/recommends/claude) como camada de modelo, os padrões de uso de ferramentas do SDK Anthropic facilitam definir uma ferramenta de "escalar" que o agente pode chamar quando lhe falta confiança. --- ## Claude Tool Use: Como Dou Capacidades Reais aos Meus Agentes de IA Source: https://alejandrorioja.com/pt/claude-tool-use-production-agents/ Published: 2026-07-21 Tags: AI Agents, Claude TL;DR: O tool use do Claude permite que seu agente tome ações — não apenas gerar texto. Você define ferramentas como esquemas JSON, o Claude decide quando chamá-las, e seu código executa a ação no mundo real. O loop tem três etapas: enviar mensagem → receber bloco tool_use → executar e retornar resultado. Implantei isso em mais de 15 agentes de produção no Cloudflare Workers. O ponto de falha quase nunca é a IA — são os resultados ambíguos que retornam das ferramentas. ## Índice _Atualizado julho 2026._ **TL;DR:** O tool use do Claude permite que seu agente tome ações — não apenas gerar texto. Você define ferramentas como esquemas JSON, o Claude decide quando chamá-las, e seu código executa a ação no mundo real. O loop tem três etapas: enviar mensagem → receber bloco tool_use → executar e retornar resultado. Implantei isso em mais de 15 agentes de produção no Cloudflare Workers. O ponto de falha quase nunca é a IA — são os resultados ambíguos que retornam das ferramentas. **[Perspectiva do operador]** Gerencio mais de 30 agentes de IA em produção entre uma marca de consultoria e a Pickleland, uma instalação de pickleball em Pflugerville, TX. Cerca de metade usa tool use — o recurso da API do Claude que permite ao modelo chamar funções definidas pelo seu código. Aqui está o padrão ao qual cheguei após implantar e iterar em produção. ## Por que o tool use muda o que um agente pode fazer Sem ferramentas, um agente só pode gerar texto. Isso é útil para resumos, rascunhos e classificação — mas não é o que a maioria das automações empresariais realmente precisa. As automações empresariais precisam consultar informações, escrever em bancos de dados, chamar APIs, enviar mensagens. O tool use é a forma como você dá esse acesso ao Claude. Você define um conjunto de ferramentas como esquemas JSON. O Claude lê os esquemas, decide qual ferramenta chamar e com quais argumentos, e retorna um bloco de conteúdo `tool_use` estruturado. Seu código executa a função real. O Claude obtém o resultado e decide o que fazer a seguir — incluindo chamar outra ferramenta ou produzir uma resposta de texto final. A chave: **o Claude decide quando e se chamar uma ferramenta.** Você define as capacidades. O modelo raciocina sobre quando usá-las. ## Como funciona o fluxo da API O loop de tool use tem três etapas. Você executará este loop uma ou várias vezes dependendo de quantas chamadas de ferramenta o modelo fizer. **Etapa 1: Envie sua mensagem com as ferramentas definidas** ```typescript const response = await anthropic.messages.create({ model: "claude-haiku-4-5-20251001", max_tokens: 1024, tools: [ { name: "check_court_availability", description: "Check if a court is available at a given date, time, and duration", input_schema: { type: "object", properties: { date: { type: "string", description: "Date in YYYY-MM-DD format", }, time: { type: "string", description: "Start time in HH:MM format (24h)", }, duration_minutes: { type: "number", description: "Duration of the booking in minutes", }, }, required: ["date", "time", "duration_minutes"], }, }, ], messages: [ { role: "user", content: "Is a court available tomorrow at 2pm for 90 minutes?", }, ], }); ``` **Etapa 2: Verifique se o Claude quer chamar uma ferramenta** ```typescript if (response.stop_reason === "tool_use") { const toolUseBlock = response.content.find( (block): block is Anthropic.ToolUseBlock => block.type === "tool_use" ); if (!toolUseBlock) throw new Error("Expected tool_use block"); // Run your actual function const toolResult = await checkCourtAvailability( toolUseBlock.input as CourtAvailabilityInput ); // Step 3: Return the result to Claude const finalResponse = await anthropic.messages.create({ model: "claude-haiku-4-5-20251001", max_tokens: 1024, tools: [ /* same tools as before */ ], messages: [ { role: "user", content: "Is a court available tomorrow at 2pm for 90 minutes?", }, { role: "assistant", content: response.content }, { role: "user", content: [ { type: "tool_result", tool_use_id: toolUseBlock.id, content: JSON.stringify(toolResult), }, ], }, ], }); // finalResponse.content now has the text answer } ``` Esse é o padrão completo. Três interações de API por chamada de ferramenta: definir ferramentas → receber bloco `tool_use` → retornar resultado. ## Exemplo real: o verificador de disponibilidade da Pickleland A Pickleland é uma instalação de pickleball. Recebemos perguntas de reserva no Facebook Messenger, nos comentários e através de um chatbot. A pergunta é quase sempre alguma variação de "vocês estão abertos no sábado às 15h?" ou "posso reservar uma quadra para meu grupo de 8 pessoas?" O agente verificador de disponibilidade usa tool use para consultar o sistema de reservas real em tempo real, em vez de dar uma resposta genérica. Aqui está o agente completo — simplificado, mas fiel à produção: ```typescript // workers/availability-checker.ts import Anthropic from "@anthropic-ai/sdk"; const anthropic = new Anthropic(); const AVAILABILITY_TOOLS: Anthropic.Tool[] = [ { name: "check_availability", description: "Check court availability for a date, time, and group size. Returns available courts and their prices.", input_schema: { type: "object", properties: { date: { type: "string", description: "YYYY-MM-DD" }, start_time: { type: "string", description: "HH:MM (24h)" }, duration_minutes: { type: "number" }, players: { type: "number", description: "Number of players" }, }, required: ["date", "start_time", "duration_minutes"], }, }, { name: "get_pricing", description: "Get current pricing for court rentals and open play sessions", input_schema: { type: "object", properties: { session_type: { type: "string", enum: ["court_rental", "open_play", "clinics"], }, }, required: ["session_type"], }, }, ]; export async function handleInquiry( userMessage: string, env: Env ): Promise { const messages: Anthropic.MessageParam[] = [ { role: "user", content: userMessage }, ]; // Agentic loop — keep going until stop_reason is "end_turn" while (true) { const response = await anthropic.messages.create({ model: "claude-haiku-4-5-20251001", max_tokens: 512, system: "You are the booking assistant for Pickleland, a pickleball facility in Pflugerville, TX. " + "Use the tools to look up real availability and pricing. Never make up availability or prices. " + "If the customer wants to book, direct them to pickleland.com/book.", tools: AVAILABILITY_TOOLS, messages, }); // Push the assistant's response into message history messages.push({ role: "assistant", content: response.content }); if (response.stop_reason === "end_turn") { const textBlock = response.content.find( (b): b is Anthropic.TextBlock => b.type === "text" ); return ( textBlock?.text ?? "I wasn't able to answer that — please call us directly." ); } if (response.stop_reason === "tool_use") { // Process ALL tool calls in this response (Claude can request multiple at once) const toolResults: Anthropic.ToolResultBlockParam[] = []; for (const block of response.content) { if (block.type !== "tool_use") continue; let result: unknown; switch (block.name) { case "check_availability": result = await checkAvailability( block.input as AvailabilityInput, env ); break; case "get_pricing": result = await getPricing(block.input as PricingInput, env); break; default: result = { error: `Unknown tool: ${block.name}` }; } toolResults.push({ type: "tool_result", tool_use_id: block.id, content: JSON.stringify(result), }); } // Return all tool results in a single user message messages.push({ role: "user", content: toolResults }); } } } ``` Dois pontos a destacar aqui. **O loop agêntico.** Continuo até que `stop_reason === "end_turn"`. O Claude pode chamar `check_availability`, decidir que também precisa de preços, chamar `get_pricing`, e então produzir a resposta final — isso são três chamadas de API para uma única mensagem do usuário. O loop lida com isso sem nenhuma lógica especial. **Múltiplas chamadas de ferramenta por turno.** O Claude pode retornar múltiplos blocos `tool_use` em uma única resposta. Processo todos eles e retorno todos os resultados em uma única mensagem `user`. Se você os processar um a um e retorná-los individualmente, quebra o fluxo da conversa e desperdiça tokens. ## Exemplo real: o agente de pesquisa de leads Minha marca de consultoria usa um agente de pesquisa que enriquece leads de entrada antes de falar com eles. Quando alguém preenche o formulário de contato, o agente pesquisa a empresa e extrai o que preciso saber antes da ligação. As definições de ferramentas para este incluem uma ferramenta de escrita — e é aqui que o padrão fica interessante: ```typescript const RESEARCH_TOOLS: Anthropic.Tool[] = [ { name: "search_company", description: "Search for information about a company", input_schema: { type: "object", properties: { company_name: { type: "string" }, website: { type: "string", description: "Company website if known" }, }, required: ["company_name"], }, }, { name: "save_research", description: "Save the completed research summary to Airtable. Call this when all research is complete.", input_schema: { type: "object", properties: { company_summary: { type: "string" }, estimated_size: { type: "string", enum: ["1-10", "11-50", "51-200", "200+"], }, likely_use_case: { type: "string" }, priority: { type: "string", enum: ["high", "medium", "low"] }, notes: { type: "string" }, }, required: [ "company_summary", "estimated_size", "likely_use_case", "priority", ], }, }, ]; ``` `save_research` é o que chamo de **ferramenta de escrita** — seu propósito não é obter informações, mas confirmar a saída do Claude em um banco de dados em forma estruturada. Uso esse padrão em vez de tentar fazer parse de JSON de uma resposta de texto. O Claude sabe quando a pesquisa está concluída e chama `save_research` com campos corretamente tipados. Nunca escrevo um parser. Esta é a aplicação mais limpa do tool use: defina uma ferramenta de "ação final" com o esquema exato que você quer, e o Claude entrega saída estruturada através da chamada de ferramenta. Sem parse de texto, sem regex, sem validação JSONSchema de saída em texto livre. ## Uma ferramenta vs. muitas O instinto ao começar com tool use é construir uma ferramenta gigante que faz tudo. Resista a isso. Ferramentas pequenas e focadas são melhores por três razões: 1. **O Claude raciocina melhor sobre ferramentas pequenas.** Uma ferramenta chamada `get_court_status` que retorna disponibilidade é mais fácil para o modelo raciocinar do que uma ferramenta chamada `manage_facility` que recebe um parâmetro `mode` e ramifica internamente. 2. **Ferramentas pequenas são mais fáceis de testar.** Cada ferramenta é uma função TypeScript que você pode testar unitariamente de forma independente do LLM. Você deveria — erros de ferramentas são difíceis de depurar dentro de uma conversa ativa. 3. **O Claude pode paralelizar ferramentas pequenas.** Se duas ferramentas não dependem uma da outra, o Claude pode chamá-las na mesma resposta e você as processa em paralelo. Isso só funciona se as ferramentas forem genuinamente independentes. A exceção: ferramentas que precisam de acesso a muito estado interno compartilhado. Se a função precisa de 10 variáveis da mesma fonte de dados, uma ferramenta com um esquema mais rico supera 10 ferramentas que cada uma acessa o banco de dados separadamente. Minha regra geral: comece com uma ferramenta por capacidade distinta. Combine ferramentas apenas quando vir o Claude chamá-las juntas em cada solicitação. ## Implicações de custo O tool use adiciona tokens. Cada definição de ferramenta vai para o contexto do prompt do sistema. Cada bloco `tool_use` e `tool_result` consome tokens no histórico da conversa. Para um loop agêntico multi-turno, isso se acumula rapidamente. Para o verificador de disponibilidade da Pickleland, uma conversa típica executa 3–4 chamadas de API no total (mensagem inicial + 1–2 chamadas de ferramenta + resposta final), cada uma processando 600–900 tokens. Nos preços do Haiku, isso custa menos de $0,001 por consulta. Como explico no [post sobre cálculo de custo de agentes de IA](/ai-agent-cost-math-when-haiku-beats-sonnet/), o Haiku lida com tarefas de chamada de ferramentas bem definidas de forma confiável e é 10× mais barato que o Sonnet para o mesmo volume de tokens. O agente de pesquisa de leads roda no Sonnet porque as decisões de julgamento — priorizar um lead, estimar adequação — requerem mais capacidade de raciocínio do que o Haiku oferece de forma confiável em entradas abertas. O cálculo ainda funciona porque roda com pouca frequência (algumas vezes por semana, não milhares por dia). A escolha do modelo segue a complexidade da tarefa, não preferência pessoal. ## O ponto de falha que ninguém menciona O ponto de falha mais comum que vejo no tool use em produção não é o Claude chamando a ferramenta errada. É a ferramenta retornando algo que o Claude não consegue raciocinar claramente. Se sua ferramenta retorna um objeto de banco de dados bruto com 40 campos, o Claude fica confuso sobre quais campos importam. Se sua ferramenta lança uma exceção (que aparece como uma falha do Worker em vez de um resultado de ferramenta), o loop quebra silenciosamente. Se sua ferramenta retorna `null` quando quer dizer "sem resultados", o Claude não sabe se deve tentar novamente ou desistir. Três regras para resultados de ferramentas: **Retorne resultados enxutos e explícitos.** `{ available: true, courts: ["Court 3", "Court 5"], price_per_hour: 20 }` — não a linha completa do banco de dados. **Capture erros dentro da função da ferramenta e retorne-os como resultados estruturados.** `{ error: "booking system timeout", retry: true }` — não uma exceção lançada que faz o Worker falhar. **Torne "sem resultados" explícito.** `{ available: false, next_available: "2026-07-23T14:00:00Z" }` — não `null` ou um array vazio sem contexto. O Claude raciocina muito melhor sobre sinais claros do que sobre valores de retorno ambíguos. Cada hora que passei depurando tool use em produção foi sobre resultados pouco claros, não sobre o raciocínio do modelo. ## A conclusão do operador O tool use é o recurso que transforma o Claude de um gerador de texto em um operador. Defina ferramentas focadas com esquemas de entrada claros. Processe todos os blocos `tool_use` em uma única resposta ao modelo. Execute o loop agêntico até que `stop_reason === "end_turn"`. Retorne resultados limpos e enxutos de suas funções de ferramenta — não objetos de dados brutos, não exceções lançadas, não nulos ambíguos. O modelo cuida do raciocínio. Seu código cuida das ações no mundo real. Mantenha esses dois trabalhos claramente separados e a arquitetura permanece sustentável mesmo quando você adiciona ferramentas. Se você está construindo seu primeiro agente com tool use, comece com o padrão do verificador de disponibilidade acima — uma ferramenta, um propósito, um loop agêntico. Implante isso. Então adicione a segunda ferramenta. --- **Relacionado:** [O stack de agentes que uso para rodar 30+ agentes em produção](/the-agent-stack-i-use-to-run-30-production-agents-no-python/) · [Haiku vs Sonnet: o cálculo de custo para tarefas de agentes](/ai-agent-cost-math-when-haiku-beats-sonnet/) · [Agentes disparados por eventos vs agendados: qual padrão para qual trabalho](/event-triggered-vs-scheduled-agents-which-pattern-for-which-job/) **Construindo um agente com tool use e travando?** [Entre em contato](/contact/) — projeto e construo arquiteturas de agentes de produção para equipes de operadores. ## FAQ ### O tool use do Claude funciona com todos os modelos? Sim — o tool use é suportado por todos os modelos Claude atuais. [Claude](/recommends/claude) Haiku lida com ferramentas bem definidas com esquemas claros de forma confiável e é a opção mais econômica para tipos de tarefas de alto volume. O Sonnet lida melhor com decisões de chamada de ferramentas mais ambíguas ou abertas. Comece com o Haiku; suba se a qualidade da saída não for suficiente. ### Qual é a diferença entre o tool use do Claude e o function calling da OpenAI? Mecanicamente idênticos. A OpenAI cunhou "function calling"; a Anthropic chama de "tool use". Em ambos os casos: você define esquemas JSON, o modelo retorna chamadas estruturadas, seu código executa a função. A forma da API difere, mas o conceito é o mesmo. ### O Claude pode chamar múltiplas ferramentas em uma única resposta? Sim. O Claude pode retornar múltiplos blocos `tool_use` em uma única resposta `assistant`. Processe todos eles e retorne todos os resultados em uma única mensagem `user`. Veja o padrão de loop agêntico no exemplo da Pickleland acima — o loop `for` sobre `response.content` lida com isso corretamente. ### Quantas ferramentas devo definir por agente? Fico abaixo de 8–10 ferramentas por agente. Além disso, vi o Claude ocasionalmente escolher a ferramenta errada na primeira tentativa, o que desperdiça tokens em um loop de correção. Se você precisa de mais de 10 capacidades, divida o agente em múltiplos agentes com conjuntos de ferramentas especializados em vez de construir um agente que sabe tudo. ### Devo usar tool use para obter saída estruturada? Sim — o padrão de ferramenta de escrita `save_research` é mais limpo do que pedir ao Claude para retornar JSON em um bloco de texto e então fazer parse dele. Defina uma ferramenta de "ação final" com o esquema exato que você quer. O Claude a chamará com campos corretamente tipados quando terminar. Sem parser necessário. --- ## Como os Motores de Busca Realmente Avaliam a Qualidade do Conteúdo em 2026 Source: https://alejandrorioja.com/pt/how-search-engines-evaluate-content-quality/ Published: 2026-07-20 Tags: SEO, GEO ## Índice _Publicado em julho de 2026._ **TL;DR:** Motores de busca e motores de IA pararam, ambos, de pontuar páginas isoladamente. Eles pontuam sites — profundidade de cobertura sobre um tema, sinais de confiança que resistem ao escrutínio e consistência ao longo de meses, não um único artigo excelente. Eu rodo 384 posts em inglês traduzidos para 13 idiomas e acompanho semanalmente se estou sendo citado no ChatGPT, Perplexity e Google AI Overviews. O padrão é consistente: posts isolados estagnam, clusters se acumulam, e os sinais de confiança que movem as taxas de citação são chatos, estruturais e baratos de construir. **Leitura do operador:** Não estou teorizando sobre qualidade de conteúdo — eu opero o motor de conteúdo deste site e observo o que acontece com as taxas de citação quando mudo alguma coisa. Este post é construído inteiramente a partir de coisas que medi no alejandrorioja.com: tamanhos reais de cluster, um experimento real de citação de seis semanas, testes reais de schema markup. Nada aqui é um palpite sobre como os algoritmos "provavelmente" funcionam. ## Qualidade parou de ser uma questão por página faz um tempo O modelo mental que a maioria das pessoas ainda carrega é: escreva um bom artigo, ele posiciona. Isso nunca foi totalmente verdade, e agora é ativamente enganoso para qualquer coisa além de um termo de cauda longa bem restrito. Tenho uma forma direta de ver isso no meu próprio site. Publico dentro de um punhado de clusters reais — um cluster de 29 posts sobre Agentes de IA e Claude, um cluster de explicadores de modelo de negócio "Como a X Ganha Dinheiro" que já chega a 20 posts (Google, OpenAI, Anthropic, Uber, Salesforce, e mais), e um grande cluster de SEO/GEO que é o maior tema individual do site em contagem de tags. Um post isolado num tema que só toquei uma vez se comporta de forma completamente diferente de um post que está dentro de um desses clusters, mesmo quando a peça isolada é objetivamente melhor escrita. Os posts em cluster são mais citados, posicionam de forma mais estável e se recuperam mais rápido depois de uma atualização de algoritmo. Os isolados disparam ou não, e quando não disparam, não há autoridade ao redor para servir de apoio. Esse é o mecanismo real por trás do que costuma ser vendido como uma [estratégia de autoridade temática para IA](https://www.linkbuildinghq.com/blog/how-to-build-topical-authority-for-ai/) — não uma pontuação de confiança mística, mas o fato simples de que uma página ao lado de outras 28 páginas sobre o mesmo assunto dá tanto ao rastreador do Google quanto à etapa de recuperação de um LLM mais contexto corroborante para se apoiar. Escrevi sobre [a mecânica completa dessa estrutura](/pillar-content/) de propósito — a versão curta é que um cluster só funciona se cada post nele linkar para o pilar e o pilar linkar de volta, de modo que o mapa temático seja explícito em vez de algo que o rastreador precise reconstruir. O teste prático que aplico antes de publicar qualquer coisa nova: este post estende um cluster que eu já possuo, ou começa algo avulso e único? Peças avulsas não são proibidas — algumas consultas genuinamente só precisam de uma página — mas eu já sei de antemão que uma peça avulsa está competindo apenas com sinais em nível de página, sem nenhum do efeito cumulativo que um post de cluster ganha de graça. ## "Valor real, não recheio" é uma afirmação testável, não uma vibe A versão genérica desse conselho diz "adicione profundidade e contexto, não repita informação comumente disponível". Verdadeiro, mas inútil sem uma forma de verificar isso. Aqui está meu teste real, rodado em escala de verdade: tenho 384 posts em inglês. Cada um é traduzido para outros 12 idiomas por [um agente que construí exatamente para isso](/how-to-translate-one-blog-post-into-13-languages-with-one-agent/). Tradução é barata — todo o backlog de 341 posts custou cerca de US$ 1,70 em chamadas de API no Haiku. Escrever não é. Se eu pudesse inflar volume reescrevendo levemente a mesma ideia em dez enquadramentos diferentes, esse agente me deixaria escalar duplicação com a mesma facilidade com que escala tradução. Não faço isso, porque enquadramento duplicado não sobrevive ao teste real: esta página responde a uma pergunta que nenhuma outra página do meu site já responde igualmente bem ou melhor? Esse é o filtro que importa mais do que qualquer diretriz de estilo. "Recheio" não é um problema de tom, é um problema de redundância — uma página que reafirma uma página vizinha sem adicionar um ângulo, número ou exemplo novo. Verifico isso antes de publicar perguntando se o novo post canibalizaria as citações de um já existente em vez de adicionar nova superfície de citação. Se dois posts no meu site satisfizessem igualmente bem a mesma consulta, um deles é recheio, não importa o quão bem escrito esteja. ## Sinais de confiança que eu realmente construí e medi "Confiabilidade" é o termo mais vago de todo artigo genérico de SEO, geralmente seguido por uma lista tipo "cite fontes, mostre expertise, mantenha as coisas precisas" sem nenhuma forma de verificar se algo disso realmente moveu alguma coisa. A versão concreta que eu rodo: schema markup, porque é o único sinal de confiança que um motor de IA analisa mecanicamente em vez de inferir. Detalhei [a implementação completa](/schema-markup-for-geo/) em outro post e me aprofundei em [quais tipos realmente valem a pena](/schema-markup-for-ai-engines-the-types-that-punch-above-their-weight/). A versão curta: `Article`/`BlogPosting` com um autor nomeado real e um `dateModified` honesto é a âncora de autoria; `FAQPage` e `HowTo` são os tipos de maior impacto porque entregam ao modelo uma pergunta pré-respondida ou um procedimento pré-estruturado em vez de fazê-lo inferir um a partir de prosa; schema de `Person` e `Organization` existem para que o modelo não me confunda com outra pessoa que compartilha meu nome. Nada disso é abstrato para mim — é a intervenção por trás de um resultado real. Aplicar uma sobreposição estrutural de quatro partes (bloco de TL;DR, passos numerados, seção de FAQ, citações de fontes primárias) a 41 posts-pilar que já estavam disparando Google AI Overviews levou a frequência de citação de 4 em 41 para 19 em 41 ao longo de seis semanas — [o teste completo de seis semanas está registrado aqui](/google-ai-overview-citation-case-study/). Isso não é "adicione sinais de confiança e torça". É um antes/depois medido nas minhas próprias páginas, com a ressalva que o próprio post declara claramente: só funcionou em páginas que já tinham o piso de autoridade de posicionar no top 5 organicamente. Estrutura amplifica um sinal existente; não fabrica um do nada. ## Consistência se acumula, mas "consistência" não significa atualizações constantes A afirmação genérica aqui costuma ser "atualidade importa, mas nem todo artigo precisa ser atualizado", declarada sem nenhuma cadência real associada. Aqui está a minha. Não toco na maioria dos posts depois de publicados. Mantenho sim um conjunto rotativo de posts-pilar e os atualizo a cada 6-12 meses quando os fatos subjacentes mudam — um novo modelo é lançado, o preço de uma ferramenta muda, uma estatística fica desatualizada. `dateModified` só muda quando o conteúdo realmente muda; já testei falsificar isso e não funciona — os motores enxergam através de uma data adiantada sem edição substantiva, que é exatamente o que o estudo de caso do AI Overview também constatou. O sinal de consistência que eu de fato acompanho semanalmente não é a cadência de publicação, é a cobertura de citações: rodo uma lista rastreada de consultas críticas para o negócio no ChatGPT, Perplexity e Google toda semana e registro se sou citado — [a metodologia está aqui](/how-to-measure-ai-search-traffic/). Cobertura de citações é um indicador antecipado — ela se move antes que o tráfego de referência ou o aumento de busca por marca se movam, então é o número que me diz se um cluster está de fato ganhando autoridade ao longo do tempo ou apenas parado ali. Um site que publica uma vez e some não recebe um segundo olhar dessa checagem semanal; um site que continua estendendo um cluster, sim. ## O que a avaliação em "nível de site" realmente recompensa, camada por camada Os três motores que acompanho não pesam os mesmos sinais de forma idêntica. Esta é a tabela prática que mantenho na cabeça ao decidir onde investir esforço: | Camada de qualidade | O que isso realmente parece na prática | Onde eu medi isso | | --- | --- | --- | | Profundidade temática | 20-30+ posts interligados sobre um assunto, pilar linkando para cada post do cluster e vice-versa | Cluster de Agentes de IA (29 posts), cluster "Como a X Ganha Dinheiro" (20 posts) | | Extraibilidade estrutural | Bloco de TL;DR, passos numerados, FAQ, alinhados à fraseologia real do usuário | 4/41 → 19/41 citações em AI Overview em 6 semanas | | Autoria/confiança | Autor nomeado + `dateModified` preciso + schema Person/Organization | Schema markup para GEO, detalhamento de tipos de schema | | Consistência ao longo do tempo | Rastreamento semanal de citações entre motores, não reescritas constantes | Metodologia de medição de busca com IA | O modo de falha que mais vejo em conselhos genéricos é tratar essas camadas como uma única pontuação de "qualidade" indiferenciada. Não são. Uma página pode acertar em cheio a extraibilidade estrutural e ainda perder para uma concorrente com mais profundidade temática. Uma página pode estar dentro de um cluster profundo e ainda perder uma citação específica para uma concorrente mais atualizada e com melhor schema. Saber qual camada é de fato o gargalo para uma determinada página é a maior parte do trabalho. ## Onde isso desanda — as ressalvas honestas Prefiro sinalizar os limites do que vender demais o padrão: - **Autoridade de domínio ainda é um portão.** A intervenção do AI Overview só funcionou em páginas que já estavam posicionando no top 5 organicamente. Estrutura amplificou um sinal existente; não criou autoridade a partir de uma página fria. - **Motores divergem no que recompensam.** Rodando os mesmos 50 termos-cabeça no ChatGPT e no Google, encontrei apenas cerca de 40% de sobreposição em quais fontes eram citadas — [detalhamento completo aqui](/chatgpt-search-vs-google-50-term-test/). Otimizar para "motores de busca" como um alvo único já é o enquadramento errado; você está otimizando para vários motores que concordam no básico e divergem no resto. - **Algumas categorias genuinamente não precisam de um cluster.** Um punhado das minhas páginas de melhor desempenho são verdadeiras peças avulsas. Profundidade é uma alavanca, não um requisito universal — forçar um cluster onde o espaço de consultas não sustenta um produz exatamente o conteúdo raso e inflado que todo o framework deveria evitar. ## Perguntas frequentes ### Um único artigo excelente algum dia supera um cluster medíocre? Sim, para uma consulta restrita o suficiente com baixa concorrência. Mas para qualquer termo-cabeça com concorrência real, as páginas que sustentam sua posição a longo prazo quase sempre têm um cluster por trás. Já observei posts isolados dispararem e sumirem de um jeito que posts em cluster não fazem. ### Quantos posts um tema precisa antes de contar como um cluster de verdade? Não há um número fixo, mas nos meus próprios dados o efeito se torna claramente visível em algum ponto ao redor de 8-10 posts genuinamente distintos sobre subtemas do mesmo assunto — o suficiente para que o pilar possa linkar para fora de forma significativa e cada post do cluster tenha para onde mandar leitores que precisam de mais profundidade. ### Schema markup é realmente necessário, ou boa escrita basta? Boa escrita é necessária, mas não suficiente especificamente para citação por motor de IA. Motores extraem fatos estruturados de forma mais confiável de schema `FAQPage` e `HowTo` do que de prosa isolada, porque o schema remove a etapa de inferência. Já medi aumentos de citação de um dígito a meados de dois dígitos percentuais ao adicioná-lo a posts antes sem schema. ### Com que frequência devo atualizar conteúdo antigo em vez de publicar posts novos? Atualizo posts-pilar a cada 6-12 meses quando um fato real muda, e nunca adianto o `dateModified` sem uma edição substantiva. A maior parte do meu orçamento de conteúdo vai para posts novos que estendem clusters, não reescritas — atualidade importa, mas não é a alavanca dominante comparada à profundidade temática e à estrutura. ### Qual é a única coisa de maior alavancagem para consertar primeiro? Se uma página já posiciona razoavelmente bem organicamente mas não está sendo citada por motores de IA, adicione um bloco de TL;DR limpo que responda diretamente à consulta-cabeça. No meu próprio teste de seis semanas, essa foi de longe a maior alavanca individual — maior que schema de FAQ, maior que citações de fontes primárias, maior que passos numerados. ## A conclusão A avaliação de qualidade de conteúdo mudou da página para o site, e os sinais em nível de site que realmente movem a agulha são mensuráveis, não místicos: profundidade de cluster que você pode contar, sobreposições estruturais que você pode testar em A/B, schema que você pode validar, e um número de cobertura de citações que você pode acompanhar semanalmente. Nada disso exige adivinhar o que um algoritmo "quer". Exige publicar dentro de uma estrutura temática real, dar aos motores uma resposta limpa e extraível em vez de fazê-los inferir uma, e checar o resultado com frequência suficiente para saber se está funcionando. Eu rodo essas quatro disciplinas neste site toda semana, e os números acima são o que elas realmente produziram — não o que um guia genérico afirma que deveriam produzir. --- ## Claude vs ChatGPT para Negócios em 2026: A Visão Honesta de um Operador Source: https://alejandrorioja.com/pt/claude-vs-chatgpt-for-business-2026/ Published: 2026-07-18 Tags: AI Agents, Productivity TL;DR: Claude ganha na construção de agentes, trabalho com contextos longos, programação e qualquer coisa que rode em produção em escala. ChatGPT ganha em integrações para consumidor, modo de voz e o ecossistema de plugins mais amplo se o seu fluxo de trabalho vive na interface de chat. Se você está construindo workflows automatizados ou agentes de IA, Claude é a melhor base. Se você quer um assistente de chat capaz com mais conexões de terceiros, ChatGPT tem vantagem. Para a maioria dos empreendedores, a pergunta real é: você está conversando com IA ou construindo com IA? Essa resposta determina a ferramenta. ## Índice _Publicado julho 2026._ **TL;DR:** Claude ganha na construção de agentes, trabalho com contextos longos, programação e qualquer coisa que rode em produção em escala. ChatGPT ganha em integrações para consumidor, modo de voz e o ecossistema de plugins mais amplo se o seu fluxo de trabalho vive na interface de chat. Se você está construindo workflows automatizados ou agentes de IA, Claude é a melhor base. Se você quer um assistente de chat capaz com mais conexões de terceiros, ChatGPT tem vantagem. Para a maioria dos empreendedores, a pergunta real é: você está conversando com IA ou construindo com IA? Essa resposta determina a ferramenta. **[Perspectiva do operador]** Gerencio dois negócios — uma marca de consultoria e a Pickleland, uma instalação de pickleball em Pflugerville, TX — com mais de 30 agentes de IA em produção gerenciando respostas em redes sociais, promoção de eventos, acompanhamento de reservas, rascunhos de newsletter e muito mais. Todo meu stack de agentes é construído sobre o [Claude](/recommends/claude). Também usei o ChatGPT o suficiente para saber onde cada um falha. Isso não é uma análise de benchmarks. É a visão de um profissional. ## A pergunta que realmente importa A maioria das comparações pergunta "qual modelo é mais inteligente?" Essa é a pergunta errada para uso empresarial. A pergunta certa é: **o que você está construindo e o que ele precisa fazer de forma confiável em escala?** Um gerente de marketing que quer que a IA ajude a redigir conteúdo tem requisitos diferentes dos de um fundador construindo um pipeline automatizado de qualificação de leads. Um solopreneur usando IA para se preparar para reuniões tem necessidades diferentes das de um operador construindo agentes que processam 500 solicitações de clientes por semana. A ferramenta que ganha para um geralmente é errada para o outro. Essa perspectiva determina tudo que se segue. ## Onde o Claude ganha ### 1. Trabalho com contextos longos A janela de contexto nativa do Claude — 200K tokens — lida com coisas que quebram outros modelos. Regularmente passo históricos completos de conversas de clientes, rascunhos de contratos inteiros ou resumos de pesquisas multi-documento para o Claude e peço que sintetize ou faça referência cruzada. Ele mantém o fio. Modelos concorrentes tecnicamente suportam contextos longos agora, mas a degradação prática em tarefas complexas ainda é pior que a do Claude. Para tarefas empresariais que envolvem leitura de documentos longos, análise de exportações de dados densas ou manutenção de coerência em workflows longos, o Claude tem vantagem genuína. ### 2. Comportamento de agente em produção Quando você executa o Claude como agente — chamando ferramentas, tomando decisões em loop, escrevendo em bancos de dados, lidando com erros — ele se comporta de forma mais consistente do que o ChatGPT na minha experiência. Segue as instruções do system prompt de forma mais confiável, produz outputs estruturados mais fáceis de parsear e tem menos probabilidade de desviar da tarefa quando o contexto cresce. Isso importa enormemente para agentes. Um modelo que segue seu system prompt 95% do tempo versus 99% do tempo parece similar. Com 500 chamadas por dia, são 25 casos de desvio por dia para detectar e limpar. O artigo que escrevi sobre [como escrever system prompts para agentes de IA que não falham em produção](/how-to-write-ai-agent-system-prompts-that-dont-fail-in-production/) cobre isso em detalhes, mas a versão curta é: o seguimento de instruções do Claude no nível do system prompt é o melhor que testei. ### 3. Programação e trabalho técnico Construo quase tudo em TypeScript no Cloudflare Workers. Claude Code é minha ferramenta de desenvolvimento diária — e é genuinamente útil em vez de apenas "bom o suficiente". Para questões de arquitetura, depuração, refatoração e escrita de lógica de agentes do zero, o Claude supera consistentemente o que usei no equivalente do ChatGPT. Isso não é apenas uma comparação Claude Code versus ChatGPT Chat. Mesmo o Claude Opus 4.8 puro via API escreve código mais limpo com menos imports alucinados do que o equivalente GPT-4o nas mesmas tarefas. ### 4. Experiência do desenvolvedor na API Se você está construindo com a API — não apenas conversando — a experiência do desenvolvedor do Claude é melhor em 2026. O Anthropic SDK é limpo, o endpoint de contagem de tokens é genuinamente útil para estimativa de custos, o cache de prompts está bem implementado e economiza dinheiro real em contextos repetidos, e o tratamento de erros é previsível. Para qualquer pessoa construindo agentes programaticamente, a diferença de qualidade de API importa. Não é grande, mas é consistente. ### 5. Fidelidade de instruções em prompts complexos O Claude lida com system prompts nuançados com múltiplas condições melhor do que o ChatGPT. Quando preciso que um agente siga um conjunto de regras — "se o comentário for uma pergunta, faça X; se for uma reclamação, faça Y; se mencionar concorrentes, sinalize para revisão humana" — o Claude analisa e aplica essas ramificações de forma mais consistente. Para prompts simples, a diferença é mínima. Para lógica condicional complexa embutida em um system prompt, o Claude é mais confiável. ## Onde o ChatGPT ganha ### 1. Integrações para consumidor e plugins O ecossistema de plugins do ChatGPT e a gama de ferramentas disponíveis através da interface nativa são mais amplos. Se o seu fluxo de trabalho já vive em ferramentas que têm integrações nativas com o ChatGPT — certos CRMs, apps de produtividade, ferramentas de pesquisa — e você trabalha principalmente através de uma interface de chat, as conexões out-of-the-box do ChatGPT economizam atrito. Para usuários avançados que querem fazer tudo a partir da interface de chat sem construir integrações personalizadas, isso importa. ### 2. Modo de voz O Advanced Voice Mode do ChatGPT é genuinamente excelente. Para uso móvel, desenvolver ideias verbalmente ou se preparar para chamadas enquanto dirige, é a melhor interface de voz de IA que usei. O Claude tem entrada de voz, mas nada comparável ao modo de voz conversacional completo do GPT-4o em meados de 2026. Se voz é uma interface principal para o seu caso de uso, o ChatGPT ganha claramente. ### 3. Geração de imagens (via DALL-E) O ChatGPT Plus inclui geração de imagens via DALL-E na mesma assinatura. O Claude não gera imagens nativamente. Se você quer uma única ferramenta para trabalho de texto e imagem sem adicionar Midjourney ou outro serviço, o ChatGPT tem vantagem. ### 4. Familiaridade e adoção Mais pessoas usaram o ChatGPT. Se você está introduzindo ferramentas de IA para uma equipe sem nenhuma experiência em IA, começar com o ChatGPT tem menor atrito — a maioria das pessoas o abriu pelo menos uma vez. Isso não é uma vantagem de capacidade, mas a velocidade de integração é um fator operacional real. ## Comparação de custos É aqui que as coisas ficam nuançadas, e onde a maioria das comparações engana. Ambas as plataformas têm precificação em camadas. No nível de API: - **Claude Haiku 4.5** e **GPT-4o mini** são os cavalos de batalha econômicos para tarefas simples de alto volume. São comparáveis em faixa de preço, com a escolha principalmente orientada pelos requisitos da tarefa. - **Claude Sonnet/Opus** e **GPT-4o** são a camada média a alta. O Claude tem [cache de prompts](/prompt-caching-cut-your-claude-costs-without-switching-models/) que reduz significativamente os custos em workflows com contexto repetido — se seus agentes reutilizam o mesmo system prompt e janela de contexto entre chamadas, o preço em cache do Claude pode ser 50–80% mais barato que a taxa sem cache. O ChatGPT não tem equivalente direto. - No nível mais alto, Claude Fable 5 e as últimas variantes do GPT-4 estão na mesma faixa de custo bruto, mas a diferença de tokenizador importa — o Fable 5 tem um tokenizador que conta tokens de forma diferente dos modelos anteriores, então contagens de tokens de referência não se traduzem diretamente. Conclusão sobre custos: **para agentes em produção com alto volume de chamadas, o cache de prompts do Claude o torna materialmente mais barato** em cargas de trabalho que reutilizam contexto. Para pagamento puro por chamada em contextos frescos, estão próximos o suficiente para que o desempenho deva orientar a escolha, não o preço de lista. O framework que uso para avaliar isso está no [artigo sobre matemática de custos de agentes de IA](/ai-agent-cost-math-when-haiku-beats-sonnet/). ## A matriz de decisão | Caso de uso | Vencedor | |---|---| | Construção de agentes de IA em produção | Claude | | Programação complexa e arquitetura | Claude | | Análise de documentos com contexto longo | Claude | | Assistente de chat com integrações de plugins | ChatGPT | | Workflows com voz como interface principal | ChatGPT | | Imagens + texto em uma interface | ChatGPT | | Automação orientada por API em escala | Claude | | Integração de equipe sem experiência em IA | ChatGPT | | Agentes voltados ao cliente em produção | Claude | | Eficiência de custo em pipelines de alto volume | Claude (com cache) | ## Minha resposta real Uso o [Claude](/recommends/claude) para tudo em produção. Não porque ganha em todos os benchmarks — não ganha — mas porque: 1. Meus agentes seguem as instruções do system prompt de forma suficientemente confiável para que eu passe quase nenhum tempo limpando outputs alucinados ou fora de tarefa. 2. O stack Cloudflare Workers + Claude API custa menos de $100/mês para minha carga de trabalho combinada, e o cache de prompts reduziu os custos nos meus workflows mais pesados em mais da metade. 3. O Claude Code tornou-se minha interface de programação principal, e ter o mesmo modelo disponível tanto para desenvolvimento quanto para produção simplifica o modelo mental. 4. Para tarefas com contexto longo — ler PDFs, sintetizar entre documentos, manter coerência em workflows de múltiplas etapas — o Claude gerencia a janela completa de 200K melhor do que experimentei em outros lugares. Se eu gerenciasse uma equipe que precisa de ferramentas assistidas por IA sem construir nenhuma infraestrutura personalizada, provavelmente os colocaria no ChatGPT Plus — a amplitude de plugins out-of-the-box e o modo de voz são genuinamente úteis no nível de consumidor. Mas para construir coisas em vez de apenas usá-las, o Claude é a base certa. ## Perguntas frequentes ### O Claude é mais inteligente que o ChatGPT? Nenhum é universalmente mais inteligente. O Claude é melhor em raciocínio com contextos longos, seguimento de instruções e programação. O ChatGPT (GPT-4o) é melhor em tarefas multimodais envolvendo imagens e voz. Benchmarks específicos alternam entre eles a cada lançamento de modelo. A pergunta mais útil é qual modelo é melhor para a sua tarefa específica. ### Posso usar tanto o Claude quanto o ChatGPT? Sim, e para alguns workflows você pode querer isso. A API do Claude e a API da OpenAI são ambas simples de integrar. Algumas equipes usam o Claude para backends de agentes e o ChatGPT para interfaces de chat voltadas ao usuário com integrações. Dito isso, executar dois provedores de IA adiciona complexidade operacional — gerenciamento de credenciais, rastreamento de custos, diferenças de comportamento a gerenciar. Comece com um. ### Qual é melhor para criação de conteúdo? Claude, na minha experiência. Produz outputs que soam menos genéricos, mantém um estilo específico melhor quando recebe exemplos e lida com conteúdo de formato longo de forma mais coerente. Para conteúdo social curto ou e-mails onde qualquer um funcionaria, a diferença é pequena. ### O Claude tem um nível gratuito? Sim — Claude.ai tem um nível gratuito com limites de mensagens. [As assinaturas Claude Pro e Max](/recommends/claude) removem os limites e adicionam acesso prioritário, upload de arquivos e a janela de contexto completa. O ChatGPT similarmente tem um nível gratuito com acesso ao GPT-4o limitado por uso. ### Devo mudar do ChatGPT para o Claude? Se você usa IA principalmente como interface de chat e está satisfeito com o ChatGPT, o custo de mudança pode não valer a pena a menos que você tenha uma necessidade específica que o Claude atende melhor. Se você está construindo automações, agentes ou fazendo trabalho de programação, eu recomendaria fortemente experimentar o Claude — o comportamento do agente e a experiência do desenvolvedor fazem uma diferença significativa para cargas de trabalho em produção. --- ## Como construir um serviço produtizado: meu framework para transformar expertise em receita escalável Source: https://alejandrorioja.com/pt/productized-service-how-to-package-your-expertise/ Published: 2026-07-16 Tags: Entrepreneurship, Marketing TL;DR: Um serviço produtizado é uma oferta de escopo fixo e preço fixo que você entrega da mesma forma todas as vezes. Quatro passos: encontre o trabalho que os clientes já contratam repetidamente, defina o limite de escopo com firmeza, precifique pelo valor do resultado (não pelas horas), e construa o sistema de entrega antes de vender para o próximo cliente. A maioria dos consultores pula o quarto passo e fica presa trocando tempo por dinheiro. Esse é o único passo que realmente cria escala. ## Índice _Publicado em julho de 2026._ **TL;DR:** Um serviço produtizado é uma oferta de escopo fixo e preço fixo que você entrega da mesma forma todas as vezes. Quatro passos: encontre o trabalho que os clientes já contratam repetidamente, defina o limite de escopo com firmeza, precifique pelo valor do resultado (não pelas horas), e construa o sistema de entrega antes de vender para o próximo cliente. A maioria dos consultores pula o quarto passo e fica presa trocando tempo por dinheiro. Esse é o único passo que realmente cria escala. **[Nota do operador]** Passei anos fazendo consultorias personalizadas — cada uma com escopo diferente, preço diferente, entrega diferente. O resultado foi um negócio que exigia minha atenção direta em cada projeto. A produtização mudou isso: transformar meu trabalho mais solicitado em ofertas definidas com entregáveis claros, preços fixos e um manual de entrega repetível. Aqui está o framework exato e os erros que cometi ao construí-lo. ## O que é realmente um serviço produtizado Um serviço produtizado não é uma retainer. Não é uma assinatura. É uma oferta definida e repetível com escopo fixo, preço fixo e um processo de entrega documentado o suficiente para funcionar da mesma forma todas as vezes. O contraste com a consultoria personalizada: em vez de "fazemos estratégia de automação de IA por $X–Y dependendo do escopo," você vende "um roadmap de automação de IA: uma auditoria escrita de 5 fluxos de trabalho, recomendações de build priorizadas e uma chamada de entrega de 30 minutos, por $2.500." Escopo fixo. Preço fixo. Cronograma fixo. A única variável é se o cliente diz sim. A diferença de uma retainer é que é baseado em projeto. Início claro. Fim claro. Sem faturamento mensal em aberto, sem desvio de escopo, sem conversas de "você pode dar uma olhada nisso também?" depois do fato. O que o torna escalável: o sistema, não a oferta. Uma oferta de preço fixo é apenas trabalho personalizado com preço renegociado. Um serviço produtizado tem um manual de entrega por trás. ## Passo 1: Encontre o que os clientes já contratam de você O serviço produtizado mais fácil de construir é o que você já entrega repetidamente mas trata como trabalho personalizado cada vez. Percorra seus últimos 10–15 clientes ou projetos e procure padrões: - Qual problema aparece com mais frequência? - Qual entregável você produz com mais frequência? - Qual tipo de projeto corre mais tranquilo e recebe melhor feedback dos clientes? Para mim, o padrão era claro: os clientes continuavam pedindo a mesma coisa — ajuda para mapear seus processos, escolher quais automatizar e selecionar as ferramentas certas para o build. Eu fazia repetidamente mas com escopo diferente cada vez. Esse padrão é seu ponto de partida. Não um novo serviço que você acha que o mercado precisa. O que você já está fazendo. Um filtro: produtize apenas trabalho onde o resultado é em grande parte o mesmo para todos os clientes. Se cada cliente recebe um entregável completamente diferente, o trabalho ainda não é produtizável — ainda é genuinamente personalizado. Tudo bem; significa apenas que o trabalho de definição vem primeiro. ## Passo 2: Defina os limites de escopo — e mantenha-os É aqui que a maioria dos consultores falha. Definem a oferta vagamente, deixam o escopo aberto à interpretação e acabam nas mesmas conversas de desvio de escopo de antes. Um serviço produtizado requer limites de escopo firmes. Você define o que está incluído e o que não está, por escrito, antes da primeira chamada de vendas. Exemplo de definição de escopo para um sprint de estratégia de automação de IA: **Incluído:** - Chamada de intake estruturada de 60 minutos - Auditoria escrita de até 5 fluxos de trabalho - Roadmap de automação priorizado com recomendações de ferramentas - Avaliação de build vs. compra para os 3 principais candidatos - Chamada de entrega de 30 minutos **Não incluído:** - Implementação (construção de agentes ou integrações) - Revisões após a entrega - Mais de 5 fluxos de trabalho - Trabalho fora do escopo de automação acordado A lista "não incluído" importa tanto quanto a lista "incluído." Quando um cliente pede algo fora dos limites, você tem duas escolhas: dizer que está fora desta oferta, ou criar um add-on com escopo e preço próprios. O que você não faz é absorvê-lo. Isso parece desconfortável no início. Você está acostumado a dizer sim para manter os clientes satisfeitos. A produtização exige dizer "isso é um projeto separado" — e cumprir isso de forma consistente. ## Passo 3: Precifique pelo valor do resultado, não pelas suas horas Cobrança por hora e serviços produtizados não se misturam. No momento em que você começa a calcular com base no seu tempo, você voltou a fazer trabalho personalizado. Três variáveis para precificar uma oferta produtizada: 1. **O custo do cliente de não resolver o problema.** Um roadmap de automação de IA que libera $4.000/mês em eficiência operacional vale milhares para o comprador. Suas 8 horas de trabalho são a âncora de preço errada. 2. **O que os compradores gastam em resultados comparáveis.** Não o que os concorrentes cobram — o que os clientes realmente gastam em resultados similares com consultores, executivos fracionados ou software que resolve parcialmente o problema. Isso define seu teto. 3. **Seu piso mínimo.** O que você precisa ganhar nesta oferta para valer a pena sua atenção, considerando tempo de entrega, gestão de clientes e despesas gerais? Isso define seu piso. Defina seu preço nessa faixa. Para ofertas produtizadas iniciais, comece no meio. À medida que coleta depoimentos e refina a velocidade de entrega, mova-se em direção ao teto. Não dê descontos. Se alguém não pode pagar pela oferta, não é o cliente certo para ela. Você pode construir uma oferta de menor preço para um segmento diferente — mas não dilua a oferta principal com descontos ad-hoc, ou você voltará aos preços personalizados. ## Passo 4: Construa o sistema de entrega antes da próxima venda Este passo é o que determina se você tem um serviço produtizado ou apenas um projeto de preço fixo. Após sua primeira entrega — antes de vender para o próximo — faça isso: 1. **Documente cada passo em ordem.** Não um esboço vago. Uma checklist detalhada o suficiente para que alguém familiarizado com o domínio possa executar 80% do processo a partir dela. Mantenho essas no [Notion](/recommends/notion) — uma página por etapa do fluxo de trabalho, com templates, exemplos de resultados e árvores de decisão para os julgamentos difíceis. 2. **Identifique o que demorou mais do que deveria.** Toda primeira entrega é mais lenta do que precisa ser. Encontre os gargalos e sistematize-os: formulários de intake, templates de entregáveis, frameworks pré-construídos. 3. **Construa o processo de intake estruturado.** Obter as informações do cliente em um formulário padronizado antes da chamada é o que torna a entrega previsível. A chamada é para perguntas de esclarecimento, não coleta de informações. 4. **Crie o template de entregável.** Cada cliente recebe a mesma estrutura de saída. O conteúdo varia; a estrutura não. Isso torna a entrega rápida e o resultado consistente e profissional todas as vezes. Se você pular este passo e apenas vender o próximo, ainda está fazendo trabalho personalizado — você apenas deu um preço fixo a ele. O sistema é o que o torna realmente escalável. ## O que a produtização realmente desbloqueia O principal benefício não é maior receita. É melhor receita: demanda previsível, entrega mais rápida, menos conversas de negociação e a capacidade de dizer não a clientes que querem algo fora da oferta. Um segundo benefício: a documentação de entrega se torna propriedade intelectual. O manual que você constrói para uma oferta de consultoria produtizada é a maior parte do conteúdo de um curso ou programa de treinamento. Fiz isso com consultoria de automação de IA — o manual de entrega se tornou diretamente a espinha dorsal do currículo do meu curso AI Agents for Beginners. Um terceiro benefício: alavancagem. Com um sistema documentado, você pode treinar alguém para executar partes da entrega — a auditoria, a pesquisa, a redação de documentos — enquanto você se concentra nas chamadas de intake e entrega. Esse é o começo de sair da esteira um-por-um de tempo por dinheiro. ## As ferramentas que uso para gerenciar ofertas produtizadas **[Airtable](/recommends/airtable)** — uma linha por projeto de cliente, rastreando status, links de entregáveis e pagamentos. Escala de um a cinquenta clientes sem complexidade. **[Notion](/recommends/notion)** — manuais de entrega e workspaces orientados ao cliente. Cada cliente recebe um workspace compartilhado do Notion construído a partir de um template que foi refinado ao longo de entregas repetidas. **[ConvertKit](/recommends/convertkit)** — gerenciamento de lista de espera e sequências de acompanhamento. Quando uma oferta está completa (a capacidade se preenche rápido com trabalho de escopo fixo), uma sequência de lista de espera mantém leads quentes engajados até a próxima abertura. ## Os erros mais comuns **Produtizar antes de ter entregado vezes suficientes.** Se você não fez esse trabalho 3–5 vezes, ainda não conhece o escopo real. Entregue como trabalho personalizado primeiro. Aprenda onde estão os limites. Então defina o produto. **Deixar o escopo vago.** Um serviço produtizado com escopo indefinido é um projeto personalizado de preço fixo — o que é o pior dos dois mundos. Defina o que está incluído, defina o que não está, coloque por escrito e coloque na página de vendas. **Dizer sim a pedidos fora do escopo.** Quando um cliente pede mais, crie um add-on com escopo e preço próprios. Não o absorva só desta vez. **Pular o sistema de entrega.** Você não terminou após a primeira entrega. Construa o manual antes de vender o segundo. O sistema é o que faz o produto. ## Perguntas frequentes ### Com quantas ofertas produtizadas devo começar? Uma. Construa, entregue, refine o sistema, colete depoimentos, então considere uma segunda. A maioria das pessoas que lança duas ao mesmo tempo termina com dois sistemas pela metade e sem depoimentos para nenhum dos dois. ### Preciso de uma landing page antes de começar a vender? Não. Para as primeiras 5–10 vendas, um PDF de uma página ou um e-mail bem escrito é suficiente. Não deixe construir um site ser a razão pela qual você ainda não vendeu nada. ### E se um cliente quiser algo fora do escopo? Diga que é um projeto separado. Cote um add-on na hora ou agende uma conversa de escopo para isso. Não absorva no projeto atual. A disciplina de manter o escopo é o que faz o modelo funcionar. ### Como consigo o primeiro cliente? Conte para 10 pessoas que conhecem seu trabalho sobre a oferta — conversas quentes com pessoas que confiam em você ou conhecem alguém que precisa. A primeira venda quase sempre vem de uma conversa direta, não de uma landing page. Uma vez que você tem um estudo de caso, a [abordagem de vendas liderada pelo fundador](/founder-led-sales-how-to-reach-decision-makers/) começa a escalá-la. ### Posso produtizar algo que só fiz uma vez? Não. Você ainda não entende o escopo real. Entregue duas ou três vezes mais como trabalho personalizado, então formalize o que aprendeu no produto. --- **Próximos passos:** Meu [curso AI Agents for Beginners](/course/) cobre os sistemas de automação que tornam a entrega produtizada escalável. O [programa cowork](/cowork/) é para operadores que constroem negócios orientados por sistemas e querem um ambiente estruturado para fazê-lo. --- ## Estratégia de geração de leads no LinkedIn: como consigo clientes B2B sem anúncios pagos Source: https://alejandrorioja.com/pt/linkedin-lead-generation-strategy/ Published: 2026-07-14 Tags: Marketing, Growth, Entrepreneurship TL;DR: O LinkedIn é o canal gratuito com maior alavancagem para geração de leads B2B — desde que você o trate como um motor de confiança, não como um disparador em massa de prospecção fria. Otimize seu perfil como uma landing page, publique consistentemente sobre um ângulo da sua expertise e construa uma sequência de contato curta que leve com valor. O efeito composto leva 60–90 dias para ser sentido, depois funciona quase sozinho. Anúncios pagos são opcionais; um perfil bem construído e um feed de conteúdo útil não são. ## Índice _Publicado em julho de 2026._ **TL;DR:** O LinkedIn é o canal gratuito com maior alavancagem para geração de leads B2B — desde que você o trate como um motor de confiança, não como um disparador em massa de prospecção fria. Otimize seu perfil como uma landing page, publique consistentemente sobre um ângulo da sua expertise e construa uma sequência de contato curta que leve com valor. O efeito composto leva 60–90 dias para ser sentido, depois funciona quase sozinho. Anúncios pagos são opcionais; um perfil bem construído e um feed de conteúdo útil não são. **Perspectiva do operador:** Usei o LinkedIn para gerar consultas de consultoria, compradores de cursos e conversas de parceria — tudo sem publicar um único anúncio. O que funciona não é um hack ou uma ferramenta; é aparecer como alguém genuinamente útil em um espaço que seus compradores já frequentam. Este é o manual exato que uso e a ordem em que eu o executaria se estivesse começando do zero hoje. ## Por que o LinkedIn em 2026 O alcance orgânico do LinkedIn se manteve melhor do que quase qualquer outra plataforma. Uma postagem de uma pessoa com algumas centenas de seguidores relevantes ainda pode alcançar milhares de profissionais direcionados — algo que custa dinheiro real na maioria dos outros canais. O algoritmo continua recompensando conteúdo denso em expertise que gera salvamentos e compartilhamentos, não apenas curtidas. Para B2B especificamente, o LinkedIn não tem substituto credível: - Tomadores de decisão são mais acessíveis aqui do que em qualquer outra plataforma. - O sinal de intenção é profissional — as pessoas estão no "modo trabalho", não rolando sem propósito. - Um comentário ou postagem cria um registro público do seu pensamento que prospects podem encontrar semanas ou meses depois. - InMails e solicitações de conexão ainda estão entre os mecanismos de prospecção com menor custo de aquisição disponíveis. O alerta: a mesma abertura que torna o LinkedIn valioso também o enche de prospecção em massa, postagens genéricas de liderança de pensamento e pitches mal disfarçados. A barra para se destacar é baixa. A maioria das pessoas simplesmente não a ultrapassa. ## Passo 1: Corrija seu perfil antes de postar qualquer coisa Seu perfil no LinkedIn é a primeira coisa que um prospect lê quando recebe sua solicitação de conexão ou tropeça em uma postagem que você escreveu. Se ele não comunicar imediatamente a quem você ajuda e como, tudo o mais que você fizer ficará comprometido. Os quatro pontos que mais importam: 1. **Título** — Não seu cargo. A fórmula que funciona: _[O que faço] para [quem] para que possam [resultado]_. "Ajudo fundadores de SaaS B2B a fechar seus primeiros 10 contratos empresariais sem equipe de vendas" é pesquisável, específico e imediatamente auto-qualificador. 2. **Imagem de fundo** — Use-a para reforçar a mesma mensagem. Um visual limpo com seu nicho ou uma breve declaração de prova supera um gradiente genérico. 3. **Seção "Sobre"** — Escreva na primeira pessoa. Dois parágrafos curtos: o que você faz e para quem, depois um ou dois pontos de prova (clientes, resultados, conquistas — reais). Termine com um call to action claro: "Me envie uma DM se estiver tentando fazer X." 4. **Seção em destaque** — Fixe um ou dois itens: um lead magnet, sua melhor postagem, um estudo de caso, um link de agendamento. Este é espaço nobre que a maioria das pessoas deixa vazio. O teste: leia seu próprio perfil como um estranho. Em 10 segundos, eles conseguem saber o que você faz, para quem faz e o que fazer a seguir? Se não, continue editando. ## Passo 2: Publique sobre um ângulo, consistentemente O erro mais comum no LinkedIn é publicar aleatoriamente — uma dica de marketing na segunda, uma citação motivacional na quarta, um pitch de produto na sexta. O algoritmo ignora você e seu público também. O que funciona é escolher um ângulo específico da sua expertise e se apropriar dele. Publique a partir desse ângulo três a quatro vezes por semana por 90 dias. Volume e consistência superam inspiração e polimento nos estágios iniciais. ### O mix de conteúdo que gera efeito composto | Formato | Use para | Por que funciona | | --- | --- | --- | | Postagem de texto curta (3–5 linhas) | Opiniões contrárias, frameworks rápidos, lições do trabalho recente | Alto alcance, baixo esforço para consumir, gera comentários | | Postagem de lista | Detalhamentos passo a passo, comparações, ferramentas | Salvamentos e compartilhamentos; favorecida pelo algoritmo | | Postagem de história | Uma situação específica que enfrentei, o que fiz, o que aconteceu | Constrói confiança mais rápido do que qualquer outro formato | | Artigo longo | Guias aprofundados, explicações perenes | Indexado pela busca; posiciona você como expert ao longo do tempo | | Carrossel (documento) | Frameworks visuais, resumos de postagens mais longas | Maior taxa de salvamentos de todos os formatos | O índice que uso: 70% postagens curtas e listas, 20% histórias, 10% long-form ou carrosséis. As postagens longas não geram muito alcance, mas se acumulam ao longo dos meses na busca e em compartilhamentos via DM. ## Passo 3: Construa sua base de conexões intencionalmente Crescer o público certo no LinkedIn é diferente de fazê-lo crescer em tamanho. Mil seguidores que são exatamente seu comprador valem mais do que dez mil que são seus pares ou observadores aleatórios. Meus critérios de segmentação: - Tomadores de decisão nos setores que atendo - Fundadores e operadores em empresas na faixa de receita com a qual trabalho - Conexões de segundo grau de clientes e colaboradores existentes (a fonte mais quente) - Pessoas que interagem com concorrentes ou pares no meu espaço Envio 15–20 solicitações de conexão por dia, cada uma com uma nota de uma linha que deixa claro por que estou me conectando. Não um pitch — apenas contexto: "Vi seu comentário sobre [tópico], conectado com o que trabalho — feliz em me conectar." Essa nota eleva a taxa de aceitação de ~30% (genérica) para ~55–65% (específica). A nota tem no máximo duas frases. Não se conecte com todo mundo. Uma lista de conexões inflada cheia de contas desqualificadas na verdade prejudica — o algoritmo do LinkedIn distribui parcialmente suas postagens para suas conexões, então um público de baixa qualidade suprime seu alcance. ## Passo 4: Sequencie seu outreach — a abordagem de três toques Assim que alguém se conecta, o objetivo não é fazer um pitch imediatamente. É iniciar uma conversa que possa, com o tempo, levar a uma reunião. As pessoas que tratam a conexão como permissão para colar um deck de vendas envenenam cada ponto de contato subsequente. A sequência que uso: **Toque 1 (Dia 1, dentro de 24 horas após a conexão):** Envie uma mensagem de boas-vindas curta e calorosa. Mencione por que você se conectou e compartilhe um recurso útil — uma postagem, um framework, um artigo — relevante para algo que eles compartilharam. Sem pedido. Termine como uma declaração, não como uma pergunta. **Toque 2 (Dias 5–7):** Interaja genuinamente com uma das postagens deles — não apenas uma curtida, um comentário reflexivo real que adicione à conversa. Isso mantém seu nome visível no feed deles sem enviar outra DM. **Toque 3 (Dias 14–21):** Faça um follow-up via DM com um pedido suave e específico. Uma pergunta clara e fácil de responder, vinculada a algo relevante que você notou no trabalho deles. Se o timing for certo e a dor for real, é aí que as reuniões são marcadas. Se não, siga em frente — a conta está aquecida e eles conhecem seu nome. O erro que vejo constantemente: pular os toques 1 e 2 e ir direto para uma mensagem de call-to-action no momento em que alguém se conecta. Isso não é geração de leads; é um imposto sobre a reputação. ## Passo 5: Converta conversas em reuniões Uma boa conversa em DMs precisa de uma saída limpa para um convite de calendário. No momento em que alguém demonstra interesse genuíno, é quando você faz o pedido. A mensagem que converte: > "Parece que [coisa específica que disseram] é real para você. Ajudei algumas empresas em situações semelhantes — fico feliz em passar 20 minutos explicando como abordamos isso, sem pitch, só para ver se é relevante. [link de agendamento] — pegue um horário se isso for útil." Curto, de baixo compromisso, fácil de dizer sim. O link de agendamento elimina a fricção de programação que mata metade das reuniões que deveriam acontecer. ## O que não fazer Os comportamentos que fazem contas serem ignoradas, relatadas ou banidas: 1. **Solicitações de conexão em massa sem contexto** — O LinkedIn vai restringir sua conta e sua taxa de aceitação vai cair. 2. **DMs de pitch primeiro** — A primeira mensagem não é o lugar para apresentar seu produto, seu preço ou seu link de calendário. 3. **Pods de engajamento** — Engajamento falso infla métricas de vaidade e recebe penalizações algorítmicas. 4. **Postar todos os dias sem ponto de vista** — Volume sem perspectiva é ruído. Uma postagem por semana com insight real supera sete "opiniões quentes" por semana sem substância. 5. **Automatizar o outreach** — A detecção de bots do LinkedIn ficou agressiva. Ferramentas de conexão automatizadas e sequências de DM escritas por IA em escala são sinalizadas. A sequência no Passo 4 leva cerca de 30 minutos por dia e tem uma relação sinal-ruído que nenhuma ferramenta consegue igualar. ## Medindo o que realmente importa Métricas de vaidade para ignorar: impressões, visualizações de perfil, contagem de seguidores. Os números que dizem se o sistema está funcionando: - **Taxa de aceitação de conexão** — alvo de 50%+ com nota; se estiver abaixo de 30%, reescreva a nota. - **Taxa de resposta em mensagens de follow-up** — 20–30% é saudável para uma lista bem segmentada. - **DMs de entrada por mês** — pessoas entrando em contato com você por causa do seu conteúdo. Acompanhe mês a mês. - **Reuniões marcadas pelo LinkedIn por mês** — o único número que se correlaciona com receita. Acompanho isso em uma tabela simples do Notion. O objetivo nos primeiros 90 dias é atingir uma DM de entrada por semana e uma reunião marcada por mês apenas pelo LinkedIn. No terceiro mês, se o conteúdo estiver funcionando, esses números sobem sem esforço proporcionalmente maior. ## O balanço do operador O LinkedIn funciona para geração de leads B2B porque é a única rede profissional onde o alcance orgânico ainda tem peso e onde sua reputação se acumula publicamente ao longo do tempo. A mecânica é simples: um perfil que explica a quem você ajuda, conteúdo que prova que você sabe do que está falando, e uma sequência de contato que lidera com valor em vez de um pitch. Execute isso consistentemente por 90 dias e os inbounds começam a chegar. Execute por um ano e se torna uma das suas fontes mais confiáveis de conversas qualificadas — sem orçamento de anúncios. --- **Relacionado:** [Vendas lideradas pelo fundador](/founder-led-sales-how-to-reach-decision-makers/) · [Como construir uma marca pessoal](/how-to-build-a-personal-brand/) · [Estratégia de prospecção](/crafting-a-successful-outreach-strategy-in-the-world-of-digital-marketing/) --- ## Como criei o Courtlines: um SaaS de gestão de clubes, construído com o Claude Source: https://alejandrorioja.com/pt/how-i-built-courtlines-a-club-management-saas-with-claude/ Published: 2026-07-11 Tags: AI Agents, Case Study TL;DR: O Courtlines é o sistema operacional para clubes e estúdios de esportes de raquete — reservas, planos de associação, aulas, ponto de venda e eventos sob um mesmo teto com a marca do clube. Eu o construí como operador solo, tendo o Claude como parceiro de engenharia. A lição: a IA não só me fez programar mais rápido, ela mudou o tamanho do produto que uma única pessoa pode, de forma crível, lançar e operar. ## Sumário _Atualizado em julho de 2026._ **Resumo:** O Courtlines é o sistema operacional para clubes e estúdios de esportes de raquete — reservas, planos de associação, aulas, ponto de venda e eventos sob um mesmo teto com a marca do clube. Eu o construí como operador solo, tendo o Claude como parceiro de engenharia. A lição: a IA não só me fez programar mais rápido, ela mudou o tamanho do produto que uma única pessoa pode, de forma crível, lançar e operar. **[Visão do operador]** Eu opero mais de 30 agentes em produção, distribuídos entre uma marca de consultoria e a Pickleland, a instalação de pickleball que administro na região metropolitana de Austin, no Texas. Administrar uma instalação de verdade me ensinou exatamente o quão ruim é o software para clubes como o meu — então construí o software que eu gostaria de ter. Esta é a história do [Courtlines](https://courtlines.com), o que ele faz e como me apoiar no Claude permitiu que uma única pessoa construísse algo que normalmente exige uma equipe. ## Por que um clube precisa de um sistema operacional, não de um app Se você nunca administrou uma instalação esportiva, o problema de software é invisível. De fora, parece só que "as pessoas reservam quadras". Por dentro, um clube é um negócio pequeno e bagunçado, com uma dúzia de partes móveis que precisam todas concordar entre si. Um membro reserva uma quadra. Essa reserva precisa saber se ele está em um plano de associação, se tem créditos, se a quadra já está bloqueada para uma clínica, se há um professor designado e se a recepção alterou o preço manualmente. Quando ele chega, alguém registra uma lata de bolinhas no balcão — isso é ponto de venda. Ele inscreve o filho num programa infantil — isso é eventos e contas de família. Ele compra um pacote de 10 aulas — isso é um pacote de treinamento com sua própria lógica de repasse para o professor. Ele indica um amigo — isso é um funil de associação. A maioria dos clubes toca isso com três ou quatro ferramentas desconectadas, mais uma planilha, mais um grupo de mensagens. O sistema de reservas não sabe do PDV. O PDV não sabe dos planos de associação. Os números de ninguém batem no fim do mês. **O Courtlines é a resposta para "e se tudo isso fosse um único sistema?"** Não é um app de reservas com funcionalidades parafusadas por cima — é um único sistema operacional onde o calendário, os planos de associação, o caixa, os repasses de aulas e as páginas públicas de eventos são todos o mesmo dado subjacente. Essa é a tese inteira, e é o slogan no site: o sistema operacional para clubes e estúdios. ## O que o Courtlines realmente faz Em alto nível, o [Courtlines](https://courtlines.com) oferece a um clube: - **Uma grade de quadras arrastar e soltar** para a recepção — cada reserva, clínica e bloqueio em uma só tela que um administrador pode reorganizar em tempo real. - **Reservas e jogo aberto** para os membros, incluindo os casos de borda incômodos mas essenciais: reservas recorrentes, listas de espera, janelas de cancelamento e créditos. - **Planos de associação e cobrança** — planos, contas de família, logins de crianças e jovens vinculados a um responsável, e a régua de cobrança que impede a receita de vazar silenciosamente. - **Aulas** — pacotes de aulas, agendamento e repasses automatizados a professores independentes. - **Ponto de venda** — um caixa de verdade para a loja e o café, atrelado ao mesmo cadastro de cliente que tudo o mais. - **Eventos e páginas públicas** — clínicas, ligas e torneios com páginas voltadas ao público, que as pessoas conseguem encontrar e nas quais se inscrever. O objetivo de design é que a plataforma desapareça. Um clube coloca a própria marca por cima e, para os seus membros, aquilo simplesmente parece "o app do nosso clube", não "algum SaaS que a gente paga". Esse é um contraste deliberado com os incumbentes desse mercado — os CourtReserve e Skedda da vida — onde o software é a marca e o clube é o inquilino. A Pickleland é o inquilino nº 1. Eu não posso me esconder atrás de uma demonstração; a coisa tem que de fato administrar uma instalação pela qual respondo pessoalmente. Essa restrição foi o melhor gerente de produto que já tive. Você pode [conhecer a Pickleland aqui](https://pickleland.com) — é o campo de provas do mundo real, e cada aspereza que um membro encontra é um bug que eu sinto no mesmo dia. ## A parte que me surpreendeu: o que um operador solo consegue lançar hoje Aqui vai a versão honesta da história, e é a razão de eu estar escrevendo este post em vez de simplesmente lançar em silêncio. Um SaaS multitenant com cobrança, PDV, acesso baseado em papéis, repasses de aulas e um sistema público de eventos não é um projeto de fim de semana. Dez anos atrás, isso seria uma equipe de cinco a oito engenheiros financiada por seed durante um ano. É o tipo de escopo em que, gentilmente, dizem a um fundador solo para estreitar tudo a uma única funcionalidade e ir levantar dinheiro. Eu o construí como uma única pessoa, com o **Claude como meu principal parceiro de engenharia.** Não é aquele "às vezes eu pedia um trechinho de código pro ChatGPT" — quero dizer que o Claude escreveu a grande maioria do código deste sistema, trabalhando a partir de especificações e decisões de produto que são minhas. Meu trabalho deixou de ser *digitar a implementação* e passou a ser *decidir o que é verdade*: qual deve ser o modelo de dados, o que um papel tem permissão de fazer, o que significa "pronto" para uma funcionalidade e o que é seguro colocar no ar. A mudança interessante não é a velocidade, embora seja mais rápido. É o **escopo.** A IA não me transformou num desenvolvedor 2× no mesmo tamanho de produto. Ela mudou o tamanho do produto que consigo, de forma crível, construir e — igualmente importante — *operar e manter* sozinho. Uma base de código escrita por um único humano desabaria sob o próprio peso. Uma base de código em que um parceiro de IA segura o detalhe de implementação e eu seguro a arquitetura e os limites de segurança é uma coisa genuinamente diferente — e é a razão pela qual um operador solo pode hoje partir para uma categoria que antes exigia uma empresa. Eu deliberadamente não estou publicando aqui o meu manual operacional exato para o Courtlines — essa é a parte que considero uma vantagem competitiva, e prefiro que meus concorrentes sigam acreditando que isso exige uma equipe grande. Mas se você quiser ver a *mecânica* de como toco o Claude num projeto real, em detalhes, escrevi tudo sobre uma construção bem menor: um jogo mobile que lancei nas lojas de aplicativos. Veja [como criei o Quads, um jogo de tabuleiro mobile, com o Claude](/how-i-built-quads-a-mobile-board-game-with-claude/) — mesmo estilo de trabalho, nada a esconder, todas as cartas na mesa. ## Os princípios com os quais eu não abro mão Mesmo mantendo o manual em sigilo, alguns princípios valem ser declarados, porque se aplicam a qualquer um que esteja construindo software sério com IA: **O humano segura as canetas perigosas.** Existe um pequeno número de ações em que um erro é caro e difícil de reverter — mudanças de schema, deploys, qualquer coisa que toque em dinheiro ou dados de produção. Essas ficam firmemente comigo. A IA pode propô-las; não cabe a ela executá-las. Traçar essa linha com clareza é o que torna seguro dar à IA bastante liberdade em todo o resto. **Testes verdes são necessários, não suficientes.** Um fluxo de reserva que passa em todos os testes unitários ainda pode estar visivelmente quebrado num navegador real. A verificação mais importante para um produto com interface é um humano — ou um processo supervisionado — de fato clicando nela contra dados realistas. Testes são um gradiente que impede as coisas de piorarem; não são prova de que uma funcionalidade funciona. Aprendi essa lição do jeito caro, e ela mudou permanentemente como defino "pronto". **As especificações são a verdadeira interface.** A alavancagem não está no prompt engenhoso — está em manter documentos claros e atualizados sobre o que o sistema é e o que cada parte deveria fazer. O tempo gasto mantendo isso preciso se paga muitas vezes ao longo de cada sessão futura. Se você quiser a versão mais aprofundada disso, é a mesma disciplina que descrevo em [como escrever system prompts de agentes de IA que não falham em produção](/how-to-write-ai-agent-system-prompts-that-dont-fail-in-production/). **Construa a coisa com a qual você tem que conviver.** A melhor decisão isolada foi fazer o Courtlines administrar uma instalação que é minha. É fácil lançar uma demonstração que impressiona; é impossível se esconder de um software do qual os seus próprios membros dependem. Se você está construindo com IA, aponte-a para um problema que você sente na pele — o teste de realidade vale mais do que qualquer suíte de testes. ## Onde isso se encaixa com tudo o mais que estou construindo O Courtlines não existe isolado. Ele faz parte de um pequeno ecossistema de esportes de raquete que estou construindo: [The Court Scout](https://thecourtscout.com) é um diretório verificado de quadras de pickleball, feito para ser genuinamente mais preciso do que os diretórios raspados com os quais compete, e a Pickleland é a instalação carro-chefe contra a qual tudo é testado. O diretório ajuda os jogadores a encontrar quadras; o Courtlines ajuda os clubes por trás dessas quadras a de fato funcionar. O tecido que conecta tudo isso é o mesmo modelo operacional: um operador solo amplificado pela IA, tocando mais superfície do que um operador solo historicamente conseguia. O Courtlines é a expressão mais ambiciosa desse modelo até agora — uma plataforma SaaS completa que, alguns anos atrás, eu simplesmente não teria tentado sozinho. Se você administra um clube ou um estúdio de esportes de raquete e está cansado de costurar quatro ferramentas, dê uma olhada no [Courtlines](https://courtlines.com). E se você é um construtor se perguntando até onde dá para levar a IA num produto real, esse é o ponto inteiro deste post: mais longe do que você provavelmente imagina. ## Perguntas frequentes ### O que é o Courtlines? O Courtlines é um sistema operacional multitenant para clubes e estúdios de esportes de raquete — pickleball, tênis, padel e além. Ele combina reservas, planos de associação, aulas, ponto de venda e gestão de eventos em uma única plataforma com a marca do clube, para que o clube toque todo o seu negócio a partir de um único sistema em vez de quatro ferramentas desconectadas. Você pode conferir em [courtlines.com](https://courtlines.com). ### O Claude realmente escreveu a maior parte do código? Sim. O Claude foi meu principal parceiro de engenharia e escreveu a grande maioria da implementação, trabalhando a partir de especificações, arquitetura e decisões de produto que são minhas e que eu controlo. Eu seguro o schema, os deploys e a definição de "pronto"; a IA segura o detalhe de implementação. Essa divisão de trabalho é o que torna sustentável de manter um SaaS desse porte construído por uma só pessoa. ### Uma única pessoa consegue mesmo construir e operar um SaaS desse tamanho com IA? Construí-lo agora é genuinamente viável — essa é a parte surpreendente. O desafio maior é operá-lo e mantê-lo, porque uma base de código grande precisa de alguém que entenda a arquitetura mesmo quando foi uma IA que escreveu os detalhes. A chave é manter especificações claras e ser firme no pequeno número de ações de alto risco que um humano precisa segurar. Feito assim, a superfície mantível para um operador solo é muito maior do que costumava ser. ### Por que construir o seu próprio software de clube em vez de usar o CourtReserve ou o Skedda? Porque administrar a Pickleland me mostrou exatamente onde as ferramentas existentes deixam a desejar: o sistema de reservas, o caixa e os planos de associação não compartilham uma única fonte de verdade, então nada reconcilia de forma limpa. Eu queria um sistema em que tudo isso fosse o mesmo dado subjacente e em que a marca do clube — não a do fornecedor de software — fosse o que os membros veem. É essa lacuna que o Courtlines foi feito para fechar. ### Onde posso aprender como você de fato trabalha com o Claude no dia a dia? Mantenho o manual detalhado do Courtlines em sigilo por razões competitivas, mas documentei exatamente o mesmo estilo de trabalho num projeto menor e totalmente aberto — um jogo de tabuleiro mobile chamado Quads. Leia [como criei o Quads, um jogo de tabuleiro mobile, com o Claude](/how-i-built-quads-a-mobile-board-game-with-claude/) para a mecânica, ou [como decido se uma automação vale a pena ser construída](/ai-agent-roi-how-i-decide-whether-automation-worth-building/) para o raciocínio de ROI por trás de tudo que lanço. --- ## Como criei o Quads, um jogo de tabuleiro mobile, com o Claude — de um hackathon de 2 horas à App Store Source: https://alejandrorioja.com/pt/how-i-built-quads-a-mobile-board-game-with-claude/ Published: 2026-07-11 Tags: AI Agents TL;DR: O Quads é um jogo de tabuleiro mobile — uma versão limpa do clássico jogo abstrato Quarto — que começou como um hackathon de 2 horas com um amigo na Colômbia e foi lançado nas lojas de aplicativos. Esta é a versão totalmente aberta de como construo com o Claude: worktrees de agentes em paralelo, uma IA de jogo de verdade (não um LLM), design offline-first e as pegadinhas específicas que me custaram horas. ## Sumário _Atualizado em julho de 2026._ **Resumo:** O Quads é um jogo de tabuleiro mobile — uma versão limpa do clássico jogo abstrato Quarto — que começou como um hackathon de 2 horas com um amigo na Colômbia e foi lançado nas lojas de aplicativos. Esta é a versão totalmente aberta de como construo com o Claude: worktrees de agentes em paralelo, uma IA de jogo de verdade (não um LLM), design offline-first e as pegadinhas específicas que me custaram horas. **[Visão do operador]** Eu opero mais de 30 agentes em produção, distribuídos entre uma marca de consultoria e a Pickleland, minha instalação de pickleball na região metropolitana de Austin. A maior parte do que construo é software de negócio sério, no qual mantenho o manual em sigilo. O Quads é o oposto — um projeto paralelo divertido que posso te mostrar de cima a baixo. Se você quer ver exatamente como trabalho com o Claude, sem nada aparado, este é o post. Você encontra o jogo em [playquads.com](https://playquads.com). ## Começou como um hackathon de 2 horas na Colômbia A origem é quase constrangedoramente casual. Eu estava numa viagem à Colômbia, e um amigo e eu nos demos um hackathon de 2 horas: escolher algo pequeno, construir com IA, ver até onde a gente chegava. Paramos no Quarto — um jogo de estratégia abstrato lindo e pequeno, fácil de aprender e surpreendentemente profundo. Duas horas depois tínhamos um protótipo jogável, e a ideia era boa demais para deixar num laptop. O que começou como um desafio com prazo virou um app mobile de verdade, lançado no iOS e no Android. Esse arco — *protótipo de brincadeira a listagem na loja* — é a razão inteira pela qual acho este projeto digno de ser contado. A distância entre "ideia divertida" e "coisa que estranhos podem baixar" desabou, e o Quads é um estudo de caso limpo de como. Primeiro, um breve desvio sobre o nome. O jogo é uma reimplementação do **Quarto**, que é um jogo registrado como marca de propriedade da Gigamic. Então a primeiríssima decisão fora do código foi *não* chamá-lo de Quarto em nenhum lugar que um cliente fosse ver. Ele foi de Quarto (a mecânica) a alguns nomes provisórios até **Quads** — um nome que é meu para usar. Se você está reimplementando um clássico, resolva a questão da marca antes de se apaixonar por um nome. ## O que o Quads realmente é Para os não iniciados: o Quads é jogado num tabuleiro 4×4 com 16 peças únicas. Cada peça tem quatro atributos binários — alta ou baixa, escura ou clara, quadrada ou redonda, maciça ou vazada — e as 16 peças cobrem cada combinação possível exatamente uma vez. Você vence completando uma linha de quatro peças que compartilhem *qualquer um* dos atributos. A reviravolta que o torna genial: **você não escolhe a peça que coloca. Seu adversário te entrega ela.** Depois você entrega a dele. Então cada turno é um duplo dilema — você está tentando colocar a peça que recebeu sem armar uma vitória, enquanto escolhe uma peça para dar que não entregue o jogo ao seu adversário. É elegante e genuinamente difícil. O app traz quatro modos de jogar, todos totalmente offline: contra o computador em cinco níveis de dificuldade, passa-e-joga num só dispositivo, um desafio diário e um modo assíncrono de "desafie um amigo". Sem conta, sem servidor, sem login. Essa decisão offline-first guiou boa parte da engenharia, e é grande parte do motivo pelo qual uma construção solo foi tratável. ## A lógica do jogo: um conjunto inteiro de regras que sai da matemática de bits Esta é a minha parte favorita, porque é o tipo de coisa satisfatória tenha uma IA escrito ou não. Cada uma das 16 peças é apenas um inteiro de 0 a 15. Cada um dos quatro bits é um atributo. É isso — o conjunto inteiro de peças são os números de 0 a 15, porque quatro bits dão a você exatamente 16 combinações. A detecção de vitória então se torna quase trivial. Para qualquer linha de quatro peças, você mantém dois acumuladores correntes: os bits que são `1` em *todas* as peças e os bits que são `0` em *todas* as peças. Se qualquer um dos acumuladores for diferente de zero após as quatro, as peças concordam em pelo menos um atributo — isso é uma vitória. O conjunto inteiro de regras colapsa em um par de operações ANDs bit a bit. Porque a lógica são funções puras sobre inteiros — sem framework, sem UI, sem estado — ela é diretamente testável em unidade, e é trivial de estender. O Quads inclusive traz uma variante de regra da casa em que os nove quadrados 2×2 também contam como formas vencedoras, o que é um acréscimo de duas linhas em cima do mesmo truque de bits. Quando você e um parceiro de IA mantêm a lógica central assim tão limpa, adicionar uma funcionalidade é uma alegria em vez de um risco. ## O adversário de IA não é um LLM (e essa é a escolha certa) Aqui vai um momento de aprendizado que me importa: **nem toda "IA" deveria ser um modelo de linguagem grande.** O adversário do Quads é IA de jogo clássica pura, e assim deve ser. A cada turno ele toma duas decisões — onde colocar a peça que recebeu e qual peça devolver — e a dificuldade escala o quão duro ele pensa: - O **Iniciante** joga essencialmente ao acaso e vai te entregar a vitória. - Os níveis intermediários adicionam heurísticas: pegar uma vitória imediata se existir uma, e evitar presentear uma peça com a qual o adversário pode vencer, preferindo a peça que arma o menor número de ameaças futuras. - O **Mestre e o Grão-Mestre** rodam uma busca negamax limitada — busca de árvore de jogo de verdade — mas com um **orçamento de nós** rígido, para que uma jogada nunca possa travar a thread principal do telefone. No início do jogo, onde a busca perfeita é intratável, ele recorre a heurísticas rápidas; no fim do jogo, onde a árvore é pequena o bastante, ele busca de verdade. Duas coisas que valem a pena roubar daqui. Primeiro, um modelo de linguagem seria *pior* aqui — mais lento, mais caro, não determinístico e derrotável — do que cinquenta linhas de negamax. Case a ferramenta com o problema. Segundo, o orçamento de nós é a engenharia de verdade: num dispositivo móvel, "correto mas ocasionalmente trava por quatro segundos" é uma funcionalidade fracassada. Limitar a busca para que uma jogada seja sempre rápida, mesmo que ocasionalmente subótima, é a diferença entre um brinquedo e um produto. Saber *quando* recorrer a um LLM é o mesmo julgamento que aplico a toda automação — é o cerne de [como decido se uma construção de IA vale a pena](/ai-agent-roi-how-i-decide-whether-automation-worth-building/). ## Como de fato toco o Claude: agentes em paralelo em worktrees Agora a parte que mantenho em sigilo nos meus produtos maiores, mas que posso te mostrar por completo aqui. Eu não construo com uma sessão do Claude por vez. Eu rodo **várias em paralelo**, cada uma em seu próprio git worktree, em seu próprio branch. Um agente adiciona internacionalização, outro constrói o sistema de desafio diário, outro faz o modo para daltônicos, outro conecta o som — cada um isolado em sua própria cópia de trabalho para que não se atropelem, e cada um é mesclado de volta quando fica verde. O histórico git do Quads é uma parede de commits `Merge branch 'worktree-agent-…'`, que é exatamente como esse fluxo de trabalho parece visto de fora. A razão pela qual os worktrees importam é simples: agentes em paralelo editando o mesmo diretório de trabalho se atropelam instantaneamente. Dê a cada um um checkout isolado e você pode genuinamente ter quatro funcionalidades em construção ao mesmo tempo, e depois mesclá-las como quaisquer outros branches. É a mudança de maior alavancagem na forma como trabalho — passei de uma conversa, uma funcionalidade, para uma pequena frota. Se você quer a disciplina por trás dos prompts que esses agentes rodam, é a mesma que descrevo em [como escrever system prompts de agentes de IA que não falham em produção](/how-to-write-ai-agent-system-prompts-that-dont-fail-in-production/): a alavancagem está em especificações claras e atualizadas, não em fraseado engenhoso. ## A pegadinha que me custou uma hora (para que não te custe uma) Todo projeto te ensina uma lição idiota e cara. No Quads foi esta: **a ferramenta de preview nem sempre mostra o branch que você acha que ela está mostrando.** Quando você roda vários agentes em vários worktrees e visualiza o trabalho deles, o preview pode ser lançado de um diretório *diferente* daquele em que sua sessão atual está — então você tira um screenshot do app, não vê nenhuma das suas mudanças e começa a depurar uma UI "faltando" que nunca esteve faltando. A funcionalidade estava boa; o preview estava apontando para o checkout errado. Perdi tempo de verdade com isso antes de descobrir o que estava acontecendo, e anotei nas próprias notas do projeto para que o meu eu do futuro (e qualquer agente a quem eu entregue o repositório) confira o alvo do preview *antes* de depurar bugs fantasmas. A armadilha relacionada: o arquivo de configuração que define esses previews é compartilhado entre as sessões em paralelo, então dois agentes editando-o ao mesmo tempo podem silenciosamente sobrescrever as entradas um do outro. Se você vai rodar uma frota, trate a configuração compartilhada como um recurso disputado — ela vai te morder exatamente uma vez, e nunca mais se você anotar a lição. Esse hábito — capturar cada pegadinha arduamente conquistada num arquivo durável que a próxima sessão vai ler — é a espinha dorsal silenciosa de construir com IA em qualquer escala. O contexto evapora entre as sessões; as lições escritas não. ## Os truques offline-first dos quais me orgulho Como o Quads não tem backend, alguns problemas precisaram de respostas engenhosas e sem servidor: - **O desafio diário** é escolhido de forma determinística a partir do dia local do ano, então todo jogador no mundo recebe o mesmo desafio com zero coordenação de servidor. (Lição bônus: eu lancei, e imediatamente corrigi, um erro de um a mais por causa do horário de verão nessa conta de datas. Datas são sempre mais difíceis do que parecem.) - O **"desafie um amigo"** codifica um desafio em um código de texto curto — algo como `QC1-01-03-3` — protegido por um checksum, para que um erro de digitação não possa produzir um desafio válido-mas-errado. Seu amigo digita isso na própria cópia do app e joga a posição exata, inteiramente offline. Sem contas, sem matchmaking, sem servidor. - Os **previews ricos de links** são o único lugar em que usei um pouquinho de código de servidor. Quando você compartilha um link de desafio, uma única Cloudflare Pages Function renderiza tags Open Graph por código, para que o link se expanda direitinho no iMessage ou no WhatsApp. Os rastreadores sociais não rodam JavaScript, então um preview renderizado no cliente pareceria idêntico para cada link — uma pequena função resolve isso sem precisar de um backend de verdade. Nenhum desses é difícil depois que você os vê, mas cada um é um lugar onde a resposta preguiçosa é "subir um servidor e um banco de dados", e a resposta melhor é "fazer a coisa engenhosa offline". Evitar um backend por completo é a razão pela qual uma única pessoa pôde lançar e manter isto. ## Do hackathon à listagem na loja O trecho final — a parte que ninguém te conta sobre um "projeto de 2 horas" — é tudo o que existe entre "funciona no meu telefone" e "estranhos podem baixar". Internacionalização em oito idiomas de uma só varrida. Textos de loja que nunca usam o nome registrado como marca. Ferramentas de build para as lojas de aplicativos, versionamento e as limpezas de permissões específicas de cada plataforma que impedem uma revisão de loja de te barrar. Isso é sem glamour, e é onde muitos projetos paralelos morrem em silêncio. Fazer isso com o Claude não deixou a lista mais curta, mas deixou cada item barato o bastante para eu de fato terminar. Essa é a história de verdade do Quads: não que a IA escreveu um jogo de tabuleiro — muita gente consegue prototipar um — mas que ela baixou o custo da *última milha* o suficiente para que uma brincadeira de hackathon virasse um produto lançado. Se você tem uma ideia pequena engavetada, essa é a minha proposta inteira. Comece a versão de 2 horas. Você vai se surpreender com o quanto a linha de chegada se aproximou. E se você quer ver até onde na escala esse mesmo estilo de trabalho vai, eu o levei até o topo, para um SaaS multitenant completo — [como criei o Courtlines, uma plataforma de gestão de clubes, com o Claude](/how-i-built-courtlines-a-club-management-saas-with-claude/). Jogue Quads em [playquads.com](https://playquads.com). ## Perguntas frequentes ### O que é o Quads? O Quads é um jogo de tabuleiro mobile para iOS e Android — uma reimplementação limpa do clássico jogo de estratégia abstrato Quarto. Você joga num tabuleiro 4×4 com 16 peças únicas, e a reviravolta é que o seu adversário escolhe a peça que você tem que colocar. É gratuito para jogar, com modos solo, passa-e-joga, um desafio diário e desafios assíncronos. Encontre-o em [playquads.com](https://playquads.com). ### O Claude escreveu o jogo inteiro? O Claude escreveu a grande maioria do código, trabalhando a partir do design e das decisões que são minhas. Eu rodei várias sessões do Claude em paralelo, cada uma em seu próprio git worktree, construindo diferentes funcionalidades que mesclei. A lógica do jogo, o adversário de IA, a internacionalização, os sons e o sistema de desafios foram em grande parte construídos assim e revisados por mim. ### O adversário de IA dentro do jogo é movido por um LLM? Não — e deliberadamente. O adversário usa IA de jogo clássica: heurísticas nas dificuldades mais baixas e uma busca negamax limitada nos níveis mais altos, com um orçamento de nós rígido para que uma jogada nunca trave o dispositivo. Um modelo de linguagem seria mais lento, mais caro e mais fraco para este trabalho. Escolher o tipo certo de IA para o problema importa mais do que sempre recorrer ao maior modelo. ### Quanto tempo levou para construir o Quads? O primeiro protótipo jogável saiu de um hackathon de 2 horas com um amigo numa viagem à Colômbia. Transformar esse protótipo em um app polido e pronto para ser lançado em ambas as lojas de aplicativos — com internacionalização, um adversário de IA de verdade, desafios offline e conformidade com as lojas — levou consideravelmente mais tempo, mas cada passo individual foi barato o bastante com IA para que o projeto de fato chegasse à linha de chegada. ### Qual é a maior lição de construir o Quads com o Claude? Duas coisas. Primeira, rode agentes em git worktrees isolados para poder construir várias funcionalidades em paralelo sem que se atropelem. Segunda, anote cada pegadinha num arquivo durável que a próxima sessão vai ler — o contexto evapora entre as sessões, mas as lições escritas se acumulam. Para o panorama maior desse estilo de trabalho, veja [como criei o Courtlines com o Claude](/how-i-built-courtlines-a-club-management-saas-with-claude/). --- ## Como escrever prompts de sistema para agentes de IA que não falham em produção Source: https://alejandrorioja.com/pt/how-to-write-ai-agent-system-prompts-that-dont-fail-in-production/ Published: 2026-07-11 Tags: AI Agents TL;DR: Um prompt de sistema em produção tem cinco camadas: identidade (quem é o agente e o que ele não pode fazer), contexto (o que sabe sobre o ambiente), tarefa (como é o sucesso passo a passo), formato de saída (a camada mais subestimada) e casos extremos (o que fazer quando as entradas falham). A maioria dos prompts falha porque pula as camadas 4 e 5. Escreva o formato de saída antes de qualquer outra coisa — isso te obriga a ser preciso sobre o que você realmente quer. ## Sumário _Atualizado julho de 2026._ **TL;DR:** Um prompt de sistema em produção tem cinco camadas: identidade (quem é o agente e o que ele não pode fazer), contexto (o que sabe sobre o ambiente), tarefa (como é o sucesso passo a passo), formato de saída (a camada mais subestimada) e casos extremos (o que fazer quando as entradas falham). A maioria dos prompts falha porque pula as camadas 4 e 5. Escreva o formato de saída antes de qualquer outra coisa — isso te obriga a ser preciso sobre o que você realmente quer. **[Perspectiva do operador]** Eu gerencio mais de 30 agentes de IA em produção para minha marca de consultoria e a Pickleland, uma instalação de pickleball em Pflugerville, TX. Reescrevi mais prompts de sistema do que escrevi — geralmente porque a primeira versão parecia funcionar bem nos testes e depois se degradava silenciosamente em produção. Isso é o que aprendi sobre escrever prompts que duram. ## O problema do prompt de sistema que ninguém admite A maioria dos prompts de sistema para agentes é escrita em cerca de 20 minutos, testada em dois ou três exemplos e depois nunca mais tocada. O modelo é lançado. Por um tempo, funciona. Então algo muda — as entradas ficam mais bagunçadas, o modelo é atualizado, um novo caso extremo aparece — e o agente começa a produzir lixo. Silenciosamente. Em escala. O problema não é que o prompt original era ruim. É que a maioria dos prompts é escrita para demonstrar o caminho feliz. Eles são projetados para a entrada que você tinha em mente quando construiu o agente, não para a distribuição completa de entradas que o agente realmente verá. ## As cinco camadas de um prompt de sistema em produção Penso em cada prompt de sistema que escrevo em cinco camadas. Elas não precisam aparecer nesta ordem — mas todas precisam estar presentes. ### Camada 1: Identidade A identidade diz ao modelo quem ele é e quais são suas restrições operacionais. Não um personagem de jogo de papéis — uma definição funcional do que este agente faz e não faz. Uma camada de identidade sólida responde três perguntas: - De que este agente é responsável? - Do que ele NÃO é explicitamente responsável (e deve escalar ou recusar)? - Que padrões ele mantém? O escopo explícito do que NÃO está incluído é a parte que a maioria dos operadores pula. Sem ela, o modelo tentará ser útil fora de sua alçada — e é aí que as coisas dão errado. ### Camada 2: Contexto O contexto é o que o agente sabe sobre seu ambiente que não está na mensagem do usuário. Isso inclui a data e hora atuais (injetar dinamicamente — nunca confie no senso interno de tempo do modelo), estado relevante de sistemas externos e regras de negócios que não são óbvias a partir da descrição da tarefa. A maioria dos agentes que reviso está com falta de contexto. Não assuma. Injete. ### Camada 3: Tarefa A camada de tarefa descreve o que o agente faz, passo a passo. Não "ajudar clientes" — o fluxo de decisão real. Escreva-a como um fluxograma, não como uma diretiva. Fluxogramas são mais robustos porque reduzem a necessidade do modelo de inferir o que você quer em casos ambíguos. ### Camada 4: Formato de saída Esta é a camada mais subestimada e a mais responsável por falhas silenciosas. Se você não especificar o formato de saída com precisão, o modelo produzirá uma saída que parece correta para um leitor humano, mas é inconsistente o suficiente para quebrar a análise posterior. Escreva o formato de saída primeiro. Se você não consegue descrever exatamente como quer que a saída seja, você ainda não entende a tarefa bem o suficiente para automatizá-la. Para saída estruturada, especifique o esquema exato. Para saída em prosa, especifique estrutura, comprimento e restrições de tom — incluindo antipadrões explícitos. Para agentes de alto risco, uso a saída estruturada do [Claude](/recommends/claude) com um esquema JSON definido. ### Camada 5: Casos extremos A camada de casos extremos responde: o que o agente faz quando a entrada é ambígua, incompleta, no idioma errado, hostil ou claramente incorreta? Para cada caso extremo, dê ao modelo um caminho de resposta explícito. ## Como eu mantenho prompts de sistema ao longo do tempo Um prompt de sistema em produção é um documento vivo: 1. **Verificação pontual semanal.** Reviso de cinco a dez saídas aleatórias de cada agente de alto risco em relação à saída esperada. 2. **Revisão após atualização do modelo.** Cada vez que a versão do modelo subjacente muda, executo o agente contra o conjunto dourado completo do meu [framework de avaliação](/how-i-measure-whether-an-ai-agent-is-actually-working/). 3. **Registro de casos extremos.** Mantenho um registro das entradas que o agente tratou mal. Quando três ou mais entradas compartilham um padrão, adiciono uma regra explícita. 4. **Versionamento do prompt.** Cada mudança significativa recebe um comentário de versão. ## Perguntas frequentes ### Qual deve ser o comprimento de um prompt de sistema em produção? Longo o suficiente para cobrir as cinco camadas. Curto o suficiente para que você possa lê-lo em dois minutos e detectar desvios. Para a maioria dos meus agentes, isso é de 200 a 600 palavras. ### Quando devo dividir uma tarefa complexa em vários agentes em vez de um prompt longo? Quando a tarefa tem dois ou mais modos distintos que exigem contexto diferente, formatos de saída diferentes ou tratamento de erros diferente. Veja [agentes por eventos vs programados](/event-triggered-vs-scheduled-agents-which-pattern-for-which-job/) para o padrão. ### Qual é a razão mais comum para um prompt que funcionou no teste falhar em produção? As entradas de teste não eram representativas da distribuição de produção. Construa um conjunto de testes a partir do tráfego de produção real, não de entradas imaginadas. ### Como sei quando atualizar o prompt vs atualizar o código? Se o agente está produzindo o formato de saída errado, atualize o prompt. Se o agente está produzindo a saída correta, mas o sistema posterior não consegue usá-la, atualize o código. Se o agente está produzindo fatos incorretos com confiança, verifique primeiro a camada de contexto. --- ## ROI de Agentes de IA: Como Decido se uma Automação Vale a Pena Construir Source: https://alejandrorioja.com/pt/ai-agent-roi-how-i-decide-whether-automation-worth-building/ Published: 2026-07-09 Tags: AI Agents, Operations TL;DR: Antes de construir qualquer agente de IA, executo uma verificação de ROI em quatro partes: quantificar o custo manual, estimar o custo de construção, projetar o custo de execução e adicionar uma taxa de manutenção. O resultado é um período de retorno. Se ultrapassar seis meses para uma tarefa não estratégica, abandono. A maioria das ideias de agentes falha neste teste — e esse é o ponto. Construir a automação errada é pior do que não construir nada. ## Índice _Atualizado julho 2026._ **TL;DR:** Antes de construir qualquer agente de IA, executo uma verificação de ROI em quatro partes: quantificar o custo manual, estimar o custo de construção, projetar o custo de execução e adicionar uma taxa de manutenção. O resultado é um período de retorno. Se ultrapassar seis meses para uma tarefa não estratégica, abandono. A maioria das ideias de agentes falha neste teste — e esse é o ponto. Construir a automação errada é pior do que não construir nada. **[Perspectiva do operador]** Gerencio mais de 30 agentes em produção para uma marca de consultoria e Pickleland, uma instalação de pickleball em Pflugerville, TX. Abandonei pelo menos tantos agentes quanto os que lancei. Os que abandonei não eram más ideias — eram boas ideias que falharam na matemática. Este framework é o que executo antes de escrever uma única linha de código de agente. ## A pergunta que ninguém faz primeiro Todos em 2026 perguntam "como automatizo isso?" A melhor pergunta é "devo automatizar isso, e quando isso se paga?" Um agente de IA não é gratuito. Custa tempo para construir, dinheiro para executar e atenção contínua para manter. Se a automação não recupera esses custos mais rápido que a alternativa manual, você tornou sua operação mais complexa e cara — não mais eficiente. O instinto de automatizar tudo é compreensível. Os agentes são genuinamente poderosos, e a curva de capacidade é íngreme. Mas capacidade e ROI são eixos diferentes. Uma tarefa pode ser completamente automatizável e ainda assim não valer a pena automatizar. ## Passo 1: Quantificar a linha de base manual O primeiro número é quanto o processo atual custa por ano. ``` custo_manual_por_ano = (tempo_por_instância × taxa_horária × frequência_por_ano) + custo_erros_por_ano ``` **Tempo por instância** é o tempo de relógio que alguém realmente dedica — não o tempo calendário do início ao fim, que inclui espera. **Taxa horária** é o custo total de quem realiza o trabalho. Se é seu próprio tempo, use sua taxa de consultoria ou oportunidade alvo, não zero. **Frequência por ano** é quantas vezes esta tarefa realmente é executada. **Custo de erros** é o que a maioria das pessoas esquece. Exemplo real do Pickleland: enviar manualmente promoções de eventos do Facebook costumava levar 45 minutos por semana. Na minha taxa de oportunidade, isso é $45/semana ou $2.340/ano. Essa é a linha de base. ## Passo 2: Estimar o custo de construção honestamente O custo de construção é quase sempre subestimado. ``` custo_de_construção = (horas_de_dev × taxa_horária) + custo_configuração_ferramentas + horas_teste_e_iteração × taxa_horária + horas_debug_integração × taxa_horária ``` Para o promotor de eventos do Pickleland: estimei 6 horas para construir, 3 horas para testar e ajustar, 2 horas de depuração de integração. À minha taxa, isso é $990 em custo de construção. ## Passo 3: Projetar o custo de execução ``` custo_execução_por_ano = (chamadas_api_por_ano × custo_por_chamada) + custo_infraestrutura_por_ano + horas_revisão_humana × taxa_horária ``` **Chamadas de API** são as chamadas Claude/LLM mais quaisquer APIs de terceiros. Calcule isso com base em contagens reais de tokens. **Infraestrutura** no Cloudflare Workers + Queues é geralmente inferior a $5/mês para volume moderado. **Revisão humana** é o custo que as pessoas mais frequentemente esquecem. Um agente que requer que um humano revise cada saída antes de agir não está totalmente automatizado — está semi-automatizado. Para o promotor Pickleland: ~1.000 chamadas de API Claude/ano. A revisão humana soma ~$800/ano. Custo de execução total: ~$810/ano. ## Passo 4: Aplicar a taxa de manutenção Este é o fator mais subestimado em cada cálculo de ROI de agente. Os agentes quebram. Aplico uma taxa fixa de 20% do custo de construção por ano como taxa de manutenção. ``` custo_manutenção_por_ano = custo_de_construção × taxa_manutenção ``` Para o promotor Pickleland: $990 × 20% = $198/ano. ## A fórmula de retorno ``` economia_líquida_anual = custo_manual_por_ano − custo_execução_por_ano − custo_manutenção_por_ano meses_retorno = (custo_de_construção ÷ economia_líquida_anual) × 12 ``` Para o promotor de eventos Pickleland: - Custo manual: $2.340/ano - Custo de execução: $810/ano - Manutenção: $198/ano - Economia líquida anual: $1.332/ano - Custo de construção: $990 - **Retorno: 8,9 meses** Isso é limítrofe. Meu limite para automações não estratégicas é de seis meses. ## Meus limites de retorno - **Menos de 3 meses:** Construir imediatamente. Esses são raros. - **3–6 meses:** Sim firme. Essas são as automações que se acumulam. - **6–12 meses:** Construir se estrategicamente importante. Abandonar caso contrário. - **Mais de 12 meses:** Quase sempre abandonar. ## Quando NÃO automatizar O erro mais caro que vejo equipes cometerem é automatizar processos instáveis. Se o fluxo de trabalho muda a cada poucas semanas porque o próprio negócio ainda está descobrindo o que está fazendo, a automação bloqueia a versão defeituosa atual. Antes de automatizar, pergunte: este processo foi estável por pelo menos três meses? O segundo erro é automatizar tarefas de baixa frequência com altos riscos. Terceiro: não automatize para evitar uma conversa. ## A pilha de agentes que executa essas automações A maioria das automações que executo em produção está no Cloudflare Workers + Queues, com [Claude](/recommends/claude) como LLM. ## FAQ ### Que taxa horária devo usar para meu próprio tempo? Use seu custo de oportunidade. Não use zero. ### Como estimo os custos da API Claude antes de construir qualquer coisa? Use o endpoint de contagem de tokens do Claude com uma amostra representativa de entradas reais. ### O que conta como automação "estratégica"? Uma automação estratégica (1) serve diretamente os clientes de uma forma que afeta a retenção ou conversão, (2) permite uma escala de operação que você não poderia atingir manualmente, ou (3) produz dados que orientam melhores decisões. ### Devo contar o tempo que passo monitorando o agente? Sim. O tempo de monitoramento é um custo contínuo real. ### E se a tarefa for algo que simplesmente odeio fazer? Odiar uma tarefa tem um custo real. Aceito um período de retorno mais longo para tarefas que genuinamente detesto, mas não é um cheque em branco. --- ## Vendas lideradas pelo fundador: como encontrar e alcançar o comprador certo antes de montar um time Source: https://alejandrorioja.com/pt/founder-led-sales-how-to-reach-decision-makers/ Published: 2026-07-09 Tags: Entrepreneurship, Growth, Marketing TL;DR: Antes de contratar um time de vendas, você precisa provar que sabe vender. Vendas lideradas pelo fundador se resumem a três coisas: identificar a única pessoa que pode de fato dizer sim, pesquisar o suficiente para merecer uma resposta e sequenciar seus canais — e-mail para o pedido, telefone para o follow-up sensível ao tempo, LinkedIn para a apresentação calorosa. A maioria dos negócios trava não porque o pitch era fraco, mas porque caiu na caixa de entrada errada. Contorne isso e você marcará reuniões que um vendedor contratado não conseguiria. ## Índice _Publicado em julho de 2026._ **TL;DR:** Antes de contratar um time de vendas, você precisa provar que sabe vender. Vendas lideradas pelo fundador se resumem a três coisas: identificar a única pessoa que pode de fato dizer sim, pesquisar o suficiente para merecer uma resposta e sequenciar seus canais — e-mail para o pedido, telefone para o follow-up sensível ao tempo, LinkedIn para a apresentação calorosa. A maioria dos negócios trava não porque o pitch era fraco, mas porque caiu na caixa de entrada errada. Contorne isso e você marcará reuniões que um vendedor contratado não conseguiria. **[Leitura do operador]** Todo fundador que vi construir uma empresa de verdade vendeu os primeiros negócios ele mesmo — geralmente mal no começo, depois bem. Não há atalho para isso. Você não pode delegar uma dinâmica de vendas que nunca rodou, porque ainda não sabe ao que seu comprador realmente responde. Este é o processo que uso e ensino aos fundadores: como encontrar a pessoa certa, fazer pesquisa suficiente para merecer uma resposta e alcançá-la sem disparar mensagens a estranhos nem comprar uma ferramenta de scraping. ## Por que os fundadores precisam vender primeiro Você não consegue delegar uma dinâmica que nunca rodou. Se contratar um vendedor antes de ter fechado alguns negócios por conta própria, você não está escalando um processo — está terceirizando a descoberta dele e pagando um salário para aprender o que deveria ter aprendido de graça. Vendas lideradas pelo fundador não são uma fase que você tolera até poder pagar um vendedor. É como você aprende as palavras exatas que seu comprador usa, a objeção que mata nove negócios em cada dez e a frase que faz alguém se inclinar para a frente. Esse conhecimento vira o roteiro, o manual e o critério de contratação lá na frente. Pule isso e sua primeira contratação de vendas herda um chute. A boa notícia: como fundador, você tem uma vantagem injusta que um vendedor nunca terá. Você construiu a coisa. Você pode responder qualquer pergunta, ajustar o roadmap durante uma ligação e falar com uma credibilidade que nenhum estranho batendo meta consegue fingir. Seu trabalho é aparecer na frente da pessoa certa com frequência suficiente para que essa vantagem importe. ## Passo 1: identifique a única pessoa que pode dizer sim O motivo mais comum de uma abordagem falhar é chegar ao cargo errado. Sua mensagem não é rejeitada — ela é recebida por alguém que nunca teve poder para agir sobre ela, e morre em silêncio. Na maioria das empresas, três tipos de pessoas ficam entre você e um negócio: - **O defensor** — sente a dor que seu produto resolve e quer que ela seja consertada. Muitas vezes não é sênior, mas é quem vai carregar sua causa internamente. - **O comprador econômico** — controla o orçamento e pode aprovar o gasto. É quem, no fim, diz sim. - **O bloqueador / porteiro** — compras, um assistente executivo, TI ou um lugar-tenente cético cujo trabalho é filtrar ruído. Não é seu inimigo, mas também não é seu alvo. Antes de contatar qualquer pessoa, decida qual delas você está mirando e por quê. Para uma primeira reunião, você normalmente quer o defensor ou o comprador econômico — nunca um funcionário aleatório cujo nome você achou porque era fácil de achar. Chegar à pessoa errada não só desperdiça a mensagem; pode queimar a conta, porque agora seu nome está ligado a um pitch frio mal direcionado. Se você não consegue articular por que uma pessoa específica é o contato certo, ainda não está pronto para fazer a abordagem. ## Passo 2: pesquise o suficiente para merecer uma resposta Pesquisa de contato não é "achar um endereço de e-mail". É reunir contexto suficiente para que sua mensagem só pudesse ter sido escrita para aquela única pessoa. É isso que merece uma resposta numa caixa de entrada que recebe cinquenta pitches por semana. Antes de rascunhar qualquer coisa, saiba: 1. **O gatilho** — por que agora? Uma rodada de captação, uma nova contratação num cargo relevante, um lançamento de produto, uma reclamação pública, uma vaga de emprego que revela uma lacuna. Uma razão para o momento fazer sentido para *eles*. 2. **A dor específica** — não "empresas como a sua têm dificuldade com X", mas evidência de que *esta* empresa tem. 3. **O tecido conectivo** — uma conexão em comum, um cliente na área deles, algo que você notou e que um template não conseguiria fingir. Fontes públicas dão a maior parte disso sem nenhuma ferramenta especial: o próprio site da empresa e a página de carreiras, o LinkedIn, imprensa recente, participações em podcasts, teleconferências de resultados no caso de empresas de capital aberto e comunidades onde seu comprador realmente circula. Se você validou o mercado direito, já fez parte desse trabalho — veja [Como validar uma ideia de negócio antes de construí-la](/how-to-validate-a-business-idea/) para a pesquisa de demanda e concorrentes que também serve de inteligência de vendas. O teste para saber se você fez o suficiente: você conseguiria escrever as duas primeiras frases da mensagem de um jeito que *não faria sentido* enviado a nenhuma outra empresa? Se sim, você está pronto. Se sua abertura serviria para cem empresas, continue pesquisando. ## Passo 3: sequencie seus canais — e-mail, telefone, LinkedIn Não existe um único melhor canal. Existe um melhor canal para cada momento. O erro é escolher um e martelar nele. A habilidade é sequenciá-los para que cada um faça o trabalho em que é de fato bom. | Canal | Melhor uso | Risco se usado mal | | --- | --- | --- | | E-mail | O pedido principal, o follow-up detalhado, qualquer coisa que o comprador precise encaminhar internamente | Ignorado na hora se parecer um template | | Telefone | Follow-up sensível ao tempo, agendar um negócio marcado mas à deriva, uma indicação calorosa que te pediram para ligar | Parece invasivo sem contexto ou motivo prévio | | LinkedIn | Primeiro toque suave, aquecer um contato frio, manter-se visível entre e-mails | Lotado, lento, fácil de parecer igual a todo outro pitch | | Apresentação calorosa | Qualquer coisa, quando você consegue uma | A credibilidade de quem indica está em jogo — não desperdice | Uma sequência que funciona na prática: comece com um e-mail curto e específico, amarrado ao gatilho que você encontrou. Se não houver resposta, agregue valor no LinkedIn — um comentário genuíno, um recurso útil, um convite de conexão com contexto — para que seu nome não seja uma surpresa fria. Só escale para uma ligação quando houver um motivo real: um prazo, uma indicação, um negócio que ficou em silêncio depois do interesse. Uma ligação do nada, para alguém que nunca ouviu seu nome, é o jeito mais rápido de ser arquivado como spam. E prefira sempre a apresentação calorosa quando conseguir merecer uma. Uma única apresentação de alguém em quem o comprador confia rende mais que vinte e-mails frios perfeitamente construídos. Invista esforço de verdade mapeando quem na sua rede pode abrir qual porta antes de ir a frio. ## Passo 4: escreva a mensagem que é respondida Depois de merecer o direito de fazer a abordagem, mantenha a mensagem curta e facilite o sim. Pitches longos de estranhos não são lidos; são arquivados. Um bom e-mail frio faz quatro coisas em menos de 90 palavras: 1. **Nomeia o gatilho** — prova que você está prestando atenção e que isso não é um disparo em massa. 2. **Declara a dor relevante** — uma frase, enquadrada como a deles, não a sua. 3. **Faz um único pedido pequeno** — uma ligação de 15 minutos, não "vamos explorar uma parceria". 4. **Dá uma saída fácil** — "Se não for você, poderia me indicar quem cuida disso?" Eis o formato: > "Oi, Priya — vi que você acabou de abrir duas vagas no time de RevOps, o que normalmente significa que os relatórios estão ficando dolorosos mais rápido do que o quadro de pessoal consegue resolver. A gente ajuda times Série B a cortar o tempo de relatórios manuais em cerca de 60% sem arrancar o stack. Vale 15 minutos na semana que vem para ver se faz sentido? E se essa não for sua área, ficaria grato por uma indicação de quem cuida disso." Isso é específico, respeita o tempo dela e é trivialmente fácil de responder — até o "não" é útil, porque te encaminha à pessoa certa. A mesma disciplina vale para todos os canais; se você quer a mecânica mais profunda de abordagem em escala sem ser marcado ou ignorado, detalhei isso em [Como criar uma estratégia de abordagem bem-sucedida](/crafting-a-successful-outreach-strategy-in-the-world-of-digital-marketing/). ## Passo 5: prepare-se como se a reunião fosse a única que você vai ter O acesso te dá a abertura. A preparação merece o próximo passo. Fundadores lutam rotineiramente por semanas para conseguir uma reunião e então entram sem ter pensado no mundo do comprador — e o negócio morre não por falta de interesse, mas por falta de preparo. Antes de qualquer ligação, saiba responder, de bate-pronto: - Como é o dia dessa pessoa e onde meu produto se encaixa nele? - Qual é o único resultado com que ela se importa e que eu consigo mover? - Quais são as duas objeções que ela vai levantar e qual é minha resposta honesta? - Qual é o menor próximo passo que eu posso pedir se ela estiver interessada mas não pronta? Você construiu o produto, então a demo é fácil. O difícil é manter as prioridades do comprador na cabeça em vez das suas. Os fundadores que convertem abordagem em receita são os que aparecem soando como se já entendessem o negócio — porque fizeram o trabalho no Passo 2. ## Quando não fazer a abordagem Abordagem agressiva queima mais pipeline do que constrói. Pule o toque frio — ou vá mais devagar — quando: - Você não consegue nomear por que essa pessoa específica é o contato certo. - Você já fez follow-up mais de duas vezes sem resposta. (Siga em frente; o mercado é grande.) - Sua abertura funcionaria enviada para outras cem empresas. - Você estaria ligando fora do horário comercial normal ou sem contexto prévio. - O único motivo de você ter escolhido essa pessoa é que o contato dela era fácil de achar. Uma boa abordagem parece um recado relevante e bem cronometrado de alguém que fez o dever de casa. Uma abordagem ruim parece spam com segmentação melhor. A diferença está inteiramente na pesquisa e na contenção. ## O stack de vendas lideradas pelo fundador As ferramentas e os hábitos em que me apoio para isso, nenhum dos quais exige um time de vendas: - **Pesquisa:** o próprio site da empresa e a página de carreiras, o LinkedIn, imprensa recente e as comunidades onde seus compradores de fato conversam - **CRM:** qualquer coisa que você realmente vá atualizar — um quadro simples no Notion ou no Airtable ganha de um CRM corporativo que você ignora - **Sequenciamento:** um rastreador leve de quem está em cada etapa e qual é o próximo toque, para que nada fique à deriva - **E-mail:** um endereço de envio real e aquecido e mensagens em texto puro — sem imagens, sem pixels de rastreamento, nada que grite "campanha" - **Agenda:** um link de agendamento para que um "sim" vire uma reunião em um clique em vez de cinco e-mails de resposta ## O veredito do operador Você não precisa de um time de vendas para começar a vender. Você precisa saber exatamente quem pode dizer sim, pesquisar o suficiente para que sua mensagem só pudesse ter sido escrita para essa pessoa e sequenciar seus canais para que cada um faça o seu trabalho. O e-mail carrega o pedido, o LinkedIn aquece o terreno, o telefone fecha uma lacuna sensível ao tempo e uma apresentação calorosa ganha de todos eles. Faça as repetições você mesmo por tempo suficiente para aprender o que de fato funciona — e então, e só então, entregue esse manual conquistado a duras penas à sua primeira contratação. --- **Relacionados:** [Como criar uma estratégia de abordagem bem-sucedida](/crafting-a-successful-outreach-strategy-in-the-world-of-digital-marketing/) · [Como validar uma ideia de negócio](/how-to-validate-a-business-idea/) · [Guia de estratégias de marketing de crescimento](/growth-marketing-strategies-guide/) --- ## Como construir um negócio solopreneur: o guia 2026 Source: https://alejandrorioja.com/pt/how-to-build-a-solopreneur-business/ Published: 2026-07-07 Tags: Entrepreneurship, Growth TL;DR: Escolha um modelo de negócio (conteúdo, serviço, SaaS ou produtos digitais), construa uma audiência em torno de um nicho específico e, depois que o modelo principal estiver convertendo, adicione fontes de renda secundárias. A armadilha é começar os quatro ao mesmo tempo — escolha o modelo que corresponde ao que você já sabe, não o que parece mais passivo. ## Índice _Atualizado em julho de 2026._ **TL;DR:** Escolha um modelo de negócio (conteúdo, serviço, SaaS ou produtos digitais), construa uma audiência em torno de um nicho específico e, depois que o modelo principal estiver convertendo, adicione fontes de renda secundárias. A armadilha é começar os quatro ao mesmo tempo — escolha o modelo que corresponde ao que você já sabe, não o que parece mais passivo. **[Leitura do operador]** Gerenciei este site, vendi cursos e administrei receitas de afiliados por anos sem nenhum funcionário em tempo integral. Nada disso começou com um grande plano — começou com uma coisa que funcionou e, a partir daí, expansão deliberada. Este guia é o que eu gostaria de ter lido antes de tentar fazer tudo de uma vez. ## O que é realmente um negócio solopreneur Um solopreneur gerencia um negócio sozinho — sem cofundadores, sem funcionários, talvez prestadores de serviços quando o volume exige. O objetivo é um negócio que funciona com base em expertise e sistemas, não em número de pessoas. Isso é diferente do freelancing. Um freelancer vende tempo. Um solopreneur constrói sistemas que geram receita sem exigir seu tempo para cada real ganho. ## Os 4 modelos de negócio solopreneur Todo negócio unipessoal se encaixa aproximadamente em um desses: 1. **Negócio de conteúdo.** Você publica (blog, newsletter, YouTube, podcast) e monetiza por meio de anúncios, receitas de afiliados, patrocínios e produtos próprios. Menor barreira de entrada, maior tempo de crescimento. 2. **Negócio de serviços.** Você entrega um resultado específico para clientes — consultoria, papéis fracionados, serviços done-for-you. O caminho mais rápido para R$50K/mês, o menos escalável. 3. **Produtos digitais.** Cursos, templates, ebooks, ferramentas. Alta alavancagem uma vez criados, difícil gerar tráfego sem audiência existente. 4. **Micro-SaaS.** Um pequeno produto de software que resolve um problema específico. O teto mais alto, a barra técnica mais exigente. O modelo certo depende do que você já tem: habilidades, uma audiência ou capital. ## Passo 1: Escolha seu nicho com profundidade real Nichos amplos (marketing, finanças, saúde) têm tráfego, mas concorrência brutal. Nichos estreitos (ferramentas de IA para fundadores de e-commerce, finanças pessoais para novos enfermeiros) convertem melhor e ranqueiam mais rápido. O teste que uso: consigo escrever 50 peças de conteúdo genuinamente úteis sobre este tópico sem ficar sem ideias? Se sim, o nicho tem profundidade. Se estou lutando para nomear 20, é muito estreito ou não o conheço bem o suficiente. Seu nicho deve estar na interseção de: - Algo que você conhece por experiência, não apenas por pesquisa - Uma audiência com dinheiro ou tempo para gastar - Um problema que se repete, não uma solução única ## Passo 2: Construa sua audiência antes de precisar dela O maior erro que vejo: lançar um produto para uma audiência de zero. Audiência antes do produto é a regra. O que realmente funciona: 1. **Escolha um canal de distribuição e aprofunde-se nele.** Blog + SEO é lento, mas duradouro. Uma newsletter é rápida de monetizar. Vídeo curto tem um teto alto, mas é dependente do algoritmo. Não divida a atenção em quatro plataformas no primeiro ano. 2. **Publique consistentemente antes de ter algo para vender.** A audiência que você constrói enquanto não tem nada para vender confia em você quando finalmente tem. 3. **Construa uma lista de e-mail desde o primeiro dia.** Seguidores em redes sociais são terra alugada. Sua lista de e-mail é sua. Uso o [ConvertKit](/recommends/convertkit) — ele gerencia sequências e transmissões sem atrapalhar. Um referencial útil: 1.000 fãs verdadeiros (assinantes de e-mail que abrem cada e-mail) são suficientes para gerar R$500K/ano com produtos digitais. ## Passo 3: Otimize primeiro sua fonte principal de receita Quando tiver uma audiência (ou um cliente de um serviço), aposte na fonte principal de receita antes de adicionar fontes secundárias. **Para negócios de conteúdo:** receita de afiliados é o primeiro dinheiro mais rápido. Você escreve sobre ferramentas que usa, linka pela sua página de recomendações e ganha uma porcentagem. Nenhum produto para construir, nenhum suporte ao cliente. O teto é real — um site de alto tráfego em um nicho lucrativo pode ganhar R$25K–R$150K/mês — mas é o melhor mecanismo de bootstrap que encontrei. **Para negócios de serviços:** cobre mais do que se sente confortável. Subprecificação é o erro mais comum do solopreneur. Se sua taxa de fechamento é de 100%, você está muito barato. **Para produtos digitais:** mantenha o escopo restrito. Um curso focado de R$500 supera um curso extenso de R$2.500 em taxa de conversão e conclusão. **Para Micro-SaaS:** construa para uma dor que você tem pessoalmente. A vantagem da empatia é real quando você é seu próprio cliente-alvo. ## Passo 4: Empilhe fontes de receita secundárias Quando seu modelo principal estiver convertendo, adicione fontes de receita que não exijam tempo proporcional: - **Receita de afiliados** — mesmo negócios de serviços e operadores de SaaS podem ganhar receita de afiliados com seu conteúdo - **Produtos digitais** — mesmo que seja principalmente um negócio de serviços, um curso ou conjunto de templates pode ganhar enquanto você dorme - **Patrocínios** — quando sua audiência ultrapassar ~5.000 assinantes engajados - **Licenciamento** — se você construiu um sistema ou ferramenta, licencie para outros em nichos adjacentes Empilhamento é um resultado, não uma estratégia. Faça um fluxo funcionar primeiro. ## O tech stack do solopreneur Gerencio toda esta operação com seis ferramentas: | Ferramenta | O que faz | |---|---| | [Claude](/recommends/claude) | Primeiros rascunhos de conteúdo, e-mails e código | | [ConvertKit](/recommends/convertkit) | Lista de e-mail, automações e transmissões | | [Notion](/recommends/notion) | Calendário editorial, documentos de clientes e SOPs | | [Canva](/recommends/canva) | Gráficos para redes sociais e design de miniaturas | | [Airtable](/recommends/airtable) | Rastreamento de afiliados, CRM, banco de dados de conteúdo | | [SEMrush](/recommends/semrush) | Pesquisa de palavras-chave e rastreamento de posições | Custo mensal total: menos de R$1.500. Uma equipe que substituísse este stack custaria mais de R$75K por mês em salários. ## Os 3 erros que matam negócios solopreneur 1. **Escalar prematuramente.** Contratar antes que o modelo de negócio seja comprovado queima recursos e adiciona sobrecarga de gestão antes de ter receita repetível. 2. **Diversificar cedo demais.** Quatro fontes de receita funcionando pela metade ganham menos do que uma totalmente otimizada. Vá mais fundo, não mais amplo, no primeiro ano. 3. **Construir sem distribuição.** O melhor produto sem audiência não supera um produto mediano com uma lista grande e engajada. A distribuição é o fosso. ## A conclusão do operador Um negócio solopreneur é uma escolha deliberada de trocar a complexidade de uma equipe por propriedade e margem. Os negócios que vi funcionar de forma consistente compartilham o mesmo padrão: um modelo, um nicho, um canal de distribuição, mantido por tempo suficiente para se compor. Escolha o modelo que corresponde às suas habilidades existentes. Construa a audiência antes de precisar dela. Adicione fontes de receita somente depois que a principal converter. O resto é execução. --- **Relacionado:** [Como validar uma ideia de negócio](/how-to-validate-a-business-idea/) · [Como monetizar uma newsletter](/how-to-monetize-a-newsletter/) · [Como construir uma marca pessoal](/how-to-build-a-personal-brand/) --- ## Como automatizar sua pequena empresa com agentes de IA: guia prático Source: https://alejandrorioja.com/pt/how-to-automate-your-small-business-with-ai-agents/ Published: 2026-07-04 Tags: AI Agents, Entrepreneurship, Operations TL;DR: Automatizar uma pequena empresa com agentes de IA não é sobre substituir pessoas — é sobre delegar o trabalho repetitivo e baseado em regras para poder dedicar seu tempo às decisões que só você pode tomar. Comece com uma tarefa, registre tudo, mantenha humanos no loop para tudo que afete dinheiro ou clientes diretamente, e expanda a partir daí. O stack que uso em dois negócios custa menos de $100/mês no total. ## Índice _Atualizado julho 2026._ **TL;DR:** Automatizar uma pequena empresa com agentes de IA não é sobre substituir pessoas — é sobre delegar o trabalho repetitivo e baseado em regras para poder dedicar seu tempo às decisões que só você pode tomar. Comece com uma tarefa, registre tudo, mantenha humanos no loop para tudo que afete dinheiro ou clientes diretamente, e expanda a partir daí. O stack que uso em dois negócios custa menos de $100/mês no total. **Nota do operador:** Gerencio dois negócios — uma instalação de pickleball indoor de nove quadras em Pflugerville, TX (Pickleland) e uma marca de consultoria. Entre os dois, tenho mais de 30 agentes de IA em produção lidando com tudo, desde respostas a comentários em redes sociais até promoção de eventos, rascunhos de newsletter e acompanhamentos de reservas. Este é o guia sem rodeios do que realmente funciona, do que desperdiça tempo e de como começar sem contratar um desenvolvedor. O enquadramento honesto: agentes de IA para pequenas empresas não são mágica. Eles não substituem o trabalho duro das relações com clientes, da qualidade do produto ou do julgamento estratégico. O que fazem é eliminar o trabalho administrativo que consome duas a três horas do dia de cada operador — a triagem da caixa de entrada, os relatórios de copiar e colar, as respostas sociais, a formatação de dados. Isso é suficiente para fazer diferença. ## Os 4 tipos de trabalho que se automatizam bem Antes de construir qualquer coisa, mapeie sua carga de trabalho em quatro categorias. Apenas uma delas é adequada para agentes de IA. ### 1. Baseado em regras, repetitivo, texto de entrada / texto de saída Este é o ponto ideal. Classificar um e-mail de cliente, redigir uma resposta a um comentário nas redes sociais, resumir uma semana de reservas em uma lista de pontos, reformatar um CSV em um relatório. A entrada é texto; a saída é texto; as regras são consistentes. Essas tarefas se automatizam com um prompt único e um wrapper leve em torno da API. **Exemplos do Pickleland:** - Classificar e-mails de consulta de quadra (pergunta / reclamação / reserva / outro) - Redigir publicações para grupos do Facebook sobre eventos futuros - Gerar resumos semanais de ocupação do sistema de reservas ### 2. Pipelines de múltiplas etapas com transferências claras Uma tarefa que tem três etapas — buscar dados, transformá-los, enviar uma notificação — onde cada etapa tem uma entrada e saída claras. Isso funciona bem com uma camada de orquestração leve (uso Cloudflare Workers Queues). A chave é que cada etapa pode falhar de forma independente e ser repetida sem refazer todo o trabalho. **Exemplos do Pickleland:** - Nova reserva → atualização do CRM → e-mail de confirmação → notificação no Slack - Envio de formulário → classificação → rascunho de resposta direcionada → fila de revisão humana ### 3. Monitoramento e alertas Agentes que monitoram uma condição e te notificam quando ela ocorre. Estes são alguns dos agentes com melhor retorno sobre investimento porque substituem a carga cognitiva de verificar manualmente os painéis. Também estão entre os mais simples: a lógica é apenas "X está acima do limite? Se sim, alerta." **Exemplos da minha marca de consultoria:** - Alertas de anomalias do Google Analytics (queda de tráfego, pico) - Taxa de cancelamento de reserva acima da base semanal - Nova avaliação publicada — marcar para resposta humana ### 4. Primeiros rascunhos de conteúdo (não o produto final) Agentes de IA podem redigir publicações sociais, newsletters por e-mail, esboços de blog e descrições de produtos com qualidade útil. O problema: eles não podem substituir seu julgamento editorial. Cada rascunho passa por uma etapa de revisão humana. O ROI vem de começar em 70% em vez de uma tela em branco. **O que NÃO se automatiza bem:** gerenciamento de relacionamento com clientes, decisões de preços, conversas de vendas, contratações e tudo que tenha um custo real para uma pessoa real se der errado. Mantenha humanos nessas tarefas. ## O stack que realmente uso Você não precisa de software empresarial para isso. É o que alimenta minhas automações: 1. **[Claude](/recommends/claude)** — a camada de modelo para todas as tarefas de IA. Uso a API diretamente, não uma interface gráfica. A qualidade por dólar é a melhor que testei, e o [cache de prompts](/prompt-caching-cut-your-claude-costs-without-switching-models/) reduz ainda mais os custos quando os prompts do sistema se repetem. 2. **Cloudflare Workers** — onde os agentes vivem. Sem servidor, distribuído globalmente, e o nível gratuito cobre a maioria das cargas de trabalho de pequenas empresas. O handler `scheduled` executa tarefas cron; o handler `fetch` recebe webhooks para fluxos acionados por eventos. 3. **Airtable** — a espinha dorsal dos dados. Cada agente lê e escreve em tabelas do Airtable. É aqui que vivem o estado do trabalho, as filas de revisão e os dados operacionais. Não-desenvolvedores podem editar os dados sem tocar no código. 4. **Kit (antes ConvertKit)** — automação de e-mail e newsletter. Meu agente de redação de newsletter escreve em um rascunho do Kit; eu reviso e envio. Custo mensal total para 30+ agentes em dois negócios: menos de $100. O maior item é o uso da API Claude. Todo o resto é nível gratuito ou quase gratuito. ## Exemplos reais: automações do Pickleland ### O promotor de eventos Todo domingo, um agente agendado verifica o sistema de reservas em busca de eventos nos próximos quatro dias. Ele combina cada evento com os grupos locais relevantes do Facebook e redige uma publicação promocional adequada para cada um. Os rascunhos vão para uma tabela de revisão do Airtable. Passo cinco minutos revisando e clicando em "Aprovar" — o agente faz os 40 minutos de redação. Nada é publicado automaticamente sem minha aprovação. Este é o [padrão de agente agendado](/event-triggered-vs-scheduled-agents-which-pattern-for-which-job/) — executa em um cronograma, faz trabalho em lote e apresenta rascunhos para revisão humana. ### O classificador de comentários sociais Quando um novo comentário chega em uma publicação monitorada do Facebook, um webhook é acionado e o agente classifica a intenção: pergunta, reclamação, elogio ou spam. Para perguntas e reclamações acima de um limite de confiança, ele redige uma resposta e a marca para revisão. Elogios são registrados. Spam é suprimido. Um ciclo de 30 segundos do comentário ao rascunho. Sem o agente, cada comentário era uma troca de contexto manual; agora a fila de respostas pré-redigidas leva cinco minutos em vez de trinta. Este é o [padrão de agente acionado por evento](/event-triggered-vs-scheduled-agents-which-pattern-for-which-job/) — acionado por webhook, deve responder rapidamente. ### O resumo operacional semanal Toda segunda-feira de manhã, um agente puxa os dados de reserva da semana anterior, a taxa de cancelamento, a ocupação por tipo de quadra e quaisquer anomalias sinalizadas. Ele formata um resumo de cinco pontos e o deposita em uma página do Notion. Leio com meu café e tenho o contexto operacional de que preciso para a semana em dois minutos em vez de vinte. ## Por onde começar: 4 passos ### Passo 1: Escolha a tarefa repetitiva de maior fricção que você faz toda semana Não a mais glamorosa, não a mais estratégica — aquela que mais te pesa. O relatório semanal que você copia e cola de três fontes. As respostas sociais nas quais você passa uma hora. Os e-mails de acompanhamento que você envia um a um. Esse é o seu primeiro agente. ### Passo 2: Mapeie a tarefa em entradas e saídas Anote: - O que aciona a tarefa (um relógio, um evento, um envio de formulário) - Quais entradas ela precisa (fontes de dados, texto, contexto) - Qual é a saída (um rascunho, uma notificação, uma linha de banco de dados) - Qual é a etapa de revisão humana (cada primeiro agente deve ter uma) Se não conseguir mapear claramente, a tarefa não está bem definida o suficiente para ser automatizada. Primeiro clarifique o processo manualmente. ### Passo 3: Construa a versão mais simples possível Não um sistema. Um prompt, uma chamada de API, uma saída. Uma função TypeScript que pega a entrada, chama o Claude e retorna o rascunho. Sem banco de dados, sem webhook, sem fila — apenas a lógica central. Execute-a manualmente cinco vezes. A qualidade da saída se mantém? Se sim, você tem um agente funcionando. Então adicione a infraestrutura. ```typescript // O primeiro agente mais simples: rascunho de promo de evento async function draftEventPromo(event: PadklelandEvent, env: Env): Promise { const msg = await env.ANTHROPIC.messages.create({ model: "claude-opus-4-8", max_tokens: 400, system: `You write Facebook event promo posts for Pickleland, an indoor pickleball facility in Pflugerville, TX. Tone: friendly, local, community-focused. Max 150 words.`, messages: [ { role: "user", content: `Write a promo post for this event: ${JSON.stringify(event)}`, }, ], }); return (msg.content[0] as { text: string }).text; } ``` ### Passo 4: Adicione observabilidade antes de adicionar mais funcionalidades Registre cada execução com um ID de rastreamento. Registre a entrada, a saída e o carimbo de hora. Você não precisa de uma ferramenta sofisticada — JSON estruturado para stdout é suficiente para começar. O motivo: seu primeiro agente falhará de maneiras que você não previu. Quando isso acontecer, você precisa ver o que aconteceu sem recriar o estado da memória. Este é o hábito que separa os operadores que escalam seu stack de agentes dos que desistem depois de uma experiência ruim. Aprofundo isso em [como depurar um agente de IA em produção](/how-to-debug-an-ai-agent-in-production/). ## Erros comuns (e como evitá-los) **Automatizar antes de entender o processo.** Se você não consegue realizar a tarefa você mesmo de maneira consistente, um agente de IA apenas a fará de forma inconsistente em escala. Documente o processo manualmente primeiro, depois automatize. **Remover a etapa de revisão humana cedo demais.** Comece cada agente com um loop de revisão humana. Deixe-o rodar por duas semanas, verifique cada saída e ganhe confiança antes de permitir que qualquer coisa funcione totalmente automatizada. A exceção são ações de baixo risco e facilmente reversíveis (como escrever um rascunho em uma pasta). **Construir o sistema inteiro antes de validar o núcleo.** Construa primeiro a versão mais simples possível. Se a qualidade central não está lá com um prompt, mais infraestrutura não vai corrigir isso. **Ignorar os custos.** Os custos da API de IA escalam com o uso. Conheça seu custo por execução antes de implantar em volume. A [matemática de custos Haiku vs Sonnet](/ai-agent-cost-math-when-haiku-beats-sonnet/) importa quando você faz milhares de execuções por semana. **Tratar falhas como catástrofes.** Agentes falham. Prompts regridem. APIs ficam fora do ar. Construa lógica de nova tentativa, construa [estruturas de avaliação](/the-eval-harness-i-use-to-ship-ai-agents/) e trate as falhas como dados, não como desastres. ## A mudança de mentalidade que muda tudo O gargalo em uma pequena empresa quase nunca é dinheiro — é o tempo e a atenção do proprietário. Cada hora que você gasta em tarefas que um agente pode gerenciar é uma hora que você não dedicou a clientes, produto ou estratégia. O framework que uso: se uma tarefa pode ser escrita como um processo repetível com entradas e saídas claras, ela é candidata para um agente. Tudo que requer julgamento, relacionamento ou criatividade fica comigo. O agente cuida do primeiro para que eu possa me concentrar no segundo. Começar com agentes de IA não requer um cofundador técnico, um orçamento de software de seis dígitos ou meses de desenvolvimento. Requer escolher uma tarefa de alta fricção, construir a versão mais pequena que funcione e aprender com a saída. A maioria dos operadores encontra seu primeiro agente funcionando em um fim de semana. A partir daí, o segundo leva uma tarde. ## Perguntas frequentes ### Quanto custa executar agentes de IA para uma pequena empresa? Meu stack executa 30+ agentes por menos de $100/mês. O maior custo é o uso da API de IA (Claude). Cloudflare Workers é gratuito até 100.000 requisições/dia e $5/mês depois. Airtable tem um nível gratuito que cobre a maioria das necessidades de dados de pequenas empresas. Os custos escalam com o uso — um único agente que executa algumas vezes por semana é negligenciável. ### Preciso de um desenvolvedor para construir agentes de IA? Para os padrões básicos — um cron agendado, um handler de webhook, um prompt simples — você consegue com um pouco de JavaScript e disposição para ler documentação. Para pipelines mais complexos, orquestração e observabilidade de nível de produção, um desenvolvedor acelera o trabalho. Meu curso ([Agentes de IA para iniciantes](/ai-agents-for-beginners-cowork-codex-guide/)) ensina os caminhos sem código e de baixo código para operadores. ### Qual é o melhor primeiro agente de IA para uma pequena empresa? O resumo operacional semanal. Ele roda em um cronograma, tem entradas claras (suas fontes de dados), produz uma saída consistente (um resumo formatado) e tem risco zero negativo — se o rascunho estiver errado, você simplesmente não o lê. Ele constrói sua intuição sobre o que os agentes podem e não podem fazer sem risco para clientes ou operações. ### Qual modelo de IA devo usar para automação empresarial? Uso Claude para quase todo meu trabalho com agentes. A qualidade da API, confiabilidade e o preço favorável ao operador (especialmente com o [cache de prompts](/prompt-caching-cut-your-claude-costs-without-switching-models/)) o tornam a escolha certa para uso em produção. Para tarefas de classificação baratas e de alto volume, Claude Haiku 4.5 é rápido e econômico. Para redação e tarefas matizadas, Claude Sonnet ou Opus. ### Como evito que agentes de IA cometam erros que prejudiquem meu negócio? Três práticas: mantenha humanos no loop para tudo que afete clientes ou dinheiro diretamente; registre cada execução para poder rastrear o que deu errado; e construa uma [estrutura de avaliação](/the-eval-harness-i-use-to-ship-ai-agents/) para que mudanças em seus prompts não quebrem silenciosamente a produção. Comece com tarefas internas de baixo risco e expanda apenas depois de confiar na qualidade da saída. --- ## Como construir uma marca pessoal online: O manual do praticante 2026 Source: https://alejandrorioja.com/pt/how-to-build-a-personal-brand/ Published: 2026-07-02 Tags: Entrepreneurship, Growth TL;DR: Uma marca pessoal é construída escolhendo uma audiência específica, publicando conteúdo útil de forma consistente em um único canal e tendo um ponto de vista claro — não otimizando sua bio do LinkedIn. Afunile seu nicho, escreva a partir da experiência real, construa uma lista de e-mail como seu único canal próprio e repita até que as pessoas certas não possam mais ignorá-lo. ## Índice _Atualizado julho de 2026._ **TL;DR:** Uma marca pessoal é construída escolhendo uma audiência específica, publicando conteúdo útil de forma consistente em um único canal e tendo um ponto de vista claro — não otimizando sua bio do LinkedIn. Afunile seu nicho, escreva a partir da experiência real, construa uma lista de e-mail como seu único canal próprio e repita até que as pessoas certas não possam mais ignorá-lo. **[Nota do praticante]** Tenho construído em público através de vários negócios — Pickleland, consultoria de agentes de IA, este site — e o padrão que continuo vendo é sempre o mesmo: as pessoas que constroem marcas pessoais reconhecíveis não são as mais talentosas. São as mais específicas e as mais consistentes. Aqui está o framework que uso e recomendo. ## O que é realmente uma marca pessoal (e o que não é) Uma marca pessoal é a resposta a uma pergunta: *O que as pessoas dizem sobre você quando você não está na sala?* Não é seu logo. Não é sua paleta de cores. Não é quantos seguidores você tem. Uma marca pessoal é o atalho mental que as pessoas formam quando ouvem seu nome — o problema específico que acreditam que você pode resolver, a perspectiva que esperam que você tenha. O erro que a maioria comete: tentam criar uma marca antes de desenvolver um ponto de vista. Uma marca é o que se acumula ao fazer coisas reais e ser específico sobre o que você aprendeu — não algo que se fabrica antecipadamente. O que você pode controlar desde o início: 1. Com quem você fala 2. Qual problema você resolve para eles 3. Onde eles te encontram 4. Com que consistência você aparece O que se acumula com o tempo: - Uma reputação por um tipo específico de expertise - Uma audiência que confia no seu julgamento - Oportunidades entrantes que você não teve que perseguir ## Passo 1: Escolha o nicho mais estreito com o qual você pode viver O erro mais comum na construção de marca pessoal é ser muito amplo. "Especialista em marketing." "Consultor de negócios." "Empreendedor de tecnologia." Esses são rótulos sem sentido em um mundo onde todos os têm. Quanto mais estreito você for, mais rápido você constrói reputação. Teste seu nicho com este filtro: - **Específico o suficiente para ser pesquisável.** Alguém pode pesquisar seu nicho no Google e encontrar uma comunidade real ao redor dele? - **Específico o suficiente para ser recomendável.** Se alguém encontra uma pessoa com exatamente seu problema, eles pensam em você primeiro? - **Amplo o suficiente para produzir conteúdo por 2+ anos.** Use uma ferramenta de palavras-chave como [Semrush](/recommends/semrush) para verificar se seu nicho é pesquisado. ## Passo 2: Escolha um canal primário Tentar estar em todo lugar ao mesmo tempo é uma maneira garantida de ser medíocre em todo lugar. No início, escolha um canal e aprofunde. - **Conteúdo escrito (blog/newsletter):** Melhor para audiências analíticas e praticantes. Acumula com o tempo via SEO. - **LinkedIn:** Melhor para audiências B2B e profissionais. - **YouTube / vídeo:** Melhor para tópicos que se beneficiam de demonstração visual. - **X / Twitter:** Melhor para ideias que viajam. ## Passo 3: Encontre seu ponto de vista Conteúdo sem ponto de vista é ruído. O que separa as marcas pessoais que são citadas, recomendadas e buscadas é uma perspectiva distinta — uma opinião sobre como o mundo funciona, informada pela experiência real. Um POV forte tem estas propriedades: - É fundamentado em algo que você realmente fez, não apenas leu - Desafia pelo menos uma suposição convencional da sua audiência - É específico o suficiente para que algumas pessoas discordem ## Passo 4: Construa uma audiência própria Cada plataforma em que você constrói pode mudar seu algoritmo, banir sua conta ou fechar. O único canal de distribuição que você realmente possui é sua lista de e-mail. Comece a construí-la desde o primeiro dia. Para e-mail, uso [ConvertKit](/recommends/convertkit) — desenvolvido especificamente para newsletters de criadores. A forma mais rápida de crescer uma lista de e-mail: 1. **Crie um lead magnet genuinamente útil.** Uma checklist, template ou guia curto que resolve um problema específico. 2. **Adicione o opt-in acima da dobra em cada página de conteúdo.** 3. **Escreva uma sequência de boas-vindas de 3 e-mails.** 4. **Mencione a lista em cada peça de conteúdo.** ## Passo 5: Publique de forma consistente — a matemática dos juros compostos Se você publicar uma peça longa por semana: - **Semanas 1–8:** Quase ninguém lê. Isso é normal. - **Meses 3–4:** Algumas peças começam a receber tráfego orgânico. - **Meses 6–9:** O tráfego de busca se acumula. Consultas entrantes começam a aparecer. - **Ano 2:** Você tem 100 peças de conteúdo. Seu nome aparece em buscas e respostas de IA. Minha regra: comprometa-se por 6 meses antes de avaliar se está funcionando. ## Como penso sobre marca visual A marca visual mínima viável: - Uma foto de perfil profissional onde seu rosto é claramente visível - Uma foto de perfil consistente em todas as plataformas - Um site simples com um tagline claro e opt-in de e-mail [Canva](/recommends/canva) serve bem para gráficos sociais e design simples. ## Erros comuns 1. **Tentar agradar a todos.** Se você escreve para "empreendedores," você escreve para ninguém. 2. **Publicar sem distribuição.** Escrever um post e esperar tráfego não é uma estratégia. 3. **Mudar seu foco a cada trimestre.** O maior assassino do impulso de marca pessoal. 4. **Medir métricas de vaidade.** Meça o tamanho da sua lista e sua taxa de conversão, não seus likes. 5. **Esperar até ser "expert o suficiente."** Você não precisa ser a autoridade mundial no seu tema. ## O stack de marca pessoal - **Plataforma de e-mail:** [ConvertKit](/recommends/convertkit) - **Pesquisa de SEO:** [Semrush](/recommends/semrush) - **Criação de conteúdo:** [Claude](/recommends/claude) - **Design:** [Canva](/recommends/canva) ## FAQ ### Quanto tempo leva para construir uma marca pessoal? Realisticamente, 12–24 meses de publicação consistente antes de ter entrada significativa de oportunidades. ### Preciso estar em todas as plataformas sociais? Não. Profundidade em uma plataforma supera presença superficial em cinco. ### O que é mais importante: qualidade do conteúdo ou frequência de publicação? Ambos, mas não igualmente. A qualidade estabelece o piso. A frequência determina se você obtém as repetições necessárias para melhorar. ### Devo usar meu nome real ou um nome de marca? Use seu nome real. Marcas pessoais ligadas a uma pessoa real sobrevivem melhor a mudanças de algoritmo. ### Como monetizar uma marca pessoal? Os quatro caminhos confiáveis: (1) cursos / produtos digitais, (2) consultoria e assessoria, (3) parcerias de afiliados, e (4) conteúdo patrocinado. --- **Relacionado:** [Como validar uma ideia de negócio antes de construí-la](/how-to-validate-a-business-idea/) · [Como construir uma lista de e-mail do zero](/how-to-build-an-email-list/) · [Como monetizar uma newsletter](/how-to-monetize-a-newsletter/) --- ## Como dar memória a um agente de IA: padrões de persistência de estado para produção Source: https://alejandrorioja.com/pt/how-to-add-memory-to-an-ai-agent/ Published: 2026-06-30 Tags: AI Agents TL;DR: Agentes sem estado — aqueles que esquecem tudo quando o Worker termina — funcionam bem para tarefas únicas. No momento em que um agente precisa lembrar o que aconteceu ontem, reconhecer um cliente recorrente ou construir sobre resultados anteriores, você precisa de memória. Existem três padrões: memória de trabalho (contexto em andamento, vive no KV durante a execução), memória episódica (o que aconteceu e quando, um log consultável) e memória semântica (o que você sabe, recuperado via busca vetorial ou dados estruturados). Conecte o padrão certo ao trabalho certo. ## Índice _Atualizado junho 2026._ **TL;DR:** Agentes sem estado — aqueles que esquecem tudo quando o Worker termina — funcionam bem para tarefas únicas. No momento em que um agente precisa lembrar o que aconteceu ontem, reconhecer um cliente recorrente ou construir sobre resultados anteriores, você precisa de memória. Existem três padrões: memória de trabalho (contexto em andamento, vive no KV durante a execução), memória episódica (o que aconteceu e quando, um log consultável) e memória semântica (o que você sabe, recuperado via busca vetorial ou dados estruturados). Conecte o padrão certo ao trabalho certo. **[Perspectiva do operador]** Já bati contra o muro do agente sem estado mais de uma vez. O agente de resposta social que continuava se apresentando para clientes com quem havia falado 20 vezes. O agente de briefing diário que sinalizava o mesmo problema quatro dias seguidos porque não tinha memória de tê-lo sinalizado ontem. Adicionar o tipo certo de memória resolveu ambos. É isso que eu uso. ## Por que agentes sem estado continuam falhando Um agente sem estado começa cada execução apenas com o que você passa explicitamente: o prompt do sistema, a mensagem do usuário e os dados que você obtém no momento da invocação. Ele não tem consciência de execuções anteriores, usuários anteriores ou decisões anteriores. Para uma tarefa de classificação única — ler um comentário, retornar uma categoria — sem estado está correto. É rápido, barato e previsível. A superfície de falha aparece no momento em que você precisa de continuidade: - Um agente orientado ao cliente que não reconhece o histórico do cliente - Um agente de conteúdo que recomenda um artigo que já recomendou semana passada - Um agente de moderação que continua re-escalando um caso resolvido - Um briefing diário que exibe o mesmo alerta obsoleto indefinidamente Todos esses são sintomas do mesmo problema: o agente não tem como carregar contexto entre execuções. ## Três tipos de memória O framework que acho útil em produção: 1. **Memória de trabalho** — o que o agente sabe _agora_, durante uma única execução. Mantida no KV ou na memória durante a vida da invocação. 2. **Memória episódica** — o que aconteceu e quando. Um log estruturado que o agente lê no início de cada execução para se orientar. 3. **Memória semântica** — o que ele sabe sobre o mundo, clientes ou uma base de conhecimento. Recuperada via consultas estruturadas ou busca vetorial quando relevante. Você nem sempre precisa das três. A maioria dos agentes que executo precisa de trabalho + episódica. A memória semântica é a mais difícil de construir e só merece seu lugar quando a base de conhecimento é grande demais para caber na janela de contexto. ## Memória de trabalho: contexto em andamento A memória de trabalho é o estado que vive durante a duração de uma execução do agente. A forma mais simples são variáveis no escopo da função. A forma mais interessante é uma chave KV compartilhada que subtarefas dentro da mesma execução leem e escrevem. Meu agente de resposta social usa memória de trabalho para acumular contexto ao processar um lote de comentários em uma mensagem de fila. Ele lê o histórico de conversas recente de cada cliente do KV no início, adiciona novo contexto durante o processamento e escreve de volta no final. ```typescript // workers/social-reply.ts async function processComment( comment: SocialCommentEvent, env: Env ): Promise { // Carregar histórico recente deste cliente do KV (memória de trabalho) const historyKey = `customer:${comment.userId}:history`; const rawHistory = await env.AGENT_KV.get(historyKey); const history: ConversationTurn[] = rawHistory ? JSON.parse(rawHistory) : []; // Construir prompt do sistema contextual a partir do histórico const systemPrompt = buildSystemPrompt(history); const response = await anthropic.messages.create({ model: "claude-opus-4-8", max_tokens: 512, system: systemPrompt, messages: [{ role: "user", content: comment.text }], }); const reply = response.content[0].type === "text" ? response.content[0].text : ""; // Atualizar histórico — manter últimos 10 turnos, TTL 30 dias const updatedHistory: ConversationTurn[] = [ ...history.slice(-9), { role: "assistant", content: reply, timestamp: comment.timestamp }, ]; await env.AGENT_KV.put(historyKey, JSON.stringify(updatedHistory), { expirationTtl: 60 * 60 * 24 * 30, }); await postReply(comment, reply, env); } ``` Dois pontos a notar. O histórico está limitado a 10 turnos — injete uma janela deslizante, não deixe crescer ilimitadamente. E o TTL é de 30 dias: se um cliente ficar em silêncio por um mês, o histórico expira e o agente começa do zero. Ambos são intencionais. ## Memória episódica: o que aconteceu e quando A memória episódica é o log do agente. Um registro estruturado de execuções passadas que o agente lê no início de cada nova execução para evitar se repetir. Meu agente de briefing diário estava exibindo os mesmos alertas obsoletos todos os dias porque cada execução não tinha consciência do que já havia sido sinalizado. A solução: um log estruturado de alertas passados que o agente lê antes de gerar o briefing. ```typescript // workers/daily-brief.ts interface AlertLogEntry { id: string; surfacedAt: string; // timestamp ISO resolvedAt?: string; summary: string; } async function buildDailyBrief(env: Env): Promise { const [emails, calendar, tasks] = await Promise.all([ fetchOvernightEmails(env), fetchTodayCalendar(env), fetchTopTasks(env), ]); // Carregar memória episódica: o que já foi sinalizado const rawLog = await env.AGENT_KV.get("brief:alert-log"); const alertLog: AlertLogEntry[] = rawLog ? JSON.parse(rawLog) : []; // Filtrar apenas alertas recentes e não resolvidos const sevenDaysAgo = new Date( Date.now() - 7 * 24 * 60 * 60 * 1000 ).toISOString(); const recentAlerts = alertLog.filter( (e) => e.surfacedAt > sevenDaysAgo && !e.resolvedAt ); const brief = await synthesizeBrief( { emails, calendar, tasks, recentAlerts }, env ); // Atualizar o log com novos alertas sinalizados nesta execução const newAlerts: AlertLogEntry[] = brief.newAlerts.map((a) => ({ id: crypto.randomUUID(), surfacedAt: new Date().toISOString(), summary: a, })); const updatedLog = [...alertLog, ...newAlerts].slice(-100); // manter últimos 100 await env.AGENT_KV.put("brief:alert-log", JSON.stringify(updatedLog)); await writeToWorkspace(brief.content, env); } ``` O agente agora sabe o que já disse. Alertas duplicados ficam fora do briefing até que o problema subjacente mude. Quando marco um alerta como resolvido, ele sai da lista ativa. Este padrão se generaliza: qualquer agente que produz decisões, sinalizações ou recomendações se beneficia de um log. O log é barato (alguns KB no KV), o retorno é alto (sem mais saídas redundantes). ## Memória semântica: o que você sabe A memória semântica é a base de conhecimento. Ela responde "o que você sabe sobre X?" no momento da consulta, em vez de colocar tudo no prompt do sistema antecipadamente. A forma mais simples é uma busca estruturada no KV ou em um banco de dados. Meu agente de reservas do Pickleland consulta perfis de clientes e preferências de quadra antes de redigir confirmações: ```typescript // workers/booking-agent.ts interface CustomerProfile { userId: string; preferredCourts: string[]; experienceLevel: "beginner" | "intermediate" | "advanced"; specialNotes: string; } async function draftConfirmation( booking: BookingEvent, env: Env ): Promise { // Obter perfil do cliente do KV (memória semântica — conhecimento factual) const profileKey = `customer:${booking.userId}:profile`; const rawProfile = await env.AGENT_KV.get(profileKey); const profile: CustomerProfile | null = rawProfile ? JSON.parse(rawProfile) : null; const systemPrompt = profile ? `Você redige confirmações de reserva personalizadas. Este cliente prefere ${profile.preferredCourts.join(", ")}, é um jogador ${profile.experienceLevel}. ${profile.specialNotes}` : "Você redige confirmações de reserva para uma instalação de pickleball."; const response = await anthropic.messages.create({ model: "claude-haiku-4-5-20251001", max_tokens: 256, system: systemPrompt, messages: [ { role: "user", content: `Redija uma confirmação para: ${JSON.stringify(booking)}`, }, ], }); return response.content[0].type === "text" ? response.content[0].text : ""; } ``` Para bases de conhecimento maiores — documentação de produtos, base de conhecimento de suporte, qualquer coisa grande demais para caber em uma janela de contexto — você precisa de um armazenamento vetorial. O fluxo de trabalho é: incorporar a consulta, recuperar os k fragmentos mais relevantes, injetá-los no contexto. O Cloudflare Vectorize lida com isso nativamente se você já está no Workers. Para índices maiores, usei o Upstash Vector. A escolha depende da escala, não do princípio. A nota honesta sobre memória semântica: é a mais difícil das três de construir e manter. O índice precisa ficar atualizado. A qualidade de recuperação varia. Comece com buscas estruturadas — KV, uma tabela no D1 — e só alcance a busca vetorial quando a abordagem estruturada não conseguir cobrir a superfície de conhecimento que você precisa. ## O framework de decisão de memória Antes de adicionar qualquer memória a um agente, responda três perguntas: 1. **O agente precisa se lembrar entre execuções?** Se cada invocação é genuinamente independente — uma tradução, uma classificação, uma geração única — ignore a memória. Sem estado é mais simples e mais barato. 2. **O agente está se repetindo ou agindo cego ao seu próprio histórico?** Se sim, adicione memória episódica primeiro. É a correção de menor esforço e cobre a maioria das reclamações de "o agente continua fazendo X". 3. **O agente está tratando todos os usuários ou entidades de forma idêntica quando não deveria?** Se sim, adicione memória de trabalho (histórico do cliente, perfil do usuário) ou memória semântica (um sistema de busca ou recuperação). O erro que mais vejo na prática: alguém adiciona uma enorme base de conhecimento (memória semântica) a um agente que estava falhando porque não tinha memória episódica — nenhum log do que já havia feito. A complexidade não corresponde ao problema. ## O que realmente uso em produção Em 30+ agentes: - **Todos** têm pelo menos memória de trabalho — alguma forma de estado dentro de uma execução, mesmo que seja apenas a própria janela de contexto. - **Cerca de metade** tem memória episódica — um log de execuções passadas, decisões ou sinalizações. Isso quase sempre vale a pena adicionar. - **Três ou quatro** têm memória semântica real apoiada por um armazenamento vetorial. Esses são os agentes que respondem perguntas sobre uma base de conhecimento grande e dinâmica. O Cloudflare KV é meu armazenamento padrão para memória de trabalho e episódica. É rápido, barato e integrado nativamente ao Workers — sem cliente extra, sem credencial separada. A limitação: KV é eventualmente consistente e não é ótimo para gravações de alta frequência. Para agentes que escrevem estado muitas vezes por segundo, uso Durable Objects ou um banco de dados D1 em vez disso. Para memória semântica apoiada por vetores, uso o Cloudflare Vectorize para índices pequenos a médios (menos de ~100K vetores) e Upstash Vector para tudo que for maior. Ambos têm clientes JavaScript de primeira classe. ## A conclusão do operador Adicione memória a um agente somente quando o comportamento sem estado estiver causando problemas reais — saídas repetidas, pontos cegos no histórico do cliente, ignorância de decisões passadas. Em seguida, escolha a camada certa: memória de trabalho para contexto em execução, episódica para o que aconteceu historicamente, semântica para o que você sabe. Comece com episódica se não tiver certeza — ela corrige o modo de falha mais comum com menos complexidade. Não recorra a um banco de dados vetorial até esgotar as buscas estruturadas. O melhor sistema de memória é o mais simples que faz o agente se comportar corretamente. --- **Relacionado:** [O stack de agentes que uso para rodar 30+ agentes em produção](/the-agent-stack-i-use-to-run-30-production-agents-no-python/) · [Agentes por evento vs. agendados](/event-triggered-vs-scheduled-agents-which-pattern-for-which-job/) · [Como meço se um agente de IA está realmente funcionando](/how-i-measure-whether-an-ai-agent-is-actually-working/) **Precisa de ajuda para projetar memória de agentes para seu caso de uso?** [Entre em contato](/contact/) — projeto sistemas de agentes em produção para equipes operadoras. --- ## Como construir uma lista de e-mail do zero: O manual de 2026 Source: https://alejandrorioja.com/pt/how-to-build-an-email-list/ Published: 2026-06-27 Tags: Entrepreneurship, Growth TL;DR: Uma lista de e-mail é o único canal de distribuição que você realmente possui. Comece com um ímã de leads que resolva um problema específico, coloque seu opt-in acima da dobra e envie uma sequência de boas-vindas de 3 e-mails assim que alguém se inscrever. A qualidade sempre supera a quantidade — 1.000 assinantes engajados superam 10.000 frios em qualquer momento. ## Índice _Atualizado em junho de 2026._ **TL;DR:** Uma lista de e-mail é o único canal de distribuição que você realmente possui. Comece com um ímã de leads que resolva um problema específico, coloque seu opt-in acima da dobra e envie uma sequência de boas-vindas de 3 e-mails assim que alguém se inscrever. A qualidade sempre supera a quantidade — 1.000 assinantes engajados superam 10.000 frios em qualquer momento. **[Perspectiva do operador]** Todo negócio em que estive envolvido e que construiu um motor de receita duradouro tinha uma coisa em comum: uma lista. Não seguidores. Não impressões. Uma lista de pessoas que pediram para ouvir de você. Aqui está exatamente como construir uma do zero. ## O único ativo que você realmente possui Qualquer outro canal de distribuição pode desaparecer. Uma atualização do algoritmo do Google elimina rankings de busca. Uma mudança de política de plataforma mata seu alcance no Facebook. Uma conta de anúncios é suspensa sem aviso. Sua lista de e-mail é a exceção. Quando você possui uma lista de e-mail, controla a entrega. Nenhum algoritmo decide quem vê seu conteúdo. Nenhuma taxa de plataforma cobra um pedágio toda vez que você quer alcançar sua audiência. É por isso que construir uma lista de e-mail é a primeira coisa que digo a cada fundador — antes de SEO, antes de anúncios pagos, antes de redes sociais. ## Passo 1: Escolha uma plataforma de e-mail Antes de coletar um único endereço, você precisa de uma plataforma para armazenar e enviar. Não use o Gmail. Não use seu e-mail empresarial. Use uma ferramenta criada especificamente com a infraestrutura adequada de conformidade e entregabilidade. Minhas duas escolhas para 2026: **[ConvertKit](/recommends/convertkit)** — A melhor para criadores e operadores solo. O sistema de marcação e segmentação de assinantes é genuinamente excelente. Gratuito até 1.000 assinantes. **[Moosend](/recommends/moosend)** — A melhor para pequenas empresas que querem automação sem o preço do ConvertKit. Construtor de arrastar e soltar sólido e entregabilidade consistentemente boa. Se você está começando do zero, ambas têm níveis gratuitos que cobrem seus primeiros centenas de assinantes. Configure a autenticação DKIM, SPF e DMARC em seu domínio antes de enviar qualquer coisa — isso é exigido pelo Gmail e Yahoo desde 2024 para remetentes de alto volume, e protege sua reputação de remetente desde o primeiro dia. ## Passo 2: Crie um ímã de leads que vale a pena baixar Um ímã de leads é o que você oferece em troca do endereço de e-mail de alguém. O erro que a maioria das pessoas comete: oferecer algo genérico. "Inscreva-se em nosso boletim" não é um ímã de leads. É um pedido de confiança sem nada em troca. Seu ímã de leads precisa resolver um problema específico para uma pessoa específica. Quanto mais específico, melhor converte. **Formatos que funcionam em 2026:** 1. **Folhas de referência rápida e modelos** — Um recurso de uma página que alguém pode usar imediatamente. Quanto mais plug-and-play, melhor. 2. **Mini-cursos (3–5 e-mails)** — Uma curta sequência que ensina uma habilidade, entregue automaticamente. Constrói a lista e o relacionamento simultaneamente. 3. **Calculadora ou planilha** — Alto valor percebido. Uma ferramenta de dimensionamento de mercado, um modelo de preços, um modelo de orçamento. Esses convertem porque poupam trabalho real. 4. **Dados ou pesquisa exclusivos** — Resultados de pesquisas originais ou um relatório de benchmark. Difícil de replicar, alta credibilidade. 5. **Swipe files** — Coleções de exemplos reais (textos de anúncios, linhas de assunto, títulos de páginas de destino). Profissionais pagam por isso. 6. **Webinar ou replay de treinamento** — Reutilize uma gravação existente como opt-in. Leva 20 minutos para configurar. Um requisito inegociável: o ímã de leads deve estar diretamente relacionado ao que você enviará por e-mail. Um modelo de anúncio do Facebook que captura assinantes para um boletim B2B SaaS é um desastre de qualidade de lista esperando para acontecer. ## Passo 3: Coloque seus formulários de opt-in onde funcionam O posicionamento do formulário impulsiona mais a conversão do que o texto. Coloque formulários de opt-in onde a atenção já existe: 1. **Acima da dobra na sua página inicial** — Não no rodapé. Não na barra lateral. Acima da dobra, com uma descrição clara do que receberão. 2. **No final de cada post do blog** — Alguém que leu todo o seu post está pré-qualificado. Capture-o enquanto ainda está engajado. 3. **Pop-up de intenção de saída** — Acionado quando um visitante está prestes a fechar a aba. Controverso, mas funciona. 4. **Página de destino dedicada** — Uma página independente sem navegação. Aqui é onde você envia tráfego pago. 5. **Atualizações de conteúdo** — Um recurso que melhora um post específico. Uma planilha de dimensionamento de mercado dentro de um guia TAM/SAM/SOM converte 3–5 vezes mais do que uma oferta genérica na mesma página. Dica de texto: comece com o resultado, não com o formato. "Baixe o guia de 5 páginas" é mais fraco do que "Conheça o tamanho do seu mercado como um VC." ## Passo 4: Escreva uma sequência de boas-vindas No momento em que alguém se inscreve, você tem a atenção máxima deles. Não desperdice com silêncio. Envie no mínimo 3 e-mails: **E-mail 1 (imediato):** Entregue o ímã de leads. Confirme para o que eles se inscreveram. Defina expectativas para o que está por vir. **E-mail 2 (dia 2):** Seu melhor pedaço de conteúdo — um post, estudo de caso, framework. Sem pitch. Apenas prova de que se inscrever valeu a pena. **E-mail 3 (dia 4–5):** Sua história de origem e ponto de vista. Por que você se importa com este tema? O que você acredita que a maioria das pessoas no seu espaço não acredita? É aqui que a confiança é construída. A partir daí, mantenha uma cadência consistente. Semanal é o padrão. Quinzenal funciona se você não conseguir manter a qualidade semanalmente. O pior erro é enviar uma vez no lançamento e depois sumir por três meses. ## Passo 5: Direcione tráfego para seu opt-in Um formulário sem tráfego não converte ninguém. Os canais de crescimento mais confiáveis: **Pesquisa orgânica** — Posts de blog que ranqueiam para os problemas que seu ímã de leads resolve. Alguém que pesquisa seu tópico e encontra seu post está pré-qualificado para sua oferta. Este é o canal de menor custo e maior retenção. **Redes sociais (orgânico)** — Posts no LinkedIn, threads no Twitter/X ou vídeos curtos que levam pessoas à sua página de opt-in. Cada post deve ser um teaser, não a história completa. **Trocas de boletins e co-promoções** — Encontre boletins em espaços adjacentes e troque menções. Você promove a lista deles; eles promovem a sua. Esta é uma das maneiras mais rápidas de crescer de 500 para 5.000 assinantes. **Participações como convidado em podcasts** — Subestimado. Um episódio de 30 minutos enviado para 2.000 ouvintes de nicho pode adicionar 50–100 assinantes profundamente interessados que têm mais probabilidade de abrir cada e-mail que você enviar. **Anúncios pagos** — Não veicule anúncios para uma oferta não validada. Primeiro, faça sua página de opt-in converter organicamente, depois escale com tráfego pago. ## Passo 6: Mantenha sua lista limpa Uma lista de e-mail se deteriora. As pessoas mudam de emprego, mudam de e-mail, mudam de interesses. Se você não limpar sua lista, sua entregabilidade sofre — o que significa que mesmo os assinantes engajados param de ver seus e-mails. Melhores práticas: - **Campanha de re-engajamento a cada 6 meses** — Envie um e-mail para qualquer pessoa que não abriu em 90+ dias. Dê-lhes uma razão para ficar. Se não se envolverem, remova-os. - **Remova bounces permanentes imediatamente** — Uma alta taxa de bounces diz aos provedores de caixa de entrada que sua lista está suja. - **Segmente por engajamento** — Marque assinantes ativos e frios separadamente. Envie campanhas sensíveis ao tempo apenas para seu segmento ativo. Excluir assinantes parece perder algo. Na prática, protege os assinantes que você deseja manter. ## Ressalvas honestas **Construir leva tempo.** Começando do zero com apenas métodos orgânicos, espere 3–6 meses para chegar a 1.000 assinantes. Qualquer pessoa que prometa milhares em semanas está vendendo métricas de vaidade ou contatos frios e não engajados que você não quer. **O nicho importa.** Audiências B2B respondem a dados e estudos de caso. Audiências de consumidores respondem a descontos e entretenimento. O ímã de leads e a cadência de conteúdo devem combinar com a audiência. **Ímãs de leads envelhecem.** O que converte bem hoje pode ser obsoleto em 18 meses quando os concorrentes copiarem o formato. Planeje atualizar seu ímã de leads anualmente. ## Benchmarks realistas | Métrica | Média do setor | Bom | |--------|-----------------|------| | Taxa de opt-in por popup | 2–4% | 5–8% | | Taxa de opt-in por página de destino | 20–30% | 40–60% | | Taxa de abertura do e-mail de boas-vindas | 50–60% | 70%+ | | Taxa de abertura contínua | 20–25% | 35–45% | | Taxa de cliques | 2–3% | 5–10% | Não otimize esses números nos primeiros 90 dias. Construa a infraestrutura, execute o ímã de leads, envie consistentemente. Depois, itere. ## Atualizado para junho de 2026 **Ímãs de leads gerados por IA** — Ferramentas como o Claude podem redigir um guia PDF de 10 páginas, um swipe file ou um modelo em minutos. A barreira para criar um ímã de leads de alta qualidade está perto de zero. O diferenciador agora é a especificidade da promessa e a relevância para sua audiência. **Autenticação do Gmail e Yahoo** — Desde 2024, DKIM, SPF e DMARC são exigidos para remetentes que enviam e-mails para mais de 1.000 endereços por dia. Tanto o [ConvertKit](/recommends/convertkit) quanto o [Moosend](/recommends/moosend) guiam você pela configuração durante o onboarding. Faça isso antes de precisar. **Tráfego de busca por IA** — Uma página de opt-in bem estruturada com um TL;DR claro e uma resposta direta a uma consulta de pesquisa pode aparecer no ChatGPT, Perplexity e Google AI Overviews. Já vi páginas de destino de opt-in gerando tráfego consistente da busca por IA sem nenhum trabalho de SEO — porque a página responde diretamente a uma pergunta específica. ## Perguntas frequentes **Quantos assinantes preciso para monetizar?** Não há número universal. Já vi boletins com 500 assinantes profundamente engajados em um nicho de alta intenção superar listas de 20.000 contatos genéricos. A questão é se seus assinantes têm um problema e se confiam em você para resolvê-lo. **Devo comprar uma lista de e-mail?** Não. Listas compradas têm engajamento terrível, farão você ser marcado como spam e podem suspender sua conta. Não há atalho. **Com que frequência devo enviar e-mails?** Com a maior frequência possível mantendo a qualidade. Semanal mantém você em destaque. O maior erro é ficar em silêncio por meses e reaparecer com um pitch. **Opt-in duplo ou único?** Opt-in duplo na maioria dos casos. A confirmação reduz o tamanho da lista, mas melhora dramaticamente o engajamento e a entregabilidade. A exceção é quando você está direcionando tráfego de alta intenção e verificado de uma fonte específica. **Qual é a melhor plataforma de e-mail para iniciantes?** [ConvertKit](/recommends/convertkit) para criadores que estão construindo uma marca pessoal ou negócio de conteúdo. [Moosend](/recommends/moosend) para pequenas empresas que querem acessibilidade e automação. Ambos são muito melhores do que tentar usar o Gmail. ## Para onde levaria isso depois A lista de e-mail não vive em isolamento. Seus posts com melhor desempenho devem ter uma atualização de conteúdo. Seus e-mails devem linkar de volta para guias aprofundados. Seu ímã de leads deve resolver exatamente o problema que suas páginas com mais tráfego abordam. Esse ciclo — tráfego → opt-in → nutrição → confiança → oferta — é a base de todo negócio online duradouro em que estive envolvido. Se você quiser discutir como implementar isso para sua situação específica, a [página de contato](/contact) é o lugar certo para começar. --- ## Como monetizar uma newsletter: 5 modelos de receita que realmente funcionam Source: https://alejandrorioja.com/pt/how-to-monetize-a-newsletter/ Published: 2026-06-25 Tags: Entrepreneurship, Growth TL;DR: A maioria das newsletters falha na monetização porque persegue o modelo errado para o tamanho da sua lista. Os cinco modelos que funcionam: assinaturas pagas (melhor para autoridade de nicho), patrocínios (melhor após 5.000+ assinantes), recomendações de afiliados (menor atrito em qualquer tamanho), funis de cursos e produtos (maior teto de renda) e upsells de serviços (caminho mais rápido para dinheiro real). Comece com um. Adicione um segundo apenas quando o primeiro estiver funcionando. ## Table of contents _Atualizado em junho de 2026._ **TL;DR:** A maioria das newsletters falha na monetização porque persegue o modelo errado para o tamanho da sua lista. Os cinco modelos que funcionam: assinaturas pagas (melhor para autoridade de nicho), patrocínios (melhor após 5.000+ assinantes), recomendações de afiliados (menor atrito em qualquer tamanho), funis de cursos e produtos (maior teto de renda) e upsells de serviços (caminho mais rápido para dinheiro real). Comece com um. Adicione um segundo apenas quando o primeiro estiver funcionando. **[Perspectiva do operador]** Tenho gerenciado uma newsletter desde antes de ser fashion chamá-la de "negócio de newsletter". A versão honesta da jornada: tentei fazer tudo de uma vez, ganhei quase nada, reduzi a um modelo e comecei a ganhar. Aqui está o que aprendi e o que vejo funcionando consistentemente entre os operadores com quem trabalho. ## Por que a maioria das newsletters nunca ganha um centavo O problema de monetização geralmente é um problema de sequenciamento. As pessoas lançam uma newsletter, fazem-na crescer lentamente e depois tentam adicionar todos os fluxos de receita de uma vez — um nível pago aqui, um slot de patrocinador ali, um link de afiliado em cada edição. O resultado é uma newsletter que parece um shopping: tudo está à venda, nada parece genuíno e os leitores se desengajam. As newsletters que ganham consistentemente fazem uma coisa bem primeiro. Elas provam que um modelo funciona para seu público específico. Então — e somente então — adicionam um segundo. O tamanho da sua lista também determina quais modelos são viáveis. Uma lista de 500 assinantes é a ferramenta errada para buscar patrocinadores. Uma lista de 50.000 assinantes está deixando dinheiro significativo na mesa se só usa links de afiliados. O modelo deve corresponder à lista. ## Modelo 1: Assinaturas pagas **Melhor para:** Newsletters de autoridade de nicho com um público profissional definido ou de alto interesse. As assinaturas pagas são a forma mais pura de monetização de newsletter: os leitores pagam diretamente pelo conteúdo. Plataformas como Beehiiv e Substack facilitam adicionar isso a uma lista gratuita. O que o faz funcionar: - Um nicho específico e de alto valor onde as informações são escassas ou economizam tempo (análise financeira, inteligência do setor, táticas em nível operacional) - Uma resposta clara para "o que um assinante ganha ao pagar que não ganha de graça?" - Um nível gratuito genuinamente valioso — não uma versão diluída, mas uma amostra da abordagem do nível pago O que o mata: - Tópicos gerais com baixa urgência ("dicas de marketing", "desenvolvimento pessoal") - Lançar o pago antes de ter prova de que os assinantes gratuitos leem seu conteúdo consistentemente Receita realista: R$ 25–100/mês por assinante. Com 5% de conversão de uma lista de 2.000 pessoas, são 100 assinantes pagos a R$ 50/mês = R$ 5.000 MRR. Pequeno, mas real, e se acumula. ## Modelo 2: Patrocínios e publicidade nativa **Melhor para:** Newsletters com 5.000+ assinantes e uma demografia de público definida. Os patrocínios são o modelo mais visível — um slot de edição vendido a uma marca relevante para seu público. Quando funciona, funciona bem: $100–$500+ CPM (custo por mil assinantes) é típico para um público B2B de nicho ou de alta renda. A restrição honesta: os patrocinadores querem escala e especificidade. "Tenho 1.000 assinantes interessados em marketing" não fecha negócios. "Tenho 6.000 assinantes que são gerentes de marketing em empresas com 10–500 funcionários, com taxa de abertura de 52%" fecha. Como chegar lá: 1. **Defina seu público** em termos demográficos, não em termos de interesses 2. **Alcance 5.000 assinantes** como piso mínimo de credibilidade antes de abordar patrocinadores 3. **Prove engajamento** — taxas de abertura acima de 40% são o diferenciador real 4. **Crie um media kit** — um PDF de uma página com contagem de assinantes, taxa de abertura, perfil do público e pacotes de patrocínio 5. **Comece com inbound** — liste em marketplaces de patrocínio antes de construir um processo de vendas outbound Verificação de CPM: se sua lista converte a 45% de taxa de abertura e você vende um slot de patrocinador por edição a $200 CPM, uma lista de 5.000 assinantes gera $1.000 por edição patrocinada. A quatro edições por mês, são $4.000/mês de um slot de patrocinador. Com dois slots, $8.000/mês. A matemática funciona — em escala. ## Modelo 3: Recomendações de afiliados **Melhor para:** Qualquer tamanho de lista, qualquer nicho onde você genuinamente usa ferramentas e serviços. O marketing de afiliados é o modelo de menor atrito para começar: você recomenda produtos que realmente usa, os leitores clicam e você ganha comissão nas compras. Sem relacionamentos com patrocinadores para gerenciar, sem produto para construir, sem nível pago para manter. A restrição-chave é a confiança. As recomendações de afiliados só convertem quando a recomendação é genuinamente útil e de fonte credível. Uma seção de "melhores escolhas" cheia de produtos que você nunca usou terá desempenho abaixo do esperado — ou pior, danificará a lista. O que funciona: - Recomendar ferramentas que você usa em seu próprio stack (para mim: [ConvertKit](/recommends/convertkit) para gerenciamento de email, [Semrush](/recommends/semrush) para SEO e pesquisa de conteúdo) - Posicionamento contextual — mencionar a ferramenta onde é relevante para o conteúdo, não em um bloco fixo de "patrocinador desta edição" que os leitores aprendem a pular - Dar uma opinião real: o que você gosta, o que não gosta e para quem não é adequado Teto de receita: as comissões de afiliados variam — ferramentas SaaS tipicamente pagam 20–40% de forma recorrente em assinantes convertidos, o que se acumula bem. Uma lista de 1.000 assinantes onde 2% dos leitores convertem em um SaaS de $50/mês a 30% de comissão = $300/mês recorrentes, crescendo com cada nova inscrição que permanece. ## Modelo 4: Funil de curso e produto digital **Melhor para:** Operadores com autoridade de ensino em um domínio específico. A newsletter é o topo do funil; o curso ou produto digital é o evento de conversão. Os leitores que confiam em você o suficiente para abrir cada edição são os leads mais qualificados para um produto pago que os ensina algo que você sabe. Este é o modelo com o maior teto de renda quando combinado com uma lista modesta. Um curso de $497 vendido a 2% de uma lista de 5.000 pessoas é $49.700 por lançamento. A três lançamentos por ano com crescimento da lista, isso se acumula de forma agressiva. O que requer: - Verdadeira autoridade de ensino em um domínio específico — não apenas "conheço marketing" mas "fiz crescer três empresas B2B usando este playbook de crescimento específico" - Conteúdo que demonstre autoridade semana após semana (não apenas links curados — seus frameworks originais e estudos de caso) - Uma sequência de lançamento para a qual a lista foi preparada — não um email frio de "compre meu curso" de uma lista que só recebe conteúdo Este é o modelo no qual mais me apoio em meu próprio trabalho. A newsletter constrói a confiança; o curso a converte. ## Modelo 5: Upsells de serviços **Melhor para:** Newsletters em fase inicial onde o operador oferece consultoria, coaching ou serviços done-for-you. Este modelo é o caminho mais rápido para receita real com tamanhos pequenos de lista, e é o mais subutilizado. A newsletter o posiciona como especialista; o serviço é o especialista em ação. Se 500 pessoas leem sua newsletter sobre growth marketing e você publica uma edição por mês que demonstra seu pensamento, 1–2 desses 500 leitores levantarão periodicamente a mão e perguntarão se você faz consultoria. Se você não oferecer, deixou receita na mesa. Como torná-lo explícito: - Adicione uma linha ao rodapé da sua newsletter: "Trabalho com um pequeno número de clientes por trimestre em [resultado específico]. Responda a este email se quiser explorar isso." - Mencione resultados de clientes (anonimizados) em edições relevantes — não como vanglória, mas como prova de que os frameworks funcionam na prática - Mantenha a capacidade intencionalmente restrita — a escassez não é fabricada aqui, é real; você tem apenas uma certa quantidade de tempo Realidade de receita: um cliente de consultoria a $5.000/mês e uma newsletter de 200 pessoas tem melhor economia do que 50.000 assinantes ganhando $0,01/assinante em receita de afiliados dispersa. Não espere pela escala para começar aqui. ## Como escolher o modelo certo O framework de decisão: | Tamanho da lista | Melhor modelo inicial | Segundo modelo a adicionar | |-----------------|----------------------|---------------------------| | 0–1.000 | Upsells de serviços | Recomendações de afiliados | | 1.000–5.000 | Afiliados + lista de espera de curso | Assinaturas pagas | | 5.000–20.000 | Patrocínios | Lançamento de curso | | 20.000+ | Patrocínios + curso | Nível pago | Uma restrição que não muda em nenhum tamanho: escolha um primeiro. A dispersão de modelos mata a conversão em todos os modelos simultaneamente. ## O stack do operador de newsletter Ferramentas que uso e recomendo para construir um negócio de newsletter: - **Plataforma de email:** [ConvertKit](/recommends/convertkit) — tagueamento de assinantes, segmentação e sequências de automação que separam compradores de leitores - **Pesquisa de SEO e tópicos:** [Semrush](/recommends/semrush) — identifique o que seu público-alvo pesquisa antes de escrever sobre isso - **Design:** [Canva](/recommends/canva) — media kit, assets de capa de curso e conteúdo social sem designer - **Pagamentos:** Stripe — para níveis de assinatura pagos ou checkouts de cursos ## A conclusão do operador Uma newsletter é o ativo de conteúdo com maior alavancagem que você pode construir em 2026: a atenção na caixa de entrada de email é escassa e valiosa de uma forma que os feeds sociais não são. Mas o ativo só se converte em receita quando você escolhe um modelo que se adapta ao tamanho da sua lista, o executa com recomendações genuínas e real autoridade, e resiste ao impulso de se dispersar em cada método de monetização de uma vez. Comece com o modelo que se adapta a onde você está hoje. Quando estiver funcionando — consistentemente, com resultados cumulativos — adicione o próximo. --- **Relacionado:** [Como validar uma ideia de negócio antes de construí-la](/how-to-validate-a-business-idea/) · [Guia de estratégias de growth marketing](/growth-marketing-strategies-guide/) · [6 melhores serviços de email marketing para pequenas empresas](/6-best-email-marketing-services-for-small-business/) --- ## Como Construir Seu Primeiro Servidor MCP: Guia Prático Source: https://alejandrorioja.com/pt/how-to-build-your-first-mcp-server/ Published: 2026-06-23 Tags: AI Agents TL;DR: MCP (Model Context Protocol) é como dar ao Claude acesso estruturado a ferramentas e dados externos — bancos de dados, arquivos, APIs — sem sobrecarregar a janela de contexto. O servidor é mais simples do que parece: instale o SDK, defina suas ferramentas como JSON schema, implemente os handlers, conecte via stdio. Você pode ter o Claude chamando suas ferramentas personalizadas em menos de 30 minutos. ## Índice _Atualizado junho 2026._ **TL;DR:** MCP (Model Context Protocol) é como dar ao [Claude](/recommends/claude) acesso estruturado a ferramentas e dados externos — bancos de dados, arquivos, APIs — sem sobrecarregar a janela de contexto. O servidor é mais simples do que parece: instale o SDK, defina suas ferramentas como JSON schema, implemente os handlers, conecte via stdio. Você pode ter o Claude chamando suas ferramentas personalizadas em menos de 30 minutos. **[Perspectiva do operador]** Conecto novas ferramentas aos meus agentes regularmente, e MCP é agora o caminho padrão para fazer isso de forma limpa. Uma vez construído o servidor, qualquer cliente compatível — Claude Desktop, Claude Code, qualquer aplicativo usando o SDK Anthropic — pode usá-lo sem alterações no código chamador. Esse é o valor: construir uma vez, reutilizar em tudo. ## O que o MCP realmente é O **Model Context Protocol** é um protocolo aberto que padroniza como modelos de IA se conectam a contexto externo e ferramentas. Pense nisso como um padrão USB-C para integrações de IA: antes dele, cada aplicativo que queria que o Claude lesse um banco de dados ou chamasse uma API precisava inventar sua própria solução. Com ele, você constrói um servidor MCP e qualquer host compatível pode usá-lo. O MCP define três coisas que um servidor pode oferecer: - **Ferramentas** — funções que o Claude pode chamar (ler um arquivo, consultar um BD, enviar mensagem no Slack) - **Recursos** — dados que o Claude pode ler (documentos, linhas de banco de dados, árvores de arquivos) - **Prompts** — templates de prompts reutilizáveis que o host pode injetar Para a maioria dos casos de uso de operadores, você está construindo **servidores de ferramentas**. Recursos e prompts vêm depois, uma vez que o básico esteja funcionando. A arquitetura é cliente-servidor, com o cliente (Claude Desktop, Claude Code, seu aplicativo personalizado) controlando tudo. O servidor é passivo — ele apenas ouve solicitações de chamada de ferramentas e retorna resultados. ## As três peças de todo servidor MCP Todo servidor MCP que você construir tem a mesma estrutura: 1. **O objeto servidor** — declara o nome, versão e capacidades do seu servidor (ferramentas, recursos, prompts) 2. **Definições de ferramentas** — uma lista de ferramentas com nomes, descrições e JSON schemas para suas entradas 3. **Handlers de requisições** — as funções que executam quando o Claude chama uma ferramenta É isso. Nenhum banco de dados, nenhum stack HTTP, nenhuma camada de auth necessária para começar. O servidor mínimo tem menos de 30 linhas de TypeScript. ## Pré-requisitos (2 minutos) - **Node.js 18+** — verifique com `node --version` - **TypeScript 5+** (incluído como dependência de desenvolvimento) - Um cliente MCP para testar — Claude Desktop é gratuito e a forma mais fácil de ver seu servidor funcionando Nenhuma chave de API Anthropic é necessária para executar um servidor MCP. A chave API vive no cliente (Claude Desktop), não no seu servidor. ## Passo 1: Configurar o projeto (3 minutos) ```bash mkdir my-mcp-server && cd my-mcp-server npm init -y npm install @modelcontextprotocol/sdk npm install -D typescript tsx @types/node ``` Adicione ao `package.json`: ```json { "type": "module", "scripts": { "build": "tsc", "dev": "tsx src/index.ts" } } ``` Crie `tsconfig.json`: ```json { "compilerOptions": { "target": "ES2022", "module": "Node16", "moduleResolution": "Node16", "outDir": "./build", "strict": true }, "include": ["src/**/*"] } ``` ## Passo 2: Escrever o servidor mínimo (5 minutos) Crie `src/index.ts`: ```typescript import { Server } from "@modelcontextprotocol/sdk/server/index.js"; import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js"; import { CallToolRequestSchema, ListToolsRequestSchema, } from "@modelcontextprotocol/sdk/types.js"; const server = new Server( { name: "my-mcp-server", version: "1.0.0" }, { capabilities: { tools: {} } } ); // Declara quais ferramentas este servidor oferece server.setRequestHandler(ListToolsRequestSchema, async () => ({ tools: [ { name: "get_word_count", description: "Conta as palavras em um bloco de texto.", inputSchema: { type: "object", properties: { text: { type: "string", description: "O texto para contar palavras", }, }, required: ["text"], }, }, ], })); // Lida com chamadas de ferramentas do cliente server.setRequestHandler(CallToolRequestSchema, async (request) => { const { name, arguments: args } = request.params; if (name === "get_word_count") { const { text } = args as { text: string }; const count = text.trim().split(/\s+/).filter(Boolean).length; return { content: [{ type: "text", text: `Contagem de palavras: ${count}` }], }; } throw new Error(`Ferramenta desconhecida: ${name}`); }); // Conectar via stdio — é assim que o Claude Desktop fala com o servidor const transport = new StdioServerTransport(); await server.connect(transport); ``` Este é o servidor completo. Ele registra uma ferramenta (`get_word_count`) e a implementa. A estrutura é o que importa. ## Passo 3: Compilar e registrar no Claude Desktop (5 minutos) Compile o TypeScript: ```bash npm run build ``` Agora registre-o no arquivo de configuração do Claude Desktop. No **macOS**: `~/Library/Application Support/Claude/claude_desktop_config.json` No **Windows**: `%APPDATA%\Claude\claude_desktop_config.json` Se o arquivo não existir, crie-o: ```json { "mcpServers": { "my-mcp-server": { "command": "node", "args": ["/caminho/absoluto/para/my-mcp-server/build/index.js"] } } } ``` Use o caminho absoluto. Reinicie o Claude Desktop após salvar. Você verá um ícone de martelo (🔨) na entrada de mensagens — isso significa que o Claude descobriu suas ferramentas. ## Passo 4: Construir uma ferramenta útil A contagem de palavras é ilustrativa. Aqui está uma ferramenta mais útil: ler arquivos de um diretório de projeto, que é o que uso para agentes de injeção de contexto que resumem bases de código, changelogs ou arquivos de configuração. ```typescript import { readFileSync, readdirSync } from "fs"; import { join, extname } from "path"; const ALLOWED_EXTENSIONS = [".md", ".txt", ".ts", ".json", ".yaml"]; const PROJECT_DIR = process.env.PROJECT_DIR ?? process.cwd(); ``` A lógica é a mesma: defina ferramentas com JSON schemas precisos, implemente os handlers, valide entradas para prevenir path traversal e retorne texto ao cliente. ## Os erros que cometi (para que você não os cometa) **O caminho deve ser absoluto.** Caminhos relativos na config do Claude Desktop não se resolvem como esperado. Sempre use o caminho completo `/home/usuario/...`. **Stdio significa nenhum `console.log` no seu servidor.** O Claude Desktop se comunica com seu servidor via stdin/stdout. Um `console.log` de depuração corrompe o stream JSON-RPC. Use stderr: ```typescript process.stderr.write(`Debug: ${message}\n`); ``` **Reinicie o Claude Desktop após cada mudança de config.** Os servidores MCP são carregados na inicialização. Um arquivo de config editado não faz nada até você fechar e reabrir o aplicativo. **Descrições de ferramentas são o produto.** O Claude decide se chama sua ferramenta com base no campo `description`. Uma descrição vaga significa que o Claude não saberá quando usá-la. Uma precisa significa que o Claude a usa no momento certo. Invista mais tempo nas descrições do que na implementação. ## Como uso servidores MCP em produção O padrão stdio funciona ótimo para Claude Desktop e Claude Code (local). Para agentes em produção — os [30+ que executo no Cloudflare Workers](/the-agent-stack-i-use-to-run-30-production-agents-no-python/) — uso a API tool-use do SDK Anthropic diretamente, pois preciso da flexibilidade para rotear para [Haiku vs Sonnet](/ai-agent-cost-math-when-haiku-beats-sonnet) por etapa. Os padrões que realmente uso em produção: 1. **Ferramentas de dev local** — servidores MCP para Claude Code que expõem ferramentas específicas do projeto 2. **Injeção de contexto** — servidores MCP que pré-carregam docs relevantes sem copiar manualmente 3. **Ponte protótipo-para-API** — construo MCP primeiro (mais rápido para iterar), depois migro a lógica para SDK tool-use para produção ## O que construir depois Uma vez que a estrutura do servidor faça sentido, as ferramentas úteis são as que acessam o contexto externo do Claude: - **Leitor de banco de dados** — executa uma consulta SQL somente leitura e retorna resultados como JSON - **Leitor Slack** — busca as últimas N mensagens de um canal - **Leitor GitHub** — lista PRs abertas, lê um arquivo em um commit específico - **Wrapper de API interna** — chama sua própria API REST com headers de auth integrados ## Perguntas frequentes ### Preciso de uma chave API Anthropic para construir um servidor MCP? Não. Seu servidor MCP não chama a API Anthropic. Ele apenas responde a solicitações de chamada de ferramentas do cliente. A chave API vive no cliente, não no servidor. ### Meu servidor MCP pode chamar APIs externas? Sim — o handler é apenas código TypeScript assíncrono. Busque uma API do tempo, consulte um banco de dados, escreva em um arquivo. O servidor não se importa com o que o handler faz internamente. ### Qual é a diferença entre os transportes stdio e HTTP? Stdio é para servidores locais — mesma máquina que Claude Desktop ou Claude Code. HTTP com SSE é para servidores remotos que você pode implantar como serviço web. Comece com stdio; é mais simples de depurar. ### Como o Claude sabe quando chamar minha ferramenta? O Claude decide com base no campo `description` da ferramenta e no contexto da conversa. Se o Claude continua ignorando sua ferramenta, refine a descrição. --- ## Como validar uma ideia de negócio antes de construí-la Source: https://alejandrorioja.com/pt/how-to-validate-a-business-idea/ Published: 2026-06-20 Tags: Entrepreneurship, Growth TL;DR: A maioria das ideias de negócio falha não por má execução, mas por pular a validação. O caminho mais rápido: confirme que o problema existe via demanda de pesquisa e evidências em fóruns, analise concorrentes para provar que alguém já está ganhando dinheiro, construa o menor teste possível e obtenha um compromisso — um depósito, uma inscrição em lista de espera, uma carta de intenção — antes de construir qualquer coisa. Se não conseguir fazer uma única pessoa se comprometer, a ideia ainda não está pronta. ## Table of contents _Atualizado em junho de 2026._ **TL;DR:** A maioria das ideias de negócio falha não por má execução, mas por pular a validação. O caminho mais rápido: confirme que o problema existe via demanda de pesquisa e evidências em fóruns, analise concorrentes para provar que alguém já está ganhando dinheiro, construa o menor teste possível e obtenha um compromisso — um depósito, uma inscrição em lista de espera, uma carta de intenção — antes de construir qualquer coisa. Se não conseguir fazer uma única pessoa se comprometer, a ideia ainda não está pronta. **[Perspectiva do operador]** Vi esse padrão dezenas de vezes em fundadores com quem trabalhei e nos meus próprios projetos: a ideia soa convincente, o fundador é apaixonado, a execução é sólida — e então lançam para o silêncio. Não porque construíram a coisa errada, mas porque pularam o único passo que os teria dito isso antes de passar seis meses nisso. Aqui está o framework de validação que uso e recomendo. ## Por que a maioria dos esforços de validação falha O modo óbvio de falha é nenhuma validação — construir primeiro, fazer perguntas depois. Mas a armadilha mais sutil é o teatro de validação: executar pesquisas, falar com amigos, coletar respostas vagas de "ótima ideia!" e chamar isso de sinal. Pesquisas mentem. As pessoas são educadas. Perguntadas "você pagaria 50 $ por isso?" em um contexto hipotético, a resposta é quase sempre sim. O único sinal que importa é o compromisso: alguém realmente dando dinheiro, tempo ou uma carta de intenção escrita. Todo o resto é redução de ruído, não validação. ## Passo 1: Confirme que o problema realmente existe em escala Antes de validar sua solução, valide que o problema é real e buscado. **A demanda de pesquisa é o proxy mais rápido.** Digite seu problema no Google. Veja as sugestões de autocompletar, a seção "As pessoas também perguntam" e as páginas mais bem classificadas. Se não houver resultados, ninguém está pesquisando — e um negócio que resolve um problema que ninguém busca gastará toda a sua energia em educação em vez de conversão. Use uma ferramenta de palavras-chave como o [Semrush](/recommends/semrush) para verificar o volume mensal real de pesquisas. Um problema com 1.000–10.000 pesquisas mensais no seu mercado-alvo é viável. Um problema com 20 pesquisas por mês é um produto de nicho com um problema de distribuição. **As evidências em fóruns são uma camada qualitativa adicional.** Pesquise no Reddit, Quora, grupos de Facebook de nicho e comunidades do Discord sobre seu problema. As pessoas estão reclamando ativamente disso? Buscando soluções? Alternativas? A frustração real é ouro — significa que a dor é forte o suficiente para motivar as pessoas a buscar ajuda publicamente. Se você não conseguir encontrar 20 tópicos em fóruns de pessoas reais descrevendo o problema, seja cético. ## Passo 2: Analise os concorrentes — prova de que o dinheiro já existe Um instinto comum de fundador: "não há concorrência, então vou dominar o mercado." Isso é quase sempre errado. Nenhuma concorrência geralmente significa nenhum mercado. A concorrência é a prova de que clientes existem e pagarão. Pesquise no Google sua categoria de solução. Quem está ranqueando? O que suas páginas de destino prometem? Quanto cobram? Leia seus depoimentos e avaliações — especialmente os negativos. Avaliações negativas são um roteiro de produto: mostram exatamente o que o mercado quer mas não está obtendo. Se você encontrar 3–5 concorrentes estabelecidos com produtos reais e clientes reais, é um sinal saudável. Se encontrar zero, pesquise mais antes de concluir que o mercado não existe — ou trate como um sinal de alerta. **Perguntas-chave a responder:** 1. Quem são os 3–5 principais players? 2. Quanto cobram? 3. O que os avaliadores estão criticando? 4. Há um gap de posicionamento que posso ocupar? ## Passo 3: Construa o menor teste de fumaça possível Depois de saber que o problema existe e há dinheiro no mercado, construa o artefato mínimo necessário para testar se *sua* versão ganha tração. Isso não é um produto completo. É um mecanismo de captura de sinal. **Opção A: Página de destino com captura de e-mail.** Um site de uma página descrevendo o problema e a solução, com um CTA "Junte-se à lista de espera" ou "Obtenha acesso antecipado". A taxa de conversão diz se seu posicionamento ressoa. Ferramentas como Webflow, Carrd ou até uma página pública do Notion funcionam bem — não complique demais. **Opção B: Pré-venda.** Um fluxo de checkout real com dinheiro real. Este é o sinal de maior qualidade. Se alguém der dinheiro por algo que ainda não existe, acredita na solução. Até um depósito reembolsável funciona. **Opção C: MVP de concierge.** Faça a coisa manualmente antes de automatizá-la. Consultoria em vez de SaaS. Uma planilha personalizada em vez de uma ferramenta de software. Uma newsletter curada manualmente em vez de uma gerada por IA. Você serve um punhado de clientes com força bruta, aprende exatamente o que eles valorizam e então constrói o produto em torno disso. ## Passo 4: Obtenha um compromisso antes de construir Este é o portão que separa a validação real do pensamento desejoso. Defina o que "compromisso" significa para sua ideia antes de executar o teste: - **SaaS / software:** Uma pré-venda a preço com desconto, ou uma carta de intenção assinada - **Conteúdo / mídia:** Assinantes de e-mail que clicaram para participar (não apenas seguidores) - **Serviços / consultoria:** Uma chamada de descoberta paga ou uma proposta assinada - **Produto físico:** Um depósito ou pré-encomenda no Kickstarter Se não conseguir que pelo menos uma pessoa se comprometa — mesmo com desconto, mesmo com garantia de devolução do dinheiro — a ideia não está pronta. Isso não é fracasso; é o sistema funcionando. Economizou meses de tempo de desenvolvimento. ## Passo 5: Estabeleça um limite de aprovação/reprovação antes de começar A armadilha é esta: você executa seu teste, obtém resultados mornos e se convence a prosseguir de qualquer maneira. "O texto da página de destino não era bom." "Não promovi o suficiente." "Só precisa de mais tempo." Pare. Antes de executar o teste, escreva o limite: > "Se eu conseguir 50 inscrições na lista de espera em 14 dias com R$ 0 em anúncios pagos, construo. Se não atingir 50, não construo — ou mudo o posicionamento ou encerro a ideia." Escreva. Diga a um amigo. Torne público se puder. Então cumpra. O número é arbitrário; o que importa é que você decide com antecedência e não move as balizas quando os dados chegam frios. ## Erros comuns de validação 1. **Perguntar às pessoas se comprariam.** Elas quase sempre dizem sim para ser educadas. A única pergunta que conta é: "Você compra agora?" 2. **Validar com amigos e família.** Eles estão torcendo por você. Eles não são seus clientes. 3. **Resolver seu próprio problema sem verificar se outros o têm.** Seu problema pode ser único para você. Verifique os fóruns. 4. **Chamar respostas de pesquisas de validação.** Uma pesquisa pode gerar ideias. Não pode validar a demanda. Só dinheiro ou compromisso genuíno podem. 5. **Esperar por informações perfeitas.** Validação é obter sinal suficiente para dar o próximo passo, não eliminar a incerteza completamente. ## O que os sinais de "vai" significam Você está procurando uma combinação de: 1. Volume de pesquisa acima de 1.000 pesquisas mensais para a palavra-chave principal do problema 2. Atividade de concorrentes — 3+ players reais cobrando dinheiro real 3. Pelo menos 20 tópicos em fóruns ou comunidades mostrando frustração ativa com o problema 4. Taxa de conversão do teste de fumaça acima de 5% em tráfego direcionado 5. Pelo menos uma pessoa se compromete — paga, assina ou deposita — sem que você precise implorar Alcance todos os cinco e você tem uma direção viável. Alcance dois ou três e você tem um sinal que vale a pena refinar. Alcance zero e você precisa de uma ideia ou público fundamentalmente diferente. ## A pilha de validação As ferramentas que uso e recomendo para este processo: - **Demanda de pesquisa:** [Semrush](/recommends/semrush) — volume de palavras-chave, análise de concorrentes e lacunas de conteúdo em um só lugar - **Pesquisa em fóruns:** Reddit, Quora, grupos de Facebook de nicho, comunidades do Discord - **Página de destino:** Carrd (gratuito, rápido) ou Webflow para mais controle de design - **Captura de e-mail / lista de espera:** Kit (ConvertKit) para começar a construir a lista enquanto valida - **Pagamentos:** Stripe — link direto para um checkout antes de construir o produto - **Analytics:** Google Analytics na sua página de teste para rastrear o comportamento real ## A conclusão do operador A coisa mais cara que você pode construir é um produto que ninguém quer. Validação não é sobre eliminar riscos — é sobre falhar rápido no papel em vez de falhar devagar na produção. Execute o teste, obtenha um compromisso, estabeleça o limite antes de começar e honre o resultado. Se o sinal estiver lá, você saberá. Se não estiver, você também saberá. --- **Relacionado:** [Como construir um negócio lucrativo](/how-to-build-profitable-business/) · [Guia de estratégias de marketing de crescimento](/growth-marketing-strategies-guide/) · [Como se tornar um empreendedor](/how-to-become-an-entrepreneur/) --- ## Prompt Caching com a API da Claude: Reduza Seus Custos de Entrada Sem Trocar de Modelo Source: https://alejandrorioja.com/pt/prompt-caching-cut-your-claude-costs-without-switching-models/ Published: 2026-06-18 Updated: 2026-06-18 Tags: AI Agents, Operations TL;DR: O prompt caching reduz o custo de entradas grandes e estáveis — seu prompt de sistema, definições de ferramentas, exemplos few-shot — para cerca de 10% do preço normal de entrada em requisições repetidas. O mecanismo é uma correspondência de prefixo: coloque um marcador cache_control no final do seu conteúdo estável e mantenha tudo o que é volátil depois dele. O erro que destrói a taxa de acerto do cache é deixar um timestamp ou UUID flutuar para dentro do prefixo. ## Table of contents _Atualizado em junho de 2026._ **TL;DR:** O prompt caching reduz o custo de entradas grandes e estáveis — seu prompt de sistema, definições de ferramentas, exemplos few-shot — para cerca de 10% do preço normal de entrada em requisições repetidas. O mecanismo é uma correspondência de prefixo: coloque um marcador `cache_control` no final do seu conteúdo estável e mantenha tudo o que é volátil depois dele. O erro que destrói a taxa de acerto do cache é deixar um timestamp ou UUID flutuar para dentro do prefixo. **[Leitura do operador]** Eu opero mais de 100 agentes entre minha marca de consultoria e a Pickleland. O maior item de custo não é o tier do modelo — é a frequência com que reenvio o mesmo prompt de sistema de 4.000 tokens em cada requisição. O prompt caching reduziu esse custo a quase nada nos agentes de alta frequência, sem mexer no modelo nem na qualidade da saída. Veja exatamente como funciona e onde estão as armadilhas. ## O que o prompt caching realmente faz Toda chamada à API da [Claude](/recommends/claude) envia tokens. Sem cache, cada token da sua requisição — prompt de sistema, definições de ferramentas, exemplos few-shot e a mensagem do usuário — é cobrado pela taxa normal de entrada. Com cache, um prefixo desses tokens fica armazenado nos servidores da Anthropic após a primeira requisição. Nas requisições seguintes que compartilham exatamente esse prefixo, você paga um preço de *leitura* de cache em vez de reprocessá-los do zero. A diferença de custo é real: - **Escrita de cache:** ~1,25× o preço base de entrada (TTL de 5 minutos) ou ~2× (TTL de 1 hora) - **Leitura de cache:** ~0,1× o preço base de entrada - **Ponto de equilíbrio:** 2 requisições com TTL de 5 minutos, 3 requisições com TTL de 1 hora Uma vez ultrapassado o ponto de equilíbrio — o que acontece rápido em qualquer agente executado mais do que algumas vezes por dia — cada acerto de cache adicional representa um desconto de ~90% sobre esses tokens. ## A invariante de correspondência de prefixo Esta é a regra que tudo o mais segue: **a chave de cache é uma correspondência de prefixo do seu prompt renderizado**. Os servidores da Anthropic armazenam o conteúdo renderizado desde o início do seu prompt até o marcador `cache_control`. Para que ocorra um acerto de cache na próxima requisição, cada token desde o início do prompt até esse marcador precisa ser idêntico — byte por byte. A ordem de renderização para a correspondência de prefixo é: tools → system → messages. Ou seja, seu array de ferramentas é processado por hash primeiro, depois o bloco de sistema, e então as mensagens em ordem. O que isso significa na prática: o conteúdo estável precisa vir primeiro. Se o seu prompt de sistema referencia qualquer coisa dinâmica — a data atual, um ID de usuário, um ID de rastreamento da requisição — e isso aparece *antes* do marcador `cache_control`, o cache vai falhar em todas as requisições, porque o prefixo fica mudando. ## Em que colocar um marcador de cache Os alvos de maior alavancagem são: **1. Seu prompt de sistema** Prompts de sistema costumam ser o maior bloco estável. Uma persona de agente detalhada, uma lista de regras de comportamento, um conjunto de instruções de formato de saída — tudo isso é idêntico em cada invocação do mesmo agente. Marque-o: ```typescript import Anthropic from "@anthropic-ai/sdk"; const client = new Anthropic(); const response = await client.messages.create({ model: "claude-opus-4-8", max_tokens: 1024, system: [ { type: "text", text: `You are a content operations agent for alejandrorioja.com. Your job is to draft blog posts in Alejandro's voice: direct, practitioner, first-person, numbered lists, honest caveats. No hedging. No filler. Every section must earn its place. [... 2000 more tokens of stable instructions ...]`, cache_control: { type: "ephemeral" }, }, ], messages: [ { role: "user", content: "Draft a post about prompt caching.", }, ], }); ``` O `cache_control: { type: "ephemeral" }` no bloco de sistema diz à Claude para armazenar em cache tudo até e incluindo esse bloco. O array `messages` é volátil — diferente a cada requisição — e fica fora do limite do cache. **2. Definições de ferramentas** Se o seu agente usa ferramentas, essas definições podem ser substanciais. Um schema de ferramenta bem documentado, com descrição, nomes de parâmetros e valores de enum, pode chegar a 500–1.000 tokens por ferramenta. Com 5 ferramentas, isso são até 5.000 tokens que você paga para reprocessar em cada chamada: ```typescript const response = await client.messages.create({ model: "claude-opus-4-8", max_tokens: 1024, tools: [ { name: "search_airtable", description: "Search the Airtable content queue...", input_schema: { type: "object", properties: { query: { type: "string" } } }, }, // ... more tools ... { name: "post_to_kit", description: "Schedule a broadcast via the Kit API...", input_schema: { /* ... */ }, // Mark the last tool to cache the entire tools array } as Anthropic.Tool & { cache_control: { type: "ephemeral" } }, ], system: "...", messages: [...], }); ``` Marque a *última* ferramenta do array. A correspondência de prefixo cobrirá todo o array de ferramentas a partir desse ponto. **3. Exemplos few-shot nas mensagens** Se você passa exemplos few-shot estáticos como mensagens iniciais no array `messages`, eles também podem ser armazenados em cache. Estruture-os como as primeiras N mensagens e marque o último turno de exemplo: ```typescript const messages: Anthropic.MessageParam[] = [ { role: "user", content: [ { type: "text", text: "Here are examples of posts in my voice:\n\n[Example 1...]\n\n[Example 2...]", cache_control: { type: "ephemeral" }, } as Anthropic.TextBlockParam & { cache_control: { type: "ephemeral" } }, ], }, { role: "assistant", content: "Understood. I'll follow that voice.", }, // The actual user turn follows — this is volatile, no cache marker { role: "user", content: actualUserRequest, }, ]; ``` ## O que NÃO armazenar em cache (invalidadores silenciosos) Estas são as coisas que parecem estáveis, mas não são — e vão destruir sua taxa de acerto silenciosamente. A API não vai avisar você. Você simplesmente vai ver `cache_creation_input_tokens` em cada requisição e se perguntar por quê. **Timestamps no prompt de sistema.** O erro mais comum de todos: ```typescript // This invalidates the cache on every request const system = `You are an agent. Current time: ${new Date().toISOString()}`; ``` Mova os timestamps para a mensagem do usuário, que é onde eles pertencem: ```typescript // Stable system prompt — cacheable const system = `You are an agent. Use the current time provided by the user.`; // Volatile user message — not cached const userMessage = `Current time: ${new Date().toISOString()}. Run the daily brief.`; ``` **UUIDs aleatórios e IDs de rastreamento.** Mesmo problema. Se você injeta um ID de rastreamento no bloco de sistema para fins de log, cada requisição recebe um prefixo novo. **Serialização de JSON não determinística.** Se você serializa um objeto dentro do prompt de sistema e a ordem das chaves não é garantida, a string renderizada pode diferir mesmo quando os dados subjacentes são os mesmos. Serialize com uma ordem de chaves estável ou use uma template string. **Seleção dinâmica de few-shot.** Se você escolhe exemplos few-shot com base na consulta atual e os coloca no prefixo armazenado em cache, você tornou o prefixo "estável" dependente da consulta. Ou comprometa-se com exemplos fixos para a camada de cache, ou mova os exemplos dinâmicos para o turno de mensagem não armazenado em cache. ## Verificando sua taxa de acerto de cache Toda resposta inclui metadados de uso. Confira-os: ```typescript const response = await client.messages.create({ /* ... */ }); console.log({ inputTokens: response.usage.input_tokens, cacheRead: response.usage.cache_read_input_tokens, cacheWrite: response.usage.cache_creation_input_tokens, outputTokens: response.usage.output_tokens, }); ``` Na primeira requisição: `cache_creation_input_tokens` será diferente de zero, `cache_read_input_tokens` será 0. Essa é a escrita. Em um acerto de cache: `cache_read_input_tokens` será diferente de zero, `cache_creation_input_tokens` será 0. Essa é a leitura. Se você está vendo `cache_creation_input_tokens` em cada requisição, seu prefixo está mudando. Adicione uma instrução de log que imprima os primeiros 200 caracteres do seu prompt de sistema renderizado antes de cada chamada — um timestamp flutuante salta aos olhos imediatamente. ## O TTL de 1 hora: quando vale o custo extra de escrita O TTL padrão é de 5 minutos. Se o seu agente roda em baixa frequência — menos de uma vez a cada 5 minutos — você estará pagando custos de escrita de cache na maioria das requisições sem obter leituras. ```typescript // Opt into a 1-hour TTL cache_control: { type: "ephemeral", ttl: "1h" } ``` A escrita de 1 hora custa ~2× o preço base de entrada em vez de 1,25×. A conta: se você está acertando o cache 3 ou mais vezes por hora, o TTL de 1 hora economiza dinheiro. Se o seu agente roda uma vez por dia (como meu briefing diário), nem mesmo o TTL de 1 hora ajuda — você paga custos de escrita toda vez. Nesse caso, o benefício do cache é modesto, a menos que o prompt de sistema seja enorme. Meu agente de briefing diário tem um prompt de sistema de 3.000 tokens, mas roda uma vez por dia. O cache não ajuda. Meu agente de newsletter roda dezenas de vezes por sessão enquanto escreve rascunhos — o cache economiza substancialmente. ## Pré-aquecimento: tornando a primeira requisição barata Se você tem um pico de tráfego conhecido a caminho — um job em lote, o lançamento de uma API — você pode pré-aquecer o cache com uma requisição fictícia de baixo custo: ```typescript // Pre-warm: write the cache at near-zero output cost await client.messages.create({ model: "claude-opus-4-8", max_tokens: 1, // minimal output system: [{ type: "text", text: stableSystemPrompt, cache_control: { type: "ephemeral" } }], messages: [{ role: "user", content: "ping" }], }); // Now the real requests read from cache ``` Isso é útil principalmente para processamento em lote, onde você sobe muitas requisições paralelas e quer que cada uma acerte um cache quente, em vez de competir para escrevê-lo. ## Prompt caching em loops agênticos Em um loop agêntico de múltiplos turnos, o histórico da conversa cresce a cada turno. O cache é inteligente o suficiente para lidar com isso: ele usa uma janela de lookback de 20 blocos, encontrando o maior prefixo correspondente dentro dos últimos 20 blocos de conteúdo. A implicação prática: mantenha seu conteúdo estável (prompt de sistema, definições de ferramentas) ancorado no topo. O histórico crescente da conversa no final do array de mensagens não quebrará a correspondência de prefixo dos blocos estáveis — eles vêm antes do conteúdo volátil, e a correspondência de prefixo começa do topo. Na prática, meus agentes estruturam os turnos assim: ``` System (cached) → Tools (cached) → Few-shot (cached) → Turn 1 → Turn 2 → ... → Current turn ``` O cache cobre tudo até o marcador de few-shot. O histórico crescente de turnos depois dele é reprocessado a cada vez, mas tudo bem — esses tokens são específicos da sessão e pequenos em relação ao prefixo estável. ## Como isso aparece na fatura Tome um agente de alta frequência: 100 chamadas por dia, prompt de sistema de 4.000 tokens, preços do Sonnet. Sem cache: - 100 × 4.000 tokens × US$ 3/1M = **US$ 1,20/dia** Com cache (TTL de 5 min, supondo 50 chamadas/hora no pico): - 1 escrita a cada 5 minutos × US$ 3,75/1M × 4.000 tokens = ~US$ 0,02/dia em escritas - ~98 leituras/dia × US$ 0,30/1M × 4.000 tokens = **US$ 0,12/dia em leituras** Isso é uma redução de aproximadamente 90% sobre esses tokens de entrada. Em escala — 1.000 chamadas por dia — a diferença se acumula ainda mais. E isso vem por cima de qualquer economia de roteamento de modelo da [matemática Haiku vs Sonnet](/ai-agent-cost-math-when-haiku-beats-sonnet): o cache funciona em todos os tiers. ## A conclusão do operador O prompt caching é a otimização de custo mais fácil na API da Claude: um campo adicional nos blocos de conteúdo que você já está escrevendo. A restrição é disciplina em torno da estabilidade do prefixo — nada dinâmico antes do marcador de cache. Se você conseguir manter seu prompt de sistema, suas ferramentas e quaisquer exemplos estáticos livres de conteúdo volátil, você pagará ~10% do custo normal de entrada em cada acerto de cache. Para agentes de alta frequência com prompts grandes e estáveis, essa é uma alavanca maior do que trocar de tier de modelo. --- **Relacionados:** [Matemática de Custo de Agentes de IA: Quando o Haiku Vence o Sonnet](/ai-agent-cost-math-when-haiku-beats-sonnet/) · [Agentes Acionados por Eventos vs Agendados](/event-triggered-vs-scheduled-agents-which-pattern-for-which-job/) · [As 5 Ferramentas de IA Que Realmente Uso Para Tocar Meu Negócio](/the-5-ai-tools-i-actually-use-to-run-my-business-2026-operator-stack/) --- ## 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](/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](/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, ou use um verificador especializado como [mentioned.at](https://mentioned.at) se você não quiser construir o agente sozinho. 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-17 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-23 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-28 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-19 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-26 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-26 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: