Framework de Agentic OS con Claude Code: Así Construí el Mío

Pasé seis meses tratando a Claude Code como a un becario muy rápido. Inteligente, incansable, a veces brillante... y olvidadizo justo en los momentos que más tiempo me costaban. Cada sesión comenzaba reexplicando la misma voz de marca, la misma estructura de carpetas, las mismas reglas que ya había anotado en otros tres sitios. Cada habilidad que construía existía en aislamiento. Cada automatización que conectaba funcionaba perfectamente... hasta el momento en que necesitaba entregarla a alguien que nunca había usado un terminal.

Entonces dejé de crear herramientas puntuales y empecé a construir un sistema.

Lo que voy a mostrar aquí es el framework agentic OS de Claude Code en el que terminé después de desmontar y reconstruir mi stack tres veces en el Q1 de 2026. No es un producto. No es un plugin. Es un patrón arquitectónico que convierte Claude Code de un asistente de codificación en algo más parecido a un sistema operativo personal — uno que recuerda, ejecuta de forma consistente y puede ser entregado a clientes que jamás han abierto un terminal en sus vidas.

La clave que lo desbloqueó para mí fue simple: la mayoría de los setups de Claude Code fallan en los mismos tres puntos. Memoria, consistencia y acceso. Si cierras esas tres brechas, la herramienta deja de ser una herramienta. Se convierte en infraestructura.

Las tres brechas que tiene toda configuración de Claude Code

Antes de que la arquitectura tenga sentido, el problema que resuelve debe ser específico. Porque si has usado Claude Code durante más de unas semanas, probablemente hayas sentido las tres brechas… aunque no les hayas puesto nombre.

Brecha uno: memoria. Claude Code no guarda estado entre sesiones a menos que le des un lugar donde almacenar lo que aprende. CLAUDE.md ayuda, pero no deja de ser un solo archivo haciendo el trabajo de un archivador. En cuanto necesitas que el agente recuerde las preferencias de un cliente, el historial de un proyecto, una decisión que tomaste hace tres semanas — vuelves a explicarlo todo. La mayoría al oír "memoria" asume que la solución es un pipeline RAG completo con embeddings vectoriales en Pinecone o Supabase. Para el 90% de los flujos de trabajo, eso es un exceso. Lo que necesitas es persistencia, no una búsqueda semántica entre un millón de documentos.

Brecha dos: consistencia. Si le pides a Claude Code que escriba un post de blog el lunes, obtendrás un resultado. Si se lo pides igual el viernes, recibirás algo diferente: otro tono, diferente estructura, distinto pie de página. La variación no es culpa del modelo. Es un problema de ingeniería de prompts disfrazado de un problema de modelo. Sin habilidades estructuradas que codifiquen cómo quieres que se haga el trabajo, cada ejecución es una moneda al aire. Las habilidades y automatizaciones resuelven esto, pero solo si están organizadas como una operación real, no tiradas en una carpeta plana como ~/.claude/skills/.

Brecha tres: acceso. Esta es la brecha de la que nadie habla porque los fundadores técnicos no la sienten. Pero si alguna vez intentaste entregar Claude Code a un compañero no técnico, un cliente, o incluso a tu propio cerebro a las 10 de la noche cuando no quieres teclear claude --continue --session-id foo — la has sentido. El terminal es un foso. Para ti es una ventaja. Para los demás, es una barrera.

El framework agentic OS es eso que surge cuando dejas de intentar cubrir estas tres brechas por separado y empiezas a resolverlas en conjunto.

Qué es realmente un Agentic OS

La frase "agentic OS" se usa de forma bastante laxa. Esto es lo que significa en este contexto específico: una arquitectura donde Claude Code es el motor de ejecución, una capa de memoria persistente le da continuidad, un sistema jerárquico de habilidades le aporta consistencia y un panel de control ofrece a los usuarios no técnicos una puerta de entrada.

Cuatro capas. Eso es todo.

┌─────────────────────────────────────────────┐
│  Dashboard / Command Center (Next.js)       │  ← acceso
├─────────────────────────────────────────────┤
│  Skills + Automations (local + remote)      │  ← consistencia
├─────────────────────────────────────────────┤
│  Memory Layer (Obsidian vault, Markdown)    │  ← memoria
├─────────────────────────────────────────────┤
│  Claude Code (engine)                       │  ← ejecución
└─────────────────────────────────────────────┘

