A Genius With Amnesia

1. Cây đèn thần và một John Carmack bị mất trí nhớ

Victor mở đầu bằng một câu chuyện tưởng tượng. Bạn bước vào một cửa hàng đồ cổ, tìm thấy một cây đèn thần. Bạn xoa nó, một vị thần đèn hiện ra và hỏi có thể giúp gì cho bạn. Lúc đó bạn đang ngập trong deadline, nên bạn nói: "Tôi cần kỹ sư giỏi nhất để giúp tôi một dự án bất khả thi ở công ty." Và thần đèn thực hiện điều ước.

Với Victor, kỹ sư giỏi nhất có lẽ là John Carmack thời còn ở id Software, nên bạn nhận được Carmack. Nhưng thần đèn có khiếu hài hước, và đặt ra vài giới hạn, có thể là vì lý do an toàn. Carmack chỉ được nhìn thấy một phần rất nhỏ trong code base của bạn, có khi chỉ một phần nghìn. Và anh ta không nhớ gì về những việc mình đã làm trước đó. Mỗi cuộc trò chuyện đều bắt đầu lại từ đầu.

Truyện tranh Promise: tìm đèn thần, gặp thần đèn, nhận được một thiên tài — Trang "Promise": một lập trình viên mặc áo "Monorepos forever" bước vào tiệm đồ cổ The Valley, xoa đèn thần, xin "một thiên tài để giúp dự án bất khả thi", thần đèn đáp "As you wish", và thiên tài đeo kính xuất hiện với câu "Let's start cranking". Đó là lời hứa của agent.

Điều đó sẽ khiến bạn phát điên, đúng không? Bạn biết có một cách làm chuẩn cho mọi thứ, còn Carmack thì không biết. Bạn sẽ phải giải thích cùng một điều lặp đi lặp lại, lặp đi lặp lại mãi. Một bên là một thiên tài, một bên là một thứ thiếu hụt rất nghiêm trọng. Và theo Victor, đó chính là agent hiện nay.

Truyện tranh Reality: thiên tài không nhìn thấy, không nhớ — Trang "Reality": người dùng hét "No, we have a standard way of doing it!", thiên tài trong laptop đáp "I can't see it"; "I already explained it to you!", "You are absolutely right!"; "You just did it in the other repo", "I have no memory of that". Sáu khung tranh gói gọn hai vấn đề của cả talk: không nhìn thấy phần còn lại của hệ thống, và không nhớ gì từ lần trước.

2. Bảy lần giải thích cho một thay đổi

Để thấy chúng ta phải giải thích lại bao nhiêu lần chỉ trong một tương tác đơn giản, Victor đưa ra một ví dụ. Có bốn repo: UI, module one, module two, và platform. Anh muốn thay đổi UI rồi lan thay đổi đó đi qua cả hệ thống.

Lần 1. Đầu tiên thay đổi UI library, chẳng hạn đổi một cái button hay gì đó. Đây là lần giải thích đầu tiên, và nó không tránh được: chúng ta phải diễn đạt intent của mình.
Lần 2. Sau đó publish package. Ta sang module one, và phải giải thích lại điều vừa xảy ra trong UI library để module one có thể dùng package mới. Lưu ý rằng người làm bước này thường là một người khác: mỗi ô trong sơ đồ đều có thể do một người khác nhau làm.
Lần 3. Rồi ta phát hiện bản UI library vừa publish không chạy được với module one. Thế là quay lại repo UI, và phải giải thích lại cả thay đổi gốc lẫn vấn đề vừa gặp. Vì đó là một agent mới: nó không biết thay đổi ban đầu, và tất nhiên cũng không biết gì về lỗi.
Lần 4. Giả sử ta sửa xong và publish lại. Ta quay sang module one, và lại giải thích thay đổi mới trong ngữ cảnh của module one, cùng một cực hình.
Lần 5. Làm y như vậy cho module two.
Lần 6. Rồi ta sang repo platform, giải thích mọi thứ khớp với nhau như thế nào, và implement thay đổi ở đó.
Lần 7. Một tuần sau khi release, một bug xuất hiện trong UI component, và ta phải sửa nó. Ta khởi động một agent trong repo UI, và lại phải giải thích thay đổi gốc từ một tuần trước cùng với lỗi production đang thấy.

