AI Engineer World's Fair 2026
Thinner Agents on a Smarter Substrate: The Ontology-based Semantic Layer
Slide chapters
19 slide and demo groups · Timestamps are approximate. 1 additional group was omitted from this pass.
Read the talk
Thinner Agents on a Smarter Substrate
A bank-account-opening agent shows how a shared ontology can connect business intent to enterprise data, centralize source mappings, and reuse execution feedback across agents.
From a talk by Emil Eifrem
Before you start: Familiarity with agent tool use and database schemas is helpful; no prior knowledge of ontologies or graph databases is required.
Opening an account means finding the right data
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
The costs accumulate across agents
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Connect business meaning to physical sources
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:
cypher
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Follow the compliance check through the graph
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:
- Reach Check Compliance, the node highlighted in green in the diagram.
- Follow its requirement to resolve a government-issued ID.
- 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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Govern the mapping and share the feedback
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.
| Concern | Per-agent wiring | Shared semantic layer |
|---|---|---|
| Discovery | Locate sources for each agent | Follow business-to-source mappings |
| Trust | Assess sources separately | Use curated knowledge and traces |
| Maintenance | Rewire affected agents | Update the governed mapping |
| Learning | Experience remains local | Reuse feedback across agents |
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Beyond the enterprise account-opening example
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
Program application, eligibility requirements, Aura credits, and graph-engineering guidance for startups.
Further reading
The startup engineering team's launch announcement describes help with graph schemas, retrieval architecture, and production scaling.
Updates since the talk
Eifrem's companion essay expands the talk into an executable enterprise knowledge layer and describes incremental adoption.
Jesús Barrasa explains ontology mappings, source discovery, governance, and shared memory for enterprise agents.
Read the complete timestamped transcript
19 slide groups. Extracted from the recording; expand builds to follow changes. Timestamps are approximate. 1 additional group was omitted from this pass.
- 0:00
[on-hold jingle] All right. At Neo4j, we work with some of the largest companies in the world to help make their data ready for AI agents.
- 0:21
And today, I wanna talk to you about a problem that we saw emerging over the last, call it, six to nine months, and propose a solution blueprint for that.
- 0:31
So let's say that we work at a big organization, a big bank, and we wanna write an agent. Let's say that agent is helping automate the opening of a bank account.
Thinner Agents on a Smarter Substrate
The talk introduces an ontology-based semantic layer and uses a bank account-opening agent as its example.
Text in image
neo4j Thinner Agents on a Smarter Substrate The Ontology-based Semantic Layer
- 0:42
Right? You can imagine that's very ripe for automation. You want to be able to orchestrate that process. And I'm gonna use the powers bestowed upon me by a short keynote slot to grossly simplify what that agent looks like.
- 0:55
I'm gonna say there's two pieces. The first one is, let's call it the business logic. Some version of interpreting intent and plan, act, and we loop around that. It's what your agent does.
- 1:06
And we know that when an agent act, it doesn't always operate on data, but we equally know that in order for agents to be successful, a huge part of that is giving it access to the right data at the right time.
- 1:18
So the second big bucket is, let's call it the data sources. Need to identify, figure out, okay, in order to solve my problem, I need access to these few things, and wire them up and make them available to the agent.
- 1:31
In the example of our account opening agent, maybe we can imagine that we need to be able to validate identity, and so we might look at two data sources for that, the Department of Motor Vehicles, the DMV registry, and maybe some kind of passport verification service.
Account Opening Agent and Data Sources
An account-opening agent needs both business logic and access to data. Motor vehicle records and passport verification are possible sources for validating identity.
Text in image
Account Opening Agent "Business Logic" (Plan, Act, Loop) "Data Sources" (Find, Assess, Resolve) Motor Vehicle Records Passport Verification
- 1:46
So we wire that up into our agent, and it works. It's great. It's fantastic, and at the same time, you and other teams in your organization are building other agents, and conceptually, they look very similar.
Agents and their data sources
Each agent embeds its own business logic and data sources. The account-opening example uses motor vehicle records and passport verification; other teams build similarly structured agents.
Text in image
Account Opening Agent "Business Logic" (Plan, Act, Loop) "Data Sources" (Find, Assess, Resolve) Motor Vehicle Records Passport Verification
Show 2 builds
- 1:46
Business logic and data sources appear inside an account-opening agent, with motor vehicle records and passport verification below.
Text in image
Account Opening Agent "Business Logic" (Plan, Act, Loop) "Data Sources" (Find, Assess, Resolve) Motor Vehicle Records Passport Verification
- 1:52
Three agents each contain business logic and data sources, with example services below.
Text in image
Account Opening Agent "Business Logic" (Plan, Act, Loop) "Data Sources" (Find, Assess, Resolve) Motor Vehicle Records Passport Verification AML Investigation Agent "Business Logic" (Plan, Act, Loop) "Data Sources" (Find, Assess, Resolve) Service C Service D Customer Service Agent "Business Logic" (Plan, Act, Loop) "Data Sources" (Find, Assess, Resolve) ... ...
- 1:46
- 1:58
So that's great. It's fantastic. It works. But it has a few problems. So first of all, every single time a team has to build an agent, they have to figure out from scratch where the data that they require for that agent to operate, where it sits, which if you work at a startup, and you have one application
- 2:17
that sits on top of one Postgres database, that's not hard. The data is in that Postgres database. But in an enterprise ecosystem, you don't have one database, you have 100 databases, and you have Snowflake and Databricks probably, and you have S3 buckets, and so on and so forth.
- 2:32
You have to do that work manually from scratch every single time. And then when you've found the data sources, you know, in an enterprise, there's lots of duplication of data.
- 2:41
So then you need to figure out, like, is this the right data? Is it the right version? Can I trust it? Am I allowed to, uh, access it? So on and so forth.
Great! Or is it...?
Each agent builder must find and assess data sources from scratch. Changes require updates across agents, while knowledge about those sources does not carry over between them.
Text in image
Great! Or is it...? Discovery: every agent builder has to find all the data services from scratch Trust: is the data current, am I allowed to access it, is it versioned Violates DRY: when things change, you have to update everywhere Learning: no agentic self-learning, no learning across agents
- 2:49
It also violates one of the core principles of software engineering, the DRY principle, Don't Repeat Yourself. So when something change, that cascades across all of your agents. You have to kind of manually rewire all of them all the time, which works, but it's just a, a lot of work.
- 3:06
And then finally, there's no learning around the data sources and how your agents operate on them. So when your agent wake up-- wakes up tomorrow, it's not smarter than it was today, and there certainly isn't any cross-agent learning because all of that wiring between business intent and the data sources is encoded in a combination of code and
- 3:25
prompts. So I know what you're all thinking, "Markdown files, skills to the rescue." And yes and no. Um, you can come talk to me afterwards for kind of the full version of this, but we've seen a ton of team that tried to solve this problem using just Markdown files.
Markdown to the rescue! Or is it...?
The speaker says teams have tried to solve the data-source problem with Markdown files, but Markdown is only part of the solution.
Text in image
Markdown to the rescue! Or is it...?
- 3:41
And the summary is, it is part of the solution, but it is not the solution. Uh, but don't take it from me, take it from Swyx. A week ago on the Latent Space spo-- podcast, he said, "Hey, guys, you gotta learn your databases.
Learn your databases
The speaker calls Markdown part of the solution and cites swyx’s warning: developers need to learn their databases, because Markdown files alone are insufficient.
Text in image
databases, guys. You cannot vibe code with just markdown files. “Learn your databases. You can't vibe code with just markdown files.” – @swyx, Latent Space pod, June 24 2026
- 3:55
You cannot vibe code with just Markdown files."
Organizations using the approach
The speaker says his team has been solving this problem at scale for a Fortune 20 global bank, a Bay Area tech platform, and a leading fintech.
Text in image
F20 Bank Global Tech Platform Leading Fintech
- 4:00
So we've been solving this problem at scale for some really massive organizations recently, including a Fortune twenty global bank, a massive tech platform company based here in the Bay Area, and a leading fintech company.
- 4:16
And the pattern that is emerging is that in order to do agents at scale, we need thin agents on a smarter shared substrate. Thin agents on a smarter shared substrate.
Thin agents on a smarter shared substrate
The speaker describes thin agents on a smarter shared substrate as an emerging pattern for scaling agentic AI across large organizations.
Text in image
To do agentic AI at scale, we need thin agents on a smarter shared substrate
- 4:31
And what does that look like in practice? There are three pillars to that. The first pillar is a business-facing ontology. And the word ontology, like, I grew up in this world, people talked about ontologies forever.
- 4:43
More recently, it's become very hype, probably thanks to Palantir, but also the rise of AI, and there's a lot of people that wanna make ontologies really complex. But the core concepts are actually super simple.
- 4:54
What are the key concepts in your organization? In our banking example, customers, accounts, um, debit cards, checks, transactions, and how do they all relate? But very importantly, they are expressed in a way that makes sense to all the human beings working in your universe, right?
- 5:14
All the people working in your company, it's expressed in that name, in that way. In other words, you don't say, "F_name." No, you have a customer, and they have a first name.
- 5:25
So that's the first, a business-facing ontology. The second pillar is a technical ontology. This is all the metadata of all the data sources and data assets in your enterprise ecosystem.
- 5:36
I have 14 Oracle databases, I have 15 Neo4j databases, I have Snowflake and Databricks, and I have S3 buckets and all of that kind of stuff. Where do they sit?
- 5:47
What are the schemas? All of that kind of good stuff. You con- you construct that tech- technical ontology in three key ways that we can talk about later, though not in this, in this talk.
- 5:57
And then you have the mapping between the two. So that customer that has a first name, that first name has a system of record, and over there, there's an Oracle database with a column called F_name.
- 6:08
The mapping between the two. And then the third pillar is the runtime signals out of your agents. When they walk this graph and they execute, they leave the traces around what have I tried, was I successful, what was the outcome, the execution traces.
Ontology-based semantic layer
The semantic layer maps business concepts to the systems and data that represent them. Execution traces add runtime signals about agent decisions, paths, outcomes and errors.
Text in image
Ontology-based Semantic Layer A Business-facing Ontology A simple description of the real world concepts of your business and how they relate, articulated in a way that makes sense to (human) users A Technical Ontology The metadata of your data asset landscape: where data lives, the schemas and attributes, and physical locations Execution Traces Runtime signals from agent execution, including decisions, paths, outcomes and errors
- 6:25
Those three pillars. Okay, so let's look at that in the context of our bank account opening agent. This is a simplified view, but you can see this graph here, it has a combination of business concept like checks and accounts and credit history and stuff like that.
Account opening agent ontology
The business ontology maps the account-opening process. The technical ontology connects compliance checks to government-issued ID and two sources: motor vehicle records and passport verification.
Text in image
Account Opening Agent A Business-facing Ontology What the org does, who does it, and what agents are asked to perform Account Opening → Onboarding: START Onboarding → Check Compliance: NEXT Account Opening → Check Compliance: ACTIVITY Check Compliance → Check Credit History: NEXT Account Opening → Check Credit History: ACTIVITY Check Credit History → Create Account: NEXT Account Opening → Create Account: ACTIVITY Create Account → Issue Debit Cards: NEXT Account Opening → Issue Debit Cards: ACTIVITY Issue Debit Cards → Order Checks: NEXT Account Opening → Order Checks: FINALIZE
Show 2 builds
- 6:27
A graph connects account opening to onboarding, compliance, credit history, account creation, debit cards and check ordering.
Text in image
Account Opening Agent A Business-facing Ontology What the org does, who does it, and what agents are asked to perform Account Opening → Onboarding: START Onboarding → Check Compliance: NEXT Account Opening → Check Compliance: ACTIVITY Check Compliance → Check Credit History: NEXT Account Opening → Check Credit History: ACTIVITY Check Credit History → Create Account: NEXT Account Opening → Create Account: ACTIVITY Create Account → Issue Debit Cards: NEXT Account Opening → Issue Debit Cards: ACTIVITY Issue Debit Cards → Order Checks: NEXT Account Opening → Order Checks: FINALIZE
- 6:57
A technical ontology links compliance checking and government-issued ID to motor vehicle records and passport verification. The lower graph is cropped.
Text in image
Account Opening Agent A Technical Ontology A live model of the systems and data assets required for your agents to execute Check Compliance → Government Issued ID Government Issued ID → Motor Vehicle Records: SYSTEM_OF_RECORD Government Issued ID → Passport Verificataion: SYSTEM_OF_RECORD Onboarding → Check Compliance: NEXT
- 6:27
- 6:41
This is a process-following agent or a process-guided agent. We want this type of agent to actually follow a process. We've also encoded that in the ontology, a business process.
- 6:52
And then if you look at the node that is surrounded by green, the check compliance one, we flip to the technical ontology, and we've put in the graph here, we've discovered and encoded that in order to do a compliance check, you might imagine that you need to resolve a government-issued ID.
- 7:09
And then we say that in this particular organization, there are two data sources that can help us with that. It's the motor vehicle records and the passport verification one.
- 7:18
Okay, so that's really great. So then when our agents come in here and they realize, "I'm gonna check compliance, I need a government-issued ID," here are the two ways that I can resolve that.
- 7:29
When they execute and they try that, they leave, the third pillar, the execution traces for that. And they're more sophisticated than what's on this simplified slide, but involves things like, okay, where was I, what did I do, what is my context, and was I successful?
- 7:45
And ultimately, it leads out to some kind of a score, and you use that as input. It's like, okay, I've been very successful using the DMV lookup, for example.
- 7:55
Then I'm more likely to choose one if I'm in the right context in my next invocation.
- 8:01
Three pillars of the ontology-based semantic layer, a business ontology, a technical ontology, the execution traces, taken together, they solve all four of the problems. We now have a very easy way to discover the data sources.
Ontology-based semantic layer
Business and technical ontologies combine with execution traces to support discovery and trust. A shared mapping avoids repeated work, while execution traces support learning across agent runs.
Text in image
Ontology-based Semantic Layer Business Ontology Technical Ontology Execution Traces Discovery ✅ Trust ✅ Don't Repeat Yourself ✅ Learning ✅
- 8:14
We know if they're trustworthy or not. We know that top-down by some kind of human curated knowledge, right, an administrator of some sort saying it. We also know it bottom-up through the execution traces.
- 8:25
This is what actually worked in reality, in practice. We have a single governed place that maps business intent and the concepts to those data sources, so we don't repeat ourselves.
- 8:35
If something changes, that cascades across all my agents, right? And we have self-learning. So my agent that wakes up tomorrow is slightly smarter than it was today, and not just self-learning on an individual agent, but across agents as well.
Agents with embedded data-source responsibilities
Each agent carries its own business logic and data-source responsibilities. The speaker describes these as thick agents with manually wired data sources.
Text in image
Account Opening Agent "Business Logic" (Plan, Act, Loop) "Data Sources" (Find, Assess, Resolve) AML Investigation Agent "Business Logic" (Plan, Act, Loop) "Data Sources" (Find, Assess, Resolve) Customer Service Agent "Business Logic" (Plan, Act, Loop) "Data Sources" (Find, Assess, Resolve) Motor Vehicle Records Passport Verification Service C Service D ... ...
- 8:52
So we move from this world, a world of thick agents with manually wired data sources, into this world, where we have thin agents on a smarter, shared ontology-based semantic layer.
An agent using a semantic layer
The account opening agent exchanges information with an ontology-based semantic layer and connects directly to motor vehicle records. The speaker describes a shift toward thinner agents on a shared substrate.
Text in image
Account Opening Agent “Business Logic” AML Investigation Agent “Business Logic” Customer Service Agent “Business Logic” Ontology-based Semantic Layer Motor Vehicle Records Passport Verification
- 9:07
And this allows us to do a ton more agents without having to re-engineer them every time. Thin agents on top of a smarter, shared substrate. If you think this is interesting, there's a documentation, a webpage that outlines more in- information about this, if you see the QR code here.
A shared semantic layer for many agents
A shared semantic layer sits between many agents and services. The speaker says it lets teams add agents without re-engineering them each time.
Text in image
Account Opening Agent "Business Logic" AML Investigation Agent "Business Logic" Customer Service Agent "Business Logic" ... ... ... ... ... ... ... ... ... ... ... ... ... ... Ontology-based Semantic Layer Motor Vehicle Records Passport Verification Service C Service D ... ...
Thin agents on a smarter shared substrate
The speaker argues that a shared ontology-based semantic layer lets teams add more thin agents without re-engineering them each time. The QR code points to more information.
Text in image
To do agentic AI at scale, we need thin agents on a smarter shared substrate Knowledge Layer
Visit Neo4j at Booth P3
The speaker invites attendees to discuss graphs and AI with the Neo4j team at expo booth P3, shown in the photograph.
Text in image
Visit Neo4j @ Booth P3 Neo4j Graph Intelligence Platform Context graphs & memory Microsoft
- 9:28
You can also come and talk to us at the booth. We have a big booth here at the expo, P3. We love talking about this, this kind of stuff.
- 9:35
But not just that. This is one pattern, a very exciting pattern that we see a lot of traction around right now for using graphs in AI. But there's hundreds of more interesting patterns that combines graphs and AI.
Graph track in Room 2005
The Room 2005 graph track features ten talks, spanning graph memory, ontologies, anomaly detection and provenance. Speakers include representatives of Neo4j, Berkeley and JPMorgan Chase.
Text in image
Amazing Graph Track in Room 2005 CrabRAG: Automated Assistants Need Graph Memory — Stephen Chin · Neo4j Active Graph Agent Runtime (BabyAGI 4) — Yohei Nakajima · Untapped Capitol Your Moat Is Your Data Model — Mike Phipps · Gates Foundation From Systems of Record to Systems of Context — Omri Bruchim · Monday AI : Learned Execution Graphs for Real-Time Anomaly Detection — Ritvik Pandya · JP Morgan Chase Why Agentic Systems Need Ontologies — Frank Coyle · UCAL Berkeley Video Has No Memory. Here's How We Built One — James Le · Twelve Labs On-Device Agentic AI for the New York Times Games — Shafik Quoraishee, Joanne Song · NYT Citation Needed: Provenance for LLM-Built Knowledge Graphs — Daniel Chalef · Zep AI Why We Killed Our Multi-Agent Pipeline: Lessons From Pharma — Subbiah Sethuraman · ZS
- 9:49
Ten of them is actually in the graph track that is kicking off right now in room 2005. And you have some really amazing talks from organizations like The Gates Foundation, monday.com, JPMorgan Chase, Berkeley, New York Times, and so on and so forth.
- 10:09
So go check out that thing. And then finally, this was primarily centered around organizations where you deal with many data sources and many agents. But if you're a startup building on Neo4j, love you.
Neo4j Startup Program
Neo4j’s startup program offers free credits and free help from solution engineers to model data and tune performance.
Text in image
neo4j Startup? Get credits... Startup Program
- 10:22
There is a startup program for Neo4j that is phenomenal. You get access to free credit, but more importantly, we've built up a dedicated solution engineering team that spend every day working with startups for free, helping them model their data in Neo4j, tune it for performance, and so on and so forth.
- 10:40
So please sign up for our startup program. Thank you very much. Enjoy the conference. Have a good day, everyone. [upbeat music]
AI Engineer World’s Fair
AI Engineer World’s Fair logo on a black background.
Text in image
AI Engineer World’s Fair HTTPS://AI.ENGINEER