La razón por la que esta arquitectura funciona es que cada capa tiene una única función, y ninguna entorpece a las demás. Claude Code hace aquello en lo que ya es bueno: razonar, escribir código, ejecutar tareas de varios pasos. Obsidian gestiona la persistencia porque ya es un sistema de archivos de documentos Markdown, que es justo el formato que Claude Code lee y escribe de forma nativa. Las skills y automatizaciones convierten mensajes ad-hoc en flujos de trabajo fiables. El dashboard lo envuelve todo en una interfaz clicable.

Quiero señalar lo que más me sorprendió durante el desarrollo: el dashboard es el elemento que cambia las reglas del juego para los usuarios no técnicos, pero también cambió la forma en la que yo trabajo. Volveré sobre esto más adelante. Tenlo presente mientras avanzamos.

Capa Uno: Memoria Sin RAG

Permíteme empezar con la parte que más retrabajo me causó.

Pasé dos fines de semana en febrero construyendo una capa de memoria RAG propiamente dicha para Claude Code. Supabase como almacén vectorial, embeddings de OpenAI, un servidor MCP personalizado que permitía a Claude consultarlo mediante búsqueda semántica. Funcionaba. Pero estaba excesivamente sobre-ingenierizado para lo que realmente necesitaba, que era simplemente "recordar lo que decidimos el martes pasado".

Lo eliminé y lo reemplacé por un vault de Obsidian. Toda la capa tomó unos 40 minutos en configurarse.

Aquí tienes por qué Obsidian funciona como capa de memoria AI para Claude Code específicamente:

• Las vaults de Obsidian son solo carpetas de archivos Markdown. Sin formato propietario. Sin base de datos. Sin capa de sincronización que debas vigilar. Claude Code lee y escribe Markdown de forma nativa, lo que significa que el "sistema de memoria" es, literalmente, solo acceso al sistema de archivos.
• El enlazado tipo wiki ([[nombre-de-nota]]) te da estructura sin esquema. Claude puede seguir enlaces igual que lo haría una persona, rastreando hilos entre notas.
• Es gratis, local y portable. Si decido cambiar Claude Code por Codex CLI o cualquier cosa nueva que salga el próximo mes, mi capa de memoria viene conmigo. Sin dependencia de proveedor.
• El propio Obsidian representa el vault de forma visualmente atractiva para humanos. Cuando quiero revisar lo que el agente escribió, no necesito consultar una base de datos. Simplemente abro Obsidian y leo.

La estructura de mi vault se ve aproximadamente así:

~/vault/
├── _claude/
│   ├── CLAUDE.md              # contexto global, cargado en cada sesión
│   ├── session-logs/          # lo que pasó en cada ejecución
│   └── decisions/             # por qué tomé decisiones específicas
├── clients/
│   └── [nombre-del-cliente]/
│       ├── brief.md
│       ├── brand-voice.md
│       └── delivered/
├── projects/
│   └── [nombre-del-proyecto]/
└── knowledge/
    ├── claude-code-patterns.md
    └── skills-registry.md

La pieza crítica es _claude/CLAUDE.md. Ese archivo es el punto de entrada de Claude Code al vault — una tabla de contenidos para el agente. Le indica a Claude dónde viven los briefs de clientes, dónde escribir los registros de sesión, qué archivos contienen decisiones que nunca deben contradecirse. En cada sesión, el agente lee este archivo primero y luego recorre la parte del vault que necesite.

Para la mayoría que lee esto, si estás decidiendo entre "construir un sistema RAG" y "configurar un vault Obsidian", empieza por el vault. Siempre puedes sumar RAG después, cuando realmente alcances una escala en la que la búsqueda semántica importe. Yo aún no he llegado a ese punto, y llevo tres meses operando esta configuración en cuatro marcas y más de 230 piezas de contenido. Si quieres una versión más profunda de este argumento, ya he escrito sobre Obsidian como memoria persistente de Claude Code y sobre por qué un knowledge vault plano supera a un pipeline RAG para la mayoría de los workflows.

