Thinner Agents on a Smarter Substrate: The Ontology-based Semantic Layer

What does an agent need to open a bank account? Beyond deciding what to do next, it needs to know which data can support each decision. Emil Eifrem introduces this problem from Neo4j’s work with large enterprises, where he says it had become increasingly visible over the preceding six to nine months.

The account-opening example starts with a deliberately simplified agent containing two parts:

• Business logic: interpret intent, plan, act, and repeat.
• Data sources: identify the information the task requires, locate it, and make it available to the agent.

Not every action operates on data, but access to the right data at the right time is a large part of making the agent useful.

For identity validation, the agent might consult the Department of Motor Vehicles registry and a passport verification service. Wire those sources into the account-opening workflow and the agent can do its job. Meanwhile, other teams build agents of their own, each with a similar division between business logic and source integration. The first implementation works; the difficulty appears as that pattern spreads.

Discovery comes first. In a startup with one application backed by one Postgres database, locating the data is straightforward. Eifrem contrasts that with an illustrative enterprise containing 100 databases, Snowflake, Databricks, and S3 buckets. Every team must work out which parts of that estate its agent needs.

Trust comes next. Finding a dataset does not establish that it is the correct copy, the right version, or a source the agent is allowed to access. Enterprise duplication turns source selection into a question of authority and permissions as well as location.

Maintenance repeats the same work. If each agent encodes its own source mappings, a change to a source forces teams to revisit every affected integration. This violates the DRY principle—Don’t Repeat Yourself—at the boundary between business intent and data access.

Experience stays isolated. When the knowledge connecting intent to sources lives in individual agents’ code and prompts, a successful execution does not by itself improve the next invocation. Nor does it teach another team’s agent which source worked in that context. The missing piece is a shared place to retain and use that experience.

Markdown files and skills can capture some of this knowledge. Eifrem describes teams trying that approach, but treats it as a component of the solution rather than the whole architecture. He invokes Swyx’s advice on a recent Latent Space podcast to learn databases rather than rely exclusively on Markdown files.

Drawing on work with an unnamed Fortune 20 global bank, a large Bay Area technology platform, and a leading fintech, Eifrem proposes thin agents on a smarter shared substrate. The agent still handles its task, but the organization stops rebuilding the same knowledge of data sources inside every agent.

The shared layer has three pillars. The first is a business-facing ontology: the concepts people in the organization use and the relationships between them. Although the term has attracted attention through Palantir and AI, the starting point is simple. For a bank, it includes customers, accounts, debit cards, checks, and transactions. Names should make sense across the company: a customer has a first name, regardless of whether a database happens to call its column F_name.

The second pillar is a technical ontology describing data assets, their locations, and their schemas. Eifrem’s illustrative inventory includes 14 Oracle databases, 15 Neo4j databases, Snowflake, Databricks, and S3 buckets. This layer describes where information physically resides. He mentions three ways of constructing it but leaves those methods outside the talk.

The connection between these ontologies makes them useful together. The business concept of a customer’s first name maps to its system of record: an Oracle database column named F_name. An agent can start with the business meaning and follow the mapping to the relevant storage detail.

A small Cypher representation makes that relationship concrete:

CREATE (customer:BusinessConcept {name: 'Customer'})
CREATE (firstName:BusinessProperty {name: 'first name'})
CREATE (oracle:DataAsset {kind: 'Oracle database'})
CREATE (column:Column {name: 'F_name'})
CREATE (customer)-[:HAS_PROPERTY]->(firstName)
CREATE (oracle)-[:HAS_COLUMN]->(column)
CREATE (firstName)-[:HAS_SYSTEM_OF_RECORD]->(column);

Here, the node labels and relationship names express the example as a graph. The essential feature is the explicit link from business meaning to the authoritative physical field.

The third pillar is runtime execution traces. As agents traverse the graph and act, they record what they attempted, whether it succeeded, and what outcome followed. In this blueprint, those records supply feedback about how the mappings work in practice; retaining and using them is an additional mechanism, not an automatic consequence of defining an ontology.

Return to account opening. The graph contains business concepts such as checks, accounts, and credit history, but it also encodes the business process itself. This matters because the agent is process-guided: it should follow the required workflow, not merely retrieve related information.

The compliance step connects business intent to technical options:

1. Reach Check Compliance, the node highlighted in green in the diagram.
2. Follow its requirement to resolve a government-issued ID.
3. Discover the two available sources: Motor Vehicle Records and Passport Verification.

The agent now has a graph path explaining why those sources are relevant to its current step. Their relevance no longer has to be reconstructed independently inside each agent.

When the agent tries a source, it leaves a trace containing its position in the graph, the action it took, its context, and whether it succeeded. Eifrem notes that the actual traces are richer than the simplified slide. These records connect an execution outcome to the circumstances in which a source was used.

Those observations can feed a score used in subsequent source selection. If DMV lookups have been successful, a later invocation becomes more likely to select that path when the context is appropriate. The feedback changes a future choice; it does not make the DMV source preferable in every situation. Eifrem describes this mechanism without specifying a scoring formula or reporting a measured learning gain.

Together, the business ontology, technical ontology, and execution traces are intended to address the original four problems. Discovery becomes a traversal from a business concept to candidate sources. Trust draws on two kinds of evidence: top-down knowledge curated by an administrator and bottom-up observations of what actually worked during execution.

A single governed mapping also changes the maintenance boundary. Instead of editing source knowledge in every agent, teams update the shared relationship between business intent and data. Agents using that mapping can then pick up the change. Execution feedback can likewise inform both the agent that produced it and other agents using the same layer.

This is the shift from thick agents containing manually wired source knowledge to thin agents using an ontology-based semantic layer. The intended scaling benefit is less repeated engineering as the organization adds agents. The shared mappings and feedback still have to be built and maintained; moving them into a common layer makes that work reusable. Eifrem points to further documentation through a QR code on the slide.

For further discussion at the conference, Eifrem directs attendees to Neo4j’s booth P3. He places this architecture among a much broader set of graph-and-AI patterns, describing hundreds of possibilities and pointing to ten represented in the graph track in Room 2005. The named organizations include The Gates Foundation, monday.com, JPMorgan Chase, Berkeley, and The New York Times.

The scope of the architecture remains specific: organizations with many data sources and many agents, where repeated discovery and integration become substantial work. For startups building on Neo4j, Eifrem closes with a separate invitation to the Neo4j startup program. He describes free credits and a dedicated solution engineering team working with startups for free on data modeling and performance tuning—the practical work of making the underlying graph useful.