Graph Engineering, Explained: Loops to Knowledge Graphs

On July 18, 2026, Peter Steinberger posted a tongue-in-cheek question on X about moving from loops to graphs. Hamel Husain ran with it and published an article titled Loop Engineering Is Dead. Enter Graph Engineering. Within a week the term was everywhere.

It was mostly a joke about how fast this field mints new disciplines — we went prompt engineering → context engineering → harness engineering → loop engineering → graph engineering in about eighteen months, and the definitions overlap heavily.

But the joke landed because it points at something real. Here’s the part worth keeping.

Three things people mean by “graph engineering”

The term arrived carrying at least three distinct ideas. Most of the confusion online is people arguing across them.

1. Orchestration graphs. Design a multi-agent system as an explicit graph instead of a while loop: typed nodes, typed transitions, checkpoints you can resume from. This is LangGraph and Temporal territory. It’s real engineering, and it mostly matters if you’re building agent infrastructure.

2. Graphs of loops. Networks of self-improvement cycles watching each other. Conceptually interesting, and by most accounts the least actionable today.

3. Graph-structured knowledge and memory. The agent’s knowledge stored as typed nodes and edges it can actually traverse, rather than a pile of documents it re-reads and re-guesses.

If you’re not building orchestration infrastructure — and most of us aren’t, even those of us watching agents move into the workspace — #3 is the one that changes your day. It also happens to be the oldest and best-supported of the three — knowledge graphs predate the term by decades.

Why edges beat search

Here’s the example that makes it click.

Ask an agent: “Why did we drop Redis for the job queue?”

Full-text search gets you every document containing “Redis” — which, if you’ve been working for a while, is dozens of files and none of them is the answer. Vector search gets you documents that sound like the question, which is often worse: semantically close, causally irrelevant.

A graph answers it in three hops:

job queue        --decided_by--> ADR-007 (Postgres queue)
ADR-007          --supersedes--> ADR-003 (Redis queue)
ADR-003          --caused-------> Incident 2026-03-11

The answer isn’t in any single document. It’s in the path between them. Search can’t retrieve a path — it retrieves nodes and hopes you connect them yourself.

And note the critical detail: the edges are named. supersedes is not caused is not decided_by. Strip the labels and you’re back to “these files are somehow related,” which means the agent has to open all of them and infer the relationship again — which is exactly the work you were trying to avoid.

Typed edges are the whole trick. Everything else is plumbing.

Your Markdown vault is already 80% of it

Here’s the underrated observation from the graph engineering discussion: a well-kept Markdown vault is already most of a GraphRAG index.

Think about what a vault of notes with wikilinks gives you for free:

• Nodes — one file per idea, source, or decision
• Edges — every [[wikilink]] is a connection someone deliberately made
• Entity resolution solved by construction — [[ADR-007]] is the same node everywhere it appears. No fuzzy matching, no embedding collisions, no “are these two mentions the same thing?”

That last one is not a small thing. Entity resolution is where most automated knowledge-graph pipelines quietly fall apart. A vault sidesteps it because a human named the entity once, and the link is the identity.

What a plain vault is missing is the labels. [[ADR-007]] tells you that two notes are connected. It doesn’t tell you how. That’s the 20%.

What that looks like in practice

This is the part Minibase Vault was built around, so I’ll be concrete about how it works rather than abstract about how it could.

Nodes come from reading. You click the Minibase extension on anything worth keeping — a doc page, an RFC, an X thread, a conference talk — and it lands as clean Markdown in a local knowledge base. No copy-paste, no export step, no “I’ll read it later” tab that dies in a browser crash.

Edges are recorded, with a reason. The vault keeps a _graph.json at its root:

{
  "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 writes those edges itself, through the vault’s MCP server, when it reads across your notes and notices a connection. They then surface as Related: lines in the per-base _index.md, so the web is visible to you too, not just to the model.

Paths get compressed into pages. When a cluster of related notes gets dense enough, Claude can synthesize them into a _topic-*.md page that cites its sources. Next time you save something in that cluster, the topic page is already there to update. That’s the compounding step — the vault gets smarter, not just bigger.

Orphans get flagged. A lint pass reports duplicates, orphaned notes, stale content and clusters ripe for synthesis. Graphs decay; something has to notice.

All of it runs locally. The search index is SQLite FTS5 with BM25 ranking, the graph is a JSON file, and nothing about your notes leaves the machine.

Where I’d temper the hype

Two honest caveats, because this is a term that got popular in a week and popularity outruns substance.

Minibase’s edges carry a reason, not a formal type. "reason": "Both explain the attention mechanism" is a sentence, not supersedes. It’s far better than an untyped wikilink and far short of an ontology. If you need strict typed relations for multi-hop reasoning at scale, you want a real graph database, and you should be honest with yourself about the maintenance that implies.

Most people don’t need any of this. If your knowledge is fifty notes, search is fine. Graphs earn their keep when you have enough material that you’ve started forgetting what you have — and when the questions you’re asking are causal (“why did we”) rather than lexical (“where did I read”).

The term “graph engineering” will probably not survive the year. The idea underneath it — that structure between your notes is worth more than volume of notes — has been true since long before it had a name, and will be true after.

Start with the boring version

1. Save what you read as Markdown instead of bookmarking it. Bookmarks are pointers to things that rot; files are things you have.
2. Keep it local, in one folder, one file per source.
3. Let your AI read the whole folder — via MCP, not copy-paste — and ask it questions that require two documents to answer.
4. Record the connections it finds. Then ask again next month.

That’s graph engineering for people who don’t ship orchestration frameworks. It’s context engineering with the connections written down.

---

Minibase turns any webpage into clean Markdown in one click, straight into a local vault your AI can search and connect. The extension is free with unlimited saves; Minibase Plus ($5.99/mo or $34.99/yr) adds AI templates, saved history and video transcription. minibase.md.