Claude Code Routines: agentes na cloud agendados, sub-rotinas e co-rotinas

Este é o guia aprofundado. Para uma visão geral em cinco minutos, leia o artigo de blog complementar.

1. Porque é que os agentes agendados importam

Até há pouco tempo, um agente de programação com IA só trabalhava enquanto alguém o acompanhava. Abria-se um terminal, dava-se uma tarefa, aprovavam-se as ações e lia-se o resultado. Quando a sessão era fechada, o trabalho parava. Esse modelo serve para trabalho exploratório, mas grande parte do trabalho de engenharia não é exploratório nem urgente. É recorrente: fazer a triagem da fila de issues da noite, verificar se a documentação ainda corresponde à API, rever cada pull request com a mesma checklist, verificar um deploy antes de fechar a janela de release.

As equipas que queriam que um agente fizesse este trabalho sem supervisão tinham de construir a canalização por conta própria. As opções habituais eram um cron job no GitHub Actions, uma máquina de reserva a funcionar num armário, ou um motor de workflows como o Trigger.dev ou o n8n com uma chamada a um agente acrescentada. Todas funcionam, mas cada uma acrescenta infraestrutura, credenciais, custos e manutenção em torno do que é, na verdade, uma única instrução: "faz isto todas as noites e diz-me o que encontraste."

As Routines eliminam essa canalização. O agendamento, a capacidade de computação, o checkout do repositório e o registo de auditoria ficam todos no próprio Claude Code.

2. O que é uma routine

A Anthropic define uma routine como uma configuração guardada do Claude Code. Tem cinco componentes:

• Prompt. A instrução que o Claude executa em cada execução. Como não há ninguém presente para responder a perguntas, tem de ser autossuficiente e dizer o que significa "concluído". É também aqui que escolhe o modelo, que será usado em todas as execuções.
• Repositórios. Um ou mais repositórios do GitHub. Cada um é clonado de novo no início de cada execução, a partir do branch predefinido, salvo indicação em contrário no prompt.
• Ambiente cloud. Controla o acesso à rede, as variáveis de ambiente e um script de configuração opcional que instala as dependências. O resultado da configuração fica em cache, pelo que não é executado de novo todas as vezes.
• Conectores. As integrações MCP da sua conta claude.ai, como Slack, Linear ou Google Drive, que a routine pode ler e nas quais pode escrever.
• Acionadores. Um ou mais de: agendamento, API e evento do GitHub. Uma única routine pode combinar os três.

Cada execução é uma sessão cloud completa do Claude Code. Pode executar comandos de shell, usar as skills versionadas no repositório clonado e chamar todas as ferramentas dos conectores que incluiu. Não há seletor de modo de permissões e nada fica à espera de aprovação. Essa autonomia é precisamente o objetivo, e é também por isso que a delimitação do âmbito é tão importante (ver a secção 8).

3. Os três tipos de acionador

3.1 Agendamento

O acionador mais simples executa a routine com uma cadência predefinida (de hora a hora, diariamente, em dias úteis ou semanalmente) ou uma única vez numa data e hora futuras. Convém conhecer alguns pormenores:

• Hora local. Indica as horas no seu próprio fuso horário e o Claude Code converte-as, pelo que uma execução às 09:00 acontece às 09:00 no seu relógio, esteja onde estiver o hardware da cloud. Alguns dos primeiros guias de terceiros afirmavam que os agendamentos só funcionavam em UTC. A documentação da Anthropic diz o contrário.
• Evite a hora certa. As execuções agendadas exatamente à hora certa podem começar com vários minutos de atraso. Escolher 09:07 em vez de 09:00 dá uma temporização mais previsível.
• Cron personalizado. Para intervalos que as predefinições não cobrem, como de duas em duas horas ou no primeiro dia do mês, escolha a predefinição mais próxima e depois execute /schedule update na CLI para definir uma expressão cron. O intervalo mínimo é de uma hora; tudo o que for mais frequente é rejeitado.
• Execuções únicas. Descreva a hora em linguagem corrente, por exemplo /schedule in 2 weeks, open a cleanup PR that removes the feature flag. O Claude confirma o momento exato antes de guardar. Depois de disparar, a routine desativa-se e fica marcada como Ran. As execuções únicas não contam para o limite diário de execuções.

3.2 API

