Consola de triaje

comprobando sesión…

Triaje Lectura Grafo

2026-09-27

La capa operativa del agente sale del framework y se reparte entre cuatroespecializaciones

12 items · 5 hallazgos · 7 radar

explorar 2

probar 2

leer 0

vigilar 8

Descartados y sin acción 0

nada descartado

J/K mover E explorar P probar L leer V vigilar X descartar G grafo ↵ abrir ficha

Selecciona un item del tablero
o pulsa J para empezar.

vigilar hallazgo 01 · #agent-management-oss pick

paperclipai/paperclip

87.937★ · 15.490 forks · TypeScript · MIT

Qué es

aplicación open-source para gestionar agentes AI en el trabajo — un producto con UI completa, persistencia, plugin ecosystem y un SaaS comercial complementario en paperclip.ing. El repo aporta el "core engine" + marketplace de plugins; la página web vende la versión gestionada.

Cómo encaja

paperclipai/paperclip agent-management-oss

implements · ya cubierto el 2026-08-11

paperclipai/paperclip agent-framework-generico

competes_with · ya cubierto el 2026-08-11

paperclipai/paperclip openai-agentkit

complements · ya cubierto el 2026-08-11

paperclipai/paperclip enterprise-agent-runtime

relevant_to · ya cubierto el 2026-08-11

paperclipai/paperclip agent-plugin-marketplace

enables · ya cubierto el 2026-08-11

Por qué importa

Paperclip confirma que el espacio "agent governance" ya tiene líder OSS indiscutible: reentra en Trendshift tras su primera mención el 2026-08-11, y en seis meses (release inicial 2026-03-02) ha pasado de ser "un AI agent framework más" a separarse del resto por el ángulo producto (UI, persistencia, plugin marketplace y SaaS opcional) más que por el framework en sí. Para el lector de Código Sin Siesta importa porque (a) demuestra que la categoría "agent management" tiene product-market fit también en OSS, no solo en SaaS propietario; (b) el plugin ecosystem abierto permite a una empresa instalar o añadir conectores sin fork; (c) es referencia seria para comparar contra vendors comerciales de agent ops.

es el OSS agent-manager más instalado del ecosistema; explorar si Alejandro tiene un caso de uso empresarial donde instalar agentes con UI + persistencia + plugins sin vendor lock-in SaaS; leer el modelo de plugin system del repo para entender cómo resuelve "agent as first-class citizen"

Alerta honesta

paperclip y wshobson/agents son repos grandes con metricas de estrella notables, pero su traccion empresarial real fuera de OSS no esta verificada en los datos.

Abrir ficha Grafo ↗

probar hallazgo 02 · #agentic-plugin-marketplace

wshobson/agents

40.014★ · 4.269 forks · Python · MIT

Qué es

multi-harness agentic plugin marketplace: 94 plugins, 202 agents, 183 skills, 105 commands, todos declarados en una sola fuente plugins/ y transformados a artefactos nativos en 6+ harnesses (Claude Code, Codex CLI, Cursor, OpenCode, Antigravity CLI, GitHub Copilot, Pi). A diferencia de samber/cc-skills-golang (3.3k★), wshobson/agents no escribe skills separadas por harness, sino que genera los artefactos desde el mismo origen via make generate HARNESS=....

Cómo encaja

wshobson/agents agentic-plugin-marketplace

implements · relación nueva de hoy

wshobson/agents single-source-multi-target-harness

enables · relación nueva de hoy

wshobson/agents samber/cc-skills-golang

competes_with · ya cubierto el 2026-09-26

wshobson/agents anthropics/skills

complements · ya cubierto el 2026-07-08

wshobson/agents vendor-skills-agnostic

relevant_to · relación nueva de hoy

Por qué importa