Una nota antes de continuar: la capa de memoria no es opcional en este framework. Sin ella, la capa de skills no tiene nada a lo que anclarse. La consistencia requiere algo con lo que ser consistente. Ese es el puente hacia la siguiente pieza.

Capa Dos: Habilidades y Automatizaciones, Estructuradas como un Organigrama

Esta es la capa donde la mayoría de los intentos de construir un agentic OS colapsan en el caos.

El error que veo repetirse constantemente —y que yo mismo cometí durante un tiempo— es arrojar cada habilidad en una carpeta plana: ~/.claude/skills/post-writer, ~/.claude/skills/research, ~/.claude/skills/social-scheduler, y treinta más. Luego, intentar recordar cuál hace qué cuando la necesitas seis semanas después.

La solución es dejar de pensar en las habilidades como simples scripts y empezar a verlas como roles dentro de un equipo.

Esta es la jerarquía a la que llegué:

Funciones son los dominios generales de trabajo. "Producción de contenido". "Investigación". "Operaciones de clientes". "Monitorización de marca". No son habilidades en sí, sino categorías a las que pertenece una habilidad.

Habilidades son tareas atómicas y reutilizables dentro de una función. Dentro de "producción de contenido" tengo blog-post-writer, image-brief-generator, social-distribution-package. Cada habilidad hace una cosa bien. Cada una tiene su propio archivo SKILL.md donde se explica cuándo Claude debe invocarla, qué entradas necesita y qué produce.

Sub-habilidades se encargan del trabajo especializado que delega una habilidad principal. blog-post-writer tiene sub-habilidades para la fase de investigación, ajuste de voz, estructuración SEO y autoevaluación. El rol principal orquesta; las sub-habilidades ejecutan.

Automatizaciones son habilidades con disparadores. Es la misma habilidad, pero ahora se ejecuta según horario o automáticamente cuando sucede algo. Las automatizaciones programadas se gestionan por cron. Las automatizaciones bajo demanda se activan con un clic en el dashboard o con un hook dentro de Claude Code.

Claude Code lanzó un plugin creador de habilidades en su marketplace oficial a principios de este año que resuelve casi toda la estructura base. Al ejecutar /plugin install skill-creator dentro de Claude Code, obtienes un flujo guiado: describes la habilidad, la pruebas con entradas reales, iteras el prompt, la grabas en tu carpeta de habilidades. El ecosistema que rodea esto es enorme: los marketplaces comunitarios en tonsofskills.com y claudemarketplaces.com ya listan miles de plugins y agentes para abril de 2026, y la mayoría encaja perfectamente en esta jerarquía si los organizas por función.

La razón por la que la estructura jerárquica importa no es estética. Es que la lógica de enrutamiento de Claude Code mejora cuando las habilidades están organizadas. Cuando el agente debe decidir qué habilidad invocar, toma esa decisión dentro de su ventana de contexto. Una carpeta plana con 60 habilidades desperdicia tokens en desambiguaciones. Una jerarquía de cuatro funciones, cada una con seis a ocho habilidades y cada una con sub-habilidades nombradas, permite que el agente acote mucho más rápido.

Si quieres profundizar más en la jerarquía, la desgloso en mi playbook de equipos de agentes en Claude Code y en la guía avanzada de habilidades para agentes. Ambos son cluster posts relacionados con este.

Automatización Local vs Remota: La Decisión Que Realmente Importa

Una vez que existen las skills, la siguiente pregunta es dónde ejecutarlas. Aquí es donde muchos proyectos se confunden, porque la distinción entre automatización local y remota no se trata de complejidad — se trata de qué necesita tocar la skill.

Las automatizaciones locales se ejecutan en tu máquina. Tienen acceso a tu sistema de archivos, tus CLIs instalados, tu bóveda local de Obsidian, tus repositorios git, tus grabaciones de pantalla, todo lo que tengas ahí. Requieren que estés logueado. Si tu laptop está en suspensión, ellas también lo están.

Las automatizaciones remotas corren en la nube — normalmente mediante Claude Routines, que Anthropic lanzó como parte del plan de $20/mes y expandió significativamente con la actualización de abril de 2026. Funcionan de manera independiente a tu máquina. No tienen acceso al sistema de archivos ni a los CLIs locales, pero tampoco dependen de que estés en línea.