Một thay đổi ở UI library lan qua bốn repo, và mỗi lần chạm vào một repo là một lần giải thích lại cho một agent mới: tổng cộng bảy lần. Đường nét đứt là vòng quay lại UI khi phát hiện bản publish không chạy với module one.

Vậy là có bảy lần giải thích cho thứ về bản chất chỉ là một thay đổi. Và có thể bảy lần đó không do cùng một người, nhưng chúng vẫn đã xảy ra. Theo Victor, chuyện này cực kỳ điển hình khi làm việc với agent.

3. Hai nhóm vấn đề: không gian và thời gian

Vậy giải quyết thế nào? Có rất nhiều vấn đề góp phần tạo ra trải nghiệm này, nhưng chúng đại khái rơi vào hai nhóm.

Nhóm thứ nhất: agent bị trói vào repo (repo-bound). Agent nhìn thấy và thay đổi, nói chung, một repo tại một thời điểm. Nó không bao giờ nhìn thấy cả hệ thống, mà hệ thống đó có thể gồm hàng trăm hay hàng nghìn repo. Đây là thành phần không gian của vấn đề.

Nhóm thứ hai: amnesia. Agent quên công việc. Mỗi session bắt đầu với một tấm bảng trắng. Trong trường hợp này, con người trở thành bộ nhớ. Đây là thành phần thời gian của vấn đề.

Slide Problems to solve: two categories — Slide "Problems to solve: There are many. They fall into two categories." Thẻ đầu tiên là Repo boundaries: agent chỉ thấy và thay đổi được một repo mỗi lần, không bao giờ thấy hệ thống xung quanh. Thẻ thứ hai, Amnesia, đang mờ và sẽ hiện ra ở phần sau.

4. Repo boundary: agent đọc kém và viết còn tệ hơn

Victor nhìn kỹ hơn từng nhóm, bắt đầu với repo boundary.

Ở phía đọc. Không có một mô hình về cách các repo khớp với nhau, agent dựa vào con người để làm phần research. Nó không thể căn chỉnh code cho khớp với phần còn lại của hệ thống. Trong ví dụ trên, nó đã không thể căn chỉnh thay đổi UI với module one: con người không giải thích điều đó, nên một bản lỗi đã được ship. Nó cũng không thể tham chiếu best practice và standard một cách tin cậy, vì những thứ đó thường nằm ở repo khác.

Ở phía viết, mọi thứ còn tệ hơn. Agent viết vào một repo mỗi lần. Nghĩa là nó không thể validate thay đổi ở downstream. CI của module one lẽ ra phải fail khi gặp thay đổi UI, nhưng nó đã không fail. Agent cũng không thể cập nhật các consumer cùng lúc, dù trong lúc làm thay đổi UI nó có thông tin hoàn hảo để làm việc đó: nó biết chính xác mình đang làm gì. Vì vậy người dùng phải giải thích lại, một cách không hoàn hảo, cho từng consumer.

Thay đổi một thứ trải qua hai mươi repo nghĩa là giải thích lại hai mươi lần. Rất nhiều thời gian của developer bị tiêu tốn, và cũng rất nhiều token bị đốt.

5. Amnesia và graph thật của công việc

Nhóm thứ hai là agent quên. Agent không có episodic memory, tức là bộ nhớ về các sự kiện đã trải qua. Mỗi session là một tấm bảng trắng, và con người, trong trường hợp này, trở thành bộ nhớ.

Slide The second category: the agent forgets — Slide "The second category: the agent forgets." Dòng dưới: agent không có episodic memory, mỗi session bắt đầu từ bảng trắng, nên con người trở thành bộ nhớ.

Rồi Victor cho thấy graph công việc của bạn thực sự trông như thế nào. Ở tầng dưới là repository graph: các artifact mà tổ chức của bạn tạo ra, cộng với mọi repo open source bạn phụ thuộc vào. Có thể là một nghìn repo bạn sở hữu và hàng chục nghìn repo open source. Ở tầng trên là tất cả các agentic session đã tạo ra và chỉnh sửa đống code đó.

