A Semana em que Meus Agentes Ganharam Sistema Operacional

Eu operei uma pequena empresa de agentes locais.

Tinha agente pesquisando, agente escrevendo, agente revisando código, agente verificando deploy, agente resumindo aprendizado, agente segurando fila, agente bloqueando quando precisava de decisão humana.

Em vez de uma janela de chat tentando lembrar tudo, eu tinha uma operação: perfis com papel, boards com estado, Garden com contexto, GBrain com protocolo, Kanban com handoff.

O número impressiona menos que o formato. Mais de duas centenas de sessões recentes passaram pelo sistema, mas a virada não foi “usei IA muitas vezes”. Isso qualquer pessoa com ansiedade e vinte abas abertas consegue fazer.

A virada foi outra: Hermes deixou de ser lugar onde eu peço respostas e virou o sistema operacional onde o trabalho acontece.

1. O erro: esperar que um modelo se comporte como uma organização

A maioria das pessoas ainda tenta resolver agente com prompt.

Prompt maior. Prompt mais esperto. Prompt com persona. Prompt com vinte regras e uma ameaça passivo-agressiva no final.

O problema aparece quando você pede para o agente operar, não apenas responder. Operar exige saber fonte de verdade, estado atual, escopo, dono, limite, evidência e critério de pronto. Nenhuma dessas coisas nasce magicamente dentro do modelo.

Essa semana apareceu um exemplo perfeito.

Um agente foi perguntado sobre status de ferramentas e respondeu como se um catálogo inteiro de apps conectáveis fosse capacidade real.

O texto parecia organizado. O problema era a taxonomia: catálogo, conectado, usável e recém-verificado estavam misturados no mesmo balde.

Quando a fronteira do sistema é ruim, até uma resposta determinística fica perigosa.

Ela passa a soar precisa justamente porque está formatada. E formatação é o perfume favorito de erro operacional.

A lição foi simples: inteligência do modelo não substitui desenho de operação.

2. O padrão: papel, fila e fonte de verdade

O que funcionou melhor na semana não foi um agente generalista com contexto infinito. Foi o oposto: papéis menores e contratos mais claros.

Um perfil coordena. Outro executa uma fatia estreita. Outro revisa.

O board segura a fila. O comentário final vira handoff. O GBrain guarda o aprendizado. O Garden guarda o contexto vivo. O humano aprova o que pode causar “danos”.

Parece burocracia até você ver o primeiro agente trabalhando sozinho por tempo suficiente para errar caro.

Sem fila, agentes pisam no mesmo arquivo. Sem fonte, cada sessão reconstrói a empresa. Sem critério de pronto, “done” vira frase simpática. Sem gate, autonomia vira risco.

Com o sistema certo, a conversa muda.

Você não pergunta “será que o agente é inteligente?”. Você pergunta:

Menos sexy que “qual modelo você usa?”. Muito mais útil.

3. Kanban não é project management. É memória de trabalho.

Eu sempre achei Kanban meio chato quando ele virava teatro corporativo: card movendo de coluna para fingir controle.

Com agentes, ele ganhou outra função.

Kanban virou memória durável de coordenação. Um card não é “uma tarefa”. É um contrato: contexto, escopo, fora-de-escopo, acceptance criteria, proof-of-work e hard lines. O agente não precisa lembrar tudo na cabeça. Ele lê o contrato, trabalha, deixa recibo e bloqueia quando precisa.

O padrão mais importante da semana foi o review-required.

Um agente terminar bloqueado para revisão não é fracasso. Muitas vezes é exatamente o comportamento saudável. Ele implementa ou pesquisa até o limite, deixa comentário, arquivos, testes, diffs ou evidências, e passa a bola para o operador.

Foi assim em uma landing pública: o trabalho só virou “feito” depois de verificar não apenas que a página respondia, mas que os marcadores novos apareciam e os claims antigos/arriscados tinham sumido.

Foi assim em uma esteira de release: sucesso no POST não bastava. O protocolo virou ler de volta branch, commit, status e artefato.

Foi assim em um app educacional: o melhor sinal não foi “eu lembro que passou”; foi o comentário final do board com testes, build e limites residuais.