El criterio de decisión que uso es literalmente esta pregunta: ¿esta skill necesita tocar algo local? Si la respuesta es sí, se ejecuta localmente. Si no, remota. Sin complicaciones.

Ejemplos concretos:

Candidatos a automatización local:

• Flujos de investigación profunda que encadenan Firecrawl CLI para scraping, Notebook LM para síntesis y escriben el output a una nota de Obsidian. Requieren CLIs locales y sistema de archivos local — debe ser local.
• Pipelines de video a blog donde descargo un video, lo paso por una etapa de transcripción local, envío la transcripción a Claude Code y guardo el post en content/mejba.me/[slug].md. Los archivos están localmente. La automatización es local.
• Refactorizaciones de bases de código donde Claude Code edita archivos reales del repositorio en disco.
• Skills de revisión de diseño basada en capturas de pantalla que capturan una ventana local del navegador y la envían al agente.

Candidatos a automatización remota:

• Búsqueda web diaria + reporte que busca noticias de IA cada mañana a las 6am, compila un resumen y lo sube como archivo Markdown a un repositorio de GitHub. No hay nada local involucrado. Corre en la nube. Me levanto, hago git pull, leo el resumen.
• Monitoreo de marca programado — búsqueda de menciones de la marca de un cliente en toda la web cada hora, registrando novedades en una base de datos de Notion. Flujo totalmente en la nube.
• Redacción de newsletter desde un feed RSS cada domingo por la noche, entregado como borrador en Ghost o Beehiiv vía API. Sin estado local.
• Investigación de leads y borradores de outreach — extracción nocturna de una lista de leads, investigación de cada empresa, redacción de un correo personalizado, lo deja en borradores para revisión humana.

La razón por la que esta distinción importa tanto es costo y confiabilidad. Las automatizaciones remotas no te cuestan nada si fallan a las 3am — simplemente reintentan. Las automatizaciones locales que fallan a las 3am quedan paralizadas hasta que te levantas. Pero las automatizaciones locales pueden hacer cosas que las remotas, por definición, no pueden, porque están dentro de tu entorno de trabajo.

Divido el framework aproximadamente en un 60/40 local-remoto, pero eso depende de a qué me dedico. Si tu trabajo es principalmente operaciones SaaS, CRM, email y herramientas cloud-native, tu balance será mucho más remoto. He escrito aparte sobre los canales de automatización cloud de Claude Code y la primera build de Claude Routines que publiqué en Opus 4.7 si quieres profundizar más en cualquiera de los dos enfoques.

Capa Cuatro: El Dashboard Es Todo El Sentido

Aquí es donde quiero hacer una pausa y confesar algo.

Cuando escuché por primera vez "construye un dashboard sobre Claude Code", reaccioné con el típico reflejo del ingeniero: ¿por qué pondría una interfaz gráfica sobre una herramienta CLI que manejo con soltura? El terminal es más rápido. Puedo encadenar cosas. Puedo crear alias. Un dashboard suena a fricción extra disfrazada de accesibilidad.

Ese reflejo era erróneo. Construir el dashboard cambió mi forma de usar Claude Code más que cualquier otra parte del framework.

Esto es lo que pasé por alto. El terminal está optimizado para el momento en que empiezas una tarea. Arranque en frío, foco total, café en mano: escribes el comando y listo. Pero el terminal es pésimo para los momentos entre tareas. Comprobar qué han producido las automatizaciones nocturnas. Monitorizar un trabajo de investigación en ejecución. Delegar la invocación de una skill a un compañero que no programa. Echar un vistazo a lo que se ejecutó ayer mientras almuerzas. Para cada uno de esos momentos, el dashboard gana.

Lo que construí es una sencilla app Next.js 15 que se ejecuta localmente y expone cinco funciones:

1. Lanzador de skills — cada skill de mi jerarquía aparece como un botón, agrupado por función. Se hace clic, se completa un pequeño formulario (cliente, proyecto, cualquier parámetro), y se ejecuta. El dashboard lanza Claude Code con la invocación adecuada.
2. Rutinas próximas — muestra todo lo programado para ejecutarse en las próximas 24 horas. Corrijo errores antes de que ocurran, no después.
3. Actividad reciente — un feed de todo lo que Claude hizo en las últimas 48 horas, extraído de la carpeta de logs de sesión en mi vault de Obsidian. Cada entrada enlaza al log completo.
4. Uso del sistema — gasto de tokens por skill por día, por modelo. Me ayuda a detectar automatizaciones que están consumiendo tokens Opus en silencio cuando Haiku sería suficiente.
5. Bandeja de salida — todo lo que Claude ha producido y está esperando mi revisión. Borradores de blog, informes de investigación, borradores de emails.

