A pergunta que devia vir antes da subscrição

Todos usamos assistentes de IA. Escrevem um email, resumem um documento, explicam um erro de PHP. O problema começa quando a pergunta deixa de ser genérica: «porque é que o site do cliente caiu ontem às três da manhã?», «qual foi a configuração de nginx que decidimos em setembro?», «faz o deploy e diz-me se o formulário voltou a enviar». Aí o assistente não sabe nada, porque nunca viu nada. O contexto da empresa vive em ficheiros, servidores e decisões — não na conta de outra pessoa.

É esta a diferença que o OpenClaw vem resolver, e é uma diferença de arquitetura, não de modelo.

De responder a fazer

Um chat convencional recebe texto e devolve texto. Um agente recebe um objetivo e tem ferramentas: ler ficheiros, executar comandos, abrir um browser, consultar uma base de dados, enviar uma mensagem. O modelo continua a ser o cérebro, mas passa a ter mãos.

Isso muda tudo — incluindo o risco. Um sistema que só escreve pode estar errado; um sistema que executa pode estar errado e agir. Toda a arquitetura de um agente sério é, por isso, metade capacidade e metade travão. Voltamos a isto mais à frente, porque é a parte que quase ninguém mostra numa demonstração.

O que é o OpenClaw

O OpenClaw é um gateway de agente que corre na máquina de quem o usa — o portátil, um servidor próprio, um VPS. É open source, funciona com vários fornecedores de modelos (e com modelos locais), e liga-se aos canais onde a conversa já acontece: WebChat, Telegram, Discord, WhatsApp, Slack, Signal, entre outros.

Na prática, isto significa uma coisa simples e rara: o mesmo agente, com o mesmo contexto, responde no telemóvel e trabalha no servidor. Não há sincronização a fazer entre dois produtos, porque é o mesmo produto.

As seis peças, uma a uma

1. Corre na máquina. Ficheiros, credenciais e histórico de sessões ficam onde estão. O modelo é chamado através de uma API, mas o que é enviado é apenas o que a tarefa exige — não um índice da sua empresa. Para quem trabalha com dados de clientes, esta é a diferença entre um sistema que se pode auditar e um que se tem de acreditar.

2. Fala em qualquer canal. O canal é uma entrada, não um produto separado. A conversa que começou no Telegram pode continuar no WebChat sem perder o fio, porque o contexto está no agente e não na aplicação.

3. Controla o browser. Abre páginas, clica, preenche, tira screenshots. E — o detalhe que interessa — verifica o resultado antes de dizer que está feito. Um agente que reporta sucesso sem confirmar é pior do que não ter agente: foi exatamente esse tipo de falha que já nos apareceu em automações antigas.

4. Memória persistente. Notas diárias e um ficheiro de memória de longo prazo. Sabe o que foi decidido, quando e porquê. É a diferença entre um assistente que começa do zero a cada conversa e um colega que se lembra do contexto do projeto.

5. Skills e plugins. Procedimentos guardados em ficheiros de texto: como fazer um deploy de um tema, como diagnosticar um 500 do PHP-FPM, como bloquear execução de PHP em uploads, como rotular um post. Em vez de reaprender a tarefa todas as semanas, o agente lê o procedimento que já funcionou — e corrige-o quando deixa de funcionar.

6. Acesso ao sistema. Shell, SSH, git, base de dados. Com aprovação explícita para ações sensíveis. É a peça mais poderosa e a que exige mais disciplina.

Um dia normal, na prática

Nada disto é abstrato. Num dia de trabalho, o mesmo agente pode:

• Verificar se o último artigo foi publicado, comparando o que o processo diz que fez com o que está mesmo no WordPress — e avisar quando os dois não coincidem.
• Ler os logs de um servidor, identificar o IP que está a martelar o formulário e propor a regra de bloqueio, com o comando exato à espera de aprovação.
• Preparar um rascunho de artigo com links internos já testados, e deixá-lo em draft para revisão humana.
• Correr o deploy de um tema e confirmar, com screenshot, que a página continua a responder 200.

Nenhuma destas tarefas é glamorosa. É precisamente por isso que valem: são as que consomem tempo e as que se esquecem quando o dia aperta.

O que impede o desastre

