Plan de implementación — agentes SOTA (2026)
Nota interna de arquitectura (sesión 2026-07-09, parte 2). Convierte el diagnóstico deagents-100x.md en un plan de ejecución, calibrado contra el estado del arte verificado por
research web (fuentes al final de cada punto). El objetivo: que los agentes de Driftless operen
al nivel de los mejores harnesses de 2026 sin romper las invariantes del producto (gobernanza,
determinismo explicable, proposer ≠ approver, no-scripting del broker).
0. Los diez principios SOTA que gobiernan este plan
- El loop canónico es gather → act → VERIFY → repeat. La pierna de verificación es la que nuestro loop no tiene. Pipelines de refutación adversarial matan ~79–91% de hallazgos falsos antes de llegar al humano (Refute-or-Promote, arXiv:2604.19049; SAST-Genius −91% FPs).
- El presupuesto es de tokens-en-contexto, no de pasos. “Context rot” es la restricción real; limpiar tool-results viejos dio +29% solo, +39% con memoria de archivo, −84% de tokens en tareas de 100 turnos (Anthropic context-management).
- Fan-out solo para lectura paralelizable; síntesis y decisión single-context. Multi-agente de research superó al single-agent 90.2% — a ~15× el costo; Cognition: nunca paralelizar decisiones (anthropic.com/engineering/multi-agent-research-system; cognition.com/blog/dont-build-multi-agents). Workers devuelven resúmenes estructurados de 1–2k tokens.
- Delta updates, nunca rewrites totales. El “context collapse” de ACE: un rewrite iterativo erosionó 18,282 tokens → 122 en un paso y dejó accuracy DEBAJO del baseline sin adaptación (arXiv:2510.04618, ICLR 2026). Vale para el vault y para cualquier skill que se auto-edite.
- La memoria gana confianza con contadores de uso. ACE: unidades atómicas con contadores helpful/harmful alimentados por feedback de ejecución. Mem0: la escritura es un clasificador ADD/UPDATE/DELETE/NOOP contra la memoria existente. Zep: invalidación temporal, no borrado.
- Cache-first prompt architecture. Reads de cache a 0.1× (Anthropic) / ~2% (DeepSeek). El Knowledge inyectado debe ser un bloque estable versionado que solo se re-renderiza cuando el topic cambia de versión — re-escribir memoria por run es un impuesto de cache además de un riesgo de gobernanza.
- Drift de claims en dos etapas. Detector barato → verificador caro → gate humano (DocPrism LCEF, arXiv:2511.00215: filtrar categorías de inconsistencia relevantes antes de reportar; el juicio one-shot de un LLM sobre drift no lo shippea nadie).
- Autonomía graduada con promoción ganada y demotion automática. Tres niveles (auto-apply reversible / notify-and-proceed / HITL); reversibilidad es el factor #1 de routing; promoción = evidencia empírica en esa clase de acción + autorización humana registrada; demotion automática al degradarse (arXiv:2606.22484; patrón Mintlify PR-gated→opt-in-push; Rovo admin-gated).
- pass^k, no pass@1, para decidir autonomía. Un agente 90% pass@1 es ~57% consistente a k=8 (τ-bench). Un skill no gradúa ni shippea sin pass^k sobre corpus sembrado.
- Supresión > generación. Presupuesto de FP <10% (el “cry-wolf effect” es la razón #1 de abandono de bots de review); suprimir 35% de sugerencias subió la aceptación +15.8pp (arXiv:2511.18849). Invertir en cuándo callar tanto como en la calidad del draft.
Workstreams
WS1 — Fiabilidad (pre-requisito; sin esto nada de lo demás es creíble)
Aceptación: cero dobles-runs en multi-réplica; un workspace gateway-only despacha por push/PR;
un run zombie no sigue gastando.
WS2 — Loop económico: tokens, cache, profundidad
Aceptación: cache hit-rate ≥80% en runs warm (ya medido ~81% en el mejor caso — sostenerlo);
tokens/run del Auditor −30% con igual o mejor recall en el eval de loop.
WS3 — Verificación adversarial (la pierna que falta)
Aceptación: en el corpus sembrado, el refuter mata ≥70% de proposals falsas plantadas sin
matar >5% de verdaderas; approval rate humano sube de 86% → ≥92%.
WS4 — Cross-surface + Steward (drift multi-superficie)
Aceptación: un cambio en una página Notion indexada que contradice Knowledge produce una
propuesta de update en <1h (staleness gap SLA); drift local llega al Auditor sin clicks.
WS5 — Autonomía graduada (earn-autonomy)
Aceptación: ninguna acción auto-aplicada irreversible; demotion dispara sola en el eval de
regresión; el humano ve el nivel vigente y el porqué (métrica) en Settings.
WS6 — El vault que aprende (ACE aplicado a Driftless)
WS7 — Runtime y orquestación
WS9 — Observabilidad viva + Agent Activity como sala de control
El observador interno ya existe —observeToolExecutor (Agent Tool Platform T3,
cognitive/tool-observability.ts): un ToolExecutionEvent sanitizado por llamada (duración,
error class, preview redactado). Estado real: Chat lo envuelve pero descarta los eventos
(chat.service.ts:592), y los agentes autónomos lo omiten. Es la señal que WS2 (presupuestos
por tool), WS5 (autonomía medida) y WS8 (trajectory evals) necesitan — cablearlo va primero.
9.1–9.3 quedaron implementados como spike verificado (tests + typecheck) en esta branch —
revisable/revertible como commit independiente.
WS8 — Evals como gate de release
Secuencia (6 sprints)
KPIs del programa
- MTTR de drift (detección → Knowledge reparado), por superficie (git / docs / records).
- pass^k (k=4) por skill en el corpus sembrado — gate de release y de autonomía.
- Approval rate por clase de acción (hoy 86% global) — objetivo ≥92% con refuter.
- FP rate de hallazgos <10% (presupuesto cry-wolf).
- Tokens/run y cache hit-rate (objetivo: −30% tokens, ≥80% cache warm).
- Staleness gap de fuentes conectadas (SLA <1h con webhook, <24h batch).
Trampas a evitar (todas documentadas en la literatura)
- Context collapse: jamás un rewrite total del vault o de un skill por un LLM — solo deltas.
- Memory poisoning: el gate humano Note→Knowledge es la defensa SOTA (OWASP ASI06) — la autonomía graduada nunca se aplica a la verdad (contenido), solo a higiene reversible.
- Verificador correlacionado: el refuter usa otro modelo/contexto — mismo modelo = mismos sesgos.
- Multi-agente para decisiones: fan-out solo lectura; síntesis y writes single-context.
- Leaderboard-itis: los números de memoria (LoCoMo etc.) están inflados por retrieval-k; medir con nuestros evals, no con benchmarks ajenos.