Meu assistente roda sozinho num VPS há meses. O que aprendi construindo em vez de assistir tutorial.

Tem uma armadilha que me pegou por anos e talvez tenha pegado você também: eu era ótimo em consumir. Assistia curso, lia thread, salvava artigo, entendia o conceito, balançava a cabeça — e não construía nada. Chamam isso de tutorial hell. Eu chamava de segunda-feira.

O que me tirou de lá não foi mais um curso. Foi decidir construir uma coisa de verdade, com peça que quebra e me acorda de madrugada. Construí um assistente pessoal — apelidei de Ralph — que roda sozinho num VPS, o tempo todo. Ele lê minha memória em ficheiros, dispara lembretes, executa tarefas de código, se protege de comando perigoso e se recupera quando trava. Não é um chatbot que responde e some. É um processo de longa duração, com todos os problemas chatos que "longa duração" carrega.

E foi aí que a teoria virou cicatriz. Deixa eu te contar três lições que só se aprende quando o negócio tá rodando e te acorda 3h da manhã.

Lição 1: a memória do modelo é volátil — a sua não pode ser

Todo mundo que brinca com IA descobre rápido que o modelo esquece. Sessão nova, contexto zerado, "quem é você mesmo?". Pra um chat, tudo bem. Pra um agente que precisa saber o que ficou pendente ontem, é a morte.

A solução não é mágica, é disciplina de engenharia velha: estado importante vive em ficheiro, não na cabeça do modelo. No Ralph eu separei em camadas. O log cru do dia vai pra um memory/2026-07-23.md — tudo, sem filtro. A sabedoria destilada, aquela que vale semanas, vai pra um MEMORY.md que eu revejo e podo. E tem um núcleo que o próprio agente não pode reescrever, protegido por um hook que barra a escrita antes de acontecer.

O detalhe que a Anthropic acertou num artigo de harness design e que eu só entendi na prática: antes de o contexto estourar, você escreve o handoff. No Ralph, antes de qualquer compactação, ele faz um append no formato ## HH:MM — tópico → decisão/status/follow-up. Parece burocracia. É salvação. É a diferença entre a sessão de amanhã saber exatamente onde parou e a sessão de amanhã inventar uma explicação genérica bonita e errada — o que, aliás, modelo faz com uma confiança assustadora.

Estrutura de pastas, aqui, não é organização. É engenharia de contexto. Onde a informação mora decide o que o agente enxerga.

Lição 2: um processo que roda pra sempre vai travar — planeje o velório antes do enterro

Essa foi humilde de aprender. Você imagina que o inimigo é o bug no seu código. Não é. O inimigo é o congelamento silencioso — o agente não deu erro, não caiu, não gritou. Ele só... parou. Fica lá, vivo pro sistema operacional, morto pra você. No systemd aparece "active". No mundo real, mudo há quarenta minutos.

Descobri isso do jeito ruim. Um dia o assistente ficou surdo. Fui investigar e a causa era ridícula: um hook de início de sessão tinha um $(cat) esperando input que nunca vinha. O processo travava antes do primeiro token, e nenhum retry embutido salvava porque o retry só dispara se a resposta começa. A resposta nunca começava.

Duas lições saíram daí. A primeira: todo processo síncrono no caminho crítico precisa de timeout. O fix foi literalmente um timeout 5 — cinco segundos e segue a vida. A segunda, mais importante: você precisa de uma testemunha externa. Botei um watchdog que não confia no status do sistema — ele olha o mtime do transcript e do heartbeat. "Ativo" não significa nada; o que importa é: escreveu alguma coisa nos últimos minutos? Se não, tá travado, mata e reinicia.

O princípio que fica: em software de longa duração, você não projeta só o caminho feliz. Você projeta como o negócio morre e ressuscita — porque ele vai morrer, e a única pergunta é se você vai estar dormindo quando isso acontecer.

Lição 3: dê autonomia, mas com o dedo perto do botão

Um agente que pode rodar comando no seu servidor é útil e é assustador na mesma medida. A tentação do iniciante é um dos dois extremos: ou trava tudo e pede permissão pra respirar (aí não serve pra nada), ou libera geral (aí um dia ele roda um rm que não devia).

O caminho do meio é o que funciona, e ele tem nome: gate de aprovação por camadas. No Ralph, comando sudo passa por um filtro. Tem uma whitelist de coisas seguras que passa direto. Tem uma blacklist que é bloqueada e ponto. E o meio-termo — o comando que não é obviamente seguro nem obviamente proibido — dispara um pedido de aprovação no meu Telegram. Eu respondo /approve ou /deny do celular, e só então ele executa. Tudo isso fica num log auditável, inclusive as tentativas.

A regra de ouro que eu me impus: os gates de segurança nunca se auto-expandem. O agente pode ganhar mais autonomia com o tempo, mas a whitelist só cresce por ratificação minha, olhando o histórico. A blacklist nunca encolhe sozinha. Confiança se constrói por evidência, não por conveniência.

E tem os heartbeats — pulsos periódicos onde ele acorda, checa e-mail, calendário, o estado dos projetos, e decide se me incomoda ou fica quieto. De madrugada, entre meia-noite e seis, ele cala a boca por regra. Autonomia de verdade inclui saber a hora de não falar.

O que muda quando você constrói

A parte que eu queria ter entendido dez anos atrás: nada disso apareceu num tutorial. O $(cat) que trava, o systemd que mente, o modelo que se auto-avalia sempre positivo e por isso precisa de um avaliador cético separado — essas coisas você não aprende assistindo. Você aprende quando o negócio é seu, tá rodando, e te acorda.

Ler sobre harness design me deu o vocabulário. Construir o Ralph me deu as cicatrizes — e cicatriz é conhecimento que não sai.

Se você também tá preso na esteira de consumir sem construir, meu conselho é chato e é o único que funciona: escolha uma coisa pequena que rode de verdade, que tenha uma peça que possa quebrar às 3h da manhã. É desconfortável. É exatamente por isso que ensina.

O tutorial acaba quando você fecha a aba. O que você constrói continua rodando — e continua te ensinando — mesmo quando você não tá olhando. 🌀