Umbra Studio · Library · Substrate
Studio / Library / Substrate v0.3
Substrate Layer · 18 primitives · Validated against 11 Indietheka agents · 2026.04.25

Dieciocho fichas. Cada una describe un patrón operativo que ya corre en producción — o que cualquier vertical va a necesitar antes de fin de año.

Si esta es tu primera vez leyendo esto, no te saltes la siguiente sección. Ahí explico en lenguaje plano qué es un schema, qué hace cada campo, y por qué cada primitivo tiene exactamente esos campos y no otros. Después podés navegar las 18 fichas con confianza.

00Si te perdiste, leé esto primero

Un schema es solo una ficha con campos fijos. Como la del libro en una biblioteca.

Cuando un libro entra a una biblioteca, alguien le hace una ficha: título, autor, año, género, ISBN. Esos campos son los mismos para todos los libros, lo que cambia es el contenido. Sin ficha, el libro existe pero no se puede encontrar, clasificar ni cruzar con otros. La biblioteca queda como un cuarto con pilas de libros — no como una biblioteca.

El library de Umbra Studio es exactamente eso: un cuarto con muchas operaciones que ya funcionan (en Indietheka, en Transit, en lo que venga), pero que sin ficha quedan como prosa. El schema le pone once campos a cada operación — siempre los mismos once, llenos distinto en cada caso — para que después se puedan encontrar, componer, instanciar y medir.

Substrate es la capa más baja del library: las piezas más pequeñas y reutilizables. Lo que hay debajo de las verticales (Indietheka, Transit) y debajo de los meta-patrones que el Studio le vende a clientes. Si el substrate está bien definido, todo lo que se construya encima compone. Si está mal, se rompe en cada engagement nuevo.

Este documento muestra los 18 primitivos propuestos para v0.3, agrupados en cuatro funciones operativas: Coordinación, Inputs, Outputs, y Visibilidad y control. Tres son nuevos respecto al v0.2 (marcados NEW), uno está renombrado (RENAMED) y catorce vienen del v0.2 confirmados por la revisión de los agentes reales de Indietheka.

01Cómo se lee una ficha

Once campos. Cada uno responde una pregunta operativa concreta.

Cada primitivo tiene la misma estructura. La columna del medio explica qué significa el campo en lenguaje plano; la columna de la derecha lo aterriza con un ejemplo o analogía familiar. Lo que el campo no hace, también es importante — el schema está diseñado para no pretender hacer todo.

— Pattern Schema · v0.1 — Anatomía 11 fields · always the same
id
El nombre estable del primitivo, en formato dominio.nombre-corto. Una vez publicado, no cambia.
version
Número de versión. Cambios chicos suben el menor, cambios incompatibles suben el mayor.
layer
A qué capa del library pertenece: substrate (primitivo), vertical (aplicación de dominio) o meta (lo que vende el Studio).
domain
Categoría funcional: queue, editorial, seo, governance, etc. Permite filtrar.
problem signature
La descripción del problema operativo que el patrón resuelve, escrita en términos del estado del cliente o del sistema. Es el campo más importante — es lo que el matching engine compara contra el Workflow Audit.
inputs
Qué necesita el patrón para operar: datos, decisiones, contratos, ownership. No describe implementación.
outputs
Qué produce el patrón cuando opera bien — y a veces qué no produce, para hacer explícitos los límites.
composes
Lista de otros patrones que éste consume. Vacío para primitivos. Es lo que vuelve al library un grafo en lugar de una lista plana.
governance hooks
Puntos donde el patrón requiere supervisión: una decisión humana, una alerta, un gate, un watchdog. Conecta directamente con el Governance Runbook del cliente.
telemetry
Las métricas que demuestran que el patrón está funcionando. Sin telemetría no hay forma de saber si algo se rompió.
fit criteria
Las condiciones bajo las cuales el patrón es la respuesta correcta — y, igual de importante, las anti-condiciones bajo las cuales no lo es. Es el campo que evita que el matching engine recomiende patrones que técnicamente encajan pero contextualmente no.
02Índice de los 18 primitivos

Cuatro funciones operativas. Cada una responde una pregunta del sistema.

