Enrichment Agent Blueprint — Cloudflare Queues + Anthropic Batch API (50% off)

Resumen ejecutivo

Blueprint de referencia para procesar cargas LLM no interactivas (enriquecimiento, re-procesado masivo, lint contradictions semanal) en la wiki Supercontexto usando el patrón Cloudflare Queues + Anthropic Batch API + D1 + cron poll. El patrón otorga 50% de descuento en tokens sobre la API normal de Messages a cambio de latencia asíncrona (minutos-horas en lugar de segundos).

Este documento NO es una implementación planeada inmediata. Es un blueprint archivado para cuando el volumen o coste justifiquen su adopción. El repo de referencia observado (Abril 2026) es jillesme/cloudflare-queue-batch-api — demo completa y muy bien construida de ~37 KB en un solo Worker con 3 entry points.

Motivación

El coste actual del pipeline Supercontexto-Ingest (Fase 3.5) ronda los ~$10/mes con el esquema 3-tier (pre-LLM filter + Haiku triage + Sonnet con prompt caching). No es sangrante, pero quedan piezas del pipeline que todavía pagan precio completo por tokens y podrían optimizarse:

1. Enriquecimiento nocturno de pages débiles: cuando el Bibliotecario-Ingest crea una incident_page con related: [] vacío (sucedió hoy con incident--20260424--bib-wiki-log-check-constraint), hoy nadie la enriquece automáticamente. Un agente batch podría proponer backlinks durante la noche.
2. Re-procesado masivo tras cambios del SYSTEM_PROMPT: cada refuerzo del prompt (Requisitos de densidad, sesión 17 p.ej.) dejaría las 250+ pages existentes sin actualizar. Re-procesarlas en batch sería ~50% más barato y no bloquearía el pipeline interactivo.
3. wiki_lint_contradictions en modo full semanal: hoy pagina Haiku síncrono (3m17s con 91 pairs en sesión 17). En batch sería más lento pero 50% más barato — aceptable para un cron nocturno.
4. Curator masivo: si los drafts superan decenas por semana, procesar el Curator review en batch reduce coste sin impactar UX (el Curator ya es diario, no interactivo).

Arquitectura del patrón (observado en el repo)

Un solo Cloudflare Worker con tres entry points:

POST /enrich              ──▶ fetch() handler
  persist D1 (status=queued) ──▶ enqueue en Queue

Queue dispara              ──▶ queue() consumer batch (hasta N=3-10 jobs)
  decide sync vs batch:
    sync  → POST /v1/messages uno por uno, resultados inmediatos en D1
    batch → POST /v1/messages/batches con N requests, guarda batch_id + processing_status:in_progress

cron * * * * *            ──▶ scheduled() handler
  SELECT batch_id WHERE processing_status='in_progress'
  → GET /v1/messages/batches/{id}
  → si ended: GET results_url (JSONL) → UPDATE D1 con resultados

Configuración de Queue (wrangler.jsonc del repo de referencia):

"queues": {
  "producers": [{ "binding": "ENRICHMENT_QUEUE", "queue": "enrichment-queue" }],
  "consumers": [{
    "queue": "enrichment-queue",
    "max_batch_size": 3,
    "max_batch_timeout": 60,
    "max_retries": 3,
    "dead_letter_queue": "enrichment-dlq"
  }]
}

El flujo batch siempre pasa por la queue aunque el consumer decida modo síncrono — esto le da buffering, retries automáticos y DLQ “gratis” a ambos caminos.

Aplicabilidad a Supercontexto

Tenemos 3 de las 4 piezas ya desplegadas:

La fricción de adopción es principalmente conceptual y de diseño, no de infraestructura: habría que enganchar el patrón a nuestro pipeline existente (probablemente como handler MCP nuevo + 1 cron adicional para poll de batches).

Casos de uso candidatos (prioridad descendente)