wshobson/agents consolida el patrón "single source, multi-target" como respuesta a la fragmentación del espacio agentic: en lugar de mantener skills/agents/plugins separados por harness (formato Anthropic SKILL.md, OpenAI agents.json, Cursor .cursor-plugin/, etc.), la fuente canónica es el directorio plugins/ en Markdown y cada harness recibe una transformación nativa vía make generate HARNESS=..., no una traducción al mínimo común denominador. Para el lector AI+dev importa porque (a) confirma que el plugin marketplace es ya el modelo de distribución (samber, wshobson, anthropic, addyosmani); (b) supera en escala al actor anterior del espacio — samber/cc-skills-golang, que ya cubrimos el 2026-09-26 con 3.3k★ — y se sitúa como complemento del repo oficial anthropics/skills, mencionado el 2026-07-08; (c) el README muestra de forma explícita la matriz de capabilities por harness, lo que lo convierte en referencia pedagógica para entender qué soporta cada entorno.

/plugin marketplace add wshobson/agents en Claude Code y probar 2-3 plugins contra un proyecto real es 5 minutos; vigilar el make generate HARNESS=... workflow porque marca la nueva arquitectura de skills cross-vendor; explorar el catálogo de 94 plugins para identificar los que matcheen con casos de uso de la audiencia

Alerta honesta

paperclip y wshobson/agents son repos grandes con metricas de estrella notables, pero su traccion empresarial real fuera de OSS no esta verificada en los datos.

Abrir ficha Grafo ↗

vigilar hallazgo 03 · #office-harness-ai

dream-num/univer

19.732★ · 1.668 forks · TypeScript · Apache-2.0

Qué es

SDK Office unificado para AI agents: spreadsheets, documents, presentations, bases, boards y PDFs (próximamente). Una sola Facade API funciona en browser y Node.js; arquitectura de plugins, render Canvas-based, motor de fórmulas propio, build pipeline de 19k★ con releases activos y soporte i18n (EN, ZH-CN, ZH-TW, JA, KO, ES).

Cómo encaja

dream-num/univer office-harness-ai

implements · ya cubierto el 2026-07-07

dream-num/univer facade-unified-api

uses · ya cubierto el 2026-07-07

dream-num/univer microsoft-office-js

competes_with · ya cubierto el 2026-07-07

dream-num/univer onlyoffice/sdkjs

complements · ya cubierto el 2026-07-07

dream-num/univer agent-document-editing

enables · ya cubierto el 2026-07-07

dream-num/univer open-slide

relevant_to · ya cubierto el 2026-07-07

Por qué importa

Univer consolida el "Office SDK integrable" como capa de infraestructura para AI agents: ya cubierto el 2026-07-07, reentra ahora tras 51 días con release nuevo en la rama dev, señal de que el vendor ha empujado hitos técnicos y no solo marketing. No es la suite ofimática final, sino el engine que apps AI pueden montar para dar a sus agentes la capacidad de editar o generar hojas, documentos y presentaciones mediante una API programática — la Facade API unificada que funciona en browser y Node.js. Para el lector AI+dev importa porque (a) la rama dev está activa con el repo archivado=false, así que el momentum es real y no un proyecto abandonado; (b) compite directamente con microsoft-office-js y se complementa con onlyoffice/sdkjs, también en nuestro grafo desde el 2026-07-07; (c) el soporte i18n incluye español, lo que lo hace inmediatamente usable para la audiencia LATAM.

es el OSS Office-harness más serio que no es Microsoft; probar el Facade API en un proyecto TypeScript para validar latencia y ergonomía; explorar si el vendor publica SDK para Node-only y si hay clientes que lo monten en cloud sin licenciamiento Microsoft

Alerta honesta

univer soporta ES en i18n pero la documentacion tecnica sigue mayoritariamente en EN/ZH, lo que puede lastrar la adopcion hispanohablante.

Abrir ficha Grafo ↗

vigilar hallazgo 04 · #rust-async-orm pick

tokio-rs/toasty

3.172★ · 142 forks · Rust · MIT

Qué es

ORM async para Rust publicado por el equipo Tokio (tokio.rs, axum, hyper, tower). Derive macros con #[derive(toasty::Model)], soporte para SQLite/Turso/PostgreSQL/MySQL + DynamoDB, no oculta capacidades del DB target (las expone). Docs en docs.rs/toasty, guide en tokio-rs.github.io/toasty/.

Cómo encaja

tokio-rs/toasty rust-async-orm

implements · relación nueva de hoy

