Yeah it’s buzzword-y but here we are. The question on my mind for the last year or two has been this: How _should_ AI Agents and humans share context with each other. I think we can all agree that sharing everything is just awful. So what should be shared, and when remains pretty fuzzy. Lets define the problem with a simple narrative.
Say you had a 10 person team (an ops person, designer, and em, a product manager, and 6 devs) all working on a project. Features get broken down to stories, or tickets or epics or who even cares, smaller chunks. Each person goes to town and starts working. If you’re lucky you’ve got some AGENTS.md file in your app repo, and there is a little bit of consistency from commit to commit on style and heuristics. Each of those humans has a swarm of bots working for them, getting the features build, running tests, and authoring commits.
Volume is at an all-time high. You’re codebase is starting to feel like sand shifting under your feet when Shai-hulud approaches. PR’s are being reviewed about as thoroughly as your average security check into a concert, because the more senior devs are reviewing 10 times as much. As log as the tests are green and the app still works… ship it.
The role of the senior/staff engineer used to be to hold the state of the application in their head and make sure stupid changes didn’t threaten that. Now the state is in such flux and growing so fast that no one engineer has the whole picture in their brain. Only fragments.
So if no one engineer has the context of the whole application loaded, and certainly no llm has that either, how do you know if a change is diverging architecturally? How can you know if you’ve accidentally opened up an unauthenticated api endpoint? How could you explain to a new engineer how everything works?
As I have pondered these problems I’ve realized a few things.
- More words is not the answer. I need pictures to ingest larger amounts of ideas faster.
- A unified vision between humans was once the goal of product leads. Now that audience needs to include all LLM’s running in an organization.
As I tumbled these two ideas around, I naturally tried to model out in my head what relational data structure could store information rich enough that would capture complex data needed to keep everyone on the same page. It did not take me long to figure out that some of the information about a specific system would CHANGE the structure of the data. After sketching out dozens of possible data structures they all started to converge on a table with ‘nodes’ and a table with ‘properties’ and a table with ‘relations’.
I need a graph database.
I’m getting a bit ahead of myself, but I’ll pick that up next post.
