Boletín del jueves 17 sept 2026

Vercel mete la cabeza en el escritorio del developer agent con una tesis editorial distinta a la de Anthropic/OpenAI: el contenedor es portable, el modelo se elige después. agent.ts con defineAgent({ model: 'openai/gpt-5.6-luna-fast' }) externaliza el binding al AI Gateway, así que un agente escrito para eve puede rotar entre proveedores con un cambio de una línea. Caveat: la adopción depende del AI Gateway de Vercel (no es Anthropic-compatible estándar, es su gateway). En el grafo ya cubrimos a sus competidores más cercanos: claude-code el 2026-09-15 y openai/codex el 2026-08-11 — eve se suma como tercer contendiente en la misma semana, pero con la apuesta diferencial de tratar la definición del agente como artefacto portable. Buena pieza editorial: comparativa de "definición portable del agente" frente a Claude Code Skills, Codex TOML, OpenAI Agents SDK, Mastra y E2B + SDK propio.

El cuadrante de "memoria persistente para agentes" está madurando rápido y MemOS trae la pieza académica que faltaba: a diferencia de memvid/memvid (encode en MP4, storage minimal) o letta/letta (stateful server), MemOS introduce "memory como capa de OS" — modular, planificable, versionable. Su adopción en volcengine/OpenViking lo coloca como el estándar de facto del ecosistema ByteDance/Tencent para memoria de agentes, con paper en arXiv y quickstart en pip install MemoryOS o npm install @memtensor/memos. Limitación honesta: el item no incluye comparativa concreta de features contra Letta/memvid (qué scheduling exacto trae, qué versión de memory kernel soporta Stardust), así que la afirmación "el estándar de facto" se apoya solo en la adopción de OpenViking, no en una tabla de capabilities. Buena pieza editorial: "MemOS × Letta × memvid × Hindsight — los 4 modelos de memoria persistente y cuál elegir por caso de uso".

Completa el patrón "OpenRouter × tools": OpenRouter resolvió el switching de modelos; Monid lo lleva a servicios externos (Tinyfish search, Exa search, scraping APIs, enrichment, etc.). El matiz más fino está en la liquidación de billing: cada conector declara su modelo de cobro (flat por call, por result, por unidad) y el engine lo liquida sobre el response envelope real — un vendor error o un resultado vacío se cobra a 0, lo que elimina el clásico problema de "el agente me cobró 100 búsquedas y me devolvió 0". Caveat: 176★ es muy temprano y el catálogo arranca con ~10 proveedores, así que la promesa de discover+settlement está validada por 188 replay tests sin red, pero todavía sin tracción de mercado real. Limitación honesta: no tenemos fecha concreta en el grafo para compararlo con sus alternativas (Composio, ToolRouter), así que esta pieza se lee como foto fija, no como continuación de una conversación previa. Pieza editorial: comparativa con Composio (15k★, monetiza vía subscriptions), ToolRouter y OpenAI Tools/Function Calling como estrategias de "economía del tool call".

Es la apuesta más explícita del día por "self-improving agent sin tocar el prompt": el usuario define un success contract externo (grading command + expected result) y ouroboros corre el agente; cada generación falla, mide y refina. El prompt nunca es el límite del agente — el grading lo es, lo que lo hace testeable y reproducible. En el grafo ya cubrimos concept:agent-os el 2026-08-14, así que ouroboros se lee como la segunda iteración semanal sobre la misma idea de "el agente como sistema operativo", pero esta vez con el giro del contract-driven grading. Caveat importante: el modelo de seguridad abre un vector de prompt-injection si el "expected result" sale de una fuente no confiable — el repo dice "we just hold the line", lo que sugiere que el operador decide cuánto punishment/fitting time dar, sin guardrails automatizados de fábrica. Buena pieza editorial: "Ouroboros × EvoPrompt × Promptwright — el cuadrilátero 'agente que se mejora solo' y los tradeoffs de seguridad de cada uno".

Coder lleva el debate "agentes en local vs agente en cloud" a una nueva capa: el agente vive en tu cluster. El loop del coding agent corre en el control plane (tu infra), BYO-model (Anthropic/OpenAI/Google/Bedrock/auto-hosted) y las credenciales nunca se filtran a los workspaces — solo metadatos + identity tokens cortos. Para una empresa europea con dudas regulatorias (RGPD, data residency) esto resuelve "el loop del agente ocurre fuera de mi perímetro", que es exactamente el problem:data-residency-agents que el grafo ya tenía mapeado. Caveat fuerte: la licencia AGPL-3.0 significa que cualquier servicio derivado debe abrir su código, lo que veta forks internos sin abrir y lo distingue del resto del ecosistema (suele ser Apache/MIT). Limitación honesta: el item no incluye comparativa concreta contra E2B/Cody/Anthropic Console en features específicas (latencia del túnel Wireguard, throughput del control plane, cobertura de providers BYO), así que la pieza editorial propuesta se sostendría mejor con un cuadro de capabilities. Buena pieza editorial: "Coder Agents vs E2B Cloud vs Cody vs Anthropic Console — los 4 sitios donde puede vivir el loop del agente".