El dashboard son unas 800 líneas de TypeScript. No es complicado. Lo verdaderamente transformador no es el código, sino el cambio operativo. Cuando todo tiene un botón, delego de forma diferente. Delego más. Delego a compañeros que jamás habrían utilizado Claude Code desde un terminal.

Y esa última parte es donde realmente se cierra la brecha de acceso. Puedo enviar a un cliente al dashboard, decirle "haz clic aquí para generar el borrador de tu actualización semanal" y obtiene valor de Claude Code sin siquiera saber qué es Claude Code. Ese es el cambio de "herramienta" a "infraestructura".

Si eres profesional independiente, construye el dashboard para ti mismo antes de pensar en los clientes. Te sorprenderá cuánto cambia tu propio comportamiento en cuanto la fricción disminuye.

Una Ruta de Construcción Práctica Que Realmente Puedes Seguir

Suficiente arquitectura. Aquí tienes la secuencia que seguiría si tuviera que empezar de nuevo hoy, pensada para alguien que ya usa Claude Code varias veces a la semana.

Semana uno: memoria. Instala Obsidian (gratis, obsidian.md). Crea una bóveda. Estructura las carpetas como mostré antes. Escribe tu archivo _claude/CLAUDE.md con cinco secciones: quién eres, en qué marcas/proyectos trabajas, dónde viven los archivos, cómo debe escribir el agente, qué nunca debe hacer. No lo pienses demasiado. Lo reescribirás tres veces en el primer mes de todas formas. Luego apunta Claude Code a la bóveda —ya sea lanzándolo desde dentro del directorio de la bóveda, o referenciando la ruta de la bóveda en tu CLAUDE.md global. Ejecuta algunas tareas reales y observa qué escribe el agente como respuesta.

Semana dos: dos skills. Elige las dos tareas que realizas más a menudo. En mi caso fue "escribir una entrada de blog a partir del resumen de un video" y "generar un paquete de distribución social a partir de un artículo". Instala el plugin skill-creator mediante /plugin dentro de Claude Code. Úsalo para estructurar cada skill. Prueba cada skill cinco veces con entradas reales. Itera el prompt hasta que la salida sea consistente. Guarda las skills en tu directorio personal de skills.

Haber hecho dos skills es suficiente para saber si el framework se adapta realmente a tu flujo de trabajo. No construyas más hasta que estas sean fiables.

Semana tres: una automatización. Selecciona una skill que se beneficiaría de ejecutarse de manera programada o bajo demanda. Si requiere archivos locales, configúrala como un cron job local que llame a Claude Code en modo headless. Si no lo necesita, usa Claude Routines para ejecutarla en la nube. Una automatización. Déjala correr durante una semana. Ajusta la programación. Arregla los casos extremos.

Semana cuatro: dashboard v0. Crea la versión más simple posible. Cinco botones que ejecutan comandos en Claude Code. Sin autenticación, sin base de datos, funcionando en localhost:3000. Si no eres de frontend, la skill de frontend-design en Claude Code puede estructurarlo todo a partir de una descripción. Mi v0 era un solo componente React. El pulido vino después.

Semana cinco en adelante: amplía solo lo que lo merezca. Añade una skill cuando identifiques un patrón repetido. Añade una automatización cuando notes que ejecutas manualmente la misma skill con la misma frecuencia. Añade un botón al dashboard cuando quieras delegar o dejar de escribir la misma invocación. No amplíes por ampliar. El framework premia la moderación: cada skill que añades representa un coste de contexto del prompt que el agente paga en cada decisión de ejecución.

Si quieres una guía más detallada sobre la parte de agent-teams, mi guía de configuración de Claude Code agent teams cubre la jerarquía de skills con mucho más detalle del que puedo ofrecer aquí.

Qué la mayoría de las guías de construcción pasan por alto