Um agente com acesso a shell é, literalmente, um utilizador com acesso a shell. A conversa sobre segurança não é opcional — é o núcleo do desenho.

• Aprovação humana para o que destrói. Comandos sensíveis pedem confirmação explícita, com o comando completo à vista. Aprovar não é dizer «sim» a uma intenção; é ver a linha exata que vai correr.
• Privilégio mínimo. O agente não precisa de root para tudo. Contas separadas, chaves separadas, permissões separadas.
• Quarentena em vez de eliminação. Mover para uma pasta isolada é reversível; apagar não é. Um agente bem configurado prefere sempre o gesto reversível.
• Segredos que não passam por chat. Nada de passwords em mensagens ou em argumentos de linha de comandos — ficheiros com permissões restritas e leitura programática.
• Registo. Cada ação fica registada. Sem registo não há auditoria, e sem auditoria não há confiança.

Isto liga-se ao que já escrevemos sobre configurações de servidor que protegem mesmo o WordPress: a maior parte dos incidentes que vimos não nasceu de um ataque sofisticado, nasceu de uma permissão a mais e de um ficheiro a menos.

Os limites honestos

Um artigo que só mostrasse vantagens não era útil. O que é preciso saber antes de experimentar:

• Custa tokens. Cada tarefa consome chamadas ao modelo. Automação contínua tem um custo mensal real, que deve ser comparado com o tempo poupado.
• Não é determinístico. Duas execuções da mesma tarefa podem divergir. Para trabalho repetitivo e verificável, isso é gerível; para decisões reguladas, não.
• É vulnerável a injeção de instruções. Se o agente lê conteúdo da web ou de um email, esse conteúdo pode tentar dar-lhe ordens. A defesa é arquitetural: separar o que é dados do que é instrução, e nunca dar acesso amplo a quem lê fontes não confiáveis.
• Precisa de supervisão. Não é um funcionário; é uma ferramenta com iniciativa limitada. Quem promete autonomia total está a vender risco.
• Não substitui critério. Um agente escreve depressa e verifica mal o que não lhe foi pedido para verificar. A revisão humana continua a ser o último passo.

Aliás, é o mesmo princípio que defendemos para os assistentes que os clientes põem nos sites: âmbito estreito, silêncio nos temas sensíveis e passagem fácil a uma pessoa. Escrevemos sobre isso em o que separa um assistente útil de mais um pop-up.

Porque é que isto nos interessa como agência

Trabalhamos com sites, servidores e prazos. A maior parte do tempo não se perde a decidir — perde-se a executar o que já foi decidido: verificar, repetir, confirmar, documentar. É aí que um agente local compensa.

E há uma razão menos óbvia: sendo open source e correndo na nossa máquina, podemos lê-lo, limitá-lo e explicar o que faz. Não temos de confiar numa caixa fechada para dizer a um cliente onde é que os dados dele passam. Numa conversa sobre RGPD, isso não é um detalhe técnico; é a resposta à pergunta.

Como avaliar em duas semanas

Não comece por «vamos automatizar tudo». Comece por uma tarefa que cumpra três condições: é repetitiva, tem um resultado verificável e o erro é reversível.

• Semana 1. Instalar, ligar um canal, dar acesso só de leitura ao sistema onde a tarefa acontece.
• Semana 2. Correr a tarefa com aprovação em cada passo e medir o tempo gasto, incluindo o tempo de revisão.

Se ao fim de duas semanas o tempo total — execução mais revisão — não for menor do que fazê-lo à mão, o problema é a tarefa escolhida, não a ferramenta. E se for maior, o ganho é real e escalável.

Em resumo

• Assistentes de chat sabem responder. Agentes sabem fazer — e por isso precisam de travões.
• O OpenClaw corre na sua máquina, fala nos canais que já usa e mantém o contexto entre eles.
• Seis capacidades: local, multicanal, browser, memória, skills, acesso ao sistema.
• A parte que importa não é a demonstração; é a aprovação, o privilégio mínimo e o registo.
• Comece por uma tarefa repetitiva, verificável e reversível. Meça o tempo total, revisão incluída.

O resto é entusiasmo. E entusiasmo, em infraestrutura, é a forma mais cara de aprender.