Các session liên quan với nhau, các repo liên quan với nhau, nên graph này là một bức tranh trung thực về công việc trong tổ chức của bạn. Nó mô tả thứ đang có ở tầng dưới, và nó đã hình thành như thế nào ở tầng trên. Đó là thứ bạn muốn agent của mình nhìn thấy.

Slide one graph of the work done: session graph và repo graph — Slide "Together, they form one graph of the work done." Các node tím là Session graph (mọi cuộc trò chuyện và quyết định về công việc, như Session A, B, C nối theo thứ tự session này tiếp nối session kia), các node xanh là Repo graph (artifact code mà tổ chức tạo ra, như auth-lib, tokens, gateway, api-core, sdk, nối theo quan hệ phụ thuộc). Đường nét đứt nối session với repo mà nó đã chạm vào. Dòng cuối: "This is what the agent should see."

6. Thứ agent thật sự nhìn thấy

Còn đây là thứ agent thực sự nhìn thấy: một session, một mẩu nhỏ trong code base của bạn, không có bộ nhớ. Vì nhìn thấy quá ít, nó dựa vào người hiểu hệ thống, tức là developer. Mỗi developer đều mang một phần của graph đó trong đầu, ít nhất là trong domain họ biết. Agent thì, nói chung, không có.

Nếu nghe chuyện này chưa thấy điên rồ, Victor đề nghị hãy tưởng tượng một agent chỉ được nhìn tối đa một file mỗi lần, và chỉ được nhìn lại năm message trước đó. Lại bị giới hạn cả về không gian (nó thấy được gì) lẫn thời gian (nó nhìn về quá khứ xa được bao nhiêu). Bạn sẽ nói làm việc như vậy là không thể. Thứ chúng ta có bây giờ giống với bức tranh điên rồ đó, và tổ chức càng phức tạp thì điều này càng lộ rõ.

Vòng tròn là session, hình chữ nhật là repo. Bên trái là graph của toàn bộ công việc; bên phải là phần agent hiện nay thấy được. Phần còn lại nằm trong đầu developer.

7. Polygraph: một synthetic monorepo

Victor nói sẽ cho mọi người thấy nhóm của anh đã giải quyết chuyện này như thế nào. Những tổ chức khác mà anh trò chuyện cũng có các giải pháp tương tự, nên anh đề nghị hãy nhìn vấn đề và giải pháp ở mức khái niệm, không phải ở công cụ cụ thể, dù công cụ thì cũng khá cool.

Họ đã build một meta-harness không phụ thuộc agent (agent-agnostic) tên là Polygraph. Anh sẽ cho thấy nó làm gì và sửa các vấn đề vừa nói ra sao.

Slide Polygraph, an agent-agnostic meta-harness — Slide giới thiệu: "An Agent-Agnostic Meta-Harness", Polygraph. Polygraph không phải là một agent mà là lớp bọc bên ngoài agent (Claude, Codex hay bất kỳ agent nào đã cài).

Ý tưởng đầu tiên họ đi tới là: nếu một user GitHub, bất kỳ user nào, có quyền truy cập hàng nghìn repo, một số là của họ, nhiều cái là open source, thì có thể phân tích chúng và rút ra rất nhiều metadata để build một unified dependency graph. Không một dòng code nào trong các repo đó bị thay đổi; tất cả diễn ra ở bên cạnh. Sau đó lấy metadata này đưa vào meta-harness, và tạo ra ảo giác về một code base lớn duy nhất mà agent có thể đọc và viết ở bất kỳ đâu.

Slide The synthetic monorepo — Slide "The idea: The synthetic monorepo". Nối các repository riêng lẻ thành một unified dependency graph, mà không di chuyển một dòng code nào. Hình minh hoạ có công tắc "Separate / Synthetic": các app, lib, shared utilities, design system, API nằm rải rác ở nhiều repo, khi bật sang synthetic thì được nhìn như một monorepo.

Victor cho xem graph cá nhân của anh. Anh chỉ sở hữu khoảng ba trăm repo, cộng với hàng nghìn repo open source mà các project của anh phụ thuộc vào. Polygraph tính ra mỗi repo, mỗi project trong mỗi repo, sản xuất ra cái gì; mỗi project tiêu thụ những package nào; chúng cung cấp và tiêu thụ những API nào; và rất nhiều thứ khác. Rồi nó khâu tất cả lại thành một khối code lớn duy nhất mà agent của bạn có thể làm việc cùng.