O agente pode dizer done. O sistema precisa provar done.

4. GBrain transforma perrengue em protocolo

A segunda peça é o pós-jogo.

Se cada erro morre como conversa antiga, você tem produtividade descartável. Se cada erro vira protocolo, você tem operação que compõe.

Essa semana deixou várias cicatrizes úteis:

• catálogo não é ferramenta conectada;

• ferramenta conectada não é ferramenta usável;

• ferramenta usável não é ferramenta verificada agora;

• deploy verde não prova que o domínio certo carregou a versão certa;

• helper script pode esconder branch hardcoded;

• migração sensível precisa de dry-run, checkpoint, aprovação literal, hash e rollback;

• sandbox e permissão não são detalhe técnico — são parte do produto.

Esse é o papel do GBrain no meu fluxo. Ele é o lugar onde perrengue vira regra consultável.

Um transcript bruto diz o que aconteceu.

Um learning curado diz o que aquilo significa.

Uma skill ou protocolo diz o que muda na próxima execução.

Sem essa separação, você só acumula histórico. Com ela, cada semana reduz a chance de repetir o mesmo erro com outro nome.

5. Autonomia boa tem hard gate

Quanto mais útil um agente fica, mais importante é desenhar onde ele para.

Isso parece contraintuitivo. Muita gente imagina autonomia como “deixa fazer tudo”. Na prática, autonomia sem limite vira adrenalina com API key.

A regra que ficou mais clara para mim: autonomia boa é deixar fazer muito dentro de limites desenhados antes da adrenalina.

Se envolve publicação, envio, dinheiro, dado sensível, produção, credencial ou promessa pública, precisa de gate explícito. Não porque o agente é burro. Porque o sistema precisa preservar confiança.

Um agente que sabe bloquear é mais valioso que um agente que tenta parecer herói.

O blocker bem escrito é uma das interfaces mais maduras de trabalho autônomo: “cheguei até aqui, estas são as evidências, este é o risco, preciso de decisão humana”.

Isso não reduz autonomia, torna autonomia habitável.

🔮 O que EU realmente penso

O próximo salto dos agentes vai ser operação melhor.

Mais contexto ajuda, claro. Modelos melhores ajudam. Ferramentas novas ajudam. Mas, sem sistema, tudo isso só aumenta a velocidade com que você produz bagunça convincente.

Antes, meu fluxo era uma janela: eu pedia, recebia, copiava, corrigia, esquecia.

Agora, quando funciona, parece mais com uma pequena organização:

• papéis claros;

• fila visível;

• fonte de verdade definida;

• aprendizado compilado;

• recibo antes de done;

• gate antes de risco.

Isso não elimina o humano. Pelo contrário. Coloca o humano no lugar certo: desenhando o ambiente, decidindo tradeoffs, auditando evidência e protegendo limites.

O agente deixa de ser “um funcionário mágico” e vira algo mais interessante: uma peça executável dentro de um sistema que aprende

E aí a pergunta muda.

Não é mais: “qual prompt eu uso?”

É: qual sistema esse agente vai habitar quando eu não estiver olhando?

🚀 Sua missão para os próximos 7 dias

1. Escolha um workflow repetido da sua semana. Pode ser revisar uma proposta, preparar um relatório, publicar uma landing, limpar um backlog ou pesquisar uma decisão. Escreva o contrato: objetivo, fonte de verdade, fora-de-escopo e critério de pronto.

2. Separe status de capacidade em quatro buckets. Catálogo, conectado, usável, verificado agora. Se você misturar esses quatro, seu agente vai parecer mais capaz do que é.

3. Crie um gate para uma ação irreversível. Produção, publicação, dinheiro, dados ou cliente. Defina antes: quando o agente pode seguir, quando deve bloquear e qual evidência precisa trazer.

📚 Conteúdos recomendados

• Docs: Hermes Agent — referência para entender o runtime local por trás de profiles, skills, ferramentas e operação persistente.

• Engineering: How we built our multi-agent research system — Anthropic — bom contraponto sobre por que orchestrator-worker não é “mais agente por hype”, mas escolha de arquitetura com tradeoff.

Forte abraço,

Equipe Olympus