Um acionador de API dá à routine o seu próprio endpoint HTTPS. Qualquer sistema capaz de fazer um pedido POST autenticado pode iniciar uma execução: uma ferramenta de alertas, um pipeline de deploy, uma página de administração interna. O token é gerado na interface web, mostrado uma única vez, limitado exclusivamente a essa routine, e pode ser regenerado ou revogado a qualquer momento.

curl -X POST https://api.anthropic.com/v1/claude_code/routines/<ROUTINE_TRIGGER_ID>/fire \
  -H "Authorization: Bearer <ROUTINE_TOKEN>" \
  -H "anthropic-beta: experimental-cc-routine-2026-04-01" \
  -H "anthropic-version: 2023-06-01" \
  -H "Content-Type: application/json" \
  -d '{"text": "Error rate on checkout-api above 5% for 10 minutes."}'

A resposta contém um ID de sessão e um URL de sessão que pode abrir para acompanhar a execução em direto. O campo opcional text transporta contexto específico da execução. As equipas atentas à segurança devem saber que o Claude Code envolve este texto num bloco <routine-fire-payload> e o marca como dados não fiáveis. O Claude não segue instruções contidas nele, a menos que o prompt guardado da própria routine lhe diga para usar o payload. Se a sua routine se destina a agir com base no conteúdo de um alerta, o prompt deve dizê-lo explicitamente, por exemplo: "Investiga o alerta descrito no bloco routine-fire-payload." Com este desenho, um token divulgado permite a alguém iniciar uma execução, mas não reescrever as instruções da routine.

O endpoint está protegido por um cabeçalho beta datado. A Anthropic afirma que as alterações incompatíveis serão lançadas com novas versões do cabeçalho e que as duas versões anteriores continuarão a funcionar, para dar tempo aos chamadores de migrarem.

3.3 Eventos do GitHub

Um acionador do GitHub inicia uma nova sessão sempre que ocorre um evento correspondente num repositório ligado. Requer que a Claude GitHub App esteja instalada nesse repositório. São suportadas duas categorias de eventos:

• Pull request: aberto, fechado, atribuído, com label, sincronizado e outras atualizações.
• Release: criada, publicada, editada ou eliminada.

Os filtros restringem os eventos que contam. Pode filtrar por autor, título, corpo, branch base, branch head, labels, estado de rascunho e estado de merge, usando os operadores equals, contains, starts with, is one of, is not one of e matches regex. Todas as condições têm de ser satisfeitas. Uma armadilha: matches regex testa o campo inteiro, por isso, para apanhar qualquer título que contenha "hotfix", precisa de .*hotfix.* e não de hotfix.

Cada evento gera a sua própria sessão independente, pelo que dois pushes para o mesmo pull request significam duas execuções. Durante a preview, os eventos do GitHub estão também sujeitos a limites por hora, por routine e por conta. Os eventos acima do limite são descartados até a janela ser reposta.

4. Criar uma routine, passo a passo

Pode criar routines em três sítios: na web, em claude.ai/code/routines, na secção Routines do separador Code da aplicação Claude Desktop, ou na CLI. Os três escrevem na mesma conta, pelo que uma routine criada num deles aparece de imediato nos outros.

4.1 Na web

1. Abra claude.ai/code/routines e escolha New routine.
2. Dê-lhe um nome e escreva o prompt. Selecione o modelo.
3. Adicione os repositórios em que o Claude deve trabalhar.
4. Escolha um ambiente cloud. O ambiente Default tem acesso à rede Trusted, que permite os registos de pacotes mais comuns, as APIs dos fornecedores cloud e domínios de desenvolvimento. Se a routine tiver de chegar aos seus próprios serviços, ajuste primeiro os domínios permitidos do ambiente.
5. Selecione um ou mais acionadores. Para um acionador de API, guarde primeiro a routine; o URL e o token são gerados depois.
6. Reveja os conectores. Todos os seus conectores ligados estão incluídos por predefinição, e o Claude pode usar todas as ferramentas deles, incluindo ações de escrita, sem pedir autorização. Remova tudo aquilo de que a tarefa não precisa.
7. Escolha Create e depois Run now para a testar antes de confiar no agendamento.

4.2 A partir da CLI

Em qualquer sessão local do Claude Code, /schedule (alias /routines) cria uma routine agendada através de uma conversa. O Claude pergunta pela cadência, pelos repositórios e pelo prompt, e depois guarda-a na sua conta.

/schedule daily PR review at 9am
/schedule tomorrow at 9am, summarise yesterday's merged PRs
/schedule list
/schedule update
/schedule run
/schedule why did my nightly review do nothing this morning?