Quiero señalar tres cosas que veo repetirse en otros artículos sobre sistemas operativos agentic OS y que considero erróneas, o al menos incompletas, basándome en tres meses de uso real.

"Necesitas RAG." No, no lo necesitas. No al nivel en el que operan la mayoría de personas individuales o equipos pequeños. Un vault de Obsidian bien organizado con 500 notas te servirá mejor que una base de datos vectorial con un millón de embeddings, porque la propia organización es el sistema de recuperación. RAG realmente es útil cuando buscas entre decenas de miles de documentos y no puedes predecir la estructura. Si puedes predecir la estructura, la estructura gana a los vectores. Cuando finalmente llegue al punto en que necesite búsqueda semántica, la añadiré como una capa más. No antes.

"Construye cada skill tú mismo." El ecosistema comunitario alrededor de Claude Code en 2026 es enorme y la mayoría de quienes escriben guías lo infravaloran. El marketplace oficial de Anthropic tiene plugins verificados. Los marketplaces comunitarios listan miles más. Antes de escribir una skill desde cero, búscala. Yo he reemplazado tres de mis primeras skills desarrolladas a mano por versiones comunitarias que eran mejores. El framework se trata de tu jerarquía y tu capa de memoria — las skills individuales pueden venir de cualquier sitio.

"El dashboard es para usuarios no técnicos." Solo es medio cierto. Es para usuarios no técnicos y para ti en todos los momentos en que no estás sentado frente al teclado con máxima concentración. Uso mi propio dashboard más que cualquier otra persona de mi equipo. El planteamiento de "accesibilidad para clientes" minimiza lo que una buena UI tipo centro de comando aporta a quien la ha construido.

Dónde Falla Este Marco

La honestidad me obliga a señalar los límites.

El marco asume que tienes un flujo de trabajo que vale la pena codificar. Si estás haciendo tareas únicas o experimentales —picos de investigación, problemas novedosos, exploración realmente creativa—, la sobrecarga de habilidades y automatizaciones en realidad te ralentizará. Para el trabajo creativo, todavía abro Claude Code sin CLAUDE.md, sin habilidades, sin vault, y lo dejo correr en bruto. El agentic OS es para trabajo repetible. Asegúrate de que lo que vas a codificar sea en realidad repetible antes de codificarlo.

También asume que lo vas a mantener. Las habilidades se desactualizan. Prompts afinados para Opus 4.5 pueden necesitar reenfoque para Opus 4.7. Las automatizaciones fallan cuando cambian las APIs externas. Dedico unas dos horas a la semana al mantenimiento del propio marco —principalmente actualizando prompts cuando cambia el comportamiento del modelo y podando habilidades que ya no uso. Ese coste de mantenimiento es real. Si construyes el marco y lo abandonas tres meses, espera encontrarte con podredumbre.

Y asume que confías en que Claude Code actúe por sí solo. El dashboard facilita disparar habilidades sin pensarlo. Las automatizaciones corren sin supervisión. Si no incluyes puntos de revisión dentro de las propias habilidades, tarde o temprano descubrirás que el agente ha enviado algo que no debía. Las salvaguardas deben estar dentro de las definiciones de las habilidades: pasos de autoevaluación, revisiones de salida, condiciones explícitas de parada. Un marco que ejecuta rápido sin controles es un marco que te avergonzará en escala.

El cambio que realmente importa

Hace seis meses, mi uso de Claude Code era una pila de pestañas de terminal y un CLAUDE.md que crecía unas 40 líneas por semana. Funcionaba. Pero no se acumulaba. Cada tarea nueva era una carga de contexto fresca, cada cliente nuevo era otro archivo en una carpeta que rara vez abría, cada buen prompt que escribía vivía en el historial de mi terminal hasta que desaparecía.

El framework agentic OS cambió la matemática de la acumulación. La memoria en la bóveda significa que lo que aprendí en marzo sigue siendo utilizable en abril. Las skills (habilidades) implican que el prompt que afiné para un cliente se convierte en el prompt que ejecuto para los siguientes veinte. Los dashboards permiten que el trabajo pase de "Mejba tiene que ejecutar esto personalmente a las 10 pm" a "cualquiera del equipo puede hacer clic en este botón".

