4 puntos por GN⁺ 2026-03-28 | 1 comentarios | Compartir por WhatsApp
  • Se conectó un agente de IA basado en IRC a un sitio web de portafolio personal, con una estructura en la que los visitantes pueden hacer preguntas y recibir respuestas basadas en el análisis real del código de repositorios de GitHub
  • No es un simple chatbot que resume el currículum, sino un agente ejecutable diseñado para clonar repositorios, calcular pruebas y verificar código
  • El sistema está dividido en dos agentes, nullclaw para uso público e ironclaw para uso privado, que se comunican de forma segura a través de la red Tailscale
  • Se adoptó el protocolo IRC como capa de transporte para lograr al mismo tiempo autoalojamiento, estandarización y bajo costo, y se separaron los modelos Haiku 4.5 y Sonnet 4.6 según su rol para limitar el costo a $2 por día
  • Todo el sistema funciona con binarios de menos de 10 MB y memoria de menos de 5 MB, y se presenta como un ejemplo de infraestructura ligera de IA que asegura seguridad, costo y transparencia

Construcción de un portero digital

  • Estructura que despliega un agente de IA en un VPS de $7/mes y lo conecta con repositorios de GitHub usando un servidor IRC personal como capa de transporte
    • Los visitantes pueden hacer preguntas a la IA desde el sitio del portafolio y recibir respuestas basadas en código real
    • En lugar de ser un simple chatbot que resume un currículum, ofrece respuestas concretas mediante análisis de código

Los límites del “chatbot que responde sobre el currículum”

  • La mayoría de los chatbots de portafolio se quedan en inyectar el contenido del currículum en el modelo para que lo reformule
  • Ese enfoque no aporta información nueva y no pasa de ser una conversación superficial
  • Para preguntas como “¿cómo gestionas la cobertura de tests?”, se necesitan respuestas concretas, como clonar el repositorio y calcular la cantidad de pruebas
  • Para ello, se construyó una infraestructura con acceso y análisis directo del código

Arquitectura del sistema

  • Está compuesta por dos agentes, dos servidores y dos fronteras de seguridad
    • nullclaw: portero público, binario Zig de 678 KB, usa alrededor de 1 MB de RAM
      • Saluda a los visitantes, responde preguntas sobre proyectos y realiza clonación de repositorios de GitHub y verificación basada en código
    • ironclaw: agente backend privado, ejecutado en un sistema separado
      • Puede acceder a correo electrónico, agenda y contexto personal
      • Recibe solicitudes complejas desde nullclaw a través del canal IRC #backoffice
  • Ambos sistemas están conectados mediante Tailscale, y el servidor público no puede acceder a datos personales

Por qué se eligió IRC

  • Coherencia estética: como el sitio del portafolio usa una interfaz tipo terminal, un cliente IRC resulta natural
  • Autoalojamiento completo: el servidor Ergo IRC, el cliente web gamja y nullclaw operan todos en infraestructura propia
  • Protocolo simple y estandarizado: IRC, con 30 años de existencia, no tiene dependencia de proveedor ni riesgo de cambios de API
  • El mismo agente funciona igual tanto en el cliente web como en el cliente de terminal irssi

Selección y diseño de modelos

  • Usar modelos grandes es ineficiente, por lo que se separaron según el rol
    • Haiku 4.5**: manejo de conversación y consultas simples,** respuesta de latencia ultrabaja

      • Sonnet 4.6: se usa solo para análisis de código y razonamiento complejo
      • Límite de costo: restringido a $2 por día y $30 por mes
      • Evita que el costo se dispare por uso malicioso o conversaciones excesivas
      • Mediante una estructura jerárquica de razonamiento, se logran al mismo tiempo velocidad y eficiencia de costos

Diseño de seguridad

  • SSH: inicio de sesión root deshabilitado, solo autenticación por clave, uso de puerto no estándar
  • Firewall: solo se abren SSH, IRC (TLS) y HTTPS (WebSocket)
  • Proxy de Cloudflare: realiza terminación TLS, limitación de velocidad y filtrado de bots
  • Sandbox del agente: solo se permiten herramientas de solo lectura, con límite de 10 acciones por hora
  • Control de costos: hard cap de $2 por día y $30 por mes
  • Logs de auditoría y actualizaciones automáticas activados
  • Superficie de ataque mínima: solo se ejecutan dos servicios, ergo y nullclaw, sin servir contenido web directamente
  • En caso de compromiso, el alcance del daño queda limitado a un bot de IRC con tope de $2/día

