Knowledge graphs can give enterprise agents a shared understanding of how data, business rules and processes fit together. However, that context becomes harder to maintain when each new agent carries its own version of what the business knows.

Organizations have become more proficient at building agents, but their results still vary widely. The difference often lies in how enterprise knowledge is presented, according to Jesús Barrasa (pictured), field chief technology officer of Gen AI at Neo4j Inc.

“You have to give agents not only access to your data, but also to your meaning, to your enterprise knowledge,” he said. “That’s unfortunately not always well captured … [or] well represented.”

Barrasa spoke with theCUBE Research’s John Furrier at the GraphSummit, during an exclusive broadcast on theCUBE, SiliconANGLE Media’s livestreaming studio. They discussed how a shared knowledge layer could help agents use enterprise context, explain their answers and reuse knowledge across tasks. (* Disclosure below.)

Why knowledge graphs need a shared layer

As organizations expand their use of agents, they face a familiar problem: Work done for one application does not necessarily carry over to the next. Barrasa sees a parallel with earlier reporting systems that produced conflicting results.

“They identify a single problem, and they build the knowledge that the agent requires in the agent itself in the form of prompts, in the form of skills,” he said. “But then what happens? They build agent number two. They’re going to do exactly the same thing. So, we’re repeating the errors that we made seven years ago when we were building reports in different platforms and getting inconsistent results.”

A knowledge layer is a governed representation of an organization’s data assets, concepts, policies and processes, according to Barrasa. It can also help people examine how an agent reached an answer — a growing concern as agents move from conversation to action.

“This knowledge layer, this idea of capturing your enterprise knowledge and using it as the context engine for your agents, not only gives you the consistency that we were talking about before, it gives you the explainability,” he said. “That’s the source of my data. These are the elements that I use to produce the answer.”

Building knowledge graphs across use cases

Knowledge graphs can connect data to the business concepts and relationships agents need to interpret it. Organizations can develop that context across multiple applications instead of attempting an enterprise-wide model at the outset, according to Barrasa.

“You want to start with one use case. And when you build use case two, you have to try to align it to number one,” he said. “That’s how you build the knowledge layer. You build it incrementally. It’s ‘identify use case, realize value and then build from there.’ The construction of the ontology is something that [large language models] can accelerate significantly.”

A shared knowledge layer may require a broader measure of return on investment than the results of any one agent. Organizations should also assess what changes as they build more agents, according to Barrasa.

“You want to measure how the construction of Agent 2 and Agent 3 and Agent 4 goes down as you go, because you’re building knowledge in the layer,” he said. “Another [metric] is … a negative metric: What’s the cost of drift? What happens when two agents return diverging results or act in different ways? What’s the cost of reconciling these results?”

Here’s the complete video interview, part of SiliconANGLE’s and theCUBE’s coverage of the GraphSummit:

(* Disclosure: TheCUBE is a paid media partner for GraphSummit. Neither Neo4j, the sponsor of theCUBE’s event coverage, nor other sponsors have editorial control over content on theCUBE or SiliconANGLE.)

Photo: SiliconANGLE