Agente de trading com IA no Claude Code: o que esse sistema 24/7 acerta

Já vi muitas demos de agentes de IA que desmoronam no instante em que tocam o mundo real.

Parecem impecáveis até o momento em que dinheiro, timing, ambiguidade ou falha entram em cena. Aí a coisa toda vira um prompt polido amarrado a um julgamento ruim.

Por isso esse passo a passo de um agente de trading com IA 24/7 chamou minha atenção.

Não porque prometia uma máquina mágica de imprimir dinheiro. Não porque usava um modelo maior. E definitivamente não porque "robô de trading com IA" seja uma expressão que costuma atrair engenheiros cuidadosos. Chamou minha atenção porque o sistema foi enquadrado da forma certa: rotinas, arquivos de memória, guard-rails, paper trading, autonomia restrita e uma estratégia construída em torno de decisões mais lentas e baseadas em fundamentos, em vez de tentar fazer scalping de candles a cada três minutos.

Esse é um design muito mais sério.

Este artigo é baseado em um vídeo que analisei e nos detalhes do sistema apresentados ali, não em um agente de trading que eu mesmo coloquei no ar com capital real.

A configuração no walkthrough usa Claude Opus dentro do Claude Code, com o projeto atualizado de Opus 4.6 para Opus 4.7 para um comportamento agêntico mais forte. Em volta desse modelo existe um sistema operacional prático: Alpaca para corretagem, Perplexity para pesquisa de mercado, ClickUp para notificações, GitHub para persistência de estado e rotinas agendadas que mantêm o agente em movimento mesmo quando ninguém está sentado em frente ao teclado.

Se você tira o hype de "trader com IA", o que está vendo na verdade é um pipeline de decisão rodando continuamente, com memória, ferramentas e restrições de risco.

Essa distinção importa.

Porque a pergunta interessante não é "o Claude consegue comprar ações?".

Claro que consegue, se você ligar ele a uma API de corretagem.

A pergunta de verdade é esta: você consegue construir um sistema que continue tomando decisões sãs quando o mercado está ruidoso, a janela de contexto é finita, as suposições de ontem estão meio erradas e ninguém está por perto para vigiar cada movimento?

Essa é a parte que esse walkthrough leva a sério. E é por isso que acho que vale a pena estudar mesmo que você nunca deixe uma IA tocar uma conta de corretagem real.

Isso não é um robô de day trading, e isso é uma força

A decisão mais inteligente em toda a arquitetura é a que a maioria das pessoas vai ignorar.

Esse agente não é posicionado como um monstro de alta frequência caçando trades de menos de um segundo. Ele não está tentando superar market makers. Ele não está fingindo que o Claude virou uma mesa quant com infraestrutura colocalizada e um time de pesquisa com PhD.

Ele foi feito para um estilo mais lento: swing trades, períodos de holding mais longos, fundamentos, pesquisa de catalisadores, revisões de portfólio e janelas de execução disciplinadas.

Essa escolha já torna o projeto inteiro mais crível.

Modelos de linguagem grandes são bons em síntese. Eles conseguem ler entradas bagunçadas, ponderar sinais conflitantes, produzir raciocínio escrito, comparar narrativas e manter um enquadramento estratégico em mente quando a tarefa está bem delimitada. Isso casa muito melhor com "pesquisar uma empresa, inspecionar catalisadores, comparar convicção, dimensionar o risco, registrar a decisão" do que com "prever o próximo movimento de cinco minutos no SPY".

O walkthrough reforça isso com um benchmark que acho que as pessoas costumam entender mal: análise financeira agêntica. Esse tipo de avaliação não é realmente sobre virar uma máquina de scalping. É sobre se o modelo consegue estudar empresas, raciocinar sobre fundamentos e produzir teses de investimento coerentes.

Esse é um caso de uso completamente diferente do day trading técnico.

E se eu fosse construir qualquer coisa nessa categoria, faria exatamente a mesma aposta: deixar o modelo operar onde linguagem, pesquisa e enquadramento de decisão realmente importam.

O verdadeiro produto aqui é o sistema de rotinas

A maioria das pessoas que assiste a um vídeo desses foca na integração com a corretora, porque essa é a parte chamativa. Compra. Venda. Posição aberta. Trade executado.

