DAP Memory Architecture Design proposal - v1

Richard Chanrequested to merge
598733-dap-memory-architecture-v1 into main

Why is this change being made?

This updated doc aims to align on key architectural directions — sufficient to start work, with details worked out along the way via discussion, PoCs, and data review.

  • Alignments from discussions over the past 2 weeks since the release of the rough draft (!20201 (closed)) were rolled into these updates.
  • Some files containing WIP information that weren't key alignments have been trimmed for easier review

Please focus your review on: index.md (most comprehensive) and release-phases.

A few things to call out specifically:

  • I've factored in existing foundational agent flow context loading for file-based rules (agents.md), which was overlooked before we decided DWS was the place to build this service.
    • As such, a couple open questions regarding file activation states and in-session loading have surfaced; please advise.
  • The former "intermediate stage" discussion has been merged into phase 1a/1b. I think this preserves compatibility with the ideas behind these suggestions; please flag if this restructuring doesn't hold up @eduardobonet @ghavenga
  • New proposal: a proactive injection mechanism.

Key ask: is this enough for initial sign off on starting the work for beta? Implementation details can evolve as we explore, PoC, and build, but key directional alignments — where the service is built, what DB to use, etc. have already taken shape.

If this is deemed sufficient for alignment, please sign off on the spike issue: gitlab-org/gitlab#598733. If not, please advise on current gaps. 🙇🏻

Author and Reviewer Checklist

Please verify the check list and ensure to tick them off before the MR is merged.

  • Provided a concise title for this Merge Request (MR)
  • Added a description to this MR explaining the reasons for the proposed change, per say why, not just what
    • Copy/paste the Slack conversation to document it for later, or upload screenshots. Verify that no confidential data is added, and the content is SAFE
  • Assign reviewers for this MR to the correct
    • The when to get approval handbook section explains when DRI approval is required
    • The who can approve handbook section explains how to identify the DRI
    • If the MR does not require DRI approval, consider asking someone on your team, such as your manager.
    • The approver may merge the MR. If they approve but don't merge, you can merge.
  • For transparency, share this MR with the audience that will be impacted.
    • Team: For changes that affect your direct team, share in your group Slack channel
    • Department: If the update affects your department, share the MR in your department Slack channel
    • Division: If the update affects your division, share the MR in your division Slack channel
    • Company: If the update affects all (or the majority of) GitLab team members, post an update in #whats-happening-at-gitlab linking to this MR
Edited by Richard Chan

Merge request reports