Consola de triaje

comprobando sesión…

Triaje Lectura Grafo

2026-08-19

La pila del agente en producción: memoria, gateway, orquestación y contexto persistente

14 items · 6 hallazgos · 8 radar

explorar 1

probar 2

leer 2

vigilar 9

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.

explorar hallazgo 01 · #single-file-agent-memory pick

memvid/memvid

16.409★ · 1.413 forks · Rust · Apache-2.0

Qué es

capa de memoria single-file para AI agents. Codifica embeddings + metadatos en un archivo .mp4 (un único fichero) que entrega retrieval instantáneo y long-term memory sin necesidad de base de datos. Stack: memvid-core (Rust crate en crates.io) + SDKs Python/Node. Casos de uso: chat history persistente, knowledge bases, context para agents, search semántico. El claim técnico fuerte: un vídeo de 50 MB almacena ~1M vectores con retrieval <50 ms.

Cómo encaja

memvid/memvid single-file-agent-memory

implements · relación nueva de hoy

Por qué importa

Es la primera pieza OSS de la categoría "memory as a single portable file" que es realmente deployable en producción: en lugar de mantener Postgres + pgvector + un proceso de embeddings, la memoria de un agente cabe en un único fichero .mp2 (sí, formato de vídeo contenedor) que se puede versionar en Git, copiar con rsync o montar como artefacto. Para el stack local-first de Alejandro (Obsidian + Git + memoria Hermes) encaja de forma directa: cada proyecto tendría su propio .mp2 con embeddings + metadatos, retrieval por similitud en menos de 50 ms sobre ~1M vectores en 50 MB según el claim del repo. La alternativa más cercana en tracción, screenpipe/screenpipe (20.373★), tiene licencia NOASSERTION, lo que en la práctica bloquea su adopción como dependencia seria. Memvid es Apache-2.0, comparable en estrellas (16.409) y ya trae SDKs Python y Node para integrarlo sin escribir Rust.

clonar, probar el sandbox oficial, comparar tamaño de .mv2 vs pgvector con el mismo corpus, validar latency

Alerta honesta

memvid: la promesa de 'reemplazar RAG con un .mp4' es lo bastante provocadora como para pedir benchmark independiente antes de sacarla en cobertura — el rendimiento de retrieval sobre vídeo comprimido merece validación empírica.

Abrir ficha Grafo ↗

leer hallazgo 02 · #ai-gateway-go

maximhq/bifrost

7.414★ · 1.065 forks · Go · Apache-2.0

Qué es

AI gateway empresarial en Go que unifica acceso a 23+ providers (OpenAI, Anthropic, AWS Bedrock, Google Vertex, etc.) detrás de una única API OpenAI-compatible. Claim headline: "<100 µs de overhead a 5k RPS, 50× más rápido que LiteLLM" — afirmación agresiva que, si se sostiene, es el argumento de adopción para equipos con budgets de inferencia serios. Features: adaptive load balancer, cluster mode, guardrails, semantic caching, MCP client, conversiones OpenAI-compatible + Anthropic-compatible + Gemini-compatible.

Cómo encaja

maximhq/bifrost ai-gateway-go

implements · relación nueva de hoy

maximhq/bifrost maximhq/bifrost

publishes · relación nueva de hoy

Por qué importa

La categoría "AI gateway" lleva 18 meses consolidándose (Portkey, LiteLLM, OpenRouter, Cloudflare AI Gateway), y Bifrost entra con un claim agresivo y concreto: <100 µs de overhead a 5k RPS, 50× más rápido que LiteLLM. Si el benchmark se sostiene en producción, es el argumento de adopción para equipos con presupuestos de inferencia serios donde el coste por request importa. Bifrost además es el primero del segmento que expone arquitectura de cluster mode (load balancing multi-nodo), no solo routing single-instance, lo que lo hace interesante para setups que ya están sufriendo el techo de un único LiteLLM. Vale leer la arquitectura antes de migrar, no adoptarlo a ciegas. Caveat operacional relevante: el default branch del repo es dev, no main, y los releases salen de dev, señal de que el proyecto todavía pivota y no conviene pinearlo como dependencia estable todavía.

revisar benchmarks propios, comparar arquitectura de cluster mode con Portkey, validar el claim de 50× en escenarios reales antes de confiar en la cifra

Alerta honesta

bifrost: el claim '50× más rápido que LiteLLM' viene del propio repo; sin metodología pública ni réplica independiente, hay que tratarlo como marketing hasta ver números externos.

Alerta honesta

bifrost: default branch dev en lugar de main es una señal de proyecto joven/inestable — relevante si alguien evalúa adoptarlo en el stack local-first.

Abrir ficha Grafo ↗

vigilar hallazgo 04 · #rust-postgres-rewrite pick

malisper/pgrust

4.571★ · 169 forks · Rust · AGPL-3.0

Qué es

reescritura completa de Postgres en Rust, wire-compatible y SQL-dialect-compatible con Postgres 18.3. Pasa los 46.066 tests de la regression suite de Postgres al 100% (badge oficial en README). Innovaciones arquitectónicas: executor vectorizado push-based con JIT, modelo de concurrencia basado en threads, query scheduler que evita que queries individuales tumben el sistema. Visión explícita: mostrar "cómo se vería Postgres si se hubiera construido en 2026". Licencia: AGPL-3.0 (obligación de abrir derivados en red).

Cómo encaja

malisper/pgrust rust-postgres-rewrite

implements · relación nueva de hoy

malisper/pgrust malisper/pgrust

publishes · relación nueva de hoy

Por qué importa