Acho que isso ignora a vitória de engenharia de verdade.

O verdadeiro produto é a camada de rotinas.

O walkthrough divide o agente em jobs agendados ao longo da semana de trading:

• Pesquisa pré-mercado
• Execução na abertura do mercado
• Gestão de risco no meio do dia
• Revisão no fechamento do mercado
• Avaliação semanal de performance

Esse cronograma é o que transforma um prompt avulso num sistema operacional.

Sem rotinas, você não tem um agente autônomo. Você tem uma sessão de chat esperta que esquece tudo no instante em que a janela fecha.

Com rotinas, você tem comportamento repetido sob condições previsíveis. O agente acorda, lê a memória, checa o ambiente, executa um job definido, atualiza logs e entrega um estado melhor para a próxima execução. Esse padrão é muito mais valioso do que o nicho de trading em si. Você poderia reusar o mesmo design para prospecção de vendas, monitoramento de segurança, triagem de suporte, pesquisa de conteúdo ou manutenção de infraestrutura. É a mesma razão pela qual fiquei animado com tasks e execução paralela no Claude Code: a alavancagem vem da orquestração repetível, não de um único prompt impressionante.

Essa é uma das maiores mudanças de mentalidade que tive trabalhando com sistemas de IA: o moat normalmente não é o prompt. É o loop.

Um sistema de rotinas forte faz três coisas ao mesmo tempo:

1. Estreita o trabalho de cada execução.
2. Torna as falhas mais fáceis de inspecionar.
3. Acumula aprendizado ao longo do tempo via arquivos, logs e revisões.

É exatamente isso que esse projeto está fazendo.

Execuções stateless, memória stateful

Essa é a parte que mais gostei.

Cada execução de rotina é tratada como stateless no momento da execução, mas o sistema mais amplo continua stateful por meio de arquivos. Esse é um padrão muito prático para trabalho com Claude Code.

Em vez de fingir que o modelo vai "simplesmente lembrar", o agente lê e escreve sua memória explicitamente:

• arquivos de estratégia
• notas de pesquisa
• histórico de trades
• logs diários
• resumos
• snapshots de portfólio

Isso dá a cada execução uma camada de continuidade sem forçar todo o conhecimento a viver dentro de uma única conversa inchada.

Vi muitos workflows de IA falharem porque o construtor assume que uma janela de contexto grande resolve a persistência. Não resolve. Mais contexto ajuda, mas também tenta as pessoas a empurrar tudo para um único lugar até o sinal ficar embaçado. O walkthrough até menciona isso com a preocupação de orçamento de tokens: cerca de 200.000 tokens parecem enormes, até você misturar instruções de sistema, logs, pesquisa anterior, respostas de API e contexto de mercado ao vivo na mesma execução.

Aí começa a podridão.

Não é uma falha dramática. Pior. É uma degradação silenciosa.

O modelo continua escrevendo um output fluente, mas o julgamento fica menos afiado. Suposições antigas persistem por tempo demais. Novas evidências recebem peso de menos. Trade-offs achatam em resumos genéricos. Isso é perigoso em qualquer workflow autônomo, e especialmente perigoso em algo que toca dinheiro.

Arquivos de memória externa são a contramedida certa.

Eles te forçam a estruturar o estado de forma intencional. O que é estratégia durável? O que é pesquisa temporária? O que pertence ao diário de trades? O que deveria ser resumido em vez de copiado para frente cru? Quando você passa a pensar assim, o agente fica mais fácil de escalar e muito mais fácil de debugar. Já vi o mesmo princípio aparecer em sistemas Claude Code que se autoaprimoram, onde os ganhos reais vêm do que o agente preserva, audita e refina ao longo do tempo.

Por que o Opus 4.7 encaixa melhor nesse tipo de trabalho

O walkthrough enquadra a mudança do Opus 4.6 para o Opus 4.7 em torno de uma performance agêntica mais forte: melhor julgamento em situações ambíguas e melhor autoverificação. Eu desempacotei essa mudança de modelo de forma mais direta na minha análise do Opus 4.7, mas nesse setup de trading a pergunta prática é mais simples: o modelo se comporta como um operador melhor ao longo de execuções agendadas repetidas?

