Skelm: agentes IA TypeScript con permisos reales
Un developer construyó Skelm, un framework TypeScript para ejecutar workflows de agentes IA localmente, después de probar n8n, OpenClaw y Hermes y encontrar que ninguno resolvía su caso de uso específico: código real, type-safety completa, y permisos que no sean simples sugerencias al modelo. El anuncio se publicó el 15 de mayo de 2026 en Dev.to.
En 30 segundos
- Skelm es un framework TypeScript code-first para agentes IA locales, creado porque n8n, OpenClaw y Hermes no cubrían el caso de uso de workflows determinísticos con permisos reales.
- n8n usa canvas visual y JSON — no es apto para developers que quieren diffs limpios en git e IDE support completo.
- Los modelos de permisos “advisory” (basados en system prompt) no son una barrera de seguridad real: el modelo puede ignorarlos o un input especialmente construido puede saltearlos.
- Skelm implementa permisos enforced a nivel de runtime, no a nivel de instrucción al modelo.
- La herramienta está disponible en GitHub y apunta a developers TypeScript que quieren agentes locales, testeables y auditables como cualquier otro código.
El problema del mercado: demasiadas opciones, ninguna que encaje del todo
Skelm es un framework de código abierto escrito en TypeScript para orquestar workflows de agentes IA localmente, con type system nativo, integración con git y un modelo de permisos que se aplica a nivel de runtime. Lo construyó un developer que identificó una brecha concreta: quería escribir módulos TypeScript reales, usar el ecosistema de testing que ya conocía, y tener permisos que no dependieran de que el modelo “se portara bien”.
El problema no era falta de herramientas. Era que las herramientas existentes estaban optimizadas para otros casos de uso. Eso pasa seguido en infraestructura para agentes IA: el ecosistema creció rápido y cada framework tiene un nicho claro, pero si tu caso de uso cae entre nichos, terminás construyendo algo propio.
Las limitaciones de n8n para frameworks agentes IA TypeScript
n8n es un caso interesante. Es genuinamente bueno para lo que hace: workflows visuales, automatizaciones con nodos, integración de servicios sin código. Si armás un pipeline de marketing o sincronizás datos entre APIs, n8n zafa muy bien.
El tema es que está construido alrededor de un canvas visual y un modelo de nodos en JSON. Si sos developer y querés meterlo en un repo, que el CI lo corra, que un reviewer pueda hacer diff de los cambios… ahí se complica. Los archivos de configuración de n8n no son legibles de la misma forma que código TypeScript. No tenés IDE support real para la lógica de los nodos, no podés usar el type system para atrapar errores antes de correr el workflow, y el testing queda relegado a probar manualmente en la interfaz. En nuestro artículo sobre instalar n8n en tu infraestructura profundizamos sobre esto.
¿Y cuándo querés componer workflows complejos con módulos reutilizables? Exacto, el canvas no está pensado para eso. La abstracción que n8n elige (visual, low-code) es un feature para su audiencia objetivo y un límite para developers que quieren code-first.
OpenClaw: un toolkit de primitivos, no un ejecutor de workflows
OpenClaw es otra historia. El framework está pensado para casos de uso de asistentes: chat routing, conversaciones multi-canal, coordinación de agentes en interacciones con usuarios. Es composable, tiene buenas primitivas, y para armar un sistema de asistencia multi-canal es probablemente una de las mejores opciones disponibles.
Pero no es un ejecutor de workflows determinísticos. La distinción importa: un “agent toolkit” te da los bloques para construir agentes que interactúan con usuarios; un “workflow executor” corre una secuencia de pasos con lógica definida, entradas y salidas predecibles, y comportamiento auditable. OpenClaw no pretende ser lo segundo, y el autor de Skelm lo deja claro: el problema no es que OpenClaw sea malo, es que resuelve otro problema.
Si tu caso es “quiero que el agente responda preguntas de clientes por WhatsApp y email”, OpenClaw es lo tuyo. Si tu caso es “quiero ejecutar un pipeline de análisis donde el agente puede llamar herramientas específicas bajo condiciones controladas”, OpenClaw no es la respuesta correcta.
Hermes y el problema de los permisos advisory
Hermes, el framework de Nous Research, tiene un problema más sutil. El framework en sí está bien construido: es Python, tiene soporte para patrones multi-agente, y buena documentación. El problema es el modelo de permisos.
Los permisos son “advisory”. Eso significa que le decís al modelo qué herramientas puede usar en el system prompt, y el modelo intenta cumplirlo. En la mayoría de los casos, cumple. Pero hay tres escenarios donde esto falla:
- Llega una nueva capacidad al modelo (una tool nueva que no estaba cuando escribiste el prompt) y el modelo decide que la necesita para completar la tarea.
- La tarea evoluciona durante la ejecución y el modelo hace una inferencia razonable de que debería poder usar una herramienta que “no fue explícitamente prohibida”.
- Un input construido específicamente (prompt injection, básicamente) empuja al modelo más allá de las instrucciones originales.
Los permisos advisory no son una barrera de seguridad. Son una sugerencia de comportamiento. Si eso te alcanza para tu caso de uso, perfecto. Si estás corriendo agentes con acceso a sistemas reales, esa distinción se vuelve crítica. Relacionado: qué ofrece n8n realmente.
Skelm: TypeScript nativo con permisos que se aplican de verdad
Ponele que tenés un agente que puede leer archivos del filesystem para generar reportes, pero no debería poder escribir ni borrar nada. Con un modelo advisory, eso lo escribís en el system prompt y confiás en que el modelo se porta bien. Con Skelm, ese permiso se aplica a nivel de runtime: si el agente intenta llamar a una función de escritura, el framework lo bloquea antes de que llegue al modelo.
Según el post del autor, Skelm ofrece:
- Workflows escritos como módulos TypeScript reales, con el type system completo y soporte nativo del IDE.
- Archivos que entran limpiamente en git, con diffs legibles como cualquier otro cambio de código.
- Integración con el test runner estándar de TypeScript, sin necesidad de mocks especiales.
- Permisos enforced a nivel de runtime, no advisory a nivel de system prompt.
- Ejecución local sin dependencia de servicios externos.
La diferencia entre “el modelo debería poder hacer X” y “el modelo puede hacer X porque el runtime se lo permite” es exactamente el tipo de distinción que separa un prototipo de algo que podés poner en producción con cierta confianza.
Permisos reales vs. advisory: por qué la diferencia importa en producción
Acá viene lo bueno, y también lo más ignorado en la mayoría de los tutoriales de agentes IA.
Cuando corrés un agente con acceso a herramientas reales (APIs de producción, bases de datos, servicios de terceros), el modelo no está “contenido” por instrucciones en el prompt. Está contenido por lo que el runtime le permite llamar. Son dos cosas completamente distintas.
Un permission model advisory tiene el mismo nivel de seguridad que una política de “por favor no abras esa puerta”. Funciona cuando todos cumplen las reglas. Un permission model enforced cierra la puerta con llave y el modelo ni sabe que existe la manija. Tema relacionado: herramientas de orquestación disponibles.
¿Por qué casi ningún framework mainstream implementa esto? Porque es más difícil de implementar y reduce la flexibilidad del agente. La mayoría de los casos de uso demo y tutorial no necesitan esa rigidez. Pero cuando el agente tiene acceso a tu infraestructura real, esa rigidez es una feature, no un bug.
Matriz comparativa: cuándo usar cada herramienta
| Herramienta | Caso de uso ideal | Lenguaje | Permisos | Git-friendly |
|---|---|---|---|---|
| n8n | Automatización visual, no-code/low-code, integraciones entre servicios | Visual (JSON) | Advisory | Limitado |
| OpenClaw | Asistentes multi-canal, chat routing, conversaciones con usuarios | TypeScript/JS | Advisory | Sí |
| Hermes (Nous) | Patrones multi-agente, investigación, orquestación compleja | Python | Advisory | Sí |
| Skelm | Workflows determinísticos locales, code-first, seguridad enforced | TypeScript | Enforced (runtime) | Sí (diffs limpios) |
La regla práctica: si tu equipo usa TypeScript, quiere agentes locales que se puedan testear como cualquier otro código, y necesita que los permisos sean una garantía real, Skelm es el candidato más cercano a lo que necesitás. Para el resto de los casos, las herramientas existentes siguen siendo válidas.
Qué está confirmado / Qué todavía no está claro
Confirmado
- Skelm existe y está disponible públicamente (publicado el 15 de mayo de 2026).
- El framework está escrito en TypeScript y apunta a ejecución local.
- El sistema de permisos es enforced a nivel de runtime, no advisory.
- Los workflows se escriben como módulos TypeScript con type system completo.
Todavía no está claro
- Madurez del proyecto: si es un proyecto individual o tiene contribuidores activos.
- Soporte para modelos distintos de los testeados por el autor.
- Roadmap de features: si hay planes para soporte cloud o integración con herramientas de observabilidad.
- Casos de uso con agentes complejos que requieran estado distribuido.
Errores comunes al elegir un framework de agentes
Elegir por popularidad en lugar de por caso de uso. n8n tiene miles de estrellas en GitHub y una comunidad enorme. Eso no significa que sea la herramienta correcta para un workflow de agentes code-first. La popularidad de una herramienta refleja qué tan bien resuelve su caso de uso principal, no todos los casos posibles.
Asumir que los permisos advisory son suficientes para producción. En demos y pruebas de concepto, el modelo generalmente cumple las instrucciones del system prompt. En producción, con inputs variables y herramientas que evolucionan, ese supuesto se rompe. Si el agente tiene acceso a sistemas reales, necesitás saber exactamente qué puede llamar y qué no, independientemente de lo que el modelo decida.
Confundir “agent toolkit” con “workflow executor”. OpenClaw, LangChain, y frameworks similares te dan primitivos para construir agentes. Un workflow executor corre una secuencia definida de pasos. Son abstracciones diferentes que resuelven problemas diferentes. Usar un toolkit cuando necesitás un executor (o viceversa) genera fricción constante que eventualmente llevás de vuelta al punto de partida: construir algo propio. Sobre eso hablamos en soporte internacional en plataformas.
Preguntas Frecuentes
¿Cuáles son las limitaciones de n8n para agentes de IA?
n8n está optimizado para workflows visuales y automatizaciones low-code. Para developers que necesitan type-safety, diffs legibles en git e IDE support completo, el modelo de nodos en JSON genera fricción constante. No está diseñado para componer módulos de lógica compleja de forma programática ni para workflows determinísticos testeables con el runner estándar de TypeScript.
¿Qué diferencia hay entre workflow visual y agente autónomo?
Un workflow visual (como n8n) define pasos en un canvas y los ejecuta en secuencia. Un agente autónomo toma decisiones en runtime sobre qué pasos seguir según el contexto y las herramientas disponibles. La distinción importa porque las herramientas optimizadas para workflows visuales no son las mejores para agentes que necesitan decisión dinámica y permisos granulares.
¿Por qué son insuficientes los permisos “advisory” en agentes IA?
Los permisos advisory le dicen al modelo qué puede hacer en el system prompt, pero no hay nada que lo fuerce a cumplirlo. Si llega una tool nueva, si el input está especialmente construido para eludir las instrucciones, o si el modelo infiere que “necesita” algo no autorizado, los permisos advisory no bloquean nada. Un sistema enforced aplica los límites a nivel de runtime, antes de que el modelo intente la llamada.
¿Existe una herramienta TypeScript para ejecutar agentes localmente con permisos reales?
Skelm, publicado en mayo de 2026, es un framework TypeScript que ejecuta workflows de agentes IA localmente con permisos enforced a nivel de runtime. A diferencia de frameworks Python como Hermes o herramientas visuales como n8n, Skelm está pensado para developers que quieren módulos TypeScript reales, integración con git y testing con el runner estándar.
¿Cuándo debería usar n8n, OpenClaw o una alternativa como Skelm?
Usá n8n si necesitás automatizaciones visuales entre servicios sin escribir mucho código. OpenClaw es la opción correcta para asistentes multi-canal y chat routing con múltiples usuarios. Skelm tiene sentido si sos developer TypeScript, necesitás workflows determinísticos locales y querés garantías de seguridad más fuertes que un system prompt. Hermes es la alternativa en Python con soporte para patrones multi-agente más complejos.
Conclusión
Skelm no es una revolución en frameworks agentes IA TypeScript. Es una solución honesta a un problema específico que muchos developers tienen y pocas herramientas resuelven: quiero código real, diffs limpios, permisos que no sean sugerencias, y ejecución local sin depender de una plataforma SaaS.
Lo interesante del anuncio no es el framework en sí (todavía hay que ver si tiene tracción más allá del post inicial) sino lo que describe sobre el estado del ecosistema. Hay una brecha entre las herramientas visuales/low-code y los frameworks de research/experimentación, y en esa brecha viven muchos equipos de desarrollo que quieren agentes en producción, no demos.
Si usás TypeScript y estás construyendo workflows de agentes que van a tocar sistemas reales, Skelm vale la pena explorar. Si tu caso es automatización entre servicios, n8n sigue siendo la respuesta más madura y documentada.
