Graph engineering: de los bucles a los grafos

El 18 de julio de 2026, Peter Steinberger publicó en X una pregunta irónica sobre pasar de los bucles a los grafos. Hamel Husain la recogió y publicó un artículo titulado Loop Engineering Is Dead. Enter Graph Engineering. En una semana, el término estaba en todas partes.

Era sobre todo una broma acerca de la velocidad con la que este campo acuña disciplinas nuevas: pasamos de prompt engineering a context engineering, luego harness engineering, loop engineering y graph engineering en unos dieciocho meses, con definiciones que se solapan muchísimo.

Pero la broma funcionó porque señala algo real. Esta es la parte que merece la pena quedarse.

Tres cosas que la gente llama «graph engineering»

El término llegó cargando al menos tres ideas distintas. Buena parte de la confusión en internet es gente discutiendo de una a otra.

1. Grafos de orquestación. Diseñar un sistema multiagente como un grafo explícito en lugar de un bucle while: nodos tipados, transiciones tipadas, puntos de control desde los que reanudar. Es territorio de LangGraph y Temporal. Es ingeniería de verdad, y sobre todo importa si construyes infraestructura de agentes.

2. Grafos de bucles. Redes de ciclos de automejora que se observan entre sí. Conceptualmente interesante y, según la mayoría, lo menos accionable hoy.

3. Conocimiento y memoria estructurados como grafo. El saber del agente almacenado como nodos y aristas tipadas que puede recorrer de verdad, en lugar de un montón de documentos que relee y vuelve a adivinar.

Si no construyes infraestructura de orquestación —y la mayoría no lo hacemos, incluso quienes miramos cómo los agentes entran en el espacio de trabajo—, el n.º 3 es el que te cambia el día. Además es el más antiguo y mejor respaldado de los tres: los grafos de conocimiento existen desde décadas antes del término.

Por qué las aristas ganan a la búsqueda

Este es el ejemplo que lo hace evidente.

Pregúntale a un agente: «¿Por qué dejamos Redis para la cola de trabajos?»

La búsqueda de texto completo te devuelve todos los documentos que contienen «Redis»: si llevas un tiempo trabajando, decenas de archivos y ninguno es la respuesta. La búsqueda vectorial te devuelve documentos que suenan como la pregunta, lo cual suele ser peor: semánticamente cercanos, causalmente irrelevantes.

Un grafo responde en tres saltos:

cola de trabajos --decided_by--> ADR-007 (cola Postgres)
ADR-007          --supersedes--> ADR-003 (cola Redis)
ADR-003          --caused------> Incidente 2026-03-11

La respuesta no está en ningún documento. Está en el camino entre ellos. Una búsqueda no puede recuperar un camino: recupera nodos y confía en que tú los conectes.

Y fíjate en el detalle decisivo: las aristas están nombradas. supersedes no es caused ni es decided_by. Quita las etiquetas y vuelves a «estos archivos están relacionados de alguna manera», lo que obliga al agente a abrirlos todos y volver a inferir la relación: justo el trabajo que querías evitar.

Las aristas tipadas son todo el truco. Lo demás es fontanería.

Tu vault Markdown ya es el 80 %

Esta es la observación infravalorada de toda la discusión: un vault Markdown bien cuidado ya es la mayor parte de un índice GraphRAG.

Piensa en lo que un vault de notas con wikilinks te da gratis:

• Nodos: un archivo por idea, fuente o decisión
• Aristas: cada [[wikilink]] es una conexión que alguien estableció a propósito
• Resolución de entidades resuelta por construcción: [[ADR-007]] es el mismo nodo dondequiera que aparezca. Sin coincidencias difusas, sin colisiones de embeddings, sin «¿estas dos menciones son lo mismo?»

Esto último no es menor. La resolución de entidades es justo donde se desmoronan en silencio la mayoría de los pipelines automáticos de grafos de conocimiento. Un vault lo esquiva porque un humano nombró la entidad una vez, y el enlace es la identidad.

