Hay un momento en todo proyecto de software en el que te das cuenta de que has estado construyendo lo incorrecto. Has pasado semanas escribiendo un enrutador de mensajes, un motor de ejecución de herramientas, un gestor de estado de conversación y un sistema de reintentos — y entonces descubres que el proveedor de IA ya maneja todo eso, mejor de lo que tú podrías, en una sola llamada a la API.
Ese momento es lo que llevó a la arquitectura de NanoClaw. Todo el núcleo — la parte que convierte un mensaje de WhatsApp en una respuesta de agente de IA con uso de herramientas, navegación web, acceso a archivos y conversación multi-turno — son aproximadamente 500 líneas de TypeScript. No 500 líneas de código pegamento que importan 50.000 líneas de framework. Quinientas líneas, en total, construidas sobre Claude Agent SDK de Anthropic.
La reacción de los desarrolladores que leen el código fuente por primera vez suele ser de incredulidad, seguida de la pregunta que importa: "¿Dónde está el resto?"
Qué hace realmente Claude Agent SDK
La mayoría de los frameworks de agentes de IA existen porque, históricamente, las APIs de modelos de lenguaje eran stateless y simples. Enviabas un prompt, recibías una respuesta. Si querías uso de herramientas, tenías que construir el bucle de ejecución de herramientas tú mismo. Si querías conversación multi-turno, tenías que gestionar el historial de mensajes tú mismo. Si querías que el modelo decidiera entre múltiples herramientas, tenías que construir la lógica de enrutamiento tú mismo.
Claude Agent SDK cambia esa ecuación de forma fundamental. El SDK no solo llama a la API de Claude — ejecuta un bucle de agente. Le das un prompt de sistema, un conjunto de herramientas y un mensaje del usuario. El SDK se encarga de todo lo demás: envía el mensaje a Claude, recibe la respuesta, comprueba si Claude quiere usar una herramienta, ejecuta la herramienta, envía el resultado de vuelta a Claude, y repite hasta que Claude produce una respuesta final. Todo el bucle de uso de herramientas — lo que la mayoría de los frameworks implementan en miles de líneas — es una sola llamada a función.
Esto no es un wrapper superficial. El SDK maneja streaming, lógica de reintentos, conteo de tokens y estado de conversación. Gestiona el ida y vuelta entre Claude y las herramientas a lo largo de múltiples turnos, manejando casos extremos como fallos en la ejecución de herramientas y límites de la ventana de contexto. La complejidad que NanoClaw no necesita implementar no falta — se ha delegado a un SDK bien probado mantenido por el propio equipo de ingeniería de Anthropic.
Qué construye realmente NanoClaw
Si el SDK maneja el bucle del agente, ¿qué hacen realmente las 500 líneas de NanoClaw? La respuesta es todo lo que rodea al bucle — las partes específicas de ejecutar un asistente personal de IA en lugar de simplemente llamar a una API.
La primera responsabilidad es la integración de canales. NanoClaw se conecta a WhatsApp a través de la librería Baileys, recibe mensajes y los enruta al contenedor de agente correcto. Este es el pegamento entre "alguien envió un mensaje en WhatsApp" y "un agente necesita procesar este mensaje." No es código complicado, pero es código esencial — sin él, el agente no tiene forma de llegar a los usuarios donde ya están.
La segunda responsabilidad es la orquestación de contenedores. Cada conversación de agente se ejecuta dentro de su propio contenedor Linux — Apple Container en macOS, Docker en Linux. NanoClaw lanza contenedores, monta los directorios correctos, pasa secretos vía stdin y recopila respuestas. Esta es la frontera de seguridad que impide que un agente comprometido acceda a cualquier cosa fuera de su sandbox. La gestión del ciclo de vida del contenedor son unas 80 líneas de código, pero esas 80 líneas son la diferencia entre un agente al que se le pueden confiar credenciales reales y uno al que no.
La tercera responsabilidad es la memoria persistente. NanoClaw mantiene una base de datos SQLite de conversaciones, estado de grupo y tareas programadas. Cada grupo de WhatsApp tiene su propio archivo CLAUDE.md que sirve como memoria a largo plazo del agente para ese grupo. El sistema de memoria es simple — intencionalmente — porque la parte compleja de la memoria (decidir qué es relevante, qué recordar, cómo usar el contexto) la maneja el propio Claude.
La cuarta responsabilidad son las tareas programadas. Los usuarios pueden pedirle al agente que haga cosas en momentos específicos — "recuérdame a las 3pm" o "revisa esta web cada mañana." El programador tipo cron de NanoClaw lanza contenedores de agente en los momentos adecuados, lo cual es una funcionalidad pequeña pero genuinamente útil que convierte un chatbot reactivo en un asistente proactivo.
Por qué importan 500 líneas
El conteo de líneas no es una métrica de vanidad. Es una medida directa de la superficie de mantenimiento, la superficie de bugs y la carga cognitiva necesaria para entender el sistema.
Cuando aparece un bug en el núcleo de NanoClaw, hay 500 líneas donde podría estar. Un desarrollador puede leer todo el código base en menos de una hora y entender cada decisión que se tomó. Compara eso con frameworks de 50.000 líneas de código central — encontrar un bug significa navegar abstracciones, entender sistemas de plugins y rastrear la ejecución a través de capas de indirección que existen para soportar funcionalidades que quizás ni uses.
Las implicaciones de seguridad son igualmente concretas. Cada línea de código es una vulnerabilidad potencial. El núcleo de 500 líneas de NanoClaw tiene una superficie de ataque menor que los parsers de configuración de la mayoría de los frameworks. El aislamiento por contenedores, el paso de secretos por stdin, las listas blancas de montaje — estas funcionalidades de seguridad están implementadas en código lo suficientemente pequeño como para auditarlo completamente en una tarde.
Y la historia de actualizaciones es simple. Cuando Anthropic lanza una nueva versión de Claude Agent SDK con mejor uso de herramientas, o streaming más rápido, o nuevas capacidades, NanoClaw obtiene esas mejoras actualizando una sola dependencia. No hay capa de abstracción del framework que necesite actualizarse para exponer las nuevas funcionalidades del SDK. El SDK es el framework.
La filosofía de no construir
La parte más difícil de la arquitectura de NanoClaw no fue construirla — fue decidir qué no construir. La tentación de añadir un motor de ejecución de herramientas personalizado, un sistema sofisticado de recuperación de memoria, una capa de abstracción multi-proveedor, un marketplace de plugins — todas estas son cosas que otros frameworks han construido, y todas son cosas que NanoClaw deliberadamente no tiene.
Cada una de esas funcionalidades añadiría miles de líneas de código, decenas de bugs potenciales y semanas de carga de mantenimiento. Y cada una duplicaría funcionalidad que Claude Agent SDK ya proporciona o que el propio Claude maneja mejor que cualquier código escrito a mano.
El resultado es un proyecto donde las decisiones interesantes son arquitectónicas, no de implementación. ¿Cómo deberían aislarse los contenedores? ¿Cómo deberían pasarse los secretos? ¿Cómo debería limitarse la memoria por grupo? Estas son las preguntas que importan para un asistente personal de IA, y son las preguntas a las que las 500 líneas de NanoClaw están dedicadas a responder.
La próxima vez que evalúes un framework de agentes de IA, no cuentes funcionalidades. Cuenta líneas. El framework con menos líneas no es el menos capaz — podría ser el que entendió el problema lo suficientemente bien como para dejar que el proveedor de IA haga el trabajo pesado.