He construido un sistema con Hermes para resolver un problema concreto que me propusieron en un departamento de una Universidad: pasar de una exploración asistida por modelos a una revisión PRISMA defendible metodológicamente, auditable técnicamente y entregable como paquete editorial real.
Lo primero, mi pliego de descargo. No es un agente que escribe artículos (bueno sí, pero no quiero entrar en peleas con más académicos). Es una infraestructura con reglas, archivos, comandos y controles materiales. No entrego en esta parte el agente paquetizado para su uso —eso vendrá en otro artículo—, sino la discusión para mejorarlo. Lo compartiré, pero necesito chance para que el que lo use replique mis mismos resultados.
No voy a entrar en el debate universitario de si utilizar o no este tipo de sistemas. Aquí lo único que pretendo, con humildad, es enseñar cómo está hecho por dentro para que puedas replicarlo, mejorarlo o aportar aquello que quieras al modelo.
Arquitectura general de Hermes para revisiones PRISMA.
El problema real que quería resolver con HERMES
Lo primero que quise resolver construyendo este sistema de agentes fue la fragilidad de las revisiones hechas con un simple modelo (da igual si de OpenAI, Anthropic, Qwen…). Un modelo puede resumir, comparar y proponer líneas argumentales muy bien, pero eso no equivale a una revisión sistemática seria. Si el proceso no deja rastro de búsqueda, criterios de inclusión, motivos de exclusión, confirmación de texto completo y cierre editorial verificable, el resultado puede sonar bien y ser metodológicamente débil. Eso era lo que quería atacar con este sistema.
PRISMA 2020 insiste en documentar cómo se identifican, seleccionan e incluyen los estudios. PRISMA-S endurece esa exigencia en la capa de búsqueda. Esa es la base sobre la que se levanta el resto.
El segundo problema ha sido operativo. Una revisión seria no se resuelve en una sola llamada al modelo. Pide un protocolo, adquisición bibliográfica, auditoría de DOI, cribado, recuperación de PDF, lectura de texto completo, extracción profunda, generación de figuras, escritura de manuscrito, revisión cruzada, empaquetado y sincronización.
Si todo eso vive solo en la memoria contextual de una conversación, el sistema es frágil por definición. Por eso Hermes separa estado, proceso y artefactos persistentes. Lo importante no es que «recuerde», sino que vuelva a leer (Vault de Obsidian) lo que dejó escrito para generar decisiones adecuadas.
Fuentes: Page et al. 2021 (BMJ n71) · Rethlefsen et al. 2021 (PRISMA-S)
De copilot a sistema replicable.
Los principios metodológicos sobre los que se construye
Hermes no se construye alrededor de la pregunta «qué puede hacer un agente en esta investigación», sino alrededor de la pregunta «qué condiciones mínimas debe cumplir una revisión para que yo me fíe de ella».
He trabajado en seis reglas:
- PRISMA 2020 como marco de elaboración de informes.
- PRISMA-S como marco de transparencia de búsqueda.
- DOI-first siempre que el identificador exista.
- Texto completo obligatorio para el corpus final.
- Recomputación de conteos desde artefactos reales.
- Cierre editorial solo con gate PASS, no con la impresión subjetiva de que «ya está bastante bien».
Estas reglas se materializan en la skill base prisma-systematic-review/SKILL.md, que funciona como contrato operativo y metodológico. Insisto en este punto porque en muchos sistemas con agentes la parte interesante vive en prompts invisibles. Aquí no: aquí la metodología es una pieza versionable y auditable.
La decisión de consumo de tokens es exigir texto completo legible para la inclusión final, así como un modelo que soporte este tipo de papers y extraiga bien todo el texto.
Un resumen ayuda a descartar rápido, pero no basta para declarar que un estudio forma parte del corpus serio. Es una frontera metodológica, no una preferencia de estilo.
Fuentes: PRISMA Statement · Cochrane Handbook ch. 4
Guardrails no negociables.
La arquitectura usada de Hermes
La arquitectura se apoya en cuatro capas.
La primera es una superficie mínima por Telegram, porque no quiero que la operativa dependa de una interfaz.
Sistema en funcionamiento desde Telegram.
La segunda es el runtime en Docker con dos servicios: hermes-agent ejecuta el gateway y el trabajo principal; hermes-prisma-watchdog monitoriza revisiones vivas y reanuda fases cuando detecta estancamiento.
La tercera capa es la política de modelos. Modelo primario: Qwen 3.6 servido por NaN Builders. Cadena de relevo en Ollama Cloud: DeepSeek v4-pro, Kimi K2.6, Qwen3-coder y Gemma4. Esta cadena vive en un config.yaml con todos sus ingredientes (temperatura, top-p, max tokens, frequency penalty, response format…).
La cuarta capa es la orquestación, con complete_review.py, publication_autopilot.py y publication_gate.py.
Hay otra capa que suele quedar escondida y hay que mencionar: las skills. En mi instalación hay diez skills locales de investigación (las pasaré con el paquete completo).
En el camino del «PRISMA publicable» uso de forma fuerte cinco: revisión sistemática, estado, revisión académica, integridad y mapa de cambios. La arquitectura no es un súper agente que lo hace todo, sino capas especializadas con contratos pequeños. Eso la hace mantenible y escalable para mi caso de uso.
Artefactos clave: config.yaml, docker-compose.yml, start-gateway.sh, prisma-watchdog.py, 10 skills en hermes-home/skills/research
Arquitectura de alto nivel.
Cómo empieza una revisión: intake, pregunta y criterios
Una revisión buena se sesga antes en el intake que al final en la discusión. Por eso el sistema obliga a congelar cuanto antes la pregunta, la ventana temporal, el tipo de estudio admisible, el N final deseado, los criterios de inclusión y exclusión, y el marco editorial esperado.
No es una formalidad. Si el tema nace como «vamos a ver qué sale», el resto del sistema solo automatiza ambigüedad.
Lo que aporta valor es que la fase deja rastro visible desde el primer minuto. Aparecen protocol/intake.md, protocol/eligibility-criteria.md y protocol/search-strategy.md. Lo importante no es solo que existan, sino que otra persona pueda abrirlos y revisar si el sesgo nace en la pregunta, en la búsqueda o en la interpretación.
Hay una decisión que me gusta mencionar: si no tengo revista concreta a la que publicar (templates), Hermes cae a un modo generic-common-core (plantilla que pasaría un primer filtro). Esa decisión luego afecta a la plantilla LaTeX, al tipo de paquete editable y al tono del cierre editorial. No es cosmética. Es una forma de no fingir alineación con una revista que aún no he elegido donde se podría publicar.
Artefactos clave: protocol/intake.md, protocol/eligibility-criteria.md, protocol/search-strategy.md
Fuentes: Cochrane Handbook ch. 4 · Kitchenham et al. 2009
Comandos reproducibles.
Las preguntas y los comandos que congelan la frontera metodológica
Esta fase es donde la revisión deja de ser una intención y se convierte en una máquina metodológica. La pregunta de investigación, la unidad de análisis, la ventana temporal, los criterios de inclusión y exclusión y el límite de calidad dejan de ser decisiones tácitas. Quedan fijados en artefactos que después condicionan todo el recorrido del sistema. Eso importa porque, en una revisión científica, gran parte del sesgo no aparece al final, cuando ya se redacta el texto, sino mucho antes, en la forma en que se define qué cuenta como estudio elegible y qué queda fuera.
El primer componente clave es bootstrap_topic_review.py. Su valor no está solo en crear carpetas, sino en materializar el punto de partida de la revisión. A partir de él aparecen protocol/intake.md, la estrategia de búsqueda y la estructura inicial del proyecto. Dicho de otra forma, este script no prepara un directorio: fija el contrato metodológico de la revisión. Si más adelante el corpus queda sesgado, puedo volver a ese origen y comprobar si el problema nació en la formulación de la pregunta, en la amplitud de la búsqueda o en la dureza de los criterios.
El segundo componente es doi_audit.py. Aquí el objetivo no es «limpiar CSV», sino estabilizar la identidad bibliográfica del corpus. Cuando las fuentes llegan desde OpenAlex, Crossref, Semantic Scholar o arXiv, lo normal es que existan duplicados, DOI ausentes, variantes mínimas de título y metadatos inconsistentes. Este script transforma ese desorden en tres vistas críticas: qué registros tienen DOI identificable, cuáles están duplicados y cuáles siguen siendo ambiguos. En términos prácticos, esto reduce uno de los errores más frecuentes en revisiones semiautomáticas: creer que se han encontrado más estudios de los que realmente existen o, peor aún, perder trazabilidad sobre por qué un paper quedó fusionado, descartado o marcado como incierto.
El tercer elemento es complete_review.py. Este archivo es importante porque no resuelve una tarea concreta, sino que gobierna la secuencia completa: adquisición, cribado, recuperación de textos completos, extracción y salto a la capa editorial. Su utilidad real es que convierte una colección de operaciones sueltas en un flujo con dependencias explícitas. No se empieza a extraer si el corpus no está suficientemente fijado, no se da por bueno un estudio sin evidencia de texto completo y no se pasa a publicación si faltan artefactos intermedios. Eso hace que la automatización no sea simplemente rápida, sino disciplinada.
El cuarto componente es review_runtime_state.py o, en su defecto, el estado material que Hermes serializa como runtime-state. Aquí el valor no está en «ver en qué fase voy», sino en preservar contexto operativo sin depender de memoria conversacional. Cuando la revisión se interrumpe, el sistema puede releer qué ya está hecho, qué falta, qué bloqueos existen y qué artefactos sostienen cada transición. Eso cambia mucho la naturaleza del trabajo: la continuidad ya no depende de recordar verbalmente dónde me había quedado, sino de releer un estado persistente que el sistema puede interpretar y reutilizar.
Lo importante, por tanto, no es que Hermes ejecute cuatro scripts, sino que cada uno clausura una incertidumbre metodológica distinta. bootstrap_topic_review.py fija el alcance. doi_audit.py estabiliza la identidad del corpus. complete_review.py impone el orden del proceso. runtime-state conserva la memoria operativa. Juntos hacen que el sistema no improvise lo que debería haber quedado definido al principio. A partir de ese momento, Hermes ya no intenta adivinar qué revisión quiero construir: ejecuta una revisión cuyas reglas, límites y transiciones ya han quedado escritas.
La frontera metodológica se fija antes de importar el primer registro y queda escrita. A partir de ahí el sistema no adivina qué quiero hacer: ejecuta lo que dejé especificado desde un primer momento.
Artefactos clave: bootstrap_topic_review.py · doi_audit.py · complete_review.py · review_runtime_state.py
Mayéutica first.
De fuentes heterogéneas a un universo «DOI-first»
Hermes se conecta a varias fuentes porque ninguna es suficiente por sí sola.
En el arranque, bootstrap_topic_review.py consulta OpenAlex, Crossref, Semantic Scholar y arXiv. Lo hace con llamadas HTTP directas y parseo de respuestas JSON o Atom. El resultado no es «una búsqueda en abstracto», sino un conjunto que se puede exportar con rastro técnico.
El primer artefacto de esta fase es searches/search-log.csv: guarda consulta, fuente, fecha y volumen recuperado. Luego aparecen records/master-records.csv, records/doi-index.csv, records/duplicates.csv y records/missing-doi.csv.
El primero es el universo bruto normalizado. El segundo consolida la clave canónica por DOI. El tercero conserva colisiones detectadas. El cuarto señala lo que no se puede resolver por DOI. Cuando no hay DOI, Hermes usa un identificador estable por hash y genera RID.
Aquí la revisión deja de ser una colección de búsquedas y empieza a parecerse a una base documental con la que empezar a trabajar.
Fuentes: Rethlefsen et al. 2021 (PRISMA-S)
Universo normalizado por DOI.
Cómo decide Hermes: OK, KO o si hace falta más
La lógica de inclusión y exclusión no es un algoritmo mágico. Es una secuencia mixta de cuatro capas: reglas mínimas, decisión asistida por modelo, canonización de la decisión y auditoría con recomputación. El sistema no se limita a preguntar a un modelo si algo «parece relevante».
La regla más visible está en complete_review.py, donde fija un umbral mínimo de texto útil. Si el texto completo no llega ahí, no es base suficiente para inclusión final. En el mismo script vive canonicalize_screening_decision, que normaliza variantes de inclusión y exclusión para que include, include_ft, exclude, excluido, excluir o maybe queden reducidas a un conjunto consistente. Esa normalización importa porque luego los conteos PRISMA no se escriben a mano: se recalculan a partir de decisiones canonizadas.
Un estudio queda OK cuando supera reglas mínimas, confirma el foco en texto completo y deja una justificación trazable en CSV. Queda KO cuando falla esos criterios o el motivo de exclusión es claro, y queda en «hace falta más» cuando el cribado rápido no basta. Esa lógica se acerca más a ROBIS o AMSTAR 2 que a una simple ordenación de relevancia.
Fuentes: Whiting et al. 2016 (ROBIS) · Shea et al. 2017 (AMSTAR 2)
Cuatro capas para decidir, no una sola pregunta al modelo.
Extracción profunda: del PDF a una ficha en la que sí hay tracción
La extracción profunda cambia de nivel la revisión. No me basta con saber que un artículo es «experimental» o que analiza. Quiero saber qué nombra (dentro de la pregunta del estudio realizada), qué benchmark usa, qué muestra describe, qué variables emplea, qué método reporta y en qué teoría se posiciona. Todo eso queda en extraction/extraction-table.csv, con campos como work_type, empirical_type, design_detail, models_or_systems_studied, benchmark_dataset_or_corpus, dependent_variables, independent_variables y theoretical_framework.
Cuando una extracción inicial se queda corta, Hermes no se resigna a una ficha sin datos. Recurre a refresh_extraction_depth.py, que relee el texto extraído del PDF y fuerza una capa más profunda. Esto resuelve un problema que he vivido varias veces: artículos que en un primer pase aparecían como «estudio experimental», cuando el documento completo sí ofrecía nombres sobre la pregunta de investigación, escalas y métricas más útiles a añadir. Esto lo marcaría como muy importante si te vas a construir el tuyo.
Organizo cada estudio en cuatro capas: núcleo común (tipo de trabajo, año, DOI, autores, publicación, palabras clave, resumen), bloque empírico (diseño, país, muestra, método, variables, instrumentos), bloque técnico (modelos, datasets, benchmarks, corpus, tareas) y bloque de teoría y síntesis (marco teórico, hallazgos clave, confianza de extracción). La comparabilidad nace del esquema de extracción, no de una tabla bonita al final.
Artefactos clave: extraction/extraction-table.csv, refresh_extraction_depth.py
Zonas empíricas, técnicas, teóricas y de núcleo.
Figuras, tablas y evidencia visual
No quería que Hermes tratara las figuras de los artículos con ruido lateral. En muchos temas, una figura concentra arquitectura, diseño experimental o relaciones conceptuales que el resumen no recoge claramente. Por eso añadí una capa explícita de evidencia visual con modelos que soportaran un visionado y procesamiento de los mismos.
El script clave es prepare_paper_figures.py. No solo exporta imágenes: separa figuras científicas extraídas de los PDF, renderizados de página diagnósticos y activos visuales generados para el manuscrito. Esa separación fue importante porque, sin ella, una página renderizada completa puede confundirse con una figura científica reutilizable (divide bien y vencerás).
El resultado vive en varias rutas: figures/extracted/ para figuras científicas detectadas, figures/page-renders/ para renderizados de apoyo, y figures/manifest.csv, figure-catalog.md y figure-ranking.csv para trazabilidad. Las figuras propias del manuscrito llevan la firma 686f6c61 (en mi caso) para distinguirlas de las del corpus. Mezclar reutilización de evidencia ajena y síntesis visual propia es mala práctica metodológica y mala práctica editorial.
Fuentes: Wilkinson et al. 2016 (FAIR) · ACM Artifact Review
Planos visuales: manifiesto y catálogo.
Del corpus al manuscrito publicable
Cuando el corpus está consolidado, el reto deja de ser documental y se vuelve editorial. La pieza central es publication_audit.py. Ese script recompone secciones, limpia incoherencias, normaliza citas y referencias, integra tablas y figuras, detecta huecos obvios y genera el manuscrito. En la práctica es el agente APA y de montaje del sistema, aunque no lleve ese nombre en el árbol.
Los tres artefactos que deja son paper/manuscript/publication-ready.md, paper/manuscript/publication-ready.tex y paper/manuscript/publication-ready.pdf. El primero es la versión editable. El segundo, salida técnica para continuidad académica en LaTeX. El tercero, versión compilada lista para circular. A eso se suma paper/references/references.generated.bib con la bibliografía BibTeX, y main-common-core.tex cuando no hay revista objetivo.
Aquí impongo mis manías (que no son pocas). Cada estudio relevante debe tener algo más que una fila de tabla. Por eso el manuscrito final incluye fichas por estudio con uno o dos párrafos antes de la tabla compacta, y bloques ampliados de discusión, implicaciones teóricas, aportación original, conclusiones y líneas futuras. El resultado no es una salida automática: es una pieza que una persona académica reconoce como manuscrito que sea «más determinista» y proporcione mayor validez.
Artefactos clave: paper/manuscript/publication-ready.{md,tex,pdf}, paper/references/references.generated.bib, main-common-core.tex
De corpus a manuscrito en PDF, MD y .TEX.
Revisión cruzada, integridad y gate editorial
Esta capa es la que más diferencia a Hermes de un flujo convencional con varios LLMs. No doy por bueno un manuscrito porque un modelo haya escrito una narrativa sólida. Lo doy por bueno cuando supera un circuito acumulativo de revisión, integridad y validación de artefactos.
publication_peer_review.py lanza la revisión cruzada y escribe paper/review/review-manifest.csv, paper/review/peer-review-overview.md y el material de cada revisor.
La política está en reviewer-models.csv: Revisor A trabaja con Qwen 3.6 sobre NaN, Revisor B con DeepSeek v4-pro, y Kimi K2.6 queda como primer relevo editorial. check_manuscript_integrity.py busca afirmaciones flojas, inconsistencias y huecos de soporte. build_revision_roadmap.py convierte esa revisión en una matriz de cambios accionables. publication_gate.py comprueba si los artefactos requeridos existen y si el cierre es legítimo. publication_autopilot.py es el bucle que reitera sobre esas capas hasta cerrar o documentar un bloqueo real.
Este sistema se parece más a la lógica de evaluación estructurada de ROBIS y AMSTAR 2, y al espíritu de revisión de artefactos de ACM, que a la idea de «dar un último vistazo». Y evita un error: entregar algo que parece terminado cuando no ha pasado los controles que justifican llamarlo publicable.
Fuentes: Whiting et al. 2016 (ROBIS) · Shea et al. 2017 (AMSTAR 2) · ACM Artifact Review
Revisión, integridad y validación.
Paquetes finales, memoria operativa y límites encontrados
Cuando el gate devuelve PASS, Hermes no termina en una carpeta suelta. Genera dos paquetes con funciones distintas: paper/package/publication-package.zip como paquete editorial general y paper/package/publication-latex-editable.zip como continuidad académica editable.
La distinción importa porque no todo lector necesita lo mismo. A la vez, sync_review_to_obsidian.py sincroniza la revisión al vault de Obsidian y conserva una versión navegable para investigación posterior: fichas, overview, biblioteca visual, notas y rastro PRISMA.
Vault de ejemplo en Obsidian.
La continuidad operacional no depende de recordar una conversación. Depende de archivos de estado como notes/runtime-state.md y notes/runtime-state.json, de manifiestos, de ZIPs y de un watchdog que sabe releer y reanudar. La memoria real del sistema está fuera del chat. Desde la lógica FAIR, esto acerca la revisión a un activo localizable, accesible e interoperable.
Memoria material.
No quiero cerrar el artículo fingiendo que Hermes es perfecto para este objetivo. Sigue dependiendo de la calidad de las fuentes, de la recuperabilidad del texto completo, de la disponibilidad de modelos en la nube y de la posibilidad de extraer figuras o tablas complejas sin pérdida.
Aún con el gate endurecido, encuentro zonas mejorables: una capa formal de risk of bias, mejores plantillas por revista, más control sobre metaanálisis cuando el corpus lo permita y una automatización aún más fina del paso entre publication-ready y submission-ready. Para esa evolución sigo trabajando para entregar y publicar algo que podáis instalar, usar y mejorar.
Dónde quiero seguir mejorando.
Fuentes: Wilkinson et al. 2016 (FAIR) · Wohlin 2014
(Si has llegado hasta aquí, te mereces un aplauso. Gracias por tu tiempo)
Referencias
- Page, M. J., McKenzie, J. E., Bossuyt, P. M., et al. (2021). The PRISMA 2020 statement: an updated guideline for reporting systematic reviews. BMJ, 372, n71.
- Page, M. J., Moher, D., Bossuyt, P. M., et al. (2021). PRISMA 2020 explanation and elaboration: updated guidance and exemplars for reporting systematic reviews. BMJ, 372, n160.
- Rethlefsen, M. L., Kirtley, S., Waffenschmidt, S., et al. (2021). PRISMA-S: an extension to the PRISMA Statement for Reporting Literature Searches in Systematic Reviews. Systematic Reviews, 10, 39.
- Cochrane Handbook for Systematic Reviews of Interventions, Chapter 4: Searching for and selecting studies.
- Kitchenham, B., Brereton, O. P., Budgen, D., Turner, M., Bailey, J., y Linkman, S. (2009). Systematic Literature Reviews in Software Engineering: A Systematic Literature Review. Information and Software Technology, 51(1), 7-15.
- Whiting, P., Savovic, J., Higgins, J. P. T., et al. (2016). ROBIS: A new tool to assess risk of bias in systematic reviews.
- Shea, B. J., Reeves, B. C., Wells, G., et al. (2017). AMSTAR 2: a critical appraisal tool for systematic reviews that include randomised or non-randomised studies of healthcare interventions, or both. BMJ, 358, j4008.
- Wilkinson, M. D., Dumontier, M., Aalbersberg, I. J., et al. (2016). The FAIR Guiding Principles for scientific data management and stewardship. Scientific Data, 3, 160018.
- Wohlin, C. (2014). Guidelines for Snowballing in Systematic Literature Studies and a Replication in Software Engineering.
- ACM. Artifact Review and Badging, current policy.
Publicado originalmente en X el 10 de mayo de 2026.