Isso importa mais aqui do que eloquência pura.

Uma rotina de trading é cheia de perguntas bagunçadas que não têm rótulos claros:

• Essa notícia é significativa ou só ruído?
• A tese da posição está quebrada ou só desconfortável?
• O agente deveria esperar confirmação ou agir agora?
• A nota anterior ainda se aplica depois do catalisador de hoje?
• Essa convicção é alta o bastante para abrir risco, ou é só uma ideia interessante?

Esses são problemas de julgamento.

Na minha experiência, os sistemas de IA que sobrevivem mais tempo em produção não são os que parecem mais inteligentes numa demo. São os que hesitam corretamente, verificam antes de agir e permanecem coerentes quando a entrada está incompleta.

É por isso que o enquadramento de "workflow agêntico" importa. Se um modelo é melhor em checar o próprio raciocínio, cruzar referências em arquivos e resistir ao impulso de improvisar além das evidências, essa é exatamente a melhoria que você quer num sistema autônomo agendado.

Eu ainda não confiaria nisso cegamente. Mas com certeza preferiria esse perfil a um modelo otimizado principalmente para prosa bonita ou velocidade de coding em uma única tacada.

A melhor parte da estratégia é o desenho de risco

O walkthrough menciona um desafio de 30 dias em que o sistema anterior superou o S&P 500 em 8%.

É um resultado divertido. Também não deveria ser o aprendizado principal.

Janelas curtas podem favorecer quase qualquer coisa. Um mês bom não é uma vantagem durável. Muitos sistemas imprudentes parecem brilhantes pouco antes de explodir.

O que me importa mais é o desenho dos guard-rails:

• tamanho máximo de posição em torno de 5% por posição
• limites para novas posições
• limites de perda diária
• gestão de stops
• paper trading primeiro

Isso é comportamento adulto.

Se você vai automatizar qualquer coisa com consequências financeiras, a primeira camada de design não deveria ser "como faço para ele ser mais agressivo?". Deveria ser "como impeço ele de fazer alguma besteira às 9h47 numa terça-feira esquisita?".

O cronograma de rotinas reflete bem essa mentalidade.

Pré-mercado é para pesquisa e geração de ideias.

Abertura de mercado é para executar trades planejados, em vez de improvisar do zero.

Meio-dia é para cortar perdedores e apertar o controle sobre vencedores.

Revisão semanal é para avaliar o sistema e ajustar a meta-camada.

Esse ritmo empurra o agente para longe de comportamento impulsivo e em direção à disciplina de processo. Até o uso de trailing stops e limiares de perda mostra consciência de que confiança da IA não é a mesma coisa que controle de risco.

Se eu fosse adaptar essa arquitetura, trataria esses guard-rails como o produto principal de fato e a geração de sinais como a camada secundária. Sinais vêm e vão. A arquitetura de risco é o que mantém o experimento vivo tempo suficiente para aprender.

Usar o GitHub como camada de persistência é uma escolha esperta e chata

Falo isso como elogio.

Um dos sinais mais fortes de que um sistema foi construído por alguém prático é quando a camada de persistência é chata de propósito.

Esse projeto guarda o estado de trabalho num repositório privado no GitHub. As rotinas na nuvem clonam o repo, rodam o job, atualizam arquivos e dão commit das mudanças de volta. Isso significa que a memória do agente, logs, documentos de estratégia e histórico operacional vivem todos numa linha do tempo versionada e inspecionável.

Isso é dramaticamente melhor do que esconder tudo dentro de um histórico de chat efêmero.

Também te dá algumas vantagens concretas:

• você pode inspecionar como a estratégia evoluiu
• você pode comparar mudanças semanais em prompts ou arquivos de memória
• você pode se recuperar de edições ruins
• você pode auditar por que uma decisão aconteceu
• você pode migrar o sistema entre ambientes sem reconstruir o estado manualmente

Existe uma lição mais profunda aqui também.

Quando as pessoas falam sobre "agentes de IA", muitas vezes ficam obcecadas com o modelo e investem pouco na higiene de software ao redor. Mas autonomia sem auditabilidade é só caos com um branding bonito.

