Đây là tình huống mà bất kỳ tech lead nào quản lý team dùng nhiều công cụ AI đều quen thuộc: thứ Hai bạn debug một test bị flaky với Claude Code, phát hiện nguyên nhân gốc là race condition trong một fixture test dùng chung, và giải thích cách fix ngay trong phiên đó. Thứ Ba, một đồng nghiệp gặp đúng test flake đó và hỏi Cursor — Cursor chưa từng “nghe” cuộc trò chuyện hôm thứ Hai, không có quyền truy cập phiên đó, và phải tự suy ra lại đúng nguyên nhân gốc từ đầu, tốn thêm hai mươi phút và một phần context window cho một vấn đề đã được giải quyết. Nhân con số đó với mỗi lần đổi công cụ, mỗi ngày, trên toàn team, bạn sẽ có thứ mà một bài viết gần đây gọi là “collective amnesia” — không phải vấn đề về khả năng suy luận, mà là vấn đề giao tiếp giữa các công cụ chưa bao giờ được thiết kế để nói chuyện với nhau. Tôi dành vài ngày tìm hiểu các dự án cross-agent memory layer mới nổi, đặc biệt là Memmy, xem chúng thực sự giải quyết vấn đề này thế nào và cái giá về kiến trúc là gì.

Vấn đề không nằm ở bộ nhớ, mà nằm ở quyền sở hữu

Mọi coding agent lớn hiện nay đều đã có một dạng bộ nhớ nào đó: Claude Code có file context ở cấp project, Cursor có hệ thống index và rules file riêng, Codex có lịch sử phiên làm việc riêng. Vấn đề chưa bao giờ là thiếu bộ nhớ — mà là mỗi công cụ sở hữu bộ nhớ của riêng nó một cách độc quyền, theo định dạng riêng, chỉ giới hạn trong phiên của chính nó. Một fact mà team bạn học được ở một công cụ sẽ vô hình với mọi công cụ khác, và tệ hơn, vô hình với cả phiên tiếp theo của chính công cụ đó nếu phiên đó bắt đầu từ đầu. Nước đi kiến trúc thực sự của Memmy khá “nhàm chán” theo nghĩa tốt: thay vì xây một hệ thống bộ nhớ thông minh hơn bên trong một agent cụ thể, nó đưa bộ nhớ ra khỏi agent hoàn toàn, vào một runtime cục bộ mà mọi agent đều đọc/ghi vào — Claude Code, Codex, OpenClaw, Cursor và các công cụ khác kết nối vào đó như một lớp nền dùng chung, thay vì mỗi công cụ tự duy trì một hòn đảo riêng.

Local-first mới là phần thực sự quan trọng

Chi tiết đáng chú ý nhất với một tech lead đang đánh giá mô hình này không phải là danh sách tính năng, mà là mô hình triển khai: Memmy mặc định chạy cục bộ, hợp nhất bộ nhớ dài hạn, việc thực thi agent, và các kết nối công cụ vào một runtime nằm ngay trên máy bạn. Đây không phải chi tiết phụ — đó là phiên bản duy nhất của kiến trúc này có thể vượt qua một buổi security review. Cross-agent memory layer, theo định nghĩa, gom mọi thứ các công cụ AI của team bạn đã học được về codebase, API nội bộ, các pattern bug, thậm chí có thể cả context sát với credential — vào một chỗ. Tập trung hoá điều đó vào một dịch vụ cloud bên thứ ba tạo ra blast radius lớn hơn nhiều so với lịch sử phiên của bất kỳ agent đơn lẻ nào, vì giờ đây một kho bộ nhớ bị xâm phạm sẽ làm lộ context trên mọi công cụ team bạn dùng, không chỉ một. Bất kỳ team nào áp dụng mô hình này nên coi câu hỏi “nó có chạy cục bộ không, và index bộ nhớ nằm chính xác ở đâu trên đĩa” là câu hỏi đầu tiên, không phải chuyện nghĩ tới sau.

Nó thực sự giải quyết được gì — thử trực tiếp

Tôi dựng một bài test với hai công cụ: Claude Code và một agent thứ hai trỏ vào cùng một project, với một lớp memory dùng chung ở giữa. Tôi cố tình dạy cho một agent một quy ước nội bộ — quy tắc không hiển nhiên của team chúng tôi rằng mọi migration database phải reversible và đi kèm script rollback, điều này không được ghi ở đâu trong repo, chỉ tồn tại dưới dạng tribal knowledge — rồi yêu cầu phiên agent thứ hai, hoàn toàn mới, viết một migration. Không có lớp memory dùng chung, agent thứ hai viết một migration một chiều như bình thường; có lớp memory dùng chung, agent thứ hai chủ động hỏi có nên sinh kèm script rollback không, vì ràng buộc đó đã được chưng cất từ cuộc trò chuyện đầu tiên thành bộ nhớ có cấu trúc, tái sử dụng được, thay vì mắc kẹt trong một transcript không ai đọc lại. Đó mới là giá trị thực sự: không phải “AI nhớ bạn”, mà là “tribal knowledge mà team bạn phải giải thích bằng lời cho mỗi phiên agent mới giờ chỉ cần capture một lần và tái sử dụng ở mọi nơi” — một sự giảm tải thực sự, đo được, cho chi phí lặp lại việc thiết lập context.

Nó vỡ trận ở đâu

Failure mode tôi gặp nhanh nhất là dữ liệu cũ (staleness): một fact đúng vào tháng Ba nhưng sai vào tháng Tám không tự động hết hạn chỉ vì nó được tập trung hoá. Nếu một quy ước thay đổi — ví dụ team bạn chuyển từ quy tắc migration-reversible sang một chiến lược rollback khác — mọi agent lấy từ lớp memory dùng chung sẽ tự tin áp dụng quy tắc cũ cho đến khi có ai đó chủ động sửa lại kho bộ nhớ, và vì bản sửa đó giờ phải lan ra mọi công cụ thay vì chỉ nằm trong phiên của một agent, một fact cũ khi bị tập trung hoá gây hại nhiều hơn so với khi nó chỉ nằm im trong một công cụ không ai dùng suốt nhiều tháng. Failure mode thứ hai là attribution: khi bốn agent khác nhau trong bốn phiên khác nhau đều đã đóng góp vào cùng một mục bộ nhớ, việc debug vì sao một agent tin vào một điều gì đó đòi hỏi lần theo một kho dùng chung thay vì một transcript phiên đơn lẻ — đây là bài toán debug khó hơn thật sự so với chính vấn đề mà pattern này giải quyết.

Kết luận

Cross-agent memory là lớp kiến trúc tiếp theo hợp lý cho bất kỳ team nào dùng nhiều hơn một coding agent — chi phí phân mảnh khi phải giải thích lại cùng một quy ước nội bộ riêng biệt cho Claude Code, Cursor và Codex là có thật và nó cộng dồn mỗi ngày. Nhưng hãy đối xử với nó như bất kỳ hệ thống shared-state nào khác: triển khai local-first không phải là tuỳ chọn với bất cứ thứ gì chạm vào context nội bộ của codebase, và bạn cần một cơ chế invalidation thật sự trước khi tin tưởng nó, giống như bạn sẽ không bao giờ tin một cache không có TTL. Nếu đang thử nghiệm mô hình này, hãy bắt đầu với một nhóm bộ nhớ ranh giới rõ ràng — quy ước coding, chứ không phải các quyết định kiến trúc thay đổi theo quý — rồi mở rộng dần sau khi đã chứng minh được team thực sự sửa các mục cũ thay vì chỉ tích luỹ chúng.