Graph cá nhân với hàng trăm node repo và quan hệ phụ thuộc — Graph cá nhân của Victor: các chấm vàng là repo anh sở hữu, các chấm xám là repo open source chúng phụ thuộc, các đường mảnh là quan hệ phụ thuộc mà Polygraph tính ra.

Việc đầu tiên Polygraph làm là cho phép bạn bắt đầu một session và mang các repository liên quan vào đó.

8. Kéo code vào chỉ là một nửa: CI như một vector

Để mang các repo vào một session, Polygraph phải làm mấy việc: set up source code, cài dependency, set up một agent cho mỗi repo, nối các agent đó với nhau để chúng làm việc cùng nhau, và cung cấp một TUI gọn gàng, đẹp mắt để thực hiện những thay đổi không tầm thường mà không bị lạc. Victor nói sẽ cho xem nó hoạt động ngay sau đây. Đó là phần kéo thông tin vào.

Slide Sets up cross-repo agentic sessions — Slide "Starting the session: Sets up cross-repo agentic sessions." Harness biến một thay đổi trải trên nhiều repo thành một thao tác đơn giản: chuẩn bị source, cài dependency, một agent cho mỗi repo, nối chúng lại, và một TUI để điều khiển.

Nhưng kéo thông tin vào chỉ là một phần câu chuyện, và nói thật thì đó là phần dễ. Thực hiện thay đổi mới khó hơn. Nếu có mười repo trong một session, bạn có thể có mười pull request. Bạn cần chạy CI, cần điều phối tất cả, cần làm đủ thứ. Và nếu một cái fail thì sao?

Slide Pulling in code is only half the story — Slide "Fixing repo boundaries: Pulling in code is only half the story." Thực hiện một thay đổi xuyên repo còn có nghĩa là: mở pull request, điều phối chúng, quản lý CI trên tất cả, và làm việc với các developer khác trên những PR đó.

Polygraph coi toàn bộ CI như một vector. Quay lại ví dụ ban đầu: khi chạy CI cho UI, module one và module two, nếu module one fail trong một Polygraph session, nó sẽ tự tìm ra ai cần sửa. Hoặc module one cần một patch, hoặc chính UI component đã sai và không tương thích với module one, khi đó tất cả đều cần patch. Polygraph cho phép bạn đối xử với một thay đổi phức tạp nhiều repo như thể đó là thay đổi trong một repo duy nhất.

9. Cùng bộ máy đó chữa luôn episodic memory

Cũng chính bộ máy đó sửa luôn vấn đề episodic memory. Vì Polygraph ghi lại công việc của bạn, bất kể có bao nhiêu repo tham gia, nó biết intent của bạn, các repository liên quan, các PR. Nó cũng ghi lại toàn bộ agent trace. Vì có tất cả những thứ đó, nó có thể liên kết chúng: công việc của bạn ở repo này nối với một công việc khác ở repo kia. Và tất cả điều đó cho phép restore bất kỳ session nào, bất kỳ phần việc nào, trên bất kỳ máy nào, hoặc tham chiếu nó từ bất kỳ đâu. Victor hứa sẽ cho xem ngay.

Kết quả là một agent có trí nhớ eidetic, tức trí nhớ kiểu chụp ảnh, về toàn bộ tổ chức của bạn. Nó hiểu các repo được viết thế nào, liên quan với nhau ra sao, được ghép lại như thế nào, và nhớ mọi session trong mọi repo của về cơ bản mọi developer. Điều đó tạo ra một trải nghiệm phát triển hoàn toàn khác.

Slide An agent with an eidetic memory of the entire organization — Slide "Meta harness: An agent with an eidetic memory of the entire organization." Nó biết mọi repo và nhớ mọi session của mọi developer. Bên phải là cửa sổ terminal của phần demo sắp tới.

10. Demo 1: bắt đầu một session nhiều repo

Victor bắt đầu demo bằng việc tạo một session, một việc đơn giản. Bạn chạy một lệnh, rồi chọn vài repository từ một danh sách. Đây là một GitHub org rất nhỏ với chỉ ba repo, vì là demo. Anh chọn backend và front end. Giả sử anh cần một thay đổi đụng tới API, phải cập nhật cả API lẫn cách dữ liệu được hiển thị.

