The Enterprise Context Layer (opens in new tab)

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

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 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

> that rule could still look valid in the ECL long after the original reasons for it stopped applying.

Ha, then it'd be doing a great job of internalizing institutional knowledge! Wait a few years and then put another one on top. I'm not sure how these things incorporate new knowledge over time, or handle re-orgs and strategy shifts, or adapt as new verticals are added. Do you need ever increasing numbers of agents to keep things in line?

As much as I'd love to have a perfect example of one of these running - it really would be very beneficial - I do have a vague feeling that these ECL concepts (and similar Enterprise-wide knowledge management AI panaceas) are the 21st century equivalents of trying to build comprehensive expert systems in Prolog.

This is cool though. Agents make it seem more plausible in a way that pure RAG systems don't. I am sure there is mileage in more focused cases (like at the author's startup, or departmentally.)

> 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?

Yes. This feels more like a way to produce an SMB context layer than enterprise.

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.

I agree! my instincts tell me most enterprises will hop onto this in the coming months (late stave startups first, then bigger companies) until we get to 100m token context window LLMs, this is probably the final pattern

haha yea claude helped me write some of it and the other parts i just wrote by hand because i wanted to phrase things in a specific way

honestly i don't think the "real infra" is there yet. someone has to make it

for now github + markdown might be the best way to do it

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.