Like everyone else, I’ve been enjoying the steady improvement in coding agents and the tooling around them, from frameworks and harnesses to evaluation suites. But the more I talk with teams actually deploying agents in enterprises, the more I circle back to plumbing. Agents need data integrations and infrastructure built for them, a theme I explored in a piece on rethinking databases for agents. I’ve also written about using knowledge graphs (GraphRAG) to improve accuracy and reduce hallucinations, which is especially important in high-stakes applications. The persistent problem has been that most teams don’t have a knowledge graph, and the few that do struggle to keep it current. A new system I recently came across is aimed squarely at that gap.
If you read often, consider becoming a paid supporter 🙏
Automating Graph Construction and Maintenance
I recently spoke with Andrew Moore, CEO of Lovelace, former head of Google Cloud AI, and former dean of Carnegie Mellon’s School of Computer Science. Lovelace’s Elemental platform turns enterprise data into structured context engines that AI agents can navigate and investigate. I think “knowledge graph” is still a reasonable term here, although “context graph” may be closer to the point. This is not a graph built mainly for a human analyst browsing nodes on a screen. It is designed for agents that need to answer questions too large, messy, or time-sensitive for ordinary search, basic RAG, or stuffing more raw documents into a context window.
Elemental ingests whatever you have: relational tables, PDF files, news feeds, JSON fragments, even satellite imagery and other multimodal sources. Everything gets converted into a common intermediate form that eventually becomes nodes and relationships in a graph. The platform automates much of the construction and maintenance of these graphs. A graph with a thousand nodes can tolerate a human in the loop, but once you’re at many millions of facts, any step that depends on a person checking whether two records refer to the same company simply collapses. Too many enterprise AI projects die in the six months of data wrangling that comes before any actual AI work, and removing that toil is the whole point.
For an agent, a context graph gives it a map of the enterprise and the surrounding world. A bank investigating exposure to a sanctioned shipping company might need to connect ownership records, trade data, vessel movements, subsidiaries, legal filings, customer relationships, and recent news. Vector search can find relevant documents, but these questions often require following relationships across many entities and events. That is where a graph-shaped context layer becomes useful.
Graphs for Agents, Without a Graph Database
Elemental is designed around four steps: data ingestion, entity resolution, graph construction, and agent-facing tool access. I covered ingestion above, but one constraint is worth adding: the system has to work without assuming clean schemas, consistent naming, or a single source of truth.
Entity resolution is the problem of deciding when different records refer to the same real-world thing. “IBM,” “International Business Machines,” an internal vendor ID, a legal entity in a filing, and a name in a PDF might all refer to the same company, or they might not. The same issue appears with people, ships, aircraft, accounts, subsidiaries, addresses, products, assets, and events. Anyone can prototype an entity resolution system in a weekend. Making one that scales, handles multiple languages, adapts to entirely new entity types, and updates as new information arrives is brutally hard. Lovelace built its own engine and goes well beyond text matching. I half-jokingly told Andrew that the entity resolution engine alone could be a standalone product, given how many applications live or die on getting this right.
Enterprise agents do not just need more context. They need context they can trace, rank, and trust.
Auditability is just as important. In regulated or high-stakes settings, the system needs to show where a fact came from, how it was linked to other facts, and what version of the graph existed when an agent produced an answer. In plain English, that means lineage, provenance, and version control: how a fact moved through the system, what evidence supports it, and what the graph believed at a point in time. That matters if a regulator, customer, or internal reviewer asks why an agent flagged a transaction, recommended an investigation, or dismissed an alert. “The model said so” will not be enough.
Retrieval is where the graph becomes more than a data catalog. In a serious graph, a single node can have hundreds of thousands of links, so a naive “show me everything within two hops” query explodes into billions of paths and grinds to a halt. Elemental takes a different route. It reframes a question like “who is most affected by this event?” as a probability problem, then uses randomized algorithms and other graph-theory tricks to surface the strongest connections without walking every path. The result is approximate rather than mathematically exact, but it returns confident, ranked answers over millions of nodes in under a second. That trade is well worth making, because the alternative is an LLM trying to reconcile contradictory probabilistic evidence in its head, which language models are genuinely bad at.
Another interesting design choice is that Elemental does not rely on a graph database as the core storage layer. The data is exposed to agents as a graph, but the persistence layer underneath is custom. The reason is simple. Traditional graph databases are very useful, but they were not built for this particular job: broad, high-speed inference across tens of millions of nodes.
Why Private Graphs Need Public Context
Lovelace also brings another asset to the table: YottaGraph. Think of it as a large, continuously updated graph of the public world, covering companies, people, places, events, filings, sanctions records, and the movements of ships and aircraft. This is useful because internal enterprise data rarely tells the whole story. YottaGraph would be hard to replicate because it requires continuous ingestion from many sources, entity resolution at scale, and a lot of operational discipline. Importantly, the enrichment flows inward. Public context can augment a company’s private graph, but Lovelace does not share one customer’s data with other organizations.
Lovelace isn’t alone in using graphs to give agents better context, and I expect to see much more activity here. There is also a funny twist. GraphRAG was promoted heavily by graph database vendors, but some of the more interesting graph systems for agentic AI may not use graph databases at all. Whatever we end up calling these things, knowledge graphs, context graphs, or context engines, the underlying idea of structured, auditable context for agents is becoming hard to ignore.
Source link
Leave a Reply