Slide Demo 01 Starting a session — Demo 01: "Starting a session".

Anh phải đặt tên cho session, và chọn một agent trong số các agent đã cài. Anh chọn Claude, nhưng agent nào đã cài cũng hoạt động y như vậy. Anh nhắc lại: Polygraph không phải là agent. Nó là một meta-harness bọc quanh agent để khiến agent có năng lực hơn.

Một giây sau agent khởi động, và anh có thể tương tác với nó như thể đang ở trong một repo duy nhất, dù có nhiều repo tham gia. Anh đưa instruction, agent lên plan cho thay đổi. Trong TUI còn có vài animation khá cool. Cuối cùng agent tìm ra hai repo liên quan với nhau thế nào và thay đổi là gì.

Create a plan to add a new API to the backend which returns the title of the frontend webapp as a string and then plan the refactoring of the website title accordingly so it uses the one returned by the API. Don't implement just yet, just create the plan

Agent trong repo frontend lập plan và giao việc điều tra backend cho một subagent — Agent mở trong repo frontend nhận yêu cầu lên plan ở trên. Nó tự explore frontend, đồng thời giao một cuộc điều tra read-only phần backend cho subagent `polygraph-delegate-subagent` chạy song song. Hai agent, hai repo, một cuộc trò chuyện.

Agent hỏi người dùng chọn response shape cho endpoint mới — Khi gom kết quả từ cả hai repo, agent phát hiện một quyết định contract cần chốt: yêu cầu nói trả title "as a string", nhưng backend hiện chỉ trả JSON. Nó hỏi người dùng chọn `JSON { title }` hay plain text string, kèm ví dụ `GET /api/app-info` trả về `{ "title": "PolyShopping" }`.

Anh có thể yêu cầu agent implement thay đổi. Cách anh tương tác giống hệt như khi làm việc trong một repo. Việc có nhiều repo tham gia không thật sự quan trọng. Chỗ duy nhất nó trở nên quan trọng là anh có nhiều pull request. Nhưng anh cũng có một Polygraph session cho biết các pull request đó là gì.

Nhìn vào session, anh thấy một description. Description này mô tả công việc ở mức khái niệm, gần như vượt qua repo boundary: cần thay đổi thứ này ở repo này, thay đổi thứ kia ở repo kia. Nó cho anh một cái nhìn tốt về những repo nào tham gia, những pull request nào, CI trong các repo đó, mọi thứ anh cần biết. Rất nhiều thứ ở đây về cơ bản là những gì anh có trong một repo, chỉ là nhân lên nhiều lần. Và anh cũng có toàn bộ agent log được ghi lại, điều rất quan trọng cho việc resume, thứ anh sẽ cho xem ngay sau.

Trang web của Polygraph session fetch-app-title-from-backend — Trang session trên web của Polygraph. Phần Description có Goal (lấy title của app frontend từ backend thay vì hardcode, để "PolyShopping" có một source of truth duy nhất), Current progress cho từng repo (backend thêm endpoint `GET /api/app-info`, frontend thêm phần data-access và context để lấy title), Contract giữa hai bên, What worked và Next steps. Có tab Overview và Log view.

Graph view của session với hai repo backend và frontend — Cùng session ở dạng graph: repo backend và repo frontend, mỗi repo một node, cùng các pull request gắn với chúng.

Đến đây mọi thứ bắt đầu thú vị. Anh đã tiết kiệm được một lần giải thích lại: anh không phải giải thích lại thay đổi ở backend cho repo front end. Anh giải thích thay đổi một lần, và nó được implement ở cả hai repo, hai bên đồng nhất với nhau.

11. Demo 2: resume session trên máy đồng nghiệp

Tiếp theo là resume một session. Giả sử anh muốn một đồng nghiệp hoàn thành phần thay đổi ở backend, có thể vì họ là người sở hữu repo backend. Anh gửi session cho họ, và họ resume nó trên máy của họ. Họ chạy lệnh, trên một máy khác, mọi thứ khác, terminal cũng khác. Session được dựng lại trên máy họ, dù họ chưa từng có session này và chưa bao giờ làm việc với nó.

