[dead]
The Enterprise Context Layer
11–20 of 28 posts
Re: The Enterprise Context Layer
#12"But what if I told you that all you need is 1000 lines of python + a github repo?" didnt need to read past this line LMAO. not at all enterprise.
Don't worry. Someone will come along and run the same 1000 lines on a Docker container using ECS Fargate launched with Step Functions under the watchful eyes of Cloud Watch all glued up with Lambda and stick everything behind IAM roles and a parem store and charge 100x more...then it can fit your definition.
its not about the cost or complexity of the solution, its just about the info density.
```The result after running 20 parallel agents on this for ~2 days:```
That's basically saying 'yeah, me and my 20 coworkers figure everything out of your company'. There is just nothing innovative apart from hoping the AI to magically just work.
Re: The Enterprise Context Layer
#13I 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. Storing it the way this article presents makes it usable for agents, but not humans. Whereas the point of knowledge graph, ontology, etc is to create the same layer for both humans and AI to interact with
Re: The Enterprise Context Layer
#14I 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…
Exactly this. Having spent almost three decades in enterprise context I see a lot of reinvention of something like a poor mans, unstructured, enterprise architecture - because AI agents.
I keep repeating ”what is good for humans in an organization is also good, or even required, for AI agents”.
Imagine every new instance of an AI agent as a new employee. With humans its ok to slowly accumulate knowledge through word of mouth, trail and error and the general inertia of larger orgs almost seem structured (or unstructured) knowledge-wise for this.
AI agents will never be useful in high value operations in a larger orgs without organizational knowledge available and reliable.
Re: The Enterprise Context Layer
#15This 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
#16I 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.
Re: The Enterprise Context Layer
#17I 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…
> 3. Storing it the way this article presents makes it usable for agents, but not humans. Whereas the point of knowledge graph, ontology, etc is to create the same layer for both humans and AI to interact with
If storing it this way makes it usable for agents, then why don't humans just use agents when they need to interact with it?
Re: The Enterprise Context Layer
#18I 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…
> 3. Storing it the way this article presents makes it usable for agents, but not humans. Whereas the point of knowledge graph, ontology, etc is to create the same layer for both humans and AI to interact with If storing it this way makes it usable for agents, then why don't humans just use agents when they need to interact with it?
Let's say that you want to know who your largest customer is, both by order value and volume. I could either:
1. Prompt my agent and deal with writing the prompt, waiting for the agent to sift through all the data (which would be massive), and pay the token costs, all of which has to be repeated everytime I want to answer this question, OR
2. I check my ontology for the answer, probably in a dashboard, and it takes 5 seconds. I have a link I can freely share around my enterprise and I haven't spent token costs.
Whats more, when I have sent my agent out to some tasks (go find out what revenue we're leaving on the table by not selling spot contracts to our biggest customers) my ontology gives me a few bits of data to validate the agents work against. For humans and AI to work together, they need the same context layer
Re: The Enterprise Context Layer
#19Earlier quoted context omitted.
Don't worry. Someone will come along and run the same 1000 lines on a Docker container using ECS Fargate launched with Step Functions under the watchful eyes of Cloud Watch all glued up with Lambda and stick everything behind IAM roles and a parem store and charge 100x more...then it can fit your definition.
its not about the cost or complexity of the solution, its just about the info density. ```The result after running 20 parallel agents on this for ~2 days:``` That's basically saying 'yeah, me and my 20 coworkers figure everything out of your company'. There is just nothing innovative apart from hoping the AI to magically just work.
Hey, OP here!
I agree the idea here is pretty simple. The main insight is just allowing the agents to figure out the unfiltered truth about a company (the good, bad, and ugly). I tried many variations of this before but they all failed because it simply captured "intended process" instead of the ground truth.
Still have a lot of hard problems to figure out like how to maintain RBAC and scale this solution!
Re: The Enterprise Context Layer
#20Felt 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 probably it