La brecha entre una herramienta poderosa y una infraestructura útil rara vez se trata de la herramienta en sí. Claude Code ha sido capaz de esto desde sus primeras versiones. Lo que faltaba era la arquitectura a su alrededor. Memoria. Consistencia. Acceso. Si cierras esas tres, la matemática de lo que puedes manejar solo —o con un equipo diminuto— cambia drásticamente.

Si no construyes nada más de este post, construye la bóveda de Obsidian. Ese único paso me desbloqueó más cosas que las otras tres capas combinadas, porque es la base sobre la que descansan todas las demás. Las skills necesitan memoria para ser consistentes. El dashboard necesita logs de sesión para mostrarse. Las automatizaciones necesitan un lugar donde escribir salidas que puedan leer otras personas.

Tu Claude Code funciona bien hoy. La pregunta es si la centésima vez que lo uses será más valiosa que la primera, o si solo será lo mismo, cien veces más.

Preguntas Frecuentes

¿Qué es un framework agentic OS para Claude Code?

Un framework agentic OS es una arquitectura que envuelve Claude Code en cuatro capas: memoria persistente, habilidades jerárquicas, automatizaciones locales y remotas, y un dashboard; de este modo, el agente recuerda el contexto entre sesiones, ejecuta tareas de manera consistente y puede ser utilizado por compañeros no técnicos. Transforma Claude Code de una herramienta de CLI en infraestructura operativa. El desglose arquitectónico completo está en la sección “Qué es realmente un Agentic OS” más arriba.

¿Necesito una pipeline RAG para darle memoria a Claude Code?

No, la mayoría de los flujos de trabajo no requieren RAG. Un vault de Obsidian con notas Markdown estructuradas, con un punto de entrada _claude/CLAUDE.md, le da memoria persistente a Claude Code sin la complejidad de los embeddings vectoriales. Claude Code lee Markdown de forma nativa, así que el vault es a la vez almacenamiento y recuperación. Añade RAG solo cuando necesites búsqueda semántica en decenas de miles de documentos no estructurados.

¿Cuál es la diferencia entre automatizaciones locales y remotas de Claude Code?

Las automatizaciones locales se ejecutan en tu máquina y pueden acceder al sistema de archivos, a CLIs locales y a vaults de Obsidian; son ideales para pipelines de investigación, trabajo en bases de código y cualquier tarea que implique archivos locales. Las automatizaciones remotas se ejecutan en la nube mediante Claude Routines y operan independientemente de tu equipo; son ideales para búsquedas web programadas, monitoreo de marca y flujos de trabajo con APIs en la nube. Regla de decisión: si la habilidad necesita acceder a algo local, ejecútala localmente.

¿En qué se diferencian las habilidades de Claude Code de los plugins?

Los plugins son el formato de distribución; las habilidades son el contenido. Un plugin es una carpeta con un manifiesto plugin.json que puede agrupar una o más habilidades (archivos SKILL.md) junto con slash commands y hooks. Instalas un plugin mediante el comando /plugin dentro de Claude Code, que descarga automáticamente sus habilidades. Desde abril de 2026, tanto el marketplace oficial de Anthropic como marketplaces comunitarios como tonsofskills.com alojan miles de plugins y habilidades.

¿Realmente pueden los usuarios no técnicos usar Claude Code a través de un dashboard?

Sí, y este es precisamente el objetivo práctico de construir uno. Un dashboard local en Next.js con botones clicables para habilidades, actividad reciente y rutinas próximas permite que cualquier persona active flujos de trabajo de Claude Code sin tocar el terminal. El dashboard interactúa con Claude Code en segundo plano: el usuario ve botones, clics y resultados. Así es como transfiero habilidades a clientes y compañeros que nunca han abierto un terminal.

Trabajemos Juntos

¿Buscas construir sistemas de IA, automatizar flujos de trabajo o escalar tu infraestructura tecnológica? Me encantaría ayudarte.

• Fiverr (desarrollos e integraciones a medida): fiverr.com/s/EgxYmWD
• Portafolio: mejba.me
• Ramlit Limited (soluciones empresariales): ramlit.com
• ColorPark (diseño y branding): colorpark.io
• xCyberSecurity (servicios de seguridad): xcybersecurity.io