Lo que le falta a un vault sin más son las etiquetas. [[ADR-007]] te dice que dos notas están conectadas. No te dice cómo. Ese es el 20 % restante.

Cómo se ve en la práctica

Esta es la parte sobre la que se construyó Minibase Vault, así que seré concreto sobre cómo funciona en lugar de abstracto sobre lo que podría hacer.

Los nodos vienen de leer. Haces clic en la extensión de Minibase sobre lo que merezca guardarse —una página de documentación, una RFC, un hilo de X, una charla— y aterriza como Markdown limpio en una base de conocimiento local. Sin copiar y pegar, sin paso de exportación, sin la pestaña de «lo leo luego» que muere en el siguiente cierre del navegador.

Las aristas se registran, con un motivo. El vault mantiene un _graph.json en su raíz:

{
  "edges": [
    {
      "from": "AI Research/attention-paper-20260405-1200.md",
      "to": "AI Research/transformer-tutorial-20260408-0900.md",
      "reason": "Both explain the attention mechanism in transformers"
    }
  ]
}

Claude escribe esas aristas por su cuenta, a través del servidor MCP del vault, cuando lee de forma transversal tus notas y detecta una conexión. Luego afloran como líneas Related: en el _index.md de cada base, para que la red sea visible también para ti, no solo para el modelo.

Los caminos se condensan en páginas. Cuando un grupo de notas relacionadas se vuelve lo bastante denso, Claude puede sintetizarlas en una página _topic-*.md que cita sus fuentes. La próxima vez que guardes algo de ese grupo, la página de síntesis ya está ahí para actualizarse. Ese es el efecto acumulativo: el vault se vuelve más inteligente, no solo más grande.

Los huérfanos se señalan. Una pasada de lint reporta duplicados, notas huérfanas, contenido caducado y grupos maduros para sintetizar. Los grafos se degradan; algo tiene que darse cuenta.

Todo corre en local. El índice de búsqueda es SQLite FTS5 con ranking BM25, el grafo es un archivo JSON y nada de tus notas sale de la máquina.

Dónde bajaría el entusiasmo

Dos reservas honestas, porque este es un término que se hizo popular en una semana y la popularidad corre más que el fondo.

Las aristas de Minibase llevan un motivo, no un tipo formal. "reason": "Both explain the attention mechanism" es una frase, no supersedes. Es muchísimo mejor que un wikilink sin etiqueta y bastante menos que una ontología. Si necesitas relaciones estrictamente tipadas para razonamiento multisalto a escala, quieres una base de datos de grafos de verdad, y conviene ser honesto sobre el mantenimiento que eso implica.

La mayoría de la gente no necesita nada de esto. Si tu conocimiento son cincuenta notas, la búsqueda basta. Los grafos empiezan a rentar cuando tienes material suficiente como para haber empezado a olvidar lo que tienes, y cuando tus preguntas son causales («por qué hicimos») en vez de léxicas («dónde leí»).

El término «graph engineering» probablemente no sobreviva al año. La idea que hay debajo —que la estructura entre tus notas vale más que el volumen de notas— era cierta mucho antes de tener nombre, y lo seguirá siendo después.

Empieza por la versión aburrida

1. Guarda lo que lees como Markdown en vez de marcarlo. Un marcador es un puntero a algo que se pudre; un archivo es algo que tienes.
2. Mantenlo local, en una sola carpeta, un archivo por fuente.
3. Deja que tu IA lea la carpeta entera —por MCP, no copiando y pegando— y hazle preguntas que exijan dos documentos para responderse.
4. Registra las conexiones que encuentre. Y vuelve a preguntar el mes que viene.

Eso es graph engineering para quienes no publicamos frameworks de orquestación. Es context engineering con las conexiones escritas.

---

Minibase convierte cualquier página web en Markdown limpio con un clic, directo a un vault local que tu IA puede buscar y conectar. La extensión es gratis con guardados ilimitados; Minibase Plus (5,99 $/mes o 34,99 $/año) añade plantillas de IA, historial y transcripción de vídeo. minibase.md.