queue.lock-and-release— Coordinación
workflow.transactional-attempt— Coordinación
workflow.commit-then-verify-and-repair— Coordinación
triage.classify-and-route— Coordinación
ranking.multi-criteria— Coordinación
ingestion.feed-poll-and-dedupe— Inputs
research.evidence-with-verification— Inputs
asset.cascading-resolution-with-validation— Inputs
editorial.draft-approve-publish— Outputs
distribution.scheduled-fanout— Outputs
write.verify-and-retry— Outputs
seo.gap-detection— Visibilidad
governance.human-in-the-loop-gate— Visibilidad
governance.policy-checklist— Visibilidad
coordination.field-ownership-allowlist— Visibilidad
throttle.bounded-action-per-run— Visibilidad
agent.dry-run-mode— Visibilidad
telemetry.periodic-recap— Visibilidad
— Categoría 01 / 04 · Coordinación Cómo el sistema acuerda quién hace qué Cinco primitivos que evitan duplicación, trabajo perdido, y caos cuando varios agentes operan contra una misma fuente.
queue.lock-and-release v0.1 · layer / substrate · domain / queue
problem signature
"Tenés varios agentes leyendo de la misma cola y, sin coordinación, dos pueden tomar el mismo trabajo y duplicarlo. O un agente crashea con el lock puesto y el trabajo queda colgado para siempre."
inputs
Una cola compartida con identidad estable por fila (sheet, base de datos, archivo). El ID estable del agente que va a tomar el trabajo. Un TTL después del cual el lock vence solo. Opcionalmente, un heartbeat si el trabajo es largo.
outputs
Una fila tomada atómicamente por un solo agente, marcada con un estado intermedio (in_review, processing). La liberación explícita del lock al terminar, o un timeout que devuelve la fila al pool.
composes
— ninguno · es primitivo
governance hooks
Watchdog que detecta locks que pasaron su TTL. Alerta si la misma fila se está pidiendo repetidamente — signo de contención real, no de bug.
telemetry
Duración promedio del lock. Tasa de contención (cuántos intentos chocaron). Timeouts por hora. Ratio de releases explícitos vs por TTL.
fit criteria
Aplica: ≥2 agentes leyendo de la misma fuente y duplicar tiene costo (artículo doble en prensa, mensaje repetido al usuario, fila procesada dos veces). No aplica: trabajo idempotente y barato, o un solo worker.
workflow.transactional-attempt v0.1 · layer / substrate · domain / workflow
problem signature
"Un agente toma un trabajo, lo procesa, pero puede fallar a media. Necesitás que la fila no se quede colgada en estado intermedio ni se publique a medias. Toda corrida termina en éxito o de vuelta en cola — nunca en limbo."
inputs
Una fila lockeada por queue.lock-and-release. El conjunto de pasos a ejecutar. Un manejador de éxito que escribe el estado final + outputs. Un manejador de fallo que revierte el estado a queued y anota el motivo.
outputs
Fila en published con metadata del éxito (URL final, IDs creados, timestamps). O fila de vuelta en queued con un campo notes explicando qué falló para que la próxima corrida sepa qué reintentar.
composes
↳queue.lock-and-release — es la otra mitad del ciclo de bloqueo
governance hooks
Watchdog que escanea filas en estado intermedio por más de N minutos sin actividad y las fuerza a queued con nota de timeout.
telemetry
Ratio éxito/reintento. Tiempo promedio por intento. Tasa de filas que requieren ≥2 intentos antes del éxito.
fit criteria
Aplica: cualquier pipeline donde el trabajo es parcial-revertible y los reintentos son seguros. No aplica: cuando un fallo a mitad ya creó efectos colaterales irreversibles (cobros, mensajes enviados, posts publicados). Para esos casos usá workflow.commit-then-verify-and-repair.
workflow.commit-then-verify-and-repair NEW v0.1 · substrate · workflow
problem signature
"El agente crea un artefacto en un sistema externo — un draft de WordPress, una fila en una base, un mensaje enviado — y una vez creado no podés deshacerlo sin coste. Pero podés re-leerlo, verificar que cumple las reglas, y si falla, reparar in-place o anotarlo. Reintentar el job entero crearía duplicados."
inputs
El conjunto de reglas que el artefacto debe cumplir post-commit. Un mecanismo para re-leer el estado actual del artefacto (no asumir lo que enviaste — re-GET fresco). Funciones de reparación PATCH-en-el-mismo-lugar para cada regla. Una convención para anotar fallos residuales sin desbloquear el trabajo.
outputs
El artefacto creado y publicado, con el estado anotado: limpio (Published) o con flag específico (Published (metadesc out of range), Published (alt_text missing)). El trabajo nunca se reprocesa después de este punto — el flag es para acción humana, no para retry automático.
composes
↳governance.policy-checklist — reusa el mismo set de reglas, ejecutado post-commit en lugar de pre-commit
↳write.verify-and-retry — para los PATCH de reparación in-place
governance hooks
Alerta cuando un artefacto queda con flag residual — son los casos que requieren toque humano antes de quedar en producción. Alerta si la tasa de flags supera un umbral (signal de que las reglas o el commit están desalineados upstream).
telemetry
% de commits limpios vs flagged. Tipo de flag más común (qué regla falla más). Tasa de reparación exitosa por tipo de regla.
fit criteria
Aplica: integraciones con CMS, envío de mensajes, creación de records en sistemas terceros — cualquier contexto donde la idempotencia se logra anotando, no revertiendo. No aplica: workflows donde el rollback es barato y limpio (ahí workflow.transactional-attempt es más simple).
triage.classify-and-route v0.1 · substrate · triage
problem signature
"Llega input nuevo — un post publicado, un artículo del feed, un mensaje del usuario — y necesitás decidir qué pipeline downstream aplica. Sin un clasificador formal terminás escribiendo if/else gigantes que se rompen al agregar un tipo nuevo."
inputs
El input a clasificar (con suficientes campos para evaluar reglas). Una lista ordenada de reglas de detección, primera-coincidencia-gana. Un destino por tipo (un pipeline downstream o un sink).
outputs
Tipo asignado + log de la regla que matcheó (audit trail) + ruta al pipeline correspondiente. Tipo default cuando ninguna regla calza, para no perder el input.
composes
— ninguno · es primitivo
governance hooks
Alerta cuando muchos inputs caen al default — signal de que falta una regla. Revisión periódica del orden de las reglas (porque el orden importa: primera-coincidencia-gana).
telemetry
Distribución de tipos por día. % de inputs en default. Reglas más usadas (validación de la jerarquía actual).
fit criteria
Aplica: cualquier punto donde un set heterogéneo de inputs requiere tratamiento distinto downstream. No aplica: cuando todos los inputs comparten el mismo tratamiento — ahí no hay nada que rutear.
ranking.multi-criteria v0.1 · substrate · ranking
problem signature
"Tenés más candidatos que capacidad — 30 noticias en el feed pero solo 3 drafts por run, 40 reviews pendientes pero solo 1 a la semana, 200 posts a auditar pero solo 15 al día. Necesitás ordenar con criterios ponderados, no por timestamp ni alfabéticamente."
inputs
Lista de candidatos. Criterios con pesos (urgencia, volumen estimado, recency, gap de cobertura, etc.). Reglas de desempate explícitas (porque siempre hay empates).
outputs
Lista rankeada con score por candidato y razón de cada score. La razón es necesaria para audit y para presentar al humano si hay duda — sin razón, el ranking es opaco.
composes
— ninguno · es primitivo
governance hooks
Revisión periódica de pesos: ¿están produciendo selecciones que se desempeñan bien? Re-pesar si la telemetría dice que no.
telemetry
Outcome por rank position (¿los #1 efectivamente performan mejor?). Distribución de scores. Cuántos candidatos rankean bajo el corte de capacidad.
fit criteria
Aplica: cuando hay capacidad limitada y los criterios de selección no son obvios. No aplica: cuando todos los candidatos elegibles deben procesarse, o cuando el orden no importa.
— Categoría 02 / 04 · Inputs Cómo entra trabajo al sistema con verificación Tres primitivos que aseguran que lo que entra al sistema es lo que parece — sin duplicar, sin asumir, sin importar de dónde viene.
ingestion.feed-poll-and-dedupe v0.1 · substrate · ingestion
problem signature
"Tenés N fuentes externas (RSS, APIs, webhooks) que entregan items y necesitás procesarlos exactamente una vez, incluso si la fuente repite, si tu agente corre cada 40 minutos, o si reinicia. Re-procesar duplica el trabajo downstream; perder uno significa silencio editorial."
inputs
Lista de fuentes con su tipo de poll (RSS, API GET, etc.). Estrategia de dedupe (hash de ID, URL, contenido). Ventana de lookback (no procesar items más viejos que N días). State file persistente para los IDs ya vistos.
outputs
Items nuevos pasados al sink (sheet, queue, base) — solo después de confirmar la escritura se marca como visto. Items vistos almacenados con TTL si la fuente no garantiza IDs estables.
composes
↳write.verify-and-retry — no marcar como visto hasta confirmar que el sink recibió el item
governance hooks
Alerta si una fuente queda silenciosa por más de N runs (probablemente Cloudflare-blocked). Validación periódica del state file (que no esté corrupto — un state file corrupto re-procesa todo).
telemetry
Items nuevos por fuente por run. Tasa de fuentes silenciosas. Tamaño del state file (creciendo demasiado = TTL mal calibrado).
fit criteria
Aplica: ingest desde fuentes externas que pueden repetir o caer. No aplica: ingest one-shot o desde fuentes garantizadas-únicas.
research.evidence-with-verification v0.1 · substrate · research
problem signature
"Antes de actuar — escribir un artículo, generar un draft, tomar una decisión editorial — necesitás confirmar el hecho contra fuentes independientes. Una sola fuente puede estar equivocada (rumor, fake news, copia de otro medio); con N fuentes el costo de error es manejable."
inputs
El hecho/claim a verificar. Un mínimo N de fuentes independientes requeridas (típicamente 2-3 según severidad). Una lista de fuentes que cuentan como independientes (no aggregadores que copian-pega). Criterios de match (¿qué cuenta como confirmación del mismo hecho, no de uno parecido?).
outputs
Decisión binaria: confirmado (≥N fuentes coinciden) o insuficiente (
composes
— ninguno · suele ir antes de editorial.draft-approve-publish o de cualquier acción que afirme un hecho
governance hooks
Log de cada verificación con fuentes contadas (audit cuando algo sale mal). Revisión periódica de qué fuentes cuentan como independientes — el panorama mediático cambia.
telemetry
% de claims que pasan el gate. Tiempo entre primera mención y verificación cumplida. Cuáles fuentes son las primeras en confirmar (señal de quién está más cerca de las primarias).
fit criteria
Aplica: contenido editorial, decisiones con consecuencias, claims públicos. No aplica: trabajo interno, datos propios, contextos donde la velocidad importa más que la exactitud.
asset.cascading-resolution-with-validation RENAMED v0.1 · substrate · asset
problem signature
"Necesitás un asset externo (imagen, embed de Spotify, video) y la fuente preferida puede fallar — devolver un thumbnail genérico, un og:image equivocado, un track del artista que no es. Sin una cascada de fuentes con validación entre layers, terminás publicando con activos rotos o irrelevantes."
inputs
El asset target especificado por contenido (no por URL — "cover de Album X", no "image_url"). Una cascada ordenada de resolvers (Pitchfork → NME → Consequence → ...). Un validator por layer (HTTP 200, tamaño mínimo, aspect ratio, match de metadata como artista/título). Una blacklist de URL patterns conocidos como malos (logos, fallbacks, placeholders).
outputs
El asset descargado con metadata de origen + sha256 para auditoría. O unresolvable después de exhaustar la cascada — mejor que un asset incorrecto.
composes
↳write.verify-and-retry — cuando el asset hay que subirlo a otro sistema (ej. WP media library)
governance hooks
Alerta cuando una fuente sube su % de fallos (degradación de proveedor). Revisión humana mandatoria cuando el resolver cae al unresolvable en categoría visible (un draft sin imagen necesita ojos antes de publicar).
telemetry
Tasa de éxito por layer. Tiempo promedio por resolución. Distribución de fuentes que ganaron. Fallos por tipo (HTTP, validation, blacklist).
fit criteria
Aplica: cualquier deliverable que incluya assets externos donde "el asset incorrecto" es peor que "sin asset". No aplica: cuando tenés un único proveedor garantizado o el asset es opcional.
— Categoría 03 / 04 · Outputs Cómo el sistema produce y publica Tres primitivos sobre transformar trabajo interno en artefactos visibles — drafts editoriales, distribución a canales, escrituras durables a sistemas que no son nuestros.
editorial.draft-approve-publish v0.1 · substrate · editorial
problem signature
"Generaste contenido con un agente y antes de publicarlo a un canal externo (sitio, redes, mailer) querés un punto explícito donde un humano (o una checklist mecánica) lo apruebe. Sin ese gate, los errores editoriales — voz mala, fact incorrecto, palabra prohibida — llegan al lector."
inputs
El contenido generado. El destino de publicación. Las reglas de aprobación (humano explícito, checklist programática, o ambas). El tipo de log requerido (quién aprobó, cuándo, contra qué reglas).
outputs
Contenido en estado draft accesible al revisor. Tras aprobación, transición a published con timestamp y aprobador. Log de aprobación inmutable.
composes
↳governance.human-in-the-loop-gate — cuando la aprobación es humana
↳governance.policy-checklist — cuando la aprobación es mecánica
governance hooks
Alerta de drafts con TTL vencido sin aprobar (atascados). Política explícita de qué hacer con rechazos (¿re-encolar para reintento, archivar, escalar?).
telemetry
Tasa de aprobación por revisor/regla. Tiempo promedio en estado draft. Razones más comunes de rechazo (señal de qué corregir upstream).
fit criteria
Aplica: cualquier contenido editorial dirigido a audiencia. No aplica: trabajo interno o ephemeral donde el costo de error es bajo.
distribution.scheduled-fanout v0.1 · substrate · distribution
problem signature
"Un mismo artefacto (una noticia, una review, un editorial) tiene que aparecer en múltiples canales (Instagram, Facebook, Lnk.Bio, newsletter), pero cada canal tiene formato propio (1080×1350 vs 1200×630), constraints únicos (algunos no aceptan ciertos hosts de imagen), y cadencia distinta. Hacerlo a mano es lento y duplica errores."
inputs
Artefacto fuente (post de WP, draft). Plantillas por canal (cómo se traduce el contenido a cada formato). Cadencia por canal (timing). Rutas de assets por canal (algunos canales requieren CDN específicos por restricciones del fetcher). Throttle por canal (rate limits).
outputs
Publicación exitosa en cada canal con post_id. Estado en state file marcando qué canales recibieron qué (audit). Posts skipped por razón explícita (asset chico, tag manual, canal caído).
composes
↳throttle.bounded-action-per-run — limita posts por run
↳asset.cascading-resolution-with-validation — genera el asset por canal
↳write.verify-and-retry — cuando un POST a un canal devuelve transient error
governance hooks
Alerta si un canal queda inactivo por N runs (token expirado, API down). Flag de posts que fallaron en N intentos para revisión humana.
telemetry
Posts/run/canal. Latencia por canal. Tasa de éxito por canal. Ratio de skips por razón.
fit criteria
Aplica: contenido que debe aparecer en múltiples canales con cadencia regular. No aplica: distribución one-off o un solo canal.
write.verify-and-retry v0.1 · substrate · write
problem signature
"Escribiste a un sistema externo (DB, CMS, API), recibiste 200 OK, pero el sistema tiene eventual consistency, race conditions, índices que se regeneran async, o plugins que pisan tu write. La verdad operativa solo aparece al re-leer. Sin verificación, marcás trabajo como hecho que en realidad falló silenciosamente."
inputs
El write a ejecutar. Las reglas de qué cuenta como "persistido correctamente" (no echo del POST — re-GET fresco). Número máximo de reintentos. Idempotencia del write (debe ser seguro repetir).
outputs
El write confirmado vía re-lectura. O un fallo después de exhaustar reintentos, con log de cada intento.
composes
— ninguno · es primitivo
governance hooks
Alerta si un sistema requiere repetidamente más de 1 intento (degradación de proveedor). Revisión de timeouts si los reintentos consumen demasiado tiempo.
telemetry
% de writes que requieren ≥2 intentos por sistema. Latencia promedio del verify. Tasa de fallos definitivos.
fit criteria
Aplica: writes a Yoast/WP, sistemas con plugins que mutan post-save, índices async, distribución multiplataforma. No aplica: writes a sistemas con fuerte consistencia donde el 200 OK garantiza el estado.
— Categoría 04 / 04 · Visibilidad y control Cómo el sistema se gobierna a sí mismo Siete primitivos: detección de oportunidades, gates humanos y mecánicos, coordinación inter-agente, throttles, modo dry-run, y telemetría periódica. La mayoría de las cicatrices del sistema están en esta categoría.
seo.gap-detection v0.1 · substrate · seo
problem signature
"Tu competencia está cubriendo X — un anuncio, un álbum, una gira — y tu sitio no. Sin un detector que cruze constantemente lo que cubren ellos contra lo que cubrís vos, los gaps se acumulan y la autoridad orgánica se erosiona porque Google ve a otros como las fuentes."
inputs
Lista de competidores con cadencia de scraping. Query API/search contra tu propio corpus para chequear coverage. Criterios de match (mismo artista, mismo álbum, mismo evento). Umbral de novedad (¿cuán reciente debe ser para ser un gap?).
outputs
Lista de oportunidades — temas cubiertos por competencia, no por nosotros, dentro de la ventana de novedad — rankeadas por valor (volumen, gap idiomático, recency).
composes
↳ranking.multi-criteria — para priorizar las oportunidades
↳throttle.bounded-action-per-run — limitar cuántas se accionan por run
governance hooks
Revisión periódica de la lista de competidores (¿siguen siendo relevantes?). Validación de que los matches no sean falsos positivos (mismo nombre, distinto artista).
telemetry
Gaps detectados/run. Gaps que terminaron en draft publicado. Gaps que ganaron tráfico orgánico a 30/90 días.
fit criteria
Aplica: medios editoriales, sitios de e-commerce con catálogo, cualquier vertical donde "cobertura" es competitiva. No aplica: contenido evergreen donde no hay carrera por novedad.
governance.human-in-the-loop-gate v0.1 · substrate · governance
problem signature
"Hay un punto del pipeline donde un humano debe decidir — aprobar un draft, elegir una propuesta entre dos, autorizar una publicación irreversible. Si no formalizás el gate, el agente sigue corriendo y publica sin permiso, o se queda esperando para siempre sin notificar."
inputs
El contexto que el humano necesita para decidir (resumen, opciones, costos). El set de respuestas válidas. Un SLA (¿cuánto puede esperar el agente?). Una política de escalación (qué pasa si el SLA vence sin respuesta).
outputs
Decisión humana registrada (qué se eligió, cuándo, quién). Flujo continuado downstream con esa decisión como input.
composes
— ninguno · suele componer con editorial.draft-approve-publish o con commit-then-verify-and-repair como gate previo
governance hooks
Alerta de gates atascados sin respuesta más allá del SLA. Log de decisiones para audit (especialmente importante en decisiones que después se cuestionan).
telemetry
Tiempo promedio en gate. Tasa de aprobación vs rechazo. Revisores activos.
fit criteria
Aplica: decisiones con consecuencias asimétricas (publicar es caro de revertir, gastar dinero, enviar mensaje masivo). No aplica: decisiones reversibles donde el agente puede iterar solo.
governance.policy-checklist v0.1 · substrate · governance
problem signature
"Hay reglas mecánicas que cada artefacto producido debe cumplir — palabras prohibidas, longitudes, presencia de campos obligatorios, formatos. Una checklist mental no escala con la tasa de producción; necesitás un gate programático que falle ruidosamente cuando una regla no se cumple."
inputs
El artefacto a validar. El set de reglas con su severidad (block, warn). Orden de aplicación. Criterio de fallo (¿una regla violada bloquea, o solo si son varias?).
outputs
Gate aprobado (continuar) o bloqueado (con la lista de reglas violadas y por qué). Log inmutable de la corrida del checklist.
composes
— ninguno · suele ser pre-commit; commit-then-verify-and-repair lo reusa post-commit
governance hooks
Revisión periódica de qué reglas se violan más (señal de que falta tooling upstream o que el agente está mal calibrado). Auditoría de reglas obsoletas.
telemetry
% de gate aprobados vs bloqueados. Reglas más violadas. Tiempo del checklist (debe ser ms, no segundos).
fit criteria
Aplica: cualquier producción a escala donde la consistencia editorial/contractual importa. No aplica: artefactos one-off donde la revisión humana es viable cada vez.
coordination.field-ownership-allowlist NEW v0.1 · substrate · coordination
problem signature
"Tenés múltiples agentes que escriben al mismo recurso (postmeta, fila de DB, archivo compartido) y cada uno solo debe tocar ciertos campos. Sin un guard explícito, un agente bug puede escribir un campo de otro y borrar trabajo. La coordinación informal — 'el agente X no toca el campo Y' — falla con el primer pull request mal revisado."
inputs
La lista de campos que este agente posee (allowlist explícito). El payload del write que el agente está por hacer. Un assertador que arroja excepción si el payload toca campos fuera del allowlist, antes de tocar el sistema externo.
outputs
Write ejecutado (si pasa el guard) o exception ruidosa (si no), antes de tocar el sistema externo.
composes
— ninguno · suele estar en el path del write de varios outputs
governance hooks
Test que se corre en CI: cualquier change que agregue un campo al allowlist requiere review explícito. Log de excepciones de scope para detectar bugs upstream.
telemetry
Violaciones de scope por agente (debe ser cero en producción — cualquier valor positivo es alerta inmediata). Cuántos campos posee cada agente (creciendo = riesgo de scope creep).
fit criteria
Aplica: ≥2 agentes escribiendo a un mismo recurso compartido. No aplica: un solo agente con dueño exclusivo del recurso.
throttle.bounded-action-per-run v0.1 · substrate · throttle
problem signature
"Un agente con un bug o un input mal formado puede producir comportamiento corrido — postear 50 veces a Instagram, crear 200 drafts vacíos, enviar mensajes masivos. Sin un techo explícito por corrida, no hay protección entre 'agente trabajando bien' y 'agente quemando crédito o reputación'."
inputs
El límite máximo por corrida (N items, N writes, N tokens). El contador acumulativo dentro del run. Política de overflow (parar y log, encolar para próximo run, alertar).
outputs
Agente que respeta el techo y termina con un resumen de cuántas acciones ejecutó. Items que excedieron el límite quedan visibles en log para próxima corrida.
composes
— ninguno · suele envolver al output principal del agente
governance hooks
Alerta cuando un agente toca su techo repetidamente (signal de que el throughput real excede la capacidad — replantear cadencia o batch). Revisión periódica del valor del techo.
telemetry
% de runs que tocan el techo. Promedio de acciones/run vs el techo. Eventos de overflow.
fit criteria
Aplica: cualquier agente con efectos externos visibles (publica, envía, gasta dinero). No aplica: agentes puramente lectores o internos.
agent.dry-run-mode NEW v0.1 · substrate · agent
problem signature
"Querés probar un cambio en un agente — nueva regla, nuevo prompt, nueva fuente — pero correrlo en producción puede crear posts, distribuir mensajes, escribir a sistemas externos. Sin un modo no-destructivo explícito, cada test es un acto de fe."
inputs
El agente con todos sus inputs reales. Un flag de modo (--dry-run). Una convención de qué se simula (todos los writes, los API calls externos, las side effects) y qué se ejecuta de verdad (lectura, computación, validación).
outputs
El log completo de qué hubiera hecho el agente — cada write, cada call, cada decisión — sin haber tocado un sistema externo. El state file no se actualiza.
composes
— ninguno · debe estar implementado en cada agente que toque sistemas externos
governance hooks
Tests automatizados que corren cada agente en --dry-run antes de cada deploy. Revisión de divergencia entre dry-run y prod cuando se reporta — un dry-run que pasa pero prod falla es un bug serio del modo.
telemetry
Frecuencia de uso del flag (debería ser alta antes de cambios). Diferencias detectadas entre dry-run y prod (señal de bugs encontrados antes de que se manifiesten).
fit criteria
Aplica: cualquier agente que produce side effects en sistemas externos. No aplica: agentes puramente computacionales (no hay nada que dry-runear).
telemetry.periodic-recap v0.1 · substrate · telemetry
problem signature
"El sistema corre 24/7 con N agentes y vos no tenés tiempo de mirar logs todo el día. Sin un resumen estructurado y periódico de qué pasó (qué corrió, qué falló, qué cambió), te enterás de los problemas cuando ya escalaron — un agente quebrado durante una semana, un canal callado, una métrica cayendo."
inputs
Ventana temporal del recap (día, semana, mes). Fuentes de eventos (logs de cada agente, métricas de canal, KPIs externos). Plantilla del recap (qué incluir y en qué orden). Destino (markdown en repo, email, mensaje en chat).
outputs
Documento estructurado con: qué corrió, qué falló, qué métricas se movieron, qué requiere atención humana. Archivado y versionado para comparar contra recaps anteriores.
composes
↳ranking.multi-criteria — para priorizar qué incluir
↳governance.policy-checklist — para validar que el recap está completo
governance hooks
Alerta si un recap no se generó (signal de que el agente recap está caído — irónico pero real). Revisión periódica de la plantilla (¿estamos midiendo lo correcto?).
telemetry
El recap es la telemetría — meta. Adicionalmente: tiempo de generación, cobertura de eventos vs total esperado.
fit criteria
Aplica: cualquier sistema con ≥2 agentes corriendo autónomos. No aplica: sistemas one-shot o que el humano supervisa en tiempo real.