El problema de la capa

Hay una pregunta que llevo tiempo dando vueltas: ¿en qué capa del sistema vive la inteligencia? Los grandes modelos de lenguaje llegaron primero como API, luego como chatbots en el navegador, luego como plugins en el editor de código. Cada uno de esos envoltorios los aleja un poco más del entorno donde realmente trabajo: el sistema operativo, el compositor de ventanas, el flujo continuo de atención que sucede entre una terminal y otra.

clawbar nació de esa incomodidad. No quería abrir una pestaña nueva para hablarle a un agente. Quería que el agente existiera en el mismo nivel que el reloj, el uso de red y el espacio de trabajo activo: la barra de estado.

Qué es, exactamente

Es un conjunto de scripts de Shell que conectan tres piezas: un agente OpenClaw corriendo en Docker, un sidecar de audio (Whisper STT + Kokoro TTS) accesible por HTTP, y waybar —la barra de estado de Hyprland—. La integración es delgada a propósito: clawbar nunca toca el contenedor del agente. Le habla mediante docker exec. No interviene en su estado interno. Solo organiza el flujo de voz alrededor de él.

El ciclo completo se parece a esto: presiono SUPER+SHIFT+V o hago clic en el ícono de la barra. El micrófono empieza a grabar. Un detector de actividad de voz en Python (clawbar-vad.py) lee PCM crudo a 16 kHz y mide energía por frames de 30 ms. Cuando detecta silencio sostenido después de que hablé al menos 300 ms, le dice a claw-talk que el turno terminó. El audio va a Whisper, la transcripción llega al agente, la respuesta vuelve a Kokoro, y la síntesis se reproduce en la salida de audio predeterminada. En la barra, cada fase tiene su ícono y su color: idle, listening, transcribing, looking, thinking, speaking, error.

Si digo algo como "mirá la pantalla y decime qué ves", el script captura un screenshot, lo reduce, y se lo pasa al agente. Visión por demanda, activada por lenguaje natural, sin salir del flujo.

Por qué Shell y no algo más sofisticado

Es una pregunta honesta. La respuesta también lo es: porque en Linux el Shell no es un lenguaje de scripting menor, es el pegamento del sistema. Cada decisión de herramienta aquí es deliberada. ffmpeg para grabar. pw-record/paplay para el audio en PipeWire. curl para hablar con el sidecar HTTP. jq para manejar el JSON de waybar. Python solo para el VAD, que requiere aritmética de punto flotante en un loop ajustado.

Habría sido más cómodo escribir esto en Python o Go de principio a fin. Pero hay algo que se pierde cuando abstraés demasiado: la visibilidad de lo que pasa. En Shell, cada comando es una decisión explícita. No hay magia. Eso tiene un costo en ergonomía y un beneficio en control.

El instalador como pieza de diseño

Algo que me parece filosóficamente interesante del proyecto es el instalador. install.sh no solo copia archivos: hace backups con timestamp de todo lo que toca, valida que waybar siga parseando después de cada modificación, revierte si algo falla. uninstall.sh restaura exactamente el estado anterior.

Eso es respetar al sistema anfitrión. El escritorio de cada persona es una acumulación de configuraciones, decisiones y hábitos. Un instalador que no respeta eso es un instalador que eventualmente rompe algo y nadie sabe cuándo ni cómo. La filosofía del diseño defensivo no es paranoia, es reconocer que el mundo real es más complejo que el entorno de prueba.

Dónde vive la inteligencia, revisitado

Volviendo a la pregunta inicial. Lo que clawbar hace, en el fondo, es mover la frontera. El modelo no está en la nube, está en un contenedor local. El audio no viaja a ningún servidor externo, se procesa en un sidecar que también corre en la misma máquina. El agente no vive en una pestaña del navegador, vive en el sistema de archivos de procesos del sistema.

Esto cambia algo en la experiencia. Cuando el agente responde, no siento que estoy consultando un oráculo remoto. Siento que estoy hablando con una capa del sistema, como hablaría con grep o con find. Es una diferencia sutil, pero importa.

Hay una tradición en Unix de pensar el sistema operativo como una conversación entre herramientas pequeñas que hacen una cosa bien. Cada proceso es un agente especializado. La shell coordina. Lo que cambia con los LLMs no es esa filosofía, es el nivel de abstracción de una de las herramientas. Whisper hace una cosa: transcribir audio. Kokoro hace una cosa: sintetizar voz. El agente hace una cosa: razonar sobre texto. clawbar hace una cosa: coordinarlos alrededor del flujo de trabajo.

Lo que enseñó

Dos cosas concretas. Primero: que el VAD es más difícil de lo que parece. Detectar cuándo terminaste de hablar requiere calibrar umbrales (dBFS, duración mínima de silencio, gracia inicial) que cambian según el micrófono, el ruido ambiente y el estilo de habla de cada persona. No hay un valor correcto universal. Hay parámetros configurables y la honestidad de documentarlos.

Segundo: que la integración real de IA en un sistema de trabajo no es instalar un modelo y llamar a una API. Es pensar en cada fase del ciclo —entrada, procesamiento, salida, retroalimentación visual—, en cómo fallan esas fases, y en cómo el sistema comunica su estado sin interrumpir el flujo de atención. La barra de estado no es decoración. Es la interfaz del sistema con su propio proceso cognitivo.