O último exemplo é particularmente útil. O Claude lista as execuções recentes da routine, lê o registo relevante e explica o que aconteceu, incluindo erros de ferramentas e permissões recusadas. As versões recentes da CLI também conseguem associar um acionador do GitHub através de conversa, depois de a GitHub App estar instalada. Os tokens de API, no entanto, só podem ser criados ou revogados na web.

Se /schedule não for reconhecido, a causa é quase sempre a autenticação. As Routines exigem uma sessão iniciada com uma subscrição claude.ai. Uma chave de API da Console, uma variável de ambiente ANTHROPIC_API_KEY ou um início de sessão através de um fornecedor cloud como o Amazon Bedrock ocultam o comando. Nos planos Team e Enterprise, um Owner pode também desativar as routines para toda a organização.

5. Escrever prompts que resistem a execuções sem supervisão

O prompt de uma routine está mais próximo de um runbook do que de uma mensagem de chat. Não há ninguém para esclarecer ambiguidades, pelo que instruções vagas produzem resultados vagos ou, pior, ações confiantes que não pretendia. Compare:

Um bom prompt de routine indica:

• Âmbito: que repositórios, que janela temporal e que itens.
• Ações permitidas: o que o Claude pode alterar e, igualmente importante, aquilo em que não deve tocar.
• Resultado: o destino e o formato exatos, como um PR em rascunho, um canal do Slack ou um comentário no tracker.
• Condições de paragem: o que fazer quando não houver nada para fazer e quando desistir.
• Tratamento do payload: para acionadores de API, se e como usar o texto enviado.

Conte refinar uma nova routine duas ou três vezes na primeira semana. Leia as transcrições, não apenas o distintivo de estado. A Anthropic é explícita: um estado verde significa apenas que a sessão começou e terminou sem erro de infraestrutura. Não significa que a tarefa foi bem-sucedida.

6. Sub-rotinas: estruturar o trabalho dentro de uma execução

A Anthropic não disponibiliza nenhuma funcionalidade chamada "sub-rotinas" (sub-routines). Na Workstation usamos o termo para um padrão de desenho que torna as execuções longas e sem supervisão muito mais fiáveis: o prompt da routine atua como orquestrador e delega cada passo bem definido num subagente ou numa skill versionada no repositório.

Isto funciona graças a dois componentes do Claude Code que acompanham o seu repositório:

• Subagentes são ficheiros Markdown com front matter YAML em .claude/agents/. Cada um tem o seu próprio prompt de sistema, lista de ferramentas permitidas e modelo opcional, e corre na sua própria janela de contexto. Apenas um resumo regressa a quem o chamou. Os subagentes podem correr em paralelo e, por predefinição, podem eles próprios delegar até três níveis de profundidade.
• Skills em .claude/skills/ empacotam procedimentos reutilizáveis, como o seu estilo de notas de release ou a sua checklist de revisão de segurança, que o Claude carrega quando são relevantes. As Routines usam as skills versionadas no repositório clonado.

Uma routine de manutenção noturna construída desta forma poderia ter este aspeto:

# Routine prompt (orchestrator)
1. Use the issue-triager subagent to label and assign issues opened since the last run.
2. Pick the single highest-priority bug labelled "good-first-fix".
3. Use the bug-fixer subagent to implement a fix on a claude/ branch.
4. Use the test-runner subagent to run the test suite; if it fails twice, stop and report.
5. Open ONE draft PR, using the release-notes skill for the description.
6. Post a three-line summary to #eng-nightly.

# .claude/agents/issue-triager.md
---
name: issue-triager
description: Labels and assigns new issues. Never edits code.
tools: Read, Grep, Glob
model: haiku
---
You triage GitHub issues. Apply area labels from CODEOWNERS and
assign the owning team. Return a table of issue, label and owner.

Os benefícios são práticos. Cada ajudante vê apenas aquilo de que precisa, pelo que o contexto do orquestrador se mantém pequeno e focado ao longo de uma execução longa. As permissões de ferramentas são mais restritas em cada passo: o triador acima não consegue editar ficheiros de todo. Modelos mais baratos podem tratar dos passos mecânicos. E, como os subagentes e as skills estão no controlo de versões, as alterações ao comportamento da routine passam por code review como qualquer outra alteração.

7. Co-rotinas: routines que cooperam

