Mapa da trilha
Conteudo detalhado
🔄 Loop Basico com Claude Code
Setup do /loop skill, criacao de plan.md, prompt para o orchestrator configurar o loop, demo com task list sequencial e wake-up automatico.
O Claude Code tem uma capability built-in chamada "loop skill" que ensina o agente a configurar loops automaticamente.
E o ponto de partida mais simples para loop engineering. Um unico prompt carrega todo o sistema.
Loop skill como capability. Prompt inicial. Auto-configuracao pelo agente.
Um documento markdown com tarefas numeradas que o agente processa item por item, marcando cada uma como concluida.
A qualidade do plan.md determina a qualidade do output. Tarefas bem definidas = resultados melhores.
Granularidade ideal. Criterio de aceitacao por tarefa. Ordem sequencial vs paralela.
O prompt que carrega o loop skill e instrui o agente a processar o plan.md. O agente configura /loop sozinho.
Um bom prompt inicial e a diferenca entre um loop funcional e um loop caótico.
"Load the loop skill". Auto-setup do /loop. Prompt como sistema, nao como instrucao.
O agente completa uma tarefa, agenda o proximo wake-up via /loop, e continua ate concluir todas as tarefas do plan.md.
Ver o fluxo real ajuda a entender como os primitivos se conectam na pratica.
Wake-up cycle. Validacao entre tarefas. Prompt auto-gerado pelo agente.
Colecao de prompts copiáveis para os cenarios mais comuns: task runner, code review, e exploracao.
Comecar com prompts testados acelera a adocao e evita erros comuns de configuracao.
Templates reutilizaveis. Parametros ajustaveis. Adaptacao por contexto.
O loop basico roda numa unica sessao, usa um unico modelo e nao tem state externo. Isso limita escala e confiabilidade.
Entender as limitacoes motiva a busca por solucoes mais robustas nos modulos seguintes.
Single session = context bloat. Single model = custo alto. Sem state = sem durabilidade.
⚙ Workflows Deterministicos com Archon
O harness builder do Cole Medin: workflows onde o humano define o processo, mix de modelos por step, e durabilidade com Postgres/Neon.
Archon e a ferramenta do Cole Medin para orquestrar sessoes de coding agents com workflows definidos pelo humano.
Representa a abordagem oposta ao loop puro: o humano define o processo, nao o agente.
Harness vs loop. Workflow file. Steps deterministicos. Mix de providers.
Pipeline deterministico: extrair issue, buscar contexto, classificar tipo, pesquisar, implementar, validar e criar PR.
E o exemplo mais pratico de como combinar determinismo com LLM, usando o agente so onde realmente precisa.
Pipeline como grafo. Steps deterministicos vs LLM-driven. Classificacao como decisao leve.
No deterministico, o humano define quais steps existem e em que ordem. No loop puro, o agente decide tudo sozinho.
Entender esse trade-off e fundamental para escolher a abordagem certa para cada cenario.
Confiabilidade vs flexibilidade. Agente como executor, nao como tomador de decisao.
Cada node do workflow pode usar um modelo diferente. Steps leves usam modelos baratos; steps criticos usam modelos fortes.
E a principal alavanca de otimizacao de custo em workflows autonomos.
Model routing. Custo por step. Provider mixing. Kimi para exploracão, Claude para implementacao.
Logs, runs e conversations sao gravados em Postgres/Neon. Se a maquina cair, o workflow retoma do step exato.
Durabilidade e o que transforma um experimento em sistema confiavel.
State store. Resume from step. Neon branching para workers paralelos.
Prompts otimizados para cada step: classificacao, pesquisa, implementacao, validacao e code review.
Prompts prontos economizam tempo e servem de base para adaptacao ao seu contexto.
Template por step. Markdown como contexto. Handoff entre steps via documentos.
📊 Dashboard de Controle (Agent Control Plane)
Observabilidade em tempo real: ver decisoes do orchestrator, cost tracking, human-in-the-loop e deploy remoto.
Dashboard open source que Cole construiu para gerenciar loops com durabilidade, observabilidade e human-in-the-loop.
Sem controle visual, loops sao caixas pretas que queimam tokens sem feedback.
Dashboard como sistema nervoso. Open source no GitHub. Backend com Pi/Kimi.
Todos os loops, eventos e logs sao gravados em Postgres (via Neon) para durabilidade e analytics.
State externo permite retomar loops apos crashes e analisar patterns de execucao historicamente.
Orchestrator le state do banco. Workers atualizam state no banco. Banco como fonte de verdade.
Ver em tempo real quais decisoes o orchestrator toma, quantos workers dispara, e o progresso de cada round.
Poder ver e entender as decisoes do orchestrator e essencial para debugar e melhorar o loop.
Decision log. Round history. Worker dispatch tracking. Event stream.
Metricas de tokens consumidos por round, por worker, e custo total do run. Visivel no dashboard.
Sem cost tracking, e impossivel otimizar. O dashboard mostrou 1M+ tokens para um app simples.
Tokens por round. Custo do orchestrator vs workers. Breakdown por modelo.
O loop pode pausar apos cada round esperando aprovacao humana antes de continuar.
HITL e a guardrail essencial que evita o problema de "run for a day, come back to crap".
Pause entre rounds. Approve/reject workflow. Permission groups. Identity verification.
O dashboard pode ser deployado na cloud via Retool, permitindo acesso remoto e compartilhamento com o time.
Deploy remoto transforma uma ferramenta local em infraestrutura de equipe.
Import React para Retool. Conexao com Neon. Permission groups. Audit trails.
💰 Otimizacao de Custos
Mix de providers, model routing, state externo, worktrees e metricas para manter loops viaveis financeiramente.
Usar providers diferentes para roles diferentes: modelos baratos para orquestracao, modelos fortes para implementacao.
E a principal alavanca para reduzir custo sem sacrificar qualidade no output final.
Pi/Kimi como orchestrator barato. Claude Code para execucao. Codex para review.
Rotear tarefas para modelos com base na complexidade: classificacao simples usa Haiku, implementacao complexa usa Claude.
Cada token conta. Usar Opus para classificar bug vs feature e desperdicio.
Complexity-based routing. Custo por token por modelo. Decisoes leves vs pesadas.
Manter estado no banco externo em vez de acumular no context window do LLM. Cada sessao comeca limpa e le o estado.
Context bloat e a causa #1 de degradacao em loops longos. State externo resolve.
Context window como cache. Banco como storage. Sessao stateless. Read-execute-write cycle.
Git worktrees criam copias isoladas do repo para que N agentes trabalhem em paralelo sem conflitos de codigo.
Paralelismo real requer isolamento real. Worktrees sao o mecanismo mais pratico para isso.
Worktree por worker. Branch por tarefa. Merge apos validacao. Port conflict avoidance.
Batch: acumular tarefas e processar de uma vez (mais barato). Real-time: processar imediatamente (mais responsivo).
Escolher o modo errado desperdiça dinheiro ou tempo. Contexto determina a escolha.
Batch para GitHub issues noturno. Real-time para fixes urgentes. Trade-off latencia vs custo.
As tres metricas essenciais: tokens consumidos por tarefa, custo por round do orchestrator, e taxa de sucesso dos workers.
O que nao se mede nao se otimiza. Essas metricas sao o minimo para evitar desperdicio.
Tokens/task como KPI. Cost per round. Success rate. Trend analysis. Budget alerting.