What Graph Engineering Actually Is: Tracing a Viral Quote to Its Source

Hello, this is Ryuta Hamamoto from TIMEWELL.

Someone showed me a screenshot of a post going around. It attributes a line to Andrew Ng, who helped start Google Brain: "Prompting will be dead in six months. Loops and graphs are what's replacing it." From a two-hour lecture at Stanford, according to the caption.

Graphs are core to what we build, so this is a quote I have every incentive to repeat. Which is exactly why I checked it first. The result, up front: I could not trace it to a primary source.

I went looking for the source and did not find one

Several accounts carry the same claim. Lined up next to each other, though, the wording does not match.

"Prompting will die in 6 months. The best AI engineers already build self-improving loops." "Prompting will be dead in 6 months, graphs are what's replacing it." "In 3-6 months, everyone will be using self-improving loops. No more prompting."

What replaces prompting changes from post to post: loops, graphs, or both. People quoting the same line from the same lecture do not usually diverge like that. It reads like a game of telephone. I checked Ng's own account, DeepLearning.AI's output and Stanford's announcements, and found nothing corresponding to this quote¹.

Let me be careful here. Not finding it is not proof that he did not say it. It was not within my reach to verify, which is all I can claim. But quoting something unverified as though it were verified puts everything downstream on soft ground.

Here is what I could confirm. DeepLearning.AI does have a course called "Agentic Knowledge Graph Construction," built with Neo4j. The instructor is Andreas Kollegger of Neo4j. Andrew Ng is not the instructor². The content: using Google's Agent Development Kit, you design a set of agents that extract nodes and relationships from structured and unstructured data, and build a knowledge graph for identifying the root cause of product issues. Three hours eight minutes, twelve video lessons².

What is verifiable as Ng's own position is the set of four design patterns for agentic workflows he laid out in 2024: Reflection, Tool use, Planning and Multi-agent collaboration³.

So whatever the status of the viral line, the shift toward building with graphs is real enough to check. The rest of this article is about the substance.

What graph engineering actually is

In one sentence: designing data as nodes (things) and edges (relationships), so that relationships themselves become the object of search and reasoning.

Picture ordinary RAG. You turn the question into a vector and retrieve similar text. It works well, but there is one thing that approach does not carry: how documents connect to each other.

An example makes it faster. Ask "who is the parent company of the parent company of Company A?" Vector search returns documents that are similar and contain the phrase "parent company." With luck, one of them happens to contain the answer. But the act of walking from A to B and from B to C is nowhere in the similarity calculation. Being similar and being connected are different pieces of information.

A graph works differently. Start at the node for Company A, follow the "is parent of" edge to B, follow it again to C. You are not finding the answer, you are assembling it. There turn out to be a lot of practical situations where that difference decides whether you get an answer at all.

The core of the work is schema design. Which node types do you define (company, person, product, matter, regulatory provision), and which relationship types (owns, supplies, approved, references). Get this wrong and no model you put on top will save it. I suspect that course centres on "having agents extract nodes and relationships" precisely because design and extraction is where the effort actually goes.

What happens when you skip the schema? The common failure is collapsing every relationship type into one: "is related to." Record that A relates to B and you can no longer tell whether A owns B, supplies B, or merely appeared in the same document. A graph whose edges carry no meaning is, in the end, a pile of points. The reverse is also true: the moment you separate relationship types properly, the range of questions you can walk expands sharply.

The other thing people miss is time. Ownership and supply relationships have a start and an end, and the answer depends on when you ask. Without a validity period on the edge, you will make today's decision on a shareholding that was unwound three years ago. Someone will eventually ask to see the graph as it stood at a past date. It is cheaper to build that in at the start.

If you want to know where your organisation currently sits on AI adoption, the AI readiness check gives you a baseline before the second half of this article.

"Loops and graphs" are two different layers

What makes the viral post confusing is that it puts loops and graphs side by side. They are not the same layer.

Graphs are about the structure of knowledge: the form in which a system holds what connects to what. Loops are about control of execution: not stopping at one output, but evaluating the result and going round again. In Ng's four patterns, Reflection sits closer to the loop side and Planning closer to the graph side³.

Designs that use both obviously exist, but "prompting is being replaced by loops and graphs" compresses two different layers into one subject. My own reading, closer to how this looks in implementation, is that prompting does not die; where the prompt lives changes. Instead of a human typing a long message into a chat box every time, graph structure and loop control take on most of that job. The prompt itself stays, inside the system.

Export control was always a graph problem

This is the part where we actually do the work.

Counterparty screening in export control is structurally a graph problem. Not as an analogy. The rules themselves have that shape.

