Sources

This page is the canonical attribution record for the Graph Engineering Course. Every idea this course borrows is credited here to where it came from. Nothing on this page, or anywhere else in this repository, is copied from the sources below — each entry states the idea we took and, in our own words, why it earned a place in the curriculum. Where a page elsewhere in this course credits a concept, it links back to the matching entry here rather than re-explaining who the person or project is.

Ten sources shaped this course. Nine were read in full for their mechanisms and then set aside before any of our material was drafted. The tenth is a short, named, direct quotation, handled as a quotation on purpose — everywhere else, credit goes to the idea, never to the sentence that first expressed it.

---

1. Panaversity — Graph Engineering: A Crash Course

agentfactory.panaversity.org

This is the course whose scope this project measures itself against: it walks through roughly a dozen and a half concepts spread over seven parts, and that shape told us how much ground a graph-engineering curriculum needs to cover to be complete rather than a sampler. We treated it strictly as a map of what to teach, never as a script for how to say it — every explanation, example, and diagram in this repository was built independently from the concept list, not adapted from its prose.

2. Panaversity — Loop Engineering: A Crash Course

agentfactory.panaversity.org

Before a reader gets here, this material assumes they already know how a single automated loop behaves — its heartbeat, its spine, and the maker/checker split that keeps one loop honest. We lean on that shared vocabulary instead of re-teaching it, which is what lets this course start from "now put more than one loop in the room" rather than from first principles.

3. Panaversity — Harness Engineering: A Crash Course

agentfactory.panaversity.org

The second prerequisite hands us a vocabulary for keeping a single agent inside its lane — constrain, inform, verify, correct, escalate. Graph Engineering doesn't replace that vocabulary; it gives those same five moves somewhere durable to write their results, so a fact one agent verifies can be trusted by another agent that never ran the check itself.

4. Andrej Karpathy — autoresearch

github.com/karpathy/autoresearch (MIT)

The idea we took from this project is a discipline more than a design: log every attempt a system makes, discard nothing, but only let the runs that actually improved on their predecessor become the record future attempts build on. That ratchet — history that only moves forward — is what keeps a long-running graph from either losing hard-won progress or accumulating every false start as if it mattered equally.

5. Andrej Karpathy — AgentHub (sketch)

referenced via companion coverage; original repo no longer public

Even known only through secondhand description now, the mechanism worth keeping is clear: a branch of exploration that fails doesn't have to disappear. Turned into a node that later work can still query, a dead end stops being wasted effort and becomes evidence — proof that a particular path was tried and what it produced, available to anything that asks.

6. Anthropic — Knowledge Graph Construction Cookbook

platform.claude.com/cookbook

What this source demonstrates is that turning unstructured text into graph-shaped facts doesn't require a dedicated natural-language-processing pipeline — asking a capable model for structured output, against a schema you define up front, does the same job with far less machinery. That schema-first move is the extraction mechanism this course teaches as the default, rather than the classical NLP techniques it displaces.

7. Anthropic — Dynamic Workflows in Claude Code

code.claude.com/docs

This source names the exact scale problem this entire course exists to answer: a session that fans out into many sub-agents running in parallel, each one starting with no memory of what the others have already found or decided. That gap between "many workers" and "one shared understanding" is the problem a graph is built to close, and it's the reason this course treats memory as infrastructure rather than an afterthought.

8. Carlos E. Perez — "From Loop Engineering to Graph Engineering?"

essay

The contribution we credit here is a diagnostic frame: a single loop, however well built, tends to fail in a small number of recognizable ways once it's asked to coordinate with others or hold state across time. Naming those failure modes is what makes the case that the fix isn't a smarter loop — it's governance structure sitting around the loop, which is exactly what a graph of nodes and edges provides.

9. Peter Steinberger — public statement, mid-2026

attributed quote

The practice this course teaches didn't start as an abstract design exercise — it started as someone naming, plainly, why a habit they'd already adopted mattered. That statement is quoted directly below, in the person's own words, because paraphrasing it would blur the one thing worth preserving exactly: the motivation in the voice that first stated it.

"the exact quoted words go here" — Peter Steinberger

BLOCKED: need the real Peter Steinberger quote text and its exact source URL/date from the user before this file can be finalized. No quote has been fabricated; the marker above is a placeholder only, flagged for resolution at the Day 1 checkpoint.

