Synopsis: An enterprise agent may need more than the document that most closely matches a question. The answer can depend on a decision in a chat thread, a related code change and the way a particular team describes its work. Reconstructing those connections for every task adds expense and complexity. A shared context layer offers a different approach: maintain organizational knowledge outside the model and make the relevant pieces available when an agent needs them.
Gilad Salinger, CEO of Uvi, joins Mike Vizard to explain why he sees context as a separate part of the enterprise AI stack. A pilot built around a curated dataset does not face the same demands as a production system spanning code, tickets, business records and conversations. Keeping that information useful means tracking relationships, changes and the company’s own terminology. Salinger argues that building the knowledge layer independently of the model also gives organizations more flexibility to change providers without rebuilding their understanding of the business.
That work requires more than choosing a vector database or a knowledge graph. Salinger describes several connected capabilities: mapping relationships between information, understanding how the enterprise defines its work, identifying the people and teams involved, and finding links that were never explicitly documented. Permissions have to carry through those connections as well. Bringing information together does not remove the need to determine which agent may use it, especially when a task draws on several applications with different access rules.
He also cautions against dividing business and engineering knowledge into isolated systems. A customer issue may require an agent to connect a support conversation with the relevant application behavior and code. Keeping those domains apart can leave the agent without the context needed to complete the task. For organizations deciding whether to build or buy this capability, the architectural question extends beyond retrieval quality: how will the system maintain a current, permission-aware understanding across departments as tools, models and workflows change?