Mais uma vez, "co-rotinas" (co-routines) é um termo nosso, não uma funcionalidade da Anthropic. Usamo-lo para várias routines independentes que passam trabalho umas às outras, tal como uma linha de produção passa uma peça de um posto para o seguinte. As routines não podem chamar-se diretamente umas às outras e não partilham memória. Em vez disso, uma routine produz um artefacto duradouro que o acionador de outra routine está a vigiar.

Uma cadeia típica:

1. Routine A (agendamento) faz a triagem do backlog nas noites de dias úteis e abre um PR em rascunho a partir de um branch claude/fix-….
2. Routine B (GitHub, pull_request.opened) está filtrada para branches head que começam por claude/. Aplica a checklist de revisão da equipa e coloca labels no PR.
3. Uma pessoa revê e faz o merge. Este é o ponto de aprovação.
4. Routine C (GitHub, pull_request.closed, merged = true) atualiza a documentação ou porta a alteração para um SDK irmão e abre um PR de seguimento.
5. Routine D (API) é chamada pelo pipeline de deploy após a release. Executa smoke checks e publica go ou no-go. Em caso de no-go, cria uma issue no tracker, que a Routine A recolhe na noite seguinte.

Os canais de passagem, do mais para o menos estruturado:

• Eventos do GitHub: nativos, filtráveis e totalmente auditáveis.
• Labels e convenções de nomes de branches: encaminham trabalho sem escrever código de ligação.
• Chamadas de API: a partir de CI, monitorização ou ferramentas internas, com o payload tratado como contexto não fiável.
• Um tracker ou artefacto partilhado: uma issue no Linear ou uma página de estado que a execução agendada seguinte lê.

Desenhe as co-rotinas com cuidado. Use filtros para que uma routine nunca seja acionada pelo seu próprio resultado, por exemplo excluindo os autores ou branches que ela cria. Mantenha um merge humano entre qualquer routine que escreva código e qualquer routine que o coloque em produção. Lembre-se de que todas as etapas consomem o mesmo limite diário de execuções da conta e os mesmos limites de eventos do GitHub. Se der por si a construir lógica de ramificação, repetições e fan-out ao longo de muitas routines, ultrapassou este padrão, e um motor de workflows dedicado é a ferramenta mais adequada.

8. Segurança e governação

• As routines agem como si. As routines pertencem a uma conta claude.ai individual e não são partilhadas com colegas de equipa. Os commits e pull requests levam a sua identidade do GitHub, e as ações dos conectores usam as suas contas associadas. Trate uma routine como um token de acesso pessoal com um cérebro acoplado.
• Proteção de branches. Por predefinição, o Claude faz push para branches com o prefixo claude/. Recusa fazer push para branches protegidos, para branches com um PR aberto de outra pessoa e para branches que contenham commits de outras pessoas.
• Privilégio mínimo. Remova os conectores desnecessários. Mantenha o acesso à rede em Trusted, a menos que seja necessário um domínio específico; os pedidos bloqueados falham com 403 e x-deny-reason: host_not_allowed. Nos planos Pro e Max, guarde as chaves de API como API credentials do ambiente e não como variáveis simples, que são visíveis para qualquer pessoa que use o ambiente.
• Entradas não fiáveis. Os payloads de API e o texto de Run now chegam marcados como não fiáveis. O conteúdo obtido durante uma execução, como o corpo de issues e páginas web, mantém o tratamento normal contra prompt injection. Escreva prompts que digam ao Claude em que deve confiar.
• Estado da ligação. Se a ligação ao GitHub expirar, as execuções são ignoradas durante até 72 horas e, depois, a routine desativa-se até voltar a ligar.
• Controlo da organização. Os Owners dos planos Team e Enterprise podem desativar as routines para todos os membros nas definições de administração.

9. Planos, utilização e limites

As Routines consomem utilização da subscrição da mesma forma que as sessões interativas. O limite diário aplica-se além disso. A sua quota atual é apresentada em claude.ai/code/routines e pode mudar durante a preview. Com os créditos de utilização ativados, as execuções acima do limite continuam como excedente faturado; sem eles, as execuções adicionais são rejeitadas até a janela ser reposta. As execuções agendadas únicas não contam para o limite. Enquanto uma subscrição estiver em pausa, as respetivas routines ficam suspensas.

10. Routines comparadas com outras opções de agendamento

10.1 Dentro do Claude Code

As tarefas /loop estão limitadas à sessão e expiram ao fim de sete dias. São ideais para vigiar um build ou um pull request enquanto trabalha, mas não substituem uma routine.

10.2 Fora do Claude Code