Slide Demo 02 Resuming a session — Demo 02: "Resuming a session".

Họ có thể chọn một agent, và agent đó có thể khác. Victor đã dùng Claude trong session gốc; giả sử đồng nghiệp dùng một agent khác, Codex. Quá trình setup y hệt diễn ra trên máy họ: cùng các repo, cùng SHA, mọi thứ được set up đúng. Agent khởi động trong từng repo giống như trên máy anh, và chúng lại được nối với nhau để làm việc cùng nhau. Tất cả đều được nạp sẵn trace đã ghi lại từ máy anh: agent của repo backend trên máy họ có cùng SHA và cùng lịch sử. Repo front end cũng vậy: được checkout đúng SHA, có agent chạy với đúng lịch sử.

Session được resume bằng Codex, agent đọc lại parent log — Session được resume trên một máy khác, lần này bằng Codex. Agent đọc skill của Polygraph, đọc `parent.log` để nắm lại phase plan, quyết định về contract và yêu cầu implement trước đó, rồi dừng lại chờ instruction mà không đổi code, branch hay PR. Panel bên phải là agent của repo backend với bản tóm tắt "What / How / Tests / Related" từ session gốc.

Vậy là agent của anh là Claude, của họ là Codex, nhưng chúng dùng chung bộ nhớ, và họ thực sự có thể tiếp tục thay đổi, như đoạn video nhỏ cho thấy. Phần chia sẻ bộ nhớ là chìa khoá: anh làm, họ làm, và hai bên có thể chia sẻ ký ức dù dùng hai agent khác nhau hay hai máy khác nhau. Toàn bộ trạng thái của session được hiện thực hoá trên máy họ. Victor nói thật ra nó ít là chuyện bộ nhớ, mà là chuyện trạng thái: trạng thái của thế giới gắn với session, chính điều đó cho phép họ tiếp tục session của anh dù ban đầu họ không làm gì với nó.

Anh so sánh nó với máy dịch chuyển (transporter) trong Star Trek: một bản sao đầy đủ của session cùng toàn bộ trạng thái hiện ra trên máy họ để họ làm tiếp.

Và đó cũng là cách Victor thường làm việc. Khi có một pull request cần anh review và anh có câu hỏi, anh thường không hỏi người viết. Anh resume session của họ trên máy mình, có được đúng trạng thái của họ, chạy được ngay, không cần setup gì, rồi chỉ việc nói chuyện với agent của mình về các quyết định đã đưa ra. Vì mọi quyết định đều nằm trong trace đã được ghi lại, agent của anh biết chính xác người kia đã nói gì với agent của họ.

Một ghi chú bên lề: cách này cũng hữu ích khi anh muốn chuyển từ Claude sang Codex giữa chừng một session vì có thứ gì đó bị sập.

12. Demo 3: tham chiếu một session cũ để sửa bug production

Victor quay lại trường hợp đã nói ở đầu: một bug rơi vào production. Lần này anh tham chiếu tới session cũ và nói, đại ý: "Về cơ bản là nó hỏng rồi, bạn tìm xem sai ở đâu và sửa được không?"

Slide Demo 03 Referencing a session — Demo 03: "Referencing a session".

We merged @plugin:polygraph:polygraph-mcp:polygraph://sessions/fetch-app-title-from-backend-c9be44e2 and there is a bug with how the title is displayed when it is too long. Can you check?

Agent sẽ tra cứu session đó và tải về những gì nó cần. Nếu description, tức thông tin ở mức cao, là đủ thì tốt. Nếu không, nó sẽ kéo về các repo liên quan, đúng SHA, agent log. Nó lấy tất cả thông tin này từ session gốc để dựng lại trạng thái, sao cho có thể thực hiện các bản sửa cần thiết.

Agent đọc resource polygraph session qua MCP rồi xem Navbar — Agent đọc session cũ qua MCP resource `polygraph://sessions/...`, biết rằng công việc trước đã đưa title vào Navbar và Footer, rồi tự đi xem title được render ở đó thế nào.

Và ở đây agent thực sự đưa ra bản sửa. Victor chỉ phải nói: "Chuyện này đã xảy ra. Có một bug." Thế thôi. Anh không phải cung cấp thêm thông tin nào.

