Neo4j CEO Emil Eifrem argues that scaling agents in the enterprise requires thin agents on a smarter shared substrate rather than thick agents with manually wired data sources. His proposed blueprint is an ontology-based semantic layer with three pillars — a business ontology, a technical ontology, and runtime execution traces — that together make enterprise data discoverable, trustworthy, and self-improving across agents.
Eifrem frames the talk around a concrete enterprise scenario: a big bank building an agent to automate opening a bank account. He grossly simplifies the agent into two pieces — the business logic (interpreting intent, plan, act, and looping) and the data sources the agent needs access to. For the account-opening agent, validating identity might require wiring in the DMV registry and a passport verification service.
The trouble is that every team building an agent repeats this work. In a startup with one Postgres database the data is easy to find, but in an enterprise you have a hundred databases plus Snowflake, Databricks, and S3 buckets. Teams must rediscover data sources from scratch, then figure out whether the data is the right version, trustworthy, and permitted for access.
This approach violates a core software engineering principle: don't repeat yourself. When something changes, that change cascades across all your agents and you have to manually rewire them. On top of that, there is no learning around the data sources — because all the wiring between business intent and data lives in a combination of code and prompts, an agent that wakes up tomorrow is no smarter than it was today, and there is no cross-agent learning.
Eifrem addresses the obvious objection — 'markdown files, skills to the rescue' — with a qualified yes and no. He has seen many teams try to solve this with just markdown files, and concludes they are part of the solution but not the solution, citing swyx's remark on the Latent Space podcast that you have to learn your databases and cannot vibe code with just markdown files.
Drawing on recent work with a Fortune 20 global bank, a large Bay Area tech platform, and a leading fintech, Eifrem describes the emerging pattern as 'thin agents on a smarter shared substrate,' built from three pillars. The first is a business-facing ontology: the key concepts in the organization — customers, accounts, debit cards, checks, transactions — and how they relate, expressed in terms that make sense to the humans in the company (a customer with a 'first name,' not 'f_name').
The second pillar is a technical ontology: the metadata for every data source and asset — the 14 Oracle databases, Snowflake, Databricks, S3 buckets — including where they sit and what their schemas are, plus a mapping from each business concept to its system of record. The third pillar is runtime execution traces: as agents walk the graph and execute, they leave traces recording what they tried, their context, and whether they succeeded, ultimately producing a score.
Applied to the account-opening agent, the ontology encodes business concepts, a business process the agent should follow, and — at the 'check compliance' node — a flip to the technical ontology showing that resolving a government-issued ID can be done via two data sources: motor vehicle records or passport verification. As agents execute, the execution traces feed back a success score, so an agent that has done well with the DMV lookup becomes more likely to choose it again in the right context.
Taken together, the three pillars solve all four original problems: data sources become easy to discover; trust is established both top-down through human curation and bottom-up through execution traces; a single governed place maps business intent to data so nothing is repeated and changes cascade automatically; and the system self-learns, both per-agent and across agents. The result is a move from thick agents with manually wired data to thin agents on a smarter shared substrate — enabling far more agents without re-engineering each one.
in order to do agents at scale, we need thin agents on a smarter shared substrate
You cannot vibe code with just markdown files.
we don't say f_name. No, you have a customer and they have a first name.
my agent that wakes up tomorrow is slightly smarter than it was today
| Time | Topic |
|---|---|
| 00:00 | Intro: Neo4j and ontology-based semantic layers |
| 00:42 | The account-opening agent: business logic plus data sources |
| 02:43 | Why manual data wiring fails in the enterprise |
| 04:15 | Markdown files: part of the solution, not the solution |
| 04:45 | Thin agents on a smarter shared substrate: the three pillars |
| 06:48 | Walking the graph: the bank example and execution traces |
| 08:20 | Solving all four problems and the graph track / startup program |