The Enterprise Context Layer

The Enterprise Context Layer(andychen32.substack.com)

65 points by zachperkel 91 days ago | 25 comments

eddy162 91 days ago |

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

andychen32 86 days ago | |

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

yumiatlead 84 days ago | | |

Agreed on Glean still being needed for retrieval. One gap worth noting though: Glean's enterprise graph on the people side is mostly org chart and document co-occurrence data. It doesn't capture who people actually trust, who informal decisions route through, or who the real subject matter experts are regardless of title. Organizational network analysis on top of that could be a meaningful additional layer for the ECL.

yumiatlead 84 days ago |

Love 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/blog/posts/the-layer-every-enterpr...

andychen32 84 days ago | |

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

yumiatlead 83 days ago | | |

I agree for something like quietly killing a project. That can live in a personal or team context layer at first.

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.

vidimitrov 91 days ago |

* * *

scrumper 90 days ago | |

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

condwanaland 86 days ago |

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

nr378 86 days ago | |

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

chrisweekly 91 days ago |

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

andychen32 84 days ago | |

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

consumer451 86 days ago |

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

andychen32 84 days ago | |

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

fittingopposite 90 days ago |

Any good open source solutions for this?

andychen32 83 days ago | |

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

kingjimmy 91 days ago |

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

F7F7F7 91 days ago | |

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.

moqizhengz 86 days ago | | |

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.

nullpoint420 90 days ago | | |

Even worse. The same code but deployed as a ZIP file….