Agent giải thích bug và bản sửa trong Navbar.tsx — "Build green, tests pass. Here's the fix." Bug: thay đổi fetch-app-title-from-backend làm title thành động (lấy từ backend, ghi đè được bằng `APP_TITLE`), nhưng Navbar render nó trong một hàng flex ngang không giới hạn độ dài. Với title cứng "PolyShopping" cũ thì ổn; title dài từ backend sẽ xuống nhiều dòng hoặc ép các nav link, làm vỡ layout (Footer không bị ảnh hưởng). Bản sửa trong `src/components/Navbar.tsx`: giới hạn title trên một dòng, tự cắt bằng dấu ba chấm khi quá dài (`max-w-[200px] truncate`), hiện đầy đủ khi hover.

13. Demo 4: để agent tự chọn repo

Cho tới giờ Victor tự tay chọn repo và session, nhưng không nhất thiết phải vậy. Thay vì chọn repo bằng tay, anh có thể nói với agent điều mình muốn. Hãy nhớ rằng graph chứa tất cả trí tuệ về cách các repo liên quan với nhau. Anh có thể nói với agent: "Tìm mọi repo phụ thuộc vào một version cụ thể của một thư viện và cập nhật nó." Và agent biết. Anh không phải chọn chúng; nó biết rất nhiều metadata về những gì đang diễn ra.

Slide Demo 04 Intelligently selecting repos — Demo 04: "Intelligently selecting repos".

Polygraph thêm mọi consumer của vitest vào session update-vitest — Session `update-vitest`: agent tự tìm mọi repo dùng vitest trong org (ocean, nx-ai-agents-config, react-template, angular-template, typescript-template, nx, nx-labs, dpe-tools) và thêm tất cả vào session, báo rằng không consumer nào bị bỏ sót. Session này chạy bằng Codex.

Anh cũng có thể hỏi những câu hỏi lỏng hơn. Ví dụ anh muốn viết một blog post hay một bài viết: anh mô tả nó, và agent sẽ tự tìm ra repo nào liên quan nhất dựa trên quan hệ giữa các repo và nội dung bên trong chúng.

14. Tìm lại session liên quan, và chuyện code nhất quán

Một ví dụ khác. Giả sử anh muốn thêm vector indexing cho PR collection, và muốn biết liệu đã có ai, vào bất kỳ lúc nào, trong bất kỳ repo nào, làm thứ gì đó liên quan mà anh có thể học theo.

I'm adding vector indexing to the PR collection. Get insights from previous sessions?

Agent nạp skill polygraph và tìm các session trước liên quan tới vector indexing — Trong session `add-pr-indexing` chỉ có một repo, agent nạp skill polygraph, đọc ngữ cảnh session hiện tại, rồi gọi Polygraph MCP để tìm các session cũ liên quan tới PR collection và vector indexing.

Khi làm vậy, anh thấy agent tìm được vài session có vẻ liên quan, và anh có thể nạp một trong số chúng hoặc cả hai. Trong demo, agent tìm ra hai session: một session đã thêm vector indexing và repository search (cùng cơ chế mà anh sắp áp dụng, chỉ là trên repositories collection thay vì PR), và một session của một đồng nghiệp từ khoảng một tháng trước đã thêm full-text search cho chính PR collection. Agent nhận xét hai session này "kẹp" đúng nhiệm vụ: một cái cho thấy pattern vector indexing, một cái cho thấy PR collection đang được sửa.

Điều này hữu ích vì nhiều lý do. Victor nêu một ví dụ nhỏ: nó giúp về best practice và tính nhất quán. Thay vì làm mọi thứ từ đầu, nơi mỗi implementation lại là một bản "may đo" riêng, anh có thể bảo agent lặp lại cách làm đã dùng trong một session của một kỹ sư anh tôn trọng. Thế là code xuyên qua các repo trở nên nhất quán. Đó là một chuyện lớn.