1. Enrichment Agent de related: [] vacíos (candidato #1)

Problema concreto observado: la incident_page creada hoy automáticamente por el Bibliotecario-Ingest en respuesta al fix del bug CHECK constraint salió con related: [] vacío. El sistema funcionó perfectamente generando la incident_page (validación en vivo del pipeline), pero ninguna tool existente cierra el gap de backlinks automáticamente.

Diseño propuesto:

• Trigger: cron semanal o diario que detecta pages con len(related) < 3 y contenido denso (>500 chars).
• Producer: encola un job {slug, title, content_snippet} por cada candidato.
• Consumer: batch de 3-10 pages → 1 sola llamada /v1/messages/batches con prompt que devuelve sugerencias de backlinks JSON.
• Cron poll: recoge resultados → añade los slugs sugeridos al related[] de la page en D1 (y opcionalmente al .md del repo via GH API, respetando el patrón del reconcile).

Coste estimado: con ~10 pages débiles/semana × ~500 tokens/request, ~$0.05/semana en modo batch. Negligible pero demuestra el patrón.

Valor: cierra el gap related: [] automáticamente. Mejora Obsidian graph conectividad. Reduce orphans silenciosos.

2. Re-procesado masivo tras cambio del SYSTEM_PROMPT

Problema: cuando se refuerza el prompt de Ingest (p.ej. Requisitos de densidad sesión 17), las ~250 pages ya existentes no reciben el refuerzo hasta que se tocan. Un re-processing masivo en batch sería ~50% más barato.

Coste estimado: 250 pages × ~2k tokens × Sonnet 3.5 ~$0.003/1k = ~$1.50 en modo batch (vs ~$3 sync). Marginal. Se ejecutaría 1-2 veces/año.

Valor: marginal. El trabajo existente (bib_ingest.py) ya hace esto pero síncrono. Ahorro monetario bajo, complejidad añadida media.

3. wiki_lint_contradictions modo full semanal en batch

Problema: hoy el handler pagina Haiku síncrono con offset/next_offset (resuelto en sesión 17 commit de47c6f tras Too many subrequests de CF Workers). Pasar a batch eliminaría el budget issue y reduciría coste.

Valor: mediano. Simplifica el workflow de consolidación semanal. Pero el problema actual ya está resuelto con paginación.

4. Curator masivo

Problema: el wiki_curator_review es diario pero procesa Haiku síncrono. Si los drafts crecieran a decenas/semana, podría pasar a batch.

Estado: diferido hasta que emerja el volumen. Hoy tenemos 0-1 draft/día.

Trade-offs

Pros

• 50% descuento en tokens — Anthropic Batch API es la única optimización estructural de coste disponible con diferencia (prompt caching ya implementado).
• Desacopla producers de consumers — si Sonnet se satura o Cloudflare tiene incidencia, los jobs se encolan en vez de perderse.
• Retries + DLQ automáticos — la Queue gestiona reintentos sin código custom.
• Fuera de horas punta — los batches pueden tardar minutos u horas; no compiten con el uso interactivo de bib_ask ni del Ingest post-merge.
• Patrón reutilizable — el mismo blueprint sirve para OCR de PDFs, análisis de logs, summaries masivos, etc.

Cons

• Latencia: batches tardan típicamente 5 min - 24 h. Inaceptable para flujos interactivos (bib_ask, query cierre).
• Complejidad extra: 1 producto CF nuevo (Queues) + 1 cron nuevo (poll) + lógica dual (sync/batch).
• Orden no garantizado: si el mismo slug genera 2 jobs, pueden completarse out-of-order.
• Inversión arquitectónica: hay que diseñar quién encola qué y cuándo, y cómo el resultado vuelve al repo (pattern reconcile).
• Debugging más complejo: un fallo puede estar en el producer, consumer, Anthropic batch, o cron poll.

Lo que NO hacemos con este patrón

El ingest post-merge de CreaRack-Pro/workspace (Fase 3) NO debería migrar a batch. Razones:

• Coste actual ~$10/mes — sin dolor.
• La feedback síncrona del Ingest post-push es valiosa: hoy mismo detectamos el fix del CHECK constraint gracias a que el Ingest creó una incident_page inmediatamente tras el commit. En batch habríamos tardado hasta el próximo poll (minutos-horas).
• Riesgo alto de romper el flujo por beneficio marginal.

Plan de adopción (cuando proceda)

Si se decide adoptar el blueprint, el orden recomendado es:

1. Implementar caso #1 (Enrichment Agent de related: []) como primer uso real — riesgo bajo, coste mínimo, valor claro.
2. Medir latencia real de batches Anthropic en producción (la documentación dice “puede tardar hasta 24h”, en la práctica suele ser 5-30 min).
3. Si el patrón funciona y Edu/Dani están cómodos, considerar los casos #2 y #3 según volumen observado.
4. Documentar el patrón como concept--biblioteca--enrichment-agent cuando la implementación esté en producción, con métricas reales.

Decisión actual

Archivado como blueprint de referencia (status: draft). No se implementa en las sesiones 19-25 del Supercontexto. Se revisa la decisión cuando:

• Los datos del pipeline 3-tier (tras 2-4 semanas) muestren coste creciente en algún tier.
• Aparezca un caso concreto de enriquecimiento nocturno (más allá del #1 teórico).
• Haya capacidad Edu/Dani para invertir en el patrón (~1 jornada completa de desarrollo + debugging).

Véase también

• [[concept—biblioteca—supercontexto]]
• [[feature—supercontext—reconcile-d1-repo]]
• [[feature—supercontext—fase-6-metricas-utility]]
• [[feature—biblioteca—wiki-lint-contradictions-pagination]]
• [[entity—mcp—tool—wiki-curator-review]]
• [[entity—mcp—tool—wiki-lint-bulk]]
• [[incident—20260424—bib-wiki-log-check-constraint]]