• GitHub Actions é barato, vive ao lado do código e dá controlo total sobre o runner. O preço é o YAML, a gestão de segredos e a manutenção dos runners. Escolha o Actions para passos de build determinísticos e as routines para trabalho que exige discernimento.
• Motores de workflows como o Trigger.dev tratam de repetições, fan-out e orquestração de longa duração, mas a orquestração é escrita por si em código. Use-os quando o próprio workflow é o produto.
• Plataformas de integração como o n8n e o Zapier destacam-se a mover dados entre ferramentas SaaS. As Routines destacam-se a raciocinar sobre código, registos e documentos. Os dois combinam bem: um fluxo do n8n pode chamar o endpoint de API de uma routine.

11. Casos de utilização que funcionam bem

• Gestão do backlog: aplicação noturna de labels e responsáveis, com um resumo pela manhã.
• Triagem de alertas: a monitorização chama o acionador de API e o Claude correlaciona o stack trace com os commits recentes e abre uma correção em rascunho.
• Code review à medida: a sua própria checklist em cada PR pronto para revisão.
• Verificação de deploys: smoke checks e análise de registos após cada release, terminando com um go ou no-go.
• Desatualização da documentação: uma análise semanal dos PRs com merge feito e PRs de atualização para a documentação que refere APIs alteradas.
• Portabilidade de bibliotecas: replicar as alterações com merge feito de um SDK no seu irmão noutra linguagem.
• Higiene de dependências: uma revisão semanal dos pacotes desatualizados com um único PR de atualização testado.

As Routines são menos adequadas para trabalho com frequência inferior a uma hora, para tarefas que exigem uma decisão humana a meio da execução e para workflows complexos com várias ramificações e repetições.

12. Como a comunidade reagiu

A reação tem sido mista, mas sobretudo positiva. A InfoQ citou engenheiros entusiasmados com a possibilidade de ligar a IA diretamente a dashboards de observabilidade e workflows de CI através de webhooks. Outros mostraram-se céticos. Apontaram funcionalidades de agendamento anteriores do Claude que só corriam na máquina do próprio utilizador e defenderam que a fiabilidade, o tempo de atividade e os limites de quota merecem atenção antes de novas funcionalidades. A nossa experiência é que as routines estão bem desenhadas do ponto de vista da segurança, em particular no tratamento de payloads não fiáveis e na proteção de branches. Os principais riscos operacionais são conectores com permissões demasiado amplas e prompts pouco específicos.

13. Como a Workstation usa isto

Na Workstation, implementamos automação agêntica para clientes nas áreas de DevOps, operações financeiras e workflows de clientes. As Routines encaixam bem na nossa abordagem: infraestrutura determinística para a canalização, IA para o discernimento e um ponto de aprovação humana antes de qualquer coisa chegar à produção. Se quiser ajuda para desenhar cadeias de routines, bibliotecas de subagentes ou a governação à sua volta, fale com a nossa equipa.

14. Principais conclusões

• Uma routine é um prompt guardado, com repositórios, ambiente, conectores e acionadores, executado de forma autónoma na cloud.
• Os acionadores podem ser um agendamento (mínimo de uma hora, hora local), uma chamada de API (bearer token, payload não fiável) ou um evento de pull request ou de release do GitHub.
• Disponível nos planos Pro, Max, Team e Enterprise, com limites diários de execuções além da utilização normal. A funcionalidade continua em research preview.
• Use sub-rotinas (subagentes e skills) para manter uma única execução longa focada e com privilégios mínimos.
• Use co-rotinas (routines que passam trabalho através de PRs, labels e chamadas de API) para pipelines com várias etapas, com um ponto de merge humano a meio.
• Restrinja rigorosamente os conectores e o acesso à rede, escreva prompts como runbooks e leia as transcrições.

Fontes e leitura adicional

• Anthropic: Introducing routines in Claude Code (14 de abril de 2026)
• Documentação do Claude Code: Automate work with routines
• Documentação do Claude Code: Run prompts on a schedule (/loop)
• Documentação do Claude Code: Subagents
• Documentação da Claude Platform: Trigger a routine through the API
• InfoQ: Anthropic Introduces Routines for Claude Code Automation
• MindStudio: Claude Code Routines: How to Run Scheduled AI Agents Without a Server
• Tahir no Medium: What is Claude Code Routines?

As Routines estão em research preview. O comportamento, os limites e a API podem mudar. Os factos deste guia refletem a documentação publicada pela Anthropic à data de 25 de setembro de 2026.