Our bet is simple: - In the future, new projects won’t just start with git init. - They’ll start with git init and ox init.
Code gives you versioned artifacts.You’ll also need versioned context.
SageOx is our attempt to make shared, inspectable team memory a first-class primitive — something agents automatically consult before they act.
Happy to go deep on architecture, tradeoffs, or why this might be wrong.
Question: how do you handle conflicting decisions? If engineer A decides on approach X in a session on Monday, and engineer B decides on approach Y on Tuesday, does SageOx surface the conflict or just store both as valid context?
Also curious about the retrieval quality. The hardest part isn't capturing decisions — it's retrieving the RIGHT context at the RIGHT time. Too much context and you're back to the LLM ignoring half of it. Too little and you miss critical constraints. What's your chunking/relevance strategy?
Many of the issues of conflicts are basically dealt with us hammering them out in our daily standups. We see these as 'merge walls'. Both Ryan and I have been principal engineers in Amazon in our past lives: every day with Claude feels like dropping into a design meeting on a team with 100 engineers. So, we just accept that we have to spend a lot of time whiteboarding and talking as we align our mental models at a daily cadence.
Really good point on the RIGHT context at the RIGHT time. With the first release, we have focused on the plumbing to collect all the sessions and the transcripts. As we get more data, we are going to step up into the next level of analysis where we collate all the data into the right insight at the right time.