Enterprise agents repeatedly rediscover, assess, and wire up data sources because that knowledge is stored inside individual agents.
2
A shared ontology-based semantic layer maps human business concepts to technical data assets and records what worked during execution.
3
Thin agents can use this shared layer to discover data, judge trust, avoid duplicated wiring, and learn from other agents.
Summary
Emil Eifrem describes a common failure pattern in enterprise agent development. A bank account-opening agent may need DMV records and passport verification, but every new agent has to rediscover where relevant data lives across databases, Snowflake, Databricks, and S3. Teams then have to assess versions, trust, and access rights. Changes require manual rewiring, and agents do not learn from one another. Eifrem proposes thin agents on a shared ontology-based semantic layer. A business ontology defines concepts such as customers, accounts, and checks in language people use. A technical ontology catalogs enterprise data sources and schemas. Mappings connect the two, while execution traces record attempts, outcomes, and context. Human curation and observed results can then guide source selection. Eifrem argues that this shared layer reduces repeated integration work and lets agents improve individually and across the wider agent system.
Enterprise agents repeat the same data discovery work
Eifrem starts with a bank account-opening agent whose business logic plans and acts while its data layer supplies the information it needs. To validate identity, the team wires in the DMV registry and a passport verification service. The arrangement works, but every other team building an agent must repeat the discovery process. In a large enterprise, relevant information is spread across many databases, Snowflake, Databricks, and S3 buckets. Teams have to find the sources manually before they can make them available to their agents.
Data duplication makes trust and access part of every integration
Finding a source is only the beginning. Enterprise systems often contain duplicated data, so an agent team must ask whether a source is the right one, whether it has the right version, whether it can be trusted, and whether the agent is allowed to access it. Eifrem connects this to the software engineering principle DRY, or 'don't repeat yourself.' When a source changes, each agent that contains its own wiring needs a manual update. The same maintenance work spreads across the organization.
Markdown files help agents but do not hold the whole solution
Eifrem acknowledges the idea that Markdown files and skills can solve the data problem. His answer is 'yes and no.' Teams have tried using only Markdown files, and he describes that approach as part of the solution rather than the complete solution. He quotes Swyx from the Latent Space podcast: 'You got to learn your databases. You cannot vibe code with just markdown files.' The point is that agents need structured knowledge about the underlying data systems, rather than only instructions written in files.
From work with a Fortune 20 global bank, a large technology platform company, and a fintech company, Eifrem says a pattern is emerging: thin agents on a smarter shared substrate. The agent still interprets intent, plans, and acts, but shared infrastructure holds the knowledge about business concepts, enterprise data, and prior execution. This separates reusable data knowledge from each agent's code and prompts. Eifrem presents the substrate as an ontology-based semantic layer with three pillars.
A business ontology names concepts in human language
The first pillar is a business-facing ontology. It defines the concepts used by the organization, such as customers, accounts, debit cards, checks, and transactions, along with their relationships. Eifrem says these concepts should be expressed in terms that people in the company understand. A field should be represented as a customer's first name, rather than as a technical name such as 'f_name.' The ontology gives agents a shared vocabulary for business intent.
A technical ontology connects that vocabulary to real systems
The second pillar catalogs the enterprise's technical data assets and metadata. It records systems such as Oracle and Neo4j databases, Snowflake, Databricks, and S3, along with where they are located and what schemas they contain. A mapping connects business concepts to technical fields. For example, a customer first name can be linked to its system of record and to an Oracle column named 'F_name.' Agents can then move from a business need to a specific place where the data can be found.
Execution traces let the shared layer learn from outcomes
The third pillar is the runtime signal produced by agents as they use the graph. Execution traces record what an agent tried, where it was in the process, its context, and whether the attempt succeeded. Eifrem says those details can produce a score. If a DMV lookup has worked well in the right context, the system is more likely to select it during a later invocation. The layer therefore captures observed performance instead of relying only on static documentation.
One governed layer addresses discovery, trust, reuse, and learning
Eifrem says the three pillars address the four problems raised earlier. The layer makes data sources easier to discover and provides trust information from human-curated knowledge as well as execution traces. A governed mapping between business intent and data sources prevents each agent from repeating the same wiring. When a source changes, that shared mapping can affect all agents. Execution history also supports learning within one agent and across agents, so a later invocation can use what previous agents learned.
"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 sits."01:48
Who should watch
You are building several enterprise agents and each team keeps creating its own integrations to the same systems.
Your agents need to find data across many databases and you need a shared way to describe business concepts, schemas, permissions, and source quality.
You want agents to learn from successful and failed data lookups across invocations instead of keeping that knowledge inside separate prompts and codebases.