La pieza más ambiciosa del cluster "AI-assisted database reimplementation", donde ya están duckdb/duckdb consolidado, risingwavelabs/risingwave desde el lado streaming y este mismo malisper/pgrust desde el lado Postgres. Lo que lo hace especial es el dato verificable del README: pasa el 100% de los 46.066 tests de la regression suite oficial de Postgres 18.3, lo que elimina la duda habitual sobre compatibilidad SQL y de protocolo en reescrituras de este tipo. El ángulo AI está explícito en el blog post "How AI Changes the Economics of JIT Compilers": los LLM bajan el coste de mantener una codebase masiva de bajo nivel, y eso es lo que hace viable un proyecto así. Para el boletín, la pregunta editorial es si es experimento de un solo autor o tiene tracción de comunidad: 4.571★ y 169 forks en 4 meses apuntan a tracción real, pero el repo está solo en v0.2. La licencia AGPL-3.0 cierra la puerta a SaaS propietarios sobre este código y abre la puerta a ofertas tipo "Postgres-as-a-Service" open source.

no adoptar como build-dependency por AGPL-3.0, pero leer el blog post "How AI Changes the Economics of JIT Compilers" — el ángulo AI-as-junior-systems-engineer es editorialmente fuerte

Abrir ficha Grafo ↗

vigilar hallazgo 05 · #agent-issue-assignment-workspace

multica-ai/multica

46.752★ · 5.970 forks · Go · NOASSERTION

Qué es

workspace open-source donde humanos y coding agents son el mismo roster. Asignas issues a 20+ agent CLIs (Claude Code, Codex, Cursor, Pi, Hermes, etc.) igual que asignarías a un teammate: el agente recoge el issue, reporta progreso, levanta blockers, devuelve el diff para review humano. Self-hostable, runtime controlado, comentarios encadenados al issue, "nada se mergea sin que un humano diga OK". Tagline: "Your next 10 hires won't be human". Re-trend después de 17 días con +282★ hoy en GitHub Trending Go.

Cómo encaja

multica-ai/multica agent-issue-assignment-workspace

implements · ya cubierto el 2026-08-03

multica-ai/multica multica-ai/multica

publishes · ya cubierto el 2026-08-03

Por qué importa

La categoría "agentes como teammates" lleva meses consolidándose, y ya cubrimos a Multica por primera vez en el boletín del 2026-08-03, cuando apareció en GitHub Trending con su propuesta de asignar issues a 20+ agent CLIs (Claude Code, Codex, Cursor, Pi, Hermes, etc.) igual que a un teammate humano. Lo que justifica volver a mencionarlo ahora es el salto de hoy en Trending Go (+282★ en24 h, ya en 46.752★) y, sobre todo, la madurez del diferenciador clave: la disciplina del review humano atado al issue. Aquí ningún agente mergea sin que un humano diga OK, lo que lo separa de la autonomía ciega y lo coloca en el lado "autonomía supervisada" del espectro. Caveat que ya advertimos en su día y aquí: la licencia reportada por la GitHub API es NOASSERTION, así que antes de usarlo como build-dependency hay que abrir el LICENSE real en el repo y verificarlo. Para equipos de 3-5 devs con 5+ agentes corriendo en paralelo, sigue siendo candidato serio a "orquestador de facto"

verificar LICENSE real antes de build-dependency, leer VISION.md, evaluar fricción de self-hosting

Alerta honesta

multica: 'más de 20 coding agents' suena aVitest contra los límites reales de orquestación práctica; sin casos de uso públicos descritos, es más demo que producto maduro.

Abrir ficha Grafo ↗

leer hallazgo 06 · #self-evolving-context-database

volcengine/OpenViking

29.659★ · 2.316 forks · Python · Apache-2.0

Qué es

"Context Database" self-evolving de ByteDance/Volcengine que unifica Agent Memory + Knowledge RAG + Skills en una sola capa para AI agents. Diferenciador: self-evolving ingestion — la base aprende y se reorganiza con el uso, no es un RAG estático. Soporte oficial dsh-plugin (DeepSeek Harness). Apache 2.0 self-hostable, sitio oficial openviking.ai. Dato nuevo desde la primera mención (2026-08-15): licencia AGPL-3.0 — no Apache-2.0 como sugería el README inicial.

Cómo encaja

volcengine/OpenViking self-evolving-context-database

implements · relación nueva de hoy

volcengine/OpenViking volcengine/OpenViking

publishes · relación nueva de hoy

volcengine/OpenViking volcengine/OpenViking

publishes · relación nueva de hoy

Por qué importa

ByteDance/Volcengine está consolidando una pila end-to-end de infraestructura de agente (DeepSeek Harness + OpenViking + dsh-plugins), y OpenViking aporta la pieza de memoria y conocimiento: un "Context Database" self-evolving que unifica Agent Memory, Knowledge RAG y Skills en una sola capa que aprende y se reorganiza con el uso, en lugar de ser un RAG estático. Es exactamente el patrón que la industria lleva meses buscando. Dato nuevo desde la primera mención del 2026-08-15: la licencia real, verificada en el repo, es AGPL-3.0, no Apache-2.0 como sugería el README inicial. Eso cambia el cálculo para SaaS: cualquier servicio que exponga OpenViking sobre la red debe abrir su código o licenciar comercialmente. Para uso interno u on-prem OSS no hay problema, pero si un equipo piensa construir producto comercial encima, toca hablar con Volcengine primero. El repositorio además arrastra 456 open issues, señal de adopción real pero también de deuda de mantenimiento a vigilar.

arquitectura self-evolving, comparativa con memvid y akitaonrails/ai-memory, evaluar implicaciones de AGPL-3.0 antes de cualquier adopción seria

Alerta honesta

OpenViking: AGPL-3.0 es una restricción seria para cualquier integración comercial o redistribución; no es bloqueante para experimentación interna, pero sí cierra puertas de producto.

Abrir ficha Grafo ↗