Most engineering teams are drowning in signal. Pull requests, issues, commit history, review threads, status checks. All of it is technically visible. Very little of it is readable at a glance, especially if you are not the person who wrote it or reviewed it in the last 24 hours.
The problem this creates is a specific kind of context loss. Engineers who are close to the work know what is happening. People one step removed, including other engineers working on adjacent things, product people trying to understand progress, or the team lead trying to see the whole picture, are spending meaningful time reconstructing context that already exists somewhere in the repository. That reconstruction time is waste, and it accumulates.
In December we built a project management layer that sits on top of GitHub activity and produces readable summaries of what is actually happening across repositories. Not a notification feed. Not a raw commit log. A structured view of what changed, what is in progress, what is blocked, and what needs attention.
The AI challenge in this kind of tool is deciding what to surface and what to leave out. GitHub generates a lot of activity, and most of it is not equally important at any given moment. A commit that fixes a typo in a comment is different from a commit that changes core logic. A pull request that has been open for three days with no review is different from one that was opened an hour ago. Getting the summarisation to reflect those distinctions accurately requires understanding the activity in context, not just listing it in order.
The result is a shared surface the team can check instead of asking each other for status updates. Async teams in particular benefit from this because the alternative is messages like what is the state of X, which interrupt flow for both the person asking and the person who has to answer.
This sits inside the Slash product line and feeds into the broader goal of making distributed engineering teams faster without requiring more synchronous communication.