I enjoyed reading this but felt like it missed a few of the points on why a lot of companies are indexing heavily on the context layer. 1. While AI is capable of driving massive value, chatbots are very rarely the solution 2. You need much more than this sort of text data to represent an enterprise. Timeseries, SAP (and other ERPs), and general relational data is part of building a knowledge graph, ontology, etc 3. S…
Yes. This feels more like a way to produce an SMB context layer than enterprise.
The Enterprise Context Layer
21–28 of 28 posts
Re: The Enterprise Context Layer
#22Re: The Enterprise Context Layer
#23Felt like this read my mind, I was shocked recently at how good Cursor (with Claude) is at answering questions given its Slack/GSuite MCP connections; and a lot faster than Glean. Also amazing to see how this can literally give better answers than some humans would.
Yea me too! I had a sense that something better than pure document retrieval was possible. But wasn't sure what. I spent months just playing around with various RAG techniques until coming up with this. I do think something like Glean is still needed (the agents here used Glean search API for building this context layer). but for the purposes of answering questions and building enterprise-ready agents, the ECL is pro…
Re: The Enterprise Context Layer
#24Love the honesty, especially around process docs describing the ideal not reality. The thing I'd push on: your agents learned data retention questions are dangerous because the history existed in the data. But what about the stuff that never gets written down at all, like whose informal veto actually kills a project? Curious if you hit that wall. Someone else wrestling with the same problem: https://behaviorgraph.com…
imagine the hierachy: enterprise context, team context and then personal context. each of the layer above can read/write to the layer below. while the layers below cannot access layers above
the personal context layer, for example, would have access to all your meetings and slack dms.
if a group of executives decide in a private meeting to kill a project. that should be saved in their personal context layer. And an agent proactively detects the difference from the enterprise context and asks: "would you like to change enterprise context" something like that
Re: The Enterprise Context Layer
#25This was great info, but as someone who is concerned about passing great info on to others about my own products, I am suddenly less worried about my posts reading like LLM-speak. This post did very well. I should probably stop overthinking it, and learn from this post about balance.
Re: The Enterprise Context Layer
#26Fantastic article. I've always felt that institutional knowledge flow is one of the most essential factors in a given company's ability to survive. In the nascent age of AI, this "Enterprise Context Layer" approach seems more likely to catch on (and become table stakes, in order to keep up) than something like https://dotwork.com which looks amazing but seems to imply vendor lock-in.
Re: The Enterprise Context Layer
#27Any good open source solutions for this?
for now github + markdown might be the best way to do it
Re: The Enterprise Context Layer
#28Love the honesty, especially around process docs describing the ideal not reality. The thing I'd push on: your agents learned data retention questions are dangerous because the history existed in the data. But what about the stuff that never gets written down at all, like whose informal veto actually kills a project? Curious if you hit that wall. Someone else wrestling with the same problem: https://behaviorgraph.com…
I think this would be solved via the team/personal context layer. imagine the hierachy: enterprise context, team context and then personal context. each of the layer above can read/write to the layer below. while the layers below cannot access layers above the personal context layer, for example, would have access to all your meetings and slack dms. if a group of executives decide in a private meeting to kill a proje…
But starting a new project is a different class of problem. That is not just about storing a decision. It is about adoption across the organization.
You can record that a few executives want something to happen. But that does not tell you who will drive it, who will resist it, which teams need to buy in, or how the change actually propagates. At that point, you are no longer dealing with just team or personal context. You are dealing with organizational behavior.
That is where I think the real gap still is.