Um sistema de memória apoiado em Git não é glamouroso. É exatamente o tipo de infraestrutura chata que torna workflows autônomos sustentáveis.

A camada de notificação diz muito sobre quem construiu

O walkthrough usa o ClickUp para resumos e alertas, em vez de cair no padrão Telegram ou em algum canal de notificação mais barulhento.

É uma escolha pequena, mas revela algo útil: o sistema não está tentando transformar cada mudança de estado em drama.

Bons workflows autônomos deveriam ser orientados a interrupção, não a ruído.

Pré-mercado só envia mensagens urgentes.

A abertura do mercado só notifica quando um trade realmente acontece.

O meio-dia registra a atividade sem fazer spam.

A revisão semanal produz um resumo digerível.

Esse é o padrão certo. Se cada rotina grita por atenção, o operador humano acaba ignorando tudo. Uma camada de notificação útil só escala quando uma pessoa precisa de fato saber de algo.

Isso importa mesmo fora de trading. Eu uso o mesmo princípio em design de automação em geral: se um workflow me cutuca cada vez que respira, eu construí um robô carente, não um sistema confiável.

A maior lição: ensine o agente como um iniciante, não como um gênio

Minha analogia favorita do walkthrough é a de andar de bicicleta.

Você não joga alguém no trânsito no primeiro dia e chama isso de estratégia de aprendizado.

Você começa com rodinhas. Depois numa rua silenciosa. Depois numa estrada de verdade.

É exatamente assim que esses sistemas deveriam ser construídos.

Comece com paper trading.

Escreva a estratégia com clareza.

Defina o que conta como sinal válido.

Registre cada ação.

Revise os erros.

Aperte os prompts.

Aumente a autonomia aos poucos.

Essa progressão é muito mais saudável do que a abordagem comum de "conectar o modelo na API e rezar". Ela respeita o fato de que agentes de IA não se tornam confiáveis porque você deu permissão a eles. Eles se tornam confiáveis porque você criou um ambiente onde o bom comportamento é mais fácil do que o mau comportamento.

É esse o ofício de verdade.

Não é o teatro de prompts. Não é a captura de tela da confirmação de um trade. O ofício está nas restrições operacionais.

Onde acho que isso pode quebrar

Gosto da arquitetura, mas também acho que qualquer um que tente isso deveria ser brutalmente honesto sobre os modos de falha.

Primeiro, o modelo ainda pode dar overfit no que for mais legível dentro do contexto. Se uma nota de pesquisa forte estiver escrita de forma mais persuasiva que as outras, o agente pode dar peso demais à qualidade da narrativa em vez da evidência real.

Segundo, memória defasada é perigosa. Um arquivo de estratégia que fazia sentido três semanas atrás pode silenciosamente virar uma orientação ruim se as condições de mercado mudarem e ninguém atualizar o documento.

Terceiro, sistemas integrados via API herdam as fraquezas de cada dependência externa. Corretora, pesquisa, notificações, sync do repo, execução do schedule, variáveis de ambiente, permissões de branch, rate limits. Cada peça em movimento adiciona mais uma forma de o workflow falhar exatamente na pior hora.

Quarto, logs podem virar entulho em vez de memória se não forem resumidos de forma agressiva. Um diário longo não é automaticamente um diário útil.

E quinto, o risco psicológico é real. Se o agente tem um estilo de escrita forte, ele pode soar mais certo do que merece. Isso pode seduzir o operador a confiar na qualidade da explicação em vez da qualidade do resultado.

Eu só rodaria um sistema desses se tivesse uma rotina para revisar o revisor: não só "que trades ele fez", mas "que suposições continuam aparecendo, quais arquivos estão ficando pesados demais e onde o sistema está racionalizando em vez de raciocinar?".

O que eu roubaria dessa arquitetura agora mesmo

Mesmo que eu tivesse zero interesse em trading automatizado, roubaria várias ideias desse setup agora mesmo.

A primeira é o modelo de rotinas agendadas para dividir o trabalho ao longo do dia.

A segunda é a arquitetura de memória baseada em arquivos para manter o agente aterrado entre execuções.

A terceira é a camada de persistência apoiada em GitHub, com histórico de versão como log de auditoria.

A quarta é o viés por notificações esparsas e de alto sinal.