The clearest case is the US BIS 50 percent rule. It does not look only at subsidiaries in which a listed party holds 50 percent or more directly; it aggregates ownership. So your counterparty may not be listed, and still be affected because a listed party sits somewhere up the shareholder chain. That is a reachability check along ownership edges, exactly. The rule and worked examples are in the complete guide to the BIS 50 percent rule.

Identifying a beneficial owner has the same shape. You climb through layers of entities until you reach a natural person. I covered that in what a beneficial owner is.

Neither can be solved by document similarity, as a matter of structure. Ask "is this company risky?" and get back similar documents, and you still have not traced the ownership chain. You have to walk the edges.

That is why our export control AI agent TRAFEED is built on a knowledge graph. It holds over 200 million nodes, including 90 million papers, 100 million patents and 300,000 researchers, and surfaces a counterparty risk view in five seconds. A joint validation with Okayama University using roughly 30,000 past review records confirmed AI determination accuracy of 95% or higher (our own study). It holds Japanese Patent No. 7862062 and is used by more than twenty organisations. Under Japan's Foreign Exchange and Foreign Trade Act, though, the final classification decision rests with your export control manager. Use the output as supporting evidence. That line is fixed by the framework.

Your internal knowledge is connected too

Export control may look like an extreme case. Internal documents are the same.

A specification belongs to a matter, which is tied to a customer, written by someone, passed through some review, and connected to some defect report. All of that was connected at the moment it was written. Put it in a folder and vectorise it, and the lines disappear. You get similar documents back, but you cannot answer "has a case with this same root cause happened before?"

The version I hear most often from manufacturers has exactly this shape. "I'm fairly sure another division solved this same defect five years ago." The person feels it, but search does not surface it. The report from back then still exists; what does not exist anywhere is the line connecting that report to today's case. One customer put it as: the line disappears the day the person leaves.

ZEROCK uses GraphRAG to keep those lines. It runs on AWS servers in Japan, with control over who can reach which knowledge, and holds the material in a form you can traverse. Access control and graphs suit each other rather well, because who may see which node is itself expressible as an edge. Departments and permissions are relationships in the end. For a closer look at how RAG and GraphRAG differ, there is a more technical breakdown in 20 frequently asked questions about RAG and GraphRAG.

Two things you can try today

After all that, the starting points are unglamorous. Two of them.

One: draw a schema on paper. Write down five "things" that appear in your business and five "relationships" between them. Company, product, matter, person, regulation. Owns, supplies, approves, references, violates. That alone shows you where relationships are not being recorded in the data you hold. In most companies, the relationships live only in email, in meetings, and in somebody's head.

Two: write ten questions that ask about relationships, and put them to your current search. "List every product that uses this component." "Which past matters had a similar defect at a customer in this industry?" "Walk this counterparty's shareholders and tell me whether a listed party is up there." The questions it cannot answer mark where you need a graph.

Back to the quote. I could not verify that line. I still think the move toward building with graphs is real. Doubting a viral sentence and taking the technology behind it seriously are compatible positions. For a company selling into compliance, they have to be. Redesigning your systems on the strength of something you could not verify is the worst version of this.

Whether the subject is putting internal knowledge back into a graph or building export control on one, the fastest route is hearing the specifics of your situation. You can reach us here.

---

Footnotes

1. The posts examined for this article, carrying the claim that prompting will be dead within six months, circulated from several accounts between July and August 2026. What supposedly replaces prompting is inconsistent between them: some say "self-improving loops," some say "graphs," some list both. As at the time of writing (9 August 2026), no primary source corresponding to this quote could be found on Andrew Ng's own account, in DeepLearning.AI's output, or in Stanford University's announcements. This is a record that verification failed, not a claim that the statement does not exist. Individual URLs for the circulating posts are not listed here, as they include engagement-driven reposts. ↩

2. DeepLearning.AI, "Agentic Knowledge Graph Construction." Built in partnership with Neo4j; the instructor is Andreas Kollegger, Lead for GenAI Innovation at Neo4j. The course uses Google's Agent Development Kit (ADK), Cypher and Neo4j to design a multi-agent system that extracts nodes and relationships from structured and unstructured data and builds a knowledge graph for identifying the root cause of product issues. Level: intermediate; length 3 hours 8 minutes; 12 video lessons, 8 code examples, 1 graded assignment. Andrew Ng is not the instructor of this course. https://www.deeplearning.ai/courses/agentic-knowledge-graph-construction/ — the same catalogue also lists "Knowledge Graphs for RAG" (also taught by Andreas Kollegger) and "Agentic AI" (taught by Andrew Ng): https://www.deeplearning.ai/courses ↩ ↩²

3. The four design patterns for agentic workflows that Andrew Ng set out on his own account in March 2024: Reflection, Tool use, Planning and Multi-agent collaboration. https://x.com/AndrewYNg/status/1773393357022298617 ↩ ↩²