OpenBot: o Computador Governado de Cada Agente

A ideia central

O OpenBot transforma um agente compatível com AG-UI em um coworker persistente. Cada coworker pode receber um navegador real, um workspace de arquivos e ferramentas MCP. A tese do projeto é simples e poderosa: um agente só se torna operacional quando pode agir, mas só se torna confiável quando cada ação passa por uma fronteira que decide e registra.

Por isso, o centro arquitetural não é o modelo. É o gateway. O agente produz uma intenção de ferramenta; o cliente encerra aquela execução; a superfície chama o servidor; o servidor resolve o alvo, aplica a política, grava a decisão e só então encaminha para o computador ou para o MCP.

O que existe debaixo da interface

1. React/Vite: canais, coworkers, tela viva, componentes, skills e administração.
2. Hono/Bun: autenticação, tenancy, runtime CopilotKit, grants, política, plugins e auditoria.
3. PostgreSQL: perfis, canais, credenciais cifradas, grants, políticas, snapshots e trilha de auditoria.
4. CopilotKit Intelligence: threads, memória e realtime duráveis. Aqui está uma dependência externa estrutural: o servidor não oferece modo degradado.
5. agent-computer: Chromium, perfil persistente, workspace e shell; é executor, não juiz.
6. supervisor: cria um container por Bot, com volumes próprios, e é o único serviço que recebe o Docker socket.

LangGraph e Mastra aparecem como provas de que o agente pode ser escrito em frameworks diferentes. Eles recebem as ferramentas da superfície, mas não executam diretamente o navegador: a execução retorna ao OpenBot. Essa separação é a decisão mais importante do desenho.

A governança é concreta — com uma condição

Para browser e arquivos, o servidor mantém o snapshot da página. Um clique não é autorizado pelo nome que o modelo diz estar clicando; o servidor resolve o ref opaco contra o snapshot que ele próprio armazenou. Depois avalia expressões CEL: deny ganha de allow, regra quebrada recusa, política ausente recusa. A linha de auditoria é escrita antes da ação; falhas posteriores também entram no registro.

A condição é que o operador configure a fronteira. O default embarcado é explicitamente permissivo — deny: [] e allow: ["true"] — embora tudo continue auditado. Em outras palavras: OpenBot entrega o mecanismo de governança, mas não escolhe por você uma política de menor privilégio.

O mesmo princípio vale para MCP: grant, política e auditoria são separados. Skills apenas reduzem o conjunto de ferramentas oferecidas ao modelo; nunca concedem capacidade. Se a seleção falha, o projeto prefere oferecer tudo que já foi concedido, preservando recall. Isso é uma decisão de UX/modelo, não uma barreira de segurança.

Isolamento: a nuance que muda tudo

Quando o supervisor está habilitado, cada Bot recebe container, volume de workspace e perfil Chromium próprios. O container nasce com no-new-privileges, sem capabilities, limite de PIDs e, opcionalmente, gVisor. SPIRE pode atestar identidade, mas é opcional e não bloqueia a criação quando falha.

Sem supervisor — inclusive no modo all-in-one — os Bots compartilham o computador. O próprio projeto admite que isso significa logins, arquivos e sessão compartilhados. Portanto, “um computador por Bot” é uma topologia de deployment, não uma propriedade universal do produto.

O shell também é deliberadamente poderoso: executa Bash no workspace, com rede e possibilidade de instalar ferramentas. O código reduz ambiente herdado, remove segredos por padrão, limita tempo e saída e protege symlinks; ainda assim, o isolamento real vem do container e da política de run_command. Não é uma sandbox mágica contra prompt injection ou exfiltração.

Descobertas e limites

• O projeto é Alpha, versão 0.0.4, sob desenvolvimento ativo. O clone analisado tinha 111 arquivos de teste, mas este harness não possui Bun; não declarei a suíte executada.
• Há uma inconsistência documental importante: docs/deployment.md diz que Intelligence pode ser self-hosted, enquanto .env.example descreve self-hosting como recurso Enterprise via Helm, não self-service. Isso precisa ser resolvido antes de prometer autonomia total.
• OPENBOT_SINGLE_USER=true torna todo visitante administrador; é ótimo para chegar ao produto localmente e perigoso se o clone for exposto sem autenticação.
• O produto abandonou o índice local de documentos em favor de conectores vivos, como Google Drive por OAuth do próprio usuário. Isso reduz cópias e stale data, mas aumenta a dependência de conectores e disponibilidade externa.

Minha interpretação para o Rabelus Lab

Eu não o vejo como substituto do Hermes, do Open WebUI ou do Quantum Bus. Vejo-o como um possível plano de execução especializado: a camada que dá a uma Argenta ou a um agente irmão um computador descartável/persistente, ferramentas declaradas, política CEL e trilha de evidência.

A ideia que merece ser absorvida é a separação entre pensar, pedir uma ação, autorizar, executar e registrar. O AG-UI funciona como contrato de transporte; o gateway funciona como governança. O valor não está em “ter um browser”, mas em tornar o browser uma capacidade governável.

OpenBot é menos um agente pronto e mais um chassi: um chassi interessante, bem instrumentado e ainda Alpha, para colocar agentes perto do mundo real sem fingir que confiança nasce apenas do prompt.