Your Semantic Layer Is a Flow

Emil Eifrem — the CEO of Neo4j, the person who has arguably done more than anyone to put graphs under production software — got on stage at the AI Engineer World's Fair and made an argument I agree with almost entirely.

The talk is called Thinner Agents on a Smarter Substrate: The Ontology-based Semantic Layer. The thesis: everyone is building thick agents with manually wired data sources. Every new agent team rediscovers the same databases, re-wires the same connections, re-learns which source to trust. It doesn't scale. The fix is to push all of that down into a shared substrate — an ontology-based semantic layer — so the agents on top can get thin.

He breaks the substrate into three pillars. A business ontology — your concepts in human language, not schema (you don't say f_name, you have a customer with a first name). A technical ontology — the metadata graph over every data asset you own, the fourteen Oracle databases and the Snowflake and the S3 buckets. And execution traces — the runtime signals coming back out of the agents, which accrue into trust: "I've been very successful using the DMV lookup," so next time, in the right context, the agent leans that way. Trust learned bottom-up from what actually happened, not just declared top-down by a curator.

It's a good talk. If you've read anything we've written, the shape will be eerily familiar — because it's the same shape. So let me do the useful thing and say exactly where we agree, and then the one place the argument stops short, and what fills the gap.

The half that's just true

Eifrem is right that the substrate is the move. He's right that the intelligence belongs around the agent, not baked into it. He's right that hand-wiring data into every agent is a dead end, and that the thing you're accumulating — the traces, the trust — is an asset in its own right. He even quotes swyx at the crowd — a line from the Latent Space podcast a week earlier: "You got to learn your databases. You cannot vibe code with just markdown files." We've made every one of those arguments. A company's real advantage is a learning layer it owns, not a model it rents. Reasoning should be done once and reused many times, not re-derived per agent. The model should be one bounded node in a larger structure, never the whole thing.

So this isn't a disagreement post. It's a "yes, and — you stopped one layer too early" post.

The half the talk leaves in the model

Here's the question the three-pillar picture doesn't answer: where does the path live?

Watch what the thin agent actually does in Eifrem's own example. It hits a "compliance check," and then it navigates the ontology — discovers there are two ID-verification sources, reasons about which to use, picks one. That navigation happens at runtime, inside the model. The substrate got richer, but the agent is still the thing deciding where to go next.

That's the black box coming back in through the side door. We made the substrate smart, and then handed the model a smart substrate and said find your own way through it. The path — the sequence of what-reads-what, what-follows-what — is still decided probabilistically, at runtime, unlogged except as another trace. You've bounded what the reasoning can see. You haven't bounded where it can lead.

This is the exact axis that separates flow engineering from agent-building: not how much the model knows, but who draws the path. Enriching the data the agent browses is still agent-building. It's just agent-building with a nicer library.

The prompt was quietly doing three jobs

Step back from Eifrem's talk and ours, and you can see the thing everyone is actually fighting: prompt overload. When a team "just writes it in text and prompts," they are asking one prompt to carry three different concerns at once.

• Instruction — what to do right here: classify this, keep it short, use this tone.
• Knowledge — what's true: which database, which schema, which source to trust, the facts themselves.
• Control — what happens next: check compliance first, then verify ID, loop until done.

A prompt is genuinely good at exactly one of those — the first. It is bad at the other two. Knowledge written as prose goes stale, doesn't dedupe, and never maps cleanly to a system of record. Control written as prose means the path lives in the model's head, chosen probabilistically and logged nowhere.

Seen this way, the two big ideas in agent-land are each taking one job off the prompt:

• Data engineering — Eifrem's move — removes the knowledge job. Stop writing what's true into markdown; engineer it into a queryable substrate. He's right, and it's the under-appreciated half: at enterprise scale you cannot vibe-code the knowledge into files.
• Flow engineering — our move — removes the control job. Stop narrating the path in a prompt; draw it as a graph — nodes and edges, visible before anything runs.

Do both, and look at what's left in the prompt: only the first job. A small, honest instruction doing bounded judgment at a single node. Not everything — just the one thing a prompt is good at.

That's the whole picture, and it's why this can't be a feature you bolt onto an agent. Eifrem takes one job off the prompt. A real agent needs both taken off — and then it needs the two engineered layers plus the shrunk prompt to live in one place, in one material, instead of three disconnected systems you hand-wire together. That is what FloMorphic is for. The rest of this post is the two layers, made concrete.

Layer one: knowledge — two faces of the substrate

Take the knowledge job first — Eifrem's job. FloMorphic removes it from the prompt too, but the substrate has two faces, not one, and the distinction is the whole payoff.

The first face is ambient. It's the organization brain: over a period, everything the company produces gets ingested, cleaned, entity-extracted, embedded, tagged, and kept current. This is Eifrem's ontology, near enough — a persistent, reusable semantic layer that every process can draw on. We've written the whole build-out of it elsewhere, so I won't repeat it here.

The second face is assembled. At the moment a process runs, it doesn't hand a thin agent the entire brain and say go navigate. It builds a context — a scoped, per-frame working substrate holding only the slice this process needs. And the thing that fills it is a query-node: a node that is a database read, a vector lookup, a call into the brain. Many sources, each reached by its own node, all landing in one context object the process iterates over.

Organization brain     ← ambient semantic layer: all data, vectored + tagged
        │
   query-nodes          ← each node IS a query; pull the relevant slice
        │
     context            ← scoped, per-frame substrate the thin agent reads
        │
    thin agent          ← acts on context, not on the whole world

Look at what moved. Eifrem's runtime ontology-navigation became FloMorphic's design-time query-nodes. The "which sources exist, which do I pull" decision that his agent makes in its head, mid-run, is drawn on the canvas before anything runs — as visible edges into the data. What stays dynamic is only which drawn path fires, and what the model does once the relevant context is in front of it. No prompt can invent a third edge — it can only choose among the ones you drew.

That phrase — "not all of data" — is the corridor, applied to the data layer. Eifrem's substrate is ambient: it's all there, always, and the agent wades in. FloMorphic's runtime substrate is assembled: bounded by design to the frame. The reuse doesn't disappear — it lives in the brain. The scoping doesn't disappear — it lives in the context. You get both, on purpose, at two different tiers.

Eifrem's substrate is ambient; FloMorphic's is assembled.

The move he can't make: the layer is a flow

Now the part that isn't just a rearrangement of his boxes.

In Eifrem's world, the semantic layer is a product. It's a thing that sits beside your agents — you stand up the graph, you populate the ontology, you maintain it. It's infrastructure, adjacent to the work.

In FloMorphic, "over a period, all the data is analysed and vectored and tagged" is not a product you install. It's a flow you author. A durable, long-running process — ingest → clean → extract → embed → tag → keep current — that runs on a schedule and on every new event, waits on external systems, survives crashes, and runs for as long as the company runs. Those are precisely the two properties that separate an agent runtime from an automation tool: a real loop, and durable long-running execution. The organization brain is built by the same primitive that later runs on it.

So the whole stack collapses into one material:

• a durable flow generates the semantic layer (the brain);
• query-nodes consume it into a scoped context;
• a thin agent acts on that context, itself a flow;
• its traces feed back into the brain, and the loop closes.

Ingestion, semantic layer, retrieval, action, learning — not five kinds of system wired together, but one kind of thing, drawn five times. Flows all the way down.

Eifrem's semantic layer is a product. FloMorphic's is a flow.

That's the difference between buying the substrate and owning the primitive that makes it. When your sources change — and they will — you don't file a request against a semantic-layer team. You open the flow and change a node, because the layer was never a separate black box; it was always a graph you can read.

The honest trade

I'll concede the thing worth conceding. Eifrem's ontology is reusable across every agent in the enterprise by construction — that's what an ambient global layer buys you, and it's real. FloMorphic's per-frame context is scoped by design, so cross-process reuse is something you compose — shared query-nodes, a plugin, a common slice of the brain — rather than get for free from one global graph.

But that's the same trade we make everywhere: bounded-and-visible over ambient-and-implicit. And it isn't a trade against reuse, because the reuse still exists — it's the brain. It's a trade about where the ambient layer meets the running agent: through a drawn query, at design time, into a scoped frame — not through the model's runtime wandering across everything at once.

One platform, the whole agent

Put the three jobs back together and you can see the shape of an agent that actually scales — and why it wants to be built in one place:

• its knowledge lives in a data layer you engineered — the organization brain, itself built as a durable flow;
• its context is assembled per frame by query-nodes, pulled from that brain, not navigated ambiently;
• its path is a graph you drew — nodes and edges — not prose the model improvises;
• its judgment is a small prompt at a node, doing the one thing prompts are good at;
• and it gets better because its execution traces flow back into the brain and sharpen the next run.

Every one of those is the same primitive: a node on an edge over a durable context. Which is the point. You don't assemble this agent out of a semantic-layer product, plus an orchestration framework, plus an eval harness, plus a vector pipeline — four black boxes, hand-wired, each owned by a different team. You draw it, on one canvas, in one material, where every layer is visible and every layer changes without a redeploy. That is what it means for FloMorphic to be a platform for building agents, not a feature bolted onto one: it is the place all three jobs come home.

Eifrem's talk is really an argument for the data layer. It's a good argument. But an agent is not a data layer with a model on top — it's knowledge, path, and judgment, plus a loop that improves all three. Build only the substrate and you've built a better library. Build all of it, in one legible runtime, and you've built the agent.

The claim, plainly

Eifrem gave the industry a clean articulation of half the future: the substrate is the point, the agents should be thin, and knowledge belongs in an engineered layer — not in prompts. He's right, and coming from him it carries weight.

The other half is that control doesn't belong in prompts either. Take both jobs off the prompt — knowledge into a data layer, the path into a flow — leave the model to judge one bounded step, and do it all in one runtime where each layer is a graph you can read and change. That isn't a better prompt or a better ontology. It's a better place to build the whole agent.

FloMorphic is that place.

Source: Emil Eifrem (Neo4j), "Thinner Agents on a Smarter Substrate: The Ontology-based Semantic Layer," AI Engineer World's Fair, 2026 — youtube.com/watch?v=VGN22pPpb-8. Quotes taken from the talk transcript; the swyx line is quoted by Eifrem from the Latent Space podcast.