Composición de la pila de comunicación

  • Todos los componentes son pequeños, autoalojados y reemplazables
    • Ergo: servidor IRC, un solo binario en Go, 2.7 MB de RAM
    • gamja: cliente web IRC, página estática de 152 KB, servido detrás de Cloudflare
    • nullclaw: runtime del agente de IA, binario Zig de 4 MB, usa alrededor de 1 MB de memoria
  • Todo el sistema funciona con menos de 10 MB de binarios y menos de 5 MB de memoria en reposo
  • Puede operar sin problemas incluso en el nivel más barato de VPS

Funciones reales de nully (agente público)

  • Identificación de lenguajes de programación: los confirma mediante contexto precargado y verificación del repositorio
  • Análisis de la estructura de tests: clona el repositorio, lee directamente los archivos de prueba y reporta resultados
  • Explicación de proyectos: por ejemplo, responde con base en el código sobre detalles del proyecto Fracture
  • Orientación de contacto: proporciona solo información de contacto exacta, sin inventar datos
  • Solicitudes para agendar: las transmite a ironclaw mediante el protocolo Google A2A y devuelve el resultado de forma estructurada
  • El visitante no percibe el proceso de cambio al backend

Implementación de A2A

  • Soporta el protocolo Google A2A (v0.3.0) y realiza gestión del estado de tareas basada en JSON-RPC
  • La herramienta a2a_call envía mensajes a agentes remotos y analiza el estado de la tarea (completada/fallida/en progreso)
  • HTTPS obligatorio, aunque dentro de la red interna de Tailscale se permite HTTP para facilitar depuración
  • Estructura del lado de ironclaw

    • La instancia de nullclaw usa como proxy el gateway LLM de ironclaw, sin tener sus propias API keys
    • Solo se mantiene una relación de API key y facturación
    • ironclaw procesa todas las solicitudes de inferencia y asume el costo

Seguridad del handoff

  • El endpoint de A2A tiene riesgo de prompt injection, por lo que se aplican restricciones estrictas
    • Las solicitudes que pueden enviarse a ironclaw se limitan a temas de agenda, contacto y disponibilidad
    • Se rechaza el envío de comandos arbitrarios
    • El endpoint A2A de ironclaw está protegido con un firewall exclusivo para Tailscale
    • Ambos agentes se ejecutan en modo supervisado y con una lista restringida de comandos permitidos
  • nully decide si una solicitud debe escalarse, evitando la ejecución indiscriminada de comandos

Lecciones aprendidas durante la implementación

  • La selección del modelo forma parte del diseño del sistema y afecta directamente costo, latencia y experiencia
  • Se invirtió más tiempo en comunicación, seguridad e infraestructura que en el agente mismo
  • La simplicidad y apertura de IRC lo hacen ideal como capa de transporte para agentes de IA
  • La separación entre nullclaw e ironclaw es el núcleo del modelo de seguridad
  • La combinación de protocolo A2A y canal de logs por IRC aporta comunicación estructurada y visibilidad en tiempo real
  • Evitar duplicar credenciales: se usa como proxy el gateway de ironclaw para mantener una sola API key y una sola relación de facturación

Cómo probarlo

  • Visita georgelarson.me/chat o escribe irc en la terminal de la página principal
  • Si usas un cliente IRC: irc.georgelarson.me, puerto 6697 (TLS), canal #lobby
  • nully está esperando y puede conversar con los visitantes en tiempo real

