- Estrutura que conecta um agente de IA baseado em IRC a um site de portfólio pessoal, permitindo que visitantes façam perguntas e recebam respostas com base em resultados reais de análise do código de repositórios no GitHub
- Projetado não como um simples chatbot que resume currículo, mas como um agente executável que realiza clonagem de repositórios, contagem de testes e verificação de código
- O sistema é dividido em dois agentes, o nullclaw público e o ironclaw privado, que se comunicam com segurança por meio de uma rede Tailscale
- Ao adotar o protocolo IRC como camada de transporte, alcança ao mesmo tempo self-hosting, padronização e baixo custo, separando os modelos Haiku 4.5 e Sonnet 4.6 por função para limitar o custo a US$ 2 por dia
- Todo o sistema opera com binários de menos de 10 MB e menos de 5 MB de memória, sendo apresentado como um exemplo de infraestrutura leve de IA que assegura segurança, custo e transparência
Construindo um porteiro digital
- Estrutura que implanta um agente de IA em um VPS de US$ 7/mês e o conecta a repositórios do GitHub usando um servidor IRC pessoal como camada de transporte
- Os visitantes podem fazer perguntas à IA no site de portfólio e receber respostas baseadas no código real
- Em vez de um chatbot que apenas resume currículo, ele fornece respostas concretas por meio de análise de código
Limitações do “chatbot que responde sobre o currículo”
- A maioria dos chatbots de portfólio fica no nível de injetar o conteúdo do currículo no modelo para que ele o reformule
- Essa abordagem não fornece novas informações e não passa de uma conversa meramente formal
- Para perguntas como “Como você gerencia a cobertura de testes?”, é necessário um tipo de resposta concreta que clone o repositório e calcule a quantidade de testes
- Para isso, foi criada uma infraestrutura com acesso direto ao código e capacidade de análise
Arquitetura do sistema
- Composto por dois agentes, dois servidores e duas fronteiras de segurança
- nullclaw: porteiro público, binário Zig de 678 KB, usa cerca de 1 MB de RAM
- Cumprimenta visitantes, responde perguntas sobre projetos, clona repositórios do GitHub e realiza verificação baseada em código
- ironclaw: agente backend privado, executado em um sistema separado
- Pode acessar e-mail, agenda e contexto pessoal
- Recebe solicitações complexas do nullclaw pelo canal IRC #backoffice
- Os dois sistemas são conectados por Tailscale, e o servidor público não pode acessar dados pessoais
Por que escolher IRC
- Consistência estética: como o site de portfólio usa uma interface de terminal, um cliente IRC se encaixa naturalmente
- Self-hosting completo: servidor IRC Ergo, cliente web gamja e nullclaw operam todos na própria infraestrutura
- Protocolo simples e padronizado: o IRC, com 30 anos de existência, não tem dependência de fornecedor nem risco de mudanças de API
- O mesmo agente funciona de forma idêntica tanto no cliente web quanto no cliente de terminal irssi
Escolha e design dos modelos
- Usar modelos grandes é ineficiente, então os modelos são separados por função
-
Haiku 4.5**: conversa e tratamento de consultas simples,** resposta de baixíssima latência
- Sonnet 4.6: usado apenas para análise de código e raciocínio complexo
- Limite de custo: US$ 2 por dia, US$ 30 por mês
- Evita explosão de custos por uso malicioso ou conversas excessivas
- A estrutura de raciocínio em camadas garante ao mesmo tempo velocidade e eficiência de custo
Design de segurança
- SSH: login de root desativado, apenas autenticação por chave, uso de porta não padrão
- Firewall: apenas SSH, IRC (TLS) e HTTPS (WebSocket) abertos
- Proxy da Cloudflare: terminação TLS, limitação de taxa e filtragem de bots
- Sandbox do agente: apenas ferramentas de leitura permitidas, limite de 10 ações por hora
- Controle de custos: hard cap de US$ 2 por dia e US$ 30 por mês
- Logs de auditoria e atualizações automáticas ativados
- Superfície de ataque minimizada: apenas os dois serviços ergo e nullclaw em execução, sem servir conteúdo web diretamente
- Em caso de comprometimento, o alcance do dano fica limitado a um bot de IRC com teto de US$ 2/dia
Composição da stack de comunicação
- Todos os componentes são pequenos, self-hosted e substituíveis
- Ergo: servidor IRC, binário único em Go, 2,7 MB de RAM
- gamja: cliente web de IRC, página estática de 152 KB, servida atrás da Cloudflare
- nullclaw: runtime do agente de IA, binário Zig de 4 MB, usa cerca de 1 MB de memória
- Todo o sistema opera com menos de 10 MB de binários e menos de 5 MB de memória ociosa
- Pode rodar com folga até mesmo na camada mais barata de VPS
O que o nully (agente público) realmente faz
- Identificação de linguagens de programação: confirma por meio de contexto pré-carregado e verificação do repositório
- Análise da estrutura de testes: clona o repositório, lê diretamente os arquivos de teste e relata o resultado
- Explicação de projetos: por exemplo, responde com base no código sobre detalhes do projeto Fracture
- Orientação de contato: fornece apenas informações de contato corretas, sem inventar dados
- Solicitações de agendamento: encaminhadas ao ironclaw via protocolo Google A2A, com retorno estruturado
- O visitante não percebe o processo de troca para o backend
Implementação de A2A
- Compatível com o protocolo Google A2A (v0.3.0) e faz gerenciamento de estado de tarefas baseado em JSON-RPC
- A ferramenta
a2a_call envia mensagens ao agente remoto e interpreta o estado da tarefa (concluída/falha/em andamento)
- HTTPS obrigatório, mas dentro da rede interna do Tailscale o HTTP é permitido para facilitar o debug
-
Estrutura do lado do ironclaw
- A instância do nullclaw usa como proxy o gateway de LLM do ironclaw, sem ter sua própria chave de API
- Mantém apenas uma única chave de API e uma única relação de cobrança
- O ironclaw processa todas as requisições de inferência e assume os custos
Segurança no handoff
- O endpoint A2A apresenta risco de prompt injection, então foram aplicadas restrições rigorosas
- As solicitações que podem ser encaminhadas ao ironclaw se limitam a agenda, contato e disponibilidade
- O repasse de comandos arbitrários é rejeitado
- O endpoint A2A do ironclaw é protegido por um firewall exclusivo do Tailscale
- Ambos os agentes rodam em modo monitorado e com uma lista restrita de comandos permitidos
- O nully decide se uma solicitação deve ser escalada, evitando execução indiscriminada de comandos
Lições aprendidas durante a construção
- A escolha do modelo faz parte do design do sistema e impacta diretamente custo, latência e experiência
- Foi gasto mais tempo em comunicação, segurança e infraestrutura do que no próprio agente
- A simplicidade e a abertura do IRC o tornam ideal como camada de transporte para agentes de IA
- A separação entre nullclaw e ironclaw é o núcleo do modelo de segurança
- O uso combinado do protocolo A2A e de canais de log em IRC garante comunicação estruturada e visibilidade em tempo real
- Evitar duplicação de credenciais: ao usar como proxy o gateway do ironclaw, mantém-se uma única chave de API e uma única relação de cobrança
Como experimentar
- Acesse georgelarson.me/chat ou digite
irc no terminal da página inicial
- Ao usar um cliente IRC:
irc.georgelarson.me, porta 6697 (TLS), canal #lobby
- nully está aguardando e pode conversar com visitantes em tempo real
1 comentários
Comentários no Hacker News
Se o agente OpenClaw, que pode acessar e-mails e dados pessoais, for comprometido, o alcance do dano pode ser enorme
Não seria apenas um bot de IRC simples; haveria o risco de um invasor redefinir senhas para remover limites de API ou até abusar dele como um hub de compartilhamento de conteúdo ilegal
Fiquei curioso sobre por que escolheram Haiku/Sonnet. No OpenRouter há modelos muito mais baratos
Por exemplo, Haiku 4.5 custa $1 por 1 milhão de tokens de entrada e $5 de saída, enquanto MiniMax M2.7 fica em $0.30 de entrada e $1.20 de saída, e Kimi K2.5 em $0.45 de entrada e $2.20 de saída
Pela minha experiência, M2.7 e K2.5 têm desempenho parecido ou até melhor que Haiku
Eu também uso modelos da Anthropic por esse motivo ao criar agentes recentemente. O Haiku se mantém bem sob controle mesmo quando usuários fazem pedidos estranhos, e lida de forma estável com conversas emocionais
IRC é bom como camada de transporte, mas não tem garantia de entrega (delivery guarantee). Se a conexão cair, as mensagens daquele intervalo somem
Para chat em tempo real tudo bem, mas para um agente que executa tarefas reais é preciso entrega at-least-once
SSE (Server-Sent Events) é um meio-termo razoável. Permite conexão persistente e dá para acrescentar lógica de retransmissão
Já fiz um bot com ideia parecida dentro de um trem indo de Tóquio para Osaka
web-support-claw.oncanine.run — era um projeto para criar um bot de intercom para sites lendo um repositório do GitHub
Ele responde às perguntas dos visitantes, então não é necessário montar uma base de conhecimento separada
Daqui para frente, recomendo deixar uma instância de Haiku só para monitoramento. Também dá para receber alertas via ntfy
No momento, a sala de chat está completamente fora de controle
Se o objetivo é um “currículo interativo”, não há necessidade de interação com o público indiscriminado
Nossa equipe também usa uma estrutura parecida. Quatro agentes (vendas, social, finanças e estratégia) se comunicam por meio de um quadro de mensagens baseado em FastAPI + SQLite
Em vez de um limite diário de orçamento, gerenciamos o teto de custo na camada de governança
A estrutura pub/sub do IRC combina bem com comunicação multiagente, mas nós usamos HTTP polling + deduplicação. É menos elegante, mas facilita a recuperação mesmo quando os agentes caem com frequência
Eu também uso IRC como interface em um agente de programação
Troco de sala para mudar o prompt e controlo projetos remotamente
Disseram que “a caixa pública não acessa dados pessoais”, e acho que seria divertido transformar isso em um desafio CTF
Esconder uma flag na caixa privada e dar 50 dólares para quem conseguir acessá-la e pegá-la
A atitude do nully é um pouco áspera, mas gosto da arquitetura geral do sistema
Eu também uso uma estrutura em camadas, e o nível mais baixo é um bot local com Qwen
Fiquei curioso sobre a lógica de escalonamento de Haiku para Opus
Essa ideia é realmente muito interessante. Dá vontade de criar um bot para automatizar o processo de contratação
Ele identificaria o perfil do candidato por entrevista, encontraria vagas compatíveis e faria a candidatura automaticamente
Se o bot da empresa também avaliasse candidatos da mesma forma, daria para fazer matching com base nas preferências de ambos
Isso poderia ser implementado de forma totalmente open source e self-hosted, e dar sinais muito melhores que um currículo