Tất nhiên còn nhiều thứ hơn thế. Nếu đang ở trong một repo mà anh hỏi về session, nó sẽ ưu tiên những session liên quan tới repo đó, và ngược lại. Nếu anh hỏi về repo, nó sẽ nhìn session hiện tại và xem những session tương tự thường mang những repo nào vào. Có rất nhiều trí tuệ thú vị khiến nó hữu ích hơn nhiều so với vẻ ngoài lúc mới nhìn.

15. Demo 5: gọi Polygraph ngay giữa một session agent

Cuối cùng, mọi thứ Victor cho xem tới giờ đều dùng Polygraph CLI, tức CLI của meta-harness, để khởi động, rồi từ bên trong đó mới chạy Claude, Codex hay agent nào cũng được. Nhưng không bắt buộc phải dùng theo cách này.

Slide Demo 05 Starting a Polygraph session in the middle of an agent session — Demo 05: "Starting a Polygraph session in the middle of an agent session".

Trong ví dụ này anh đã ở sẵn trong một session Claude, nhưng cách này chạy với bất kỳ agent nào. Anh có thể nói: "Này, tôi nghĩ một repo riêng sẽ hữu ích đấy." Chẳng hạn anh đang làm một Vitest plugin trong repo Nx, và anh có thể hỏi: "Bạn thêm repository Vitest vào session này được không, để tôi biết chuyện gì đang xảy ra?" Khi đó agent sẽ gọi Polygraph, set up mọi thứ, cấu hình tất cả, và mang thư viện Vitest, tức repo open source vitest-dev/vitest, vào session của anh.

Polygraph session mới với nrwl/nx và vitest-dev/vitest read-only — Agent khởi tạo một Polygraph session mới ngay trong session đang chạy: repo `nrwl/nx` là initiator (repo đang làm việc), còn `vitest-dev/vitest` được thêm vào ở chế độ read-only. Sau đó người dùng hỏi "Can you check how vitest is built?".

Giờ agent của anh có thể explore repo đó, tìm hiểu nó hoạt động thế nào, và có thể giải quyết một issue anh đang gặp trong repo của mình. Victor nói anh thích cách này hơn nhiều so với, chẳng hạn, Context7, vì khi có code thật thì agent có thể đi rất sâu.

Agent giao việc điều tra cách build vitest cho một subagent — Agent giao việc điều tra cách vitest được build cho một subagent chạy trong repo vitest (read-only), trong khi nó tiếp tục ở repo nx.

Đó là cách hai vấn đề anh mô tả ở đầu được giải quyết.

16. Kết: gỡ giới hạn không gian và thời gian

Victor tóm lại: agent bị giới hạn trong không gian và thời gian. Chúng chỉ nhìn thấy một phần nhỏ của code base, và không biết quá khứ. Cả hai giới hạn này đều có thể được gỡ bỏ.

Polygraph cho agent quyền truy cập vào toàn bộ code mà tổ chức của bạn có thể với tới, cả code bạn sở hữu lẫn open source, nên nó không còn bị giới hạn về không gian. Agent nào cũng có thể mang tất cả vào. Và nó cho agent một bộ nhớ hoàn hảo về những gì đã xảy ra: mọi session, mọi quyết định đều nằm trong tầm với.

Slide summary: the agent can see all the code and remember every decision made — Slide tổng kết: "The agent can see all the code and remember every decision made." Lại là graph hai tầng ở đầu talk, session graph ở trên và repo graph ở dưới, nhưng giờ agent nhìn thấy toàn bộ.

Vì bộ nhớ này vượt qua ranh giới giữa các developer, không phải chỉ riêng cho từng người, agent có thể có nhiều ngữ cảnh hơn bất kỳ developer đơn lẻ nào. Hãy hình dung một nghìn kỹ sư trong một tổ chức tạo ra đủ loại session; tất cả đều truy cập được bởi từng người trong số họ. Gần giống như tộc Borg: agent nào cũng có thể chạy, nhưng mỗi developer đều đóng góp vào một tâm trí tập thể lớn duy nhất.

Victor kết: nếu thấy thú vị, tên anh là Victor, bạn có thể follow anh trên Twitter. Nếu muốn thử, hãy vào trypolygraph.com và xem nó có hợp với bạn không. Cảm ơn mọi người.

Slide follow Victor Savkin — Slide cuối: Victor Savkin, x.com/victorsavkin, và Polygraph (early access) tại trypolygraph.com.