tokio-rs/toasty tokio-runtime

uses · relación nueva de hoy

tokio-rs/toasty sqlx

competes_with · relación nueva de hoy

tokio-rs/toasty diesel-async

competes_with · relación nueva de hoy

tokio-rs/toasty tokio-rs/topcoat

complements · ya cubierto el 2026-07-18

tokio-rs/toasty tokio-fullstack

relevant_to · relación nueva de hoy

Por qué importa

toasty cierra el "Tokio full-stack" que empezamos a mapear el 2026-07-18 con topcoat: la secuencia que el vendor está construyendo va de tokio (runtime) → axum (web) → tower (middleware) → toasty (data layer) → topcoat (full-stack framework). Es la primera vez que el equipo Tokio ataca el data layer con un ORM propio, no solo con drivers async, y el soporte de DynamoDB (no-SQL) lo coloca en un terreno que ni sqlx ni diesel-async cubren. Para el lector AI+dev importa porque confirma la tendencia "un solo vendor controla el stack completo en Rust", un árbol de decisiones único que evita el compose hell típico de axum + sqlx + diesel + askama; la guía 0.11.0 activa indica releases recientes y momentum sostenido.

vendor serio + momento temprano = ventana de adopción; probar con SQLite local y un derive macro simple para validar la propuesta vs sqlx; leer la guía 0.11.0 antes del primer breaking change; ignorar para producción hasta v1.0

Alerta honesta

toasty es ORM v0.x con API inestable probable: la guia 0.11.0 indica movimiento pero no madurez.

Abrir ficha Grafo ↗

probar hallazgo 05 · #local-first-agent-memory pick

tigerless-labs/agent-memory

1.220★ · 76 forks · Markdown · MIT

Qué es

runtime de memoria long-term para AI agents donde archivos Markdown en un directorio son la fuente única de verdad y un índice SQLite adyacente es el cache (regenerable, borrable, no crítico). Retrieval local rankeado que responde con paths (no chunks opacos); writes disparados en conversation boundaries; sleep-time pass que olvida por valor. Cero API keys, soporta Claude Code y Codex CLI.

Cómo encaja

tigerless-labs/agent-memory local-first-agent-memory

implements · relación nueva de hoy

tigerless-labs/agent-memory markdown-as-source-of-truth

uses · relación nueva de hoy

tigerless-labs/agent-memory mem0

competes_with · ya cubierto el 2026-08-10

tigerless-labs/agent-memory letta

competes_with · relación nueva de hoy

tigerless-labs/agent-memory tigerless-labs/cost-xray

complements · ya cubierto el 2026-09-05

tigerless-labs/agent-memory air-gapped-agent-runtime

enables · relación nueva de hoy

tigerless-labs/agent-memory agent-skills-pack

relevant_to · ya cubierto el 2026-09-26

Por qué importa

agent-memory resuelve el dilema "embeddings vs filesystem" sin vendor lock-in: donde mem0 (que ya cubrimos el 2026-08-10), Letta y Zep montan memory layers con embeddings + graph DB opaco, este runtime apuesta por archivos Markdown como única fuente de verdad y un SQLite adyacente como cache regenerable — si el SQLite se borra, se reconstruye desde el Markdown sin perder nada. Para el lector AI+dev importa porque (a) el enfoque local-first y zero-API-key lo hace viable en entornos air-gapped; (b) el retrieval devuelve paths exactos en lugar de chunks opacos, lo que reduce el coste de operar el agente al evitar pagar embeddings por consulta; (c) completa la vertical "AI dev tooling" del mismo vendor, tigerless-labs, que abrió con cost-xray el 2026-09-05 y ahora conecta con el agent-skills-pack que cubrimos el 2026-09-26.

instalable como skill en Claude Code; explorar el patrón "recall returns paths, not chunks" porque es una decisión arquitectónica replicable en otros memory layers; vigilar el vendor tigerless-labs porque está construyendo una vertical AI dev tooling coherente

Alerta honesta

agent-memory evita embeddings por diseno; eso reduce coste y dependencia pero limita la calidad de recall frente a mem0 o Zep en cargas con volumen real.

Abrir ficha Grafo ↗