10. Panaversity — agentfactory-labs companion repo

github.com/panaversity/agentfactory-labs/tree/main/crash-course/graph-eng

What we took from this repository is structural, not literal: proof that a companion set of small, runnable, dependency-free demos belongs alongside a course like this one, so a learner can execute an idea instead of only reading about it. Every live lab in this course is written from scratch against our own scenarios — none of this repository's code is reused — but the decision to ship labs at all, and to keep them minimal enough to run without a heavy setup, follows the precedent this companion repo set.

---

Placeholder attribution identity for this repository: Graph Engineering Course Contributors, pending confirmation of a real identity before publishing (see CITATION.cff).

Anti-Patterns

Hook

None of the mistakes below show up as a stack trace. Each one is a graph that keeps running, keeps answering queries, and keeps looking healthy on a dashboard — while quietly becoming useless or actively wrong. This page collects them by the layer they live in, so a team can name what's actually broken instead of reaching for a generic "the graph feels off."

Explanation

Three layers, three different kinds of damage:

• A design anti-pattern is a structural flaw baked in at build time — the graph itself is unsound.
• A governance anti-pattern only appears once more than one loop shares a graph, and lives in the missing edges between loops, not in either loop's code.
• A judgment anti-pattern isn't a flaw in any graph at all — it's reaching for a graph, or trusting one, in a situation that called for something else entirely.

Fixing the wrong layer doesn't help: adding a counter-metric to a loop won't repair a graph with no schema, and a tighter schema won't stop a team from treating a two-month-old claim as gospel.

Design anti-patterns

• No schema before extraction. Let an extraction prompt invent entity and relationship types as it goes, and every later query has to reverse-engineer which of several inconsistent shapes a node happens to use — before it can even ask its real question.
• Silent, irreversible merges. A resolution step that folds two mentions into one node and throws away which mentions they were removes the only way anyone later learns the merge was wrong. A bad merge becomes the permanent record.
• Edges with no provenance. An edge nobody can trace to a source document or extraction run can't be defended when challenged. A team either trusts it on faith, or treats the whole graph as suspect the day one edge turns out false.
• A subgraph big enough to be "the whole graph again." Widening a task-scoped slice past what the task needs doesn't inform a worker better — it just reintroduces the cost a subgraph exists to avoid.
• A checker that trusts tone over evidence. A checker that approves a claim because the prose reads confidently will approve a confidently written false claim just as readily as a true one. That's theater, not verification.

Governance anti-patterns

• A loop grading its own metric with no counter-signal. A loop that only consults the number it's optimizing has no way to notice the day that number and the actual goal come apart — from where it sits, the two still look identical.
• Every loop checking only its neighbors, with no anchor to outside reality. A ring of loops validating only each other can reach total internal agreement on something false, because nothing in the ring answers to anything the loops didn't produce themselves.
• No frozen nodes, so a loop can rewrite the rule it's judged by. Leave a success threshold editable by the same loops it grades, and "did we get better" becomes a question those loops can answer however they like.
• Two loops racing on the same resource with no arbitration edge. Two individually sound loops that both assume exclusive claim to something will occasionally collide, and without a recorded precedence rule, the outcome depends on whichever one happened to run first that day.

Judgment anti-patterns

• Building a graph for a job a spreadsheet already does. A schema, an extraction pipeline, and a resolution step are real, ongoing costs. Paying them for a small, fixed relationship set that never grows just means maintaining infrastructure a plain table would have handled for less.
• Treating the fact graph as permanent truth instead of the team's current best understanding. A fact graph is a snapshot of what's been checked so far, not a verdict that closes the question. A team that stops re-examining old claims will eventually build new work on one that quietly stopped being true.
• Letting the work-history graph and the fact graph blur into one. Once every attempt and every checked claim live in one undifferentiated graph, neither question can be asked cleanly — "what did we try" gets polluted with unverified claims, and "what do we actually know" gets buried under ordinary attempts.

Related

• failure-modes.md — the compact reference for the four ways a single loop fails itself, which sit one level below the governance anti-patterns here.
• safety.md — operational risks to a shared graph that go beyond any one anti-pattern above.