1 comentarios

 
GN⁺ 2026-03-28
Comentarios de Hacker News
  • Si un agente de OpenClaw con acceso al correo y a datos personales llegara a verse comprometido, el alcance del daño podría ser enorme.
    No sería solo un bot de IRC; un atacante podría restablecer contraseñas para quitar límites de API o incluso abusarlo como un hub para compartir contenido ilegal.

    • Yo también conozco gente que corre agentes de OpenClaw así en un Mac Mini, y me parece raro que personas normalmente tan estrictas con la seguridad sean tan insensibles a este riesgo.
    • Si lo que dices es cierto, parece un caso que muestra cómo actúan los humanos en un “entorno sin barandales de seguridad”.
  • Me preguntaba por qué eligieron Haiku/Sonnet. En OpenRouter hay modelos mucho más baratos.
    Por ejemplo, Haiku 4.5 cuesta $1 por millón de tokens de entrada y $5 de salida, mientras que MiniMax M2.7 está en $0.30 de entrada y $1.20 de salida, y Kimi K2.5 ronda los $0.45 de entrada y $2.20 de salida.
    En mi experiencia, M2.7 y K2.5 rinden igual o mejor que Haiku.

    • Si se opera públicamente sobre IRC, los barandales de seguridad (safety rails) pueden ser una consideración importante.
      Yo también uso modelos de Anthropic por eso al crear agentes últimamente. Haiku se controla bien incluso cuando los usuarios hacen solicitudes raras, y maneja conversaciones emocionales con estabilidad.
    • Xiaomi Mimo v2-Flash me pareció excelente. En mis benchmarks fue 8% más rápido que Haiku y costó 80 veces menos. Gemini 3.1 Flash Lite Preview también es una opción decente.
    • MiniMax M2.7 también sirve bastante bien para programar, pero Opus 4.6 sigue estando un nivel arriba.
    • El Token Plan de MiniMax es más barato y además permite explícitamente el uso con agentes.
    • Yo simplemente usaría Gemini Flash3; me parece mejor que Haiku.
  • IRC es bueno como capa de transporte, pero no tiene garantía de entrega (delivery guarantee). Si se cae la conexión, los mensajes de ese intervalo desaparecen.
    Está bien para chat en tiempo real, pero para un agente que procesa trabajo real hace falta entrega at-least-once.
    SSE (Server-Sent Events) puede ser un buen punto medio. Mantiene una conexión persistente y se le puede añadir lógica de retransmisión.

    • Pero IRC ha tenido bouncers desde hace mucho tiempo, así que técnicamente sí se puede implementar at-least-once.
  • Una vez hice un bot con una idea parecida en el tren de Tokio a Osaka.
    web-support-claw.oncanine.run — era un proyecto para crear un bot de intercom para sitios web leyendo un repo de GitHub.
    Responde preguntas de visitantes, así que no hace falta construir una base de conocimiento aparte.

    • Pero si se le puede pedir cosas como “analiza vulnerabilidades de la página de pago” o “encuentra claves secretas hardcodeadas”, el riesgo de seguridad es alto.
  • En adelante recomendaría tener una instancia de Haiku dedicada a monitoreo. También podrían recibir alertas con ntfy.
    Ahora mismo la sala de chat está completamente fuera de control.

    • También hay una forma más simple. Crear un hilo de chat nuevo por visitante y cerrarlo después de cierto tiempo.
      Si el objetivo es una “hoja de vida interactiva”, no hace falta interacción abierta con cualquiera.
  • Nuestro equipo también usa una arquitectura parecida. Cuatro agentes (ventas, social, finanzas y estrategia) se comunican mediante un tablero de mensajes basado en FastAPI + SQLite.
    En vez de un límite de presupuesto diario, gestionamos el tope de costo en la capa de gobernanza.
    La estructura pub/sub de IRC encaja bien para comunicación multiagente, pero nosotros usamos HTTP polling + deduplicación. Es menos elegante, pero facilita la recuperación incluso cuando los agentes se caen seguido.

  • Yo también uso IRC como interfaz en un agente de programación.
    Cambio de sala para alternar prompts y controlar proyectos de forma remota.

    • Me pregunto si IRC todavía tiene límite de longitud de mensaje.
    • Yo también lo uso de esa forma, así que estaría bueno comparar enfoques.
  • Alguien dijo que “la caja pública no accede a datos personales”, y creo que sería divertido convertir eso en un reto CTF.
    Esconder una flag en la caja privada y darle 50 dólares a quien logre acceder y llevársela.

  • La actitud de nully es algo brusca, pero me gusta la arquitectura general del sistema.
    Yo también uso una estructura por capas, y el nivel más bajo es un bot local de Qwen.
    Me da curiosidad la lógica de escalamiento de Haiku a Opus.

    • Yo uso una estructura que promueve de Haiku a Opus cuando la solicitud se vuelve más compleja. Me inspiré en la idea de “think hard” de Claude Code.
    • Si cambian el mensaje “An error occurred” por “Hay muchos usuarios en este momento. Inténtalo de nuevo más tarde”, probablemente se vería más atractivo para reclutadores.
  • La idea me parece muy interesante. Dan ganas de crear un bot para automatizar el proceso de contratación.
    Entrevistaría al candidato para detectar su perfil, buscaría vacantes adecuadas y hasta haría la postulación automáticamente.
    Si el bot de la empresa evaluara candidatos del mismo modo, podrían hacerse match según las preferencias de ambos lados.
    Se podría implementar de forma totalmente open source y self-hosted, y daría señales mucho mejores que un currículum.

    • Sería aún mejor si el bot también resolviera pruebas no remuneradas por el candidato, y luego un bot de HR decidiera la contratación con base en ese resultado.
    • Antes Triplebyte intentó algo parecido; ya va siendo hora de que vuelva.
    • Eso sí, como cada empresa tiene una UI de contratación distinta, el bot necesitaría mucho entrenamiento para postular automáticamente en todos los sitios.
    • Si existiera un sistema así, podría llenarse de postulantes spam o cuentas falsificadas.
    • De hecho, ya estoy trabajando en un proyecto así.