E a quinta é a insistência no modo paper antes do modo ao vivo.

Essa última se aplica em quase todo lugar. Antes de um agente tocar infra de produção, dados de cliente, faturas, ações de segurança ou capital real, deixe ele operar em modo sombra primeiro. Veja ele pensar. Veja ele logar. Veja ele errar num ambiente seguro.

Essa disciplina é o que separa um sistema autônomo útil de uma história cara.

O que eu exigiria antes de deixar isso tocar dinheiro de verdade

Se alguém me perguntasse onde traçar a linha entre "protótipo legal" e "sistema em que confiaria com uma conta ao vivo", minha resposta seria bem rigorosa.

Eu iria querer pelo menos quatro coisas no lugar.

A primeira é um período sombra longo o suficiente para expor pattern drift. Não dois dias. Não uma semana de sorte. Eu iria querer que o agente rodasse em modo paper tempo suficiente para mostrar como ele se comporta em sessões chatas, sessões voláteis, sessões cheias de notícias e dias em que não fazer nada é a escolha correta.

A segunda é revisão de decisão no nível da tese, não apenas no nível do trade. Muitos construtores só revisam se o trade ganhou ou perdeu dinheiro. Isso não é suficiente. Eu quero saber se o raciocínio era internamente consistente, se os catalisadores citados eram reais, se o sizing combinava com a convicção declarada e se a lógica de saída seguiu as regras escritas.

A terceira é fallback operacional duro. Se o sync com o GitHub falhar, se a API da corretora estiver indisponível, se uma chamada de pesquisa retornar lixo ou se as variáveis de ambiente estiverem faltando, o comportamento mais seguro deveria ser parar e logar a falha, não improvisar em torno dela. Sistemas autônomos ganham confiança em parte pelo que se recusam a fazer.

A quarta é um ritual regular de poda da estratégia. Um risco subestimado em sistemas de memória baseados em arquivos é o acúmulo. Toda semana você adiciona mais notas, mais lições, mais opiniões, mais exceções. Com o tempo o agente pode acabar lendo um museu de crenças semimortas. Eu iria querer uma passada de limpeza semanal ou mensal em que suposições defasadas sejam removidas, regras vivas sejam reescritas de forma limpa e a estratégia central fique compacta o bastante para continuar afiada.

É essa a parte que muitos construtores de IA subestimam. O sistema não precisa só de inteligência em runtime. Ele precisa de disciplina de manutenção entre execuções.

E sinceramente, talvez essa seja a vantagem real em projetos como este. Não a atualização de modelo. Não a stack de APIs. Não a redação dos prompts. A vantagem é se o operador humano mantém o ambiente limpo o suficiente para o agente continuar tomando decisões sãs.

Minha visão

Esse walkthrough é interessante porque trata autonomia de IA como engenharia de sistemas, em vez de pensamento mágico.

Sim, a manchete é um agente de trading com IA 24/7 no Claude Code.

Mas a lição de verdade é mais ampla: se você quer que um agente de IA faça trabalho sério de forma contínua, dê a ele rotinas, memória, limites de risco, estado versionado, notificações seletivas e um job estreito o bastante para que o julgamento realmente importe.

Eu confiaria em algum agente de trading com IA cegamente com dinheiro real? Não.

Eu estudaria essa arquitetura como template para construir agentes de longa duração que operam com mais disciplina do que a isca de demo padrão? Com certeza.

Essa é a parte que merece atenção.

Porque o futuro dos agentes de IA úteis provavelmente não vai ser um robô gigante onisciente fazendo tudo de uma vez. Vai ser sistemas como esse: agendados, restritos, registrados, revisados e construídos para melhorar ao longo do tempo.

E sinceramente, esse é um futuro muito melhor do que o que os mercadores de hype estão vendendo.

Vamos trabalhar juntos

Quer construir sistemas de IA, automatizar workflows ou escalar sua infraestrutura de tecnologia? Adoraria ajudar.

• Fiverr (builds e integrações sob medida): fiverr.com/s/EgxYmWD
• Portfólio: mejba.me
• Ramlit Limited (soluções enterprise): ramlit.com
• ColorPark (design e branding): colorpark.io
• xCyberSecurity (serviços de segurança): xcybersecurity.io