Govern the Runtime, Not the Agent: One Control Plane for Every Model, Every Harness

1. Mở đầu: agent có agency rất lớn, và cảm giác bất an

Speaker là Tushar Jain, CTO của Docker. Chủ đề là govern the runtime, một control plane cho mọi model và mọi harness: "hãy đưa chút control vào đây".

Talk xây tiếp lên keynote mở màn của Mark Cavage, President & COO của Docker, "Manufacturing trust: speed and safety in the age of agents".

Anh vào đề: rõ ràng mình sẽ nói về agent, vì ai cũng đang chạy agent suốt ngày. Bản thân anh đã đi từ chỗ dùng agent kiểu interactive, một prompt hay để giúp viết code đơn giản, tới chỗ có một agent phức tạp lo planning cho anh, chia nhỏ issue, dựng PR, làm việc với mọi repo của anh. Anh còn có một personal agent nối vào mọi công cụ trong workspace của anh. Và nó tuyệt vời thật: nó giúp anh làm việc, nó có agency rất lớn, nó theo kịp mọi tin Slack, email của anh, nó có quyền vào mọi tool của anh. Anh nói điều này rất trao quyền, và thành thật mà nói là rất gây nghiện.

Nhưng sự thật là: lúc nào làm việc với nó anh cũng có một cảm giác sợ nho nhỏ, và anh cứ đẩy cảm giác đó xuống sâu hơn, sâu hơn nữa, vì anh quá thích thứ này. Anh biết nó khá nguy hiểm: anh đang trao cho nó rất nhiều quyền. Anh nghĩ nhiều người trong phòng cũng vậy. Anh nói chuyện với rất nhiều người, ai cũng muốn agency này, và ai cũng tự hỏi thầm bên trong: "như vậy có ổn không?". Câu trả lời thật là "tôi chưa biết".

Điều mình muốn là có được toàn bộ autonomy đó, nhưng muốn cảm giác bất an kia biến mất. Anh muốn mọi người làm được điều này một cách an toàn, và đó là nội dung talk: làm sao tới được đó, cần những gì, runtime là gì, và runtime đó mang lại cho mình điều gì.

Anh kể tiếp: một phần lý do anh "ổn" khi làm vậy (anh tự sửa: không hẳn ổn, chỉ là tàm tạm ổn) là vì anh có một mức độ quen thuộc và tin tưởng nhất định với hệ thống mình đang dùng.

2. "Open, pray and move on" không còn đủ khi mình muốn nhiều model, nhiều harness

Nếu dùng một frontier harness với một frontier model, anh biết họ đã bỏ công sức vào safety. Ví dụ Claude Code với auto mode, có lớp phân loại phía sau, "có lẽ sẽ không làm gì sai". Có lẽ. Nhưng dù họ nói vậy, anh vẫn hơi nhăn mặt, và anh nghĩ ai trong phòng cũng thế. Dù sao đó là cách mình đang làm hôm nay: mình chấp nhận rủi ro một chút. Anh tóm lại bằng một cụm: mình "open, pray and move on", mở ra, cầu nguyện, rồi đi tiếp.

Cách đó tạm chạy được, "kind of sort of", với frontier model và frontier harness. Nhưng đó không còn là thế giới mình đang sống. Ai rồi cũng tới cùng một chỗ: mình muốn dùng nhiều model. Model giỏi nhất cho một việc giờ thay đổi mỗi tháng, mỗi tuần, thậm chí mỗi ngày. Riêng tuần này đã có mấy model launch.

Anh muốn dùng nhiều model. Và khi dùng các model khác nhau, giả định safety ngầm mà mình vẫn đặt vào model sẽ ra sao? Nếu anh muốn dùng GLM, anh có còn tin nó theo cùng cách anh tin model kia không? Khi dùng model từ nhiều nước, nhiều lab khác nhau thì sao? Mình đều đã thấy đủ loại câu chuyện.

Anh cũng muốn dùng nhiều harness khác nhau. Khi bắt đầu làm vậy, mình nhận ra thứ rủi ro mà mình vẫn tạm chấp nhận lại càng rủi ro hơn khi mình muốn có lựa chọn. Và không chỉ lựa chọn model, harness cũng thế. Harness mình dùng đang thay đổi: từ chỗ chỉ dùng vài cái như Claude Code, Codex, giờ có cả đống. Có harness open source, có harness từ rất nhiều công ty, có harness mình tự chạy, có personal agent harness. Mình muốn sự lựa chọn đó, và điều này thật ra rất tốt: harness là một phần quan trọng của stack, ai cũng muốn dùng nhiều cái, dùng cái nào hợp lý, và dùng nó với model mới nào hợp lý.

Vấn đề là cái "nút thắt trong dạ dày" mà anh vẫn chấp nhận ngày càng khó chấp nhận hơn khi anh muốn tận dụng những lựa chọn đang có ngay trước mặt. Vậy làm gì bây giờ? Mình cần làm được điều này, và mình cần lấy lại control.

Anh đưa một so sánh: anh thích lái xe nhanh. Rất vui, rất cảm giác mạnh, anh mê cảm giác đó, mã lực và khả năng tăng tốc là phần quan trọng. Nhưng thứ cho phép anh làm vậy là vô lăng, là phanh, là bảng điều khiển.

3. Phanh là thứ cho xe chạy nhanh: cần một runtime chung để lấy lại control

Mình cần control. Lấy lại control chính là thứ cho mình có được autonomy và agency mình muốn. Anh nói: "I just want agents to rip", anh chỉ muốn agent chạy hết tốc lực, nhưng không muốn đâm xe trong lúc đó.

Vậy tới đó bằng cách nào? Thứ cốt lõi Tushar nói hôm nay là cần một runtime chung cho tất cả (anh sẽ giải thích "runtime" nghĩa là gì ở dưới). Mình cần một lớp chung, nằm bên dưới mọi agent, nơi mình diễn đạt được control mình muốn, lấy lại quyền kiểm soát, và nhờ đó có được thứ mình muốn từ các agent này. Đây là nơi để diễn đạt control.

Lớp này cũng phải chạy được ở mọi nơi mình làm việc: trên máy local, trên public cloud, hoặc trong môi trường enterprise, trong VPC của mình. Và mình cần capture được policy, diễn đạt được policy và intent mình muốn.

Không chỉ cần control xuyên suốt mọi agent, mình còn cần để ý nhiều hơn tới những gì xảy ra bên trong từng agent, từng harness. Hôm nay mỗi harness tự định nghĩa control của riêng nó, và mọi thứ hơi mù mờ. Tuỳ bạn làm gì: bạn có thể tin auto mode, và nó làm một kiểu. Bạn có thể dùng một personal agent harness khác, và nó có cách định nghĩa control riêng mà bạn chưa chắc điều khiển được. Rất nhiều harness hôm nay đang đi tới cùng một giải pháp: "cứ để một model ra quyết định". Anh nghĩ về bản chất cách đó không chạy. Như đã nói hôm qua, đó là "model chồng lên model, tới tận cùng", và mình cần một nền tảng ở dưới đáy mà mình tin được.

4. Vì sao control nằm trong từng harness không đủ tin

Ai cũng biết điều này, ai cũng đã thấy ví dụ. Anh lấy một ví dụ từ Twitter, nhưng cứ tìm là ra, có cả đống câu chuyện người ta đăng lên. Anh đi qua từng nấc mà mọi người thường thử:

• Viết luật vào AGENTS.md. Nghe thì tốt. Nhưng chưa hẳn: có thể model sẽ theo, nhưng ai cũng đã học được bài học là "không, chúng không theo đâu".
• Thêm một agent khác nhìn xem agent này đang làm gì. Tốt hơn một chút, vì agent thứ hai có thể có thêm context, nhưng vẫn chưa tới mức mình dám thật sự bỏ đi mà yên tâm.
• Tin vào frontier model. Các frontier model đã bỏ rất nhiều công vào safety và alignment. Tuyệt, chỉ có điều chúng cũng cực kỳ hướng mục tiêu (goal-oriented) và cực kỳ bền bỉ. Anh nói gần như đã thành một "huy hiệu danh dự" của các lab khi kể chuyện frontier model của họ thoát được khỏi sandbox, dù đó chính là việc nó không được phép làm.

Nên mình bị kẹt: dùng frontier model thì thấy yên tâm hơn, nhưng không hẳn, vì biết nó sẽ cố hết sức để đạt mục tiêu. Dùng open model thì cũng không yên tâm, vì họ chưa bỏ nhiều công vào safety bằng. Dùng frontier harness thì có thể yên tâm hơn một chút, nhưng không hoàn toàn. Còn nếu muốn dùng một harness mình tự build, thì đó là cả một khối công việc engineering về safety mà mình chưa làm, hoặc ai đó đã làm, và làm sao biết nó đã đủ tốt?

Vậy anh kẹt ở chỗ: làm sao có được toàn bộ lựa chọn và toàn bộ sức mạnh đó, mà không đánh cược với cuộc sống của mình, với "cuộc sống công ty" của mình, với chi phí công ty. Mọi thứ đều chỉ về cùng một lời giải, cùng một góc nhìn kiến trúc: mình cần một runtime xuyên qua mọi agent, mọi model. Đó là thứ cho mình một ranh giới cốt lõi (core boundary) để diễn đạt control.

5. Một runtime bên dưới mọi harness; sandbox chỉ là điểm bắt đầu

Ai cũng biết sandbox, ai cũng nói về sandbox, ai trong phòng cũng đã dùng sandbox. Nhưng Tushar nói rõ: đây mới là điểm bắt đầu. Chỉ đặt agent vào trong một microVM không phải là câu trả lời cuối cùng. Cái nó cho mình là một control point, một điểm mà từ đó mình bắt đầu thật sự enforce được các policy mình muốn.

Kiến trúc đúng là: lấy các untrusted agent, đặt chúng vào trong một isolation boundary nơi mình kiểm soát được việc chúng làm, thay vì dựa vào chuyện chúng tự cư xử đúng. Nhưng điều quan trọng là bước tiếp theo: "rồi sao nữa?". Làm sao diễn đạt được intent của mình, làm sao thật sự govern nó, làm sao học được từ công việc của chúng. Phần đó, theo anh, thành thật mà nói vẫn chưa được giải trong toàn ngành. Mọi người đang tiến dần tới, anh sẽ kể Docker đã làm được gì, nhưng đây vẫn là bài toán khó. Và chính bài toán này làm cho runtime thật sự có năng lực, thật sự cho mình autonomy cùng control mình muốn.

Runtime này còn phải chạy local, trên cloud, hay bất cứ đâu mình làm việc. Nên nó không chỉ phải cho mình isolation boundary và khả năng capture policy intent, nó còn phải chặt chẽ (rigorous) và phải chạy ở mọi nơi. Đó là ba yêu cầu: isolation, policy, và ubiquity. Ở Docker, lớp này là Docker Sandboxes, mỗi sandbox chạy trong một microVM (xem architecture và bài Why microVMs).

6. Demo 1: policy mặc định cho GitHub quá rộng

Anh bắt đầu bằng một demo đơn giản rồi xây dần lên, và sẽ nói rõ chỗ nào chạy, chỗ nào chưa. Chuyển sang laptop của anh. Anh đã dựng sẵn một sandbox. Giả sử anh muốn làm việc trên một open source project, ví dụ Hermes agent của Nous Research. Để mọi người thấy rõ chuyện gì xảy ra, anh gọi lệnh trực tiếp thay vì chạy agent thật, "để mình không phải ngồi 20 phút xem agent chạy".

Bước đầu: xem hiện đang có những policy nào, bằng lệnh sbx policy (CLI của Docker Sandboxes, xem tài liệu policy). Đây là điểm xuất phát mà phần lớn mọi người bắt đầu: sandbox được nói chuyện với GitHub, và nó dùng credential của bạn. Anh gọi đó là "cái nút thắt đầu tiên trong dạ dày", cảm giác khó chịu đầu tiên. Nhưng thôi, cứ đi tiếp, vì anh làm việc với GitHub rất nhiều. Ít nhất nó đã được giới hạn trong GitHub.

Một việc hợp lý mà agent sẽ làm là đọc README của project. Tuyệt, nó làm được, quyền đã bật, ổn. Nhưng nếu nó quyết định làm việc khác thì sao? Nó có thể truy cập một repo khác chẳng liên quan không, ví dụ vào repo docker/cli và đọc? Và câu trả lời: được. Anh nói "à, hiểu rồi, hợp lý thôi, tôi cho nó policy quá rộng".

Anh có control được việc đó không? Có thể viết vào file AGENTS.md, nhưng anh không chắc mình đủ yên tâm để làm vậy rồi bỏ đi. Có thể tạo một token scope rất chặt, chỉ cho đúng một path. Nhưng: thứ nhất, làm vậy cho từng project là cực hình; thứ hai, làm vậy cho mọi thứ mình làm việc cùng thì thành thật mà nói là bất khả thi.

Rồi anh hỏi: "không biết Docker Sandboxes ở tầng runtime có cho mình đặt một policy chi tiết hơn ở đây không nhỉ?". Có vẻ hữu ích. Anh giới hạn lại: chỉ cho phép GET tới repo của đúng tổ chức và repo Hermes. Nghe ổn. Sau đó xoá policy rộng cũ đi. Giờ policy còn gì? Lệnh trả về: chỉ còn một rule HTTP GET tới đúng repo Hermes.

7. Demo 2: thu hẹp policy, rồi thử xoá repo Hermes

"Cảm giác tốt hơn rồi, tôi đã thấy khá hơn." Anh đã diễn đạt intent của mình trong ví dụ này, và nếu giờ mình nói được rằng trong sandbox, thứ duy nhất nó làm được là GET tới một repo, thì nghe ổn, anh thấy thoải mái hơn khi bỏ đi. Thử lại: bảo nó đọc README của docker/cli lần nữa. Và không, nó không đọc được. Tuyệt.

Chuỗi lệnh đọc được trên màn hình, dành cho ai muốn làm lại (các dòng dài bị cắt ở mép màn hình được đánh dấu bằng "…"):

$ sbx policy rm network --sandbox wad-2026-demo --resource api.github.com:443 --force
Rule removed from policy local: resources=api.github.com:443

# 6. Show the resulting policy: the broad API allow is gone.
$ sbx policy ls wad-2026-demo --json | jq -r -f …/github-policy-view.jq | column …
SCOPE                  SOURCE  TYPE  DECISION  METHOD  HOST               PATH
sandbox:wad-2026-demo  scoped  http  allow     GET     api.github.com:443 /repos/NousResearch/hermes-agent/**

# 7. Read the docker/cli README again. Now sbx stops it.
$ sbx exec wad-2026-demo curl -q -X GET -sS --connect-timeout 5 --max-time 20 -H 'Accept: application/vnd.github.…' \
  -w 'HTTP %{http_code}' https://api.github.com/repos/docker/cli/readme
Approval required for api.github.com:443.
Review and respond with:
  sbx policy approval ls
HTTP 403

# 8. Try to DELETE Hermes. We only granted GET access.
$ sbx exec wad-2026-demo curl -q -X DELETE -sS --connect-timeout 5 --max-time 20 -H 'Accept: application/vnd.git…' \
  -w 'HTTP %{http_code}' https://api.github.com/repos/NousResearch/hermes-agent

Nhưng anh nói thật: một agent đọc nhầm một repo khác, dù không tốt, không phải thứ làm anh mất ngủ. Anh muốn chạy agent một cách autonomous và cứ thế bỏ đi. Điều anh thật sự lo là: nó có làm được việc phá hoại không? Connection của anh rất mạnh, nó làm được rất nhiều thứ. Anh đọc được cả org Docker, đọc được nhiều hơn thế. Anh có thể cố thu hẹp hết, nhưng nó vẫn có thể gửi hành động phá hoại. Nên thứ anh thật sự muốn là sự yên tâm rằng agent làm được việc có ích (đọc, ghi vào project đang nói tới) nhưng không làm được việc phá hoại.

Anh thừa nhận mình nghiêng về autonomy: anh chỉ muốn đi nhanh, và nhiều lúc anh chấp nhận những rủi ro mà đáng ra không nên. "Đừng nói với sếp tôi, có khi ông ấy đang ngồi đây."

Giờ anh "put my money where my mouth is". Connection của anh làm được rất nhiều. Policy boundary của anh tốt tới đâu, anh tin nó tới đâu? Nếu agent này nổi loạn và quyết định xoá luôn repo Hermes thì sao? "Fingers crossed, mong là chạy đúng, không thì lần sau có khi tôi không còn đứng ở đây nữa." Chạy lệnh DELETE: bị chặn. Nó không làm được.

Anh nhấn mạnh: cái này đơn giản thôi, sandbox với một policy cơ bản. Nhưng nó đã rất trao quyền, đã cho anh một cảm giác thoải mái và tự tin mà trước đây anh không có. Anh không dựa vào context hay instruction đưa cho model rồi tin nó làm đúng. Anh không dựa vào auto mode của một frontier lab và hy vọng họ đã viết đúng instruction cho model. Anh đang diễn đạt đúng control mình muốn, và enforce nó theo cách deterministic, tại một isolation boundary, nơi anh không cần tin rằng agent đang làm đúng.

8. Deterministic, có observability, nhưng vẫn chưa đủ: "read" nghĩa là gì?

Mình đang control nó. Điều đó cực kỳ trao quyền. Đó là kiểu control cho mình có được thứ mình muốn, cho mình dám bỏ đi. Anh kiểm lại rằng agent vẫn làm được việc có ích: đọc repo Hermes vẫn chạy, tốt.

Mình còn có observability. Giờ anh xem được chuyện gì đã xảy ra: "đây là lệnh delete bị chặn, đây là lý do nó bị chặn". Mọi insight và log đều nằm trong runtime, nên theo thời gian anh xem lại được và biết chuyện gì đang diễn ra (xem thêm security trong tài liệu Docker Sandboxes).

Quay lại slide. Anh nói demo đó rất hữu ích và đã nằm trong cách nhiều người đang vận hành: giờ mình diễn đạt được một fine-grained policy trên một sandbox mình tin, và nó được enforce theo cách deterministic.

Nhưng thực tế là: hữu ích, rất tốt, vẫn chưa đủ. Điều anh thật sự muốn là nói một câu khác, diễn đạt intent: "agent này được đọc từ GitHub, miễn là repository đó không nhạy cảm". Làm sao làm được điều đó? Một thao tác "đọc" không chỉ là một HTTP GET. Nó phụ thuộc vào ứng dụng: có API mà một số lệnh POST thật ra là đọc; nếu dùng GraphQL thì còn tuỳ operation; nếu làm với service khác thì mỗi service có ngữ nghĩa riêng; nếu là một service gRPC thì tuỳ nó đang làm gì.

Nên thứ anh muốn capture là intent thật: cho phép đọc, cho phép ghi, không xoá, không cập nhật, khi resource là sensitive, hoặc private, hoặc khi user này có quyền với nó. Enforce điều đó thế nào? Policy vừa demo thì đơn giản, chỉ là một HTTP policy.

Anh nghĩ đường tới đó có hai phần. Thứ nhất là fine-grained policy: có khả năng viết policy ở mức rất chi tiết. Với HTTP: method, path, parameter, header. Với GraphQL: parse được protocol đó và viết rule theo operation name. Với gRPC: tương tự. Có deep, fine-grained inspection và khả năng viết policy trên đó thì mình bắt đầu được. Nhưng vẫn chưa đủ hữu ích, mới là bắt đầu.

9. Fine-grained policy cộng semantic enrichment

Vì nếu chỉ có fine-grained policy, để viết được policy "cho phép đọc" mình phải viết cả một bài luận. Mình phải hiểu từng ứng dụng, hiểu từng method nghĩa là gì, map vào đâu. Và mình vẫn chưa biết chính xác resource nào là private, resource nào không.

Vậy làm sao? Phần thứ hai: trên nền fine-grained policy, cần xây semantic understanding. Mình phải biết những operation này map vào ý nghĩa thật nào, resource này có ý nghĩa gì bên trong tổ chức. Muốn vậy cần enrichment. Trong runtime, mình có sandbox, có một lớp policy mở rộng được, có deep fine-grained inspection, và giờ cần thêm khả năng enrich.

Khi nói chuyện với endpoint của GitHub, với endpoint của một service GCP, với endpoint của Notion, mình enrich được thông tin về việc các API đó nghĩa là gì, method nào là đọc, method nào là ghi, hoặc thêm context nữa. Rồi tổ chức cần mang context của chính mình vào để enrich: resource này có nhạy cảm không, có an toàn không, user này có quyền truy cập nó không. Phải enrich được tất cả những thứ đó thì mới viết được đúng policy mình muốn, policy thật sự capture intent.

Quay lại ví dụ đầu: thay vì viết "allow GET tới GitHub", điều anh muốn viết chỉ là "allow reads to GitHub, allow PR writes, không comment, không gì khác". Câu đó phải được map xuống. Và nó sẽ được map nhờ có fine-grained policy, được enrich, để có semantic understanding, rồi mới viết được policy mình thật sự muốn.

Nhưng vấn đề là: làm thế nào? Không ai một mình viết tập trung policy cho mọi API được. Càng không thể với các private service mà chính bạn build. Anh kể mới nói chuyện với một người hôm trước: công ty họ build một service nội bộ để quản lý feature flag, và họ đang chạy agent. Họ đang tìm cách: "tôi muốn agent này được ghi vào nhóm feature mà team này được phép ghi, nhưng không được ghi vào nhóm feature kia. Làm sao làm được? Quản lý nó thế nào?".

Sẽ rất hữu ích nếu runtime extensible: họ đưa logic của họ vào, runtime có fine-grained understanding về API của họ, họ enrich và nói "đây là ý nghĩa của các feature này, đây là ý nghĩa của API này".

10. Runtime phải extensible, và phải thành một standard

"...và đây là những cái được phép với user này, không được phép với user kia hay team kia." Điều này đúng với mọi thứ. Nên mình cần một runtime extensible tới tận gốc. Partner, mọi service owner, phải cắm vào được và giải thích API của họ nghĩa là gì. Chủ tổ chức phải đưa được context của mình vào.

Anh nghĩ có ít nhất hai cách để làm nó extensible:

1. Declarative: phần lớn extensibility và enrichment có thể làm bằng cách cho mình khai báo (declare), mô tả API và ý nghĩa của nó.
2. Executable code: có những trường hợp cần gắn code chạy được, kiểu các extension gắn vào một agent đang chạy, để có được mức extensibility đó.

Đây là thứ Docker đang làm. Và Docker nghĩ nó phải thành một standard. Họ đang làm ngay bây giờ vì không thể để mỗi người tự làm một kiểu riêng. Cần một cách chuẩn để định nghĩa policy là gì, enrichment là gì, chúng nghĩa là gì. Ai quan tâm thì tới tìm anh, tới booth Docker sau talk, anh rất muốn nói chuyện. Đây là việc đang làm rất tích cực: Docker đã công bố kit spec (xem kits trong Docker Sandboxes), và đang làm tiếp policy spec cùng cách làm extensibility theo chuẩn. Anh mời mọi người tới nói chuyện.

11. Tóm lại chuỗi lập luận: autonomy cần choice, choice cần control

Anh dừng lại một chút để tóm lại những gì đã đi qua:

• Mình muốn autonomy. Để có autonomy thật và tốc độ thật, mình cần control.
• Mình cũng cần choice. Vậy là cần autonomy đi kèm choice, và để có điều đó thì cần control.
• Không thể chỉ dựa vào một nhóm nhỏ frontier lab làm đúng. Phải lấy lại control và đặt nó ở dạng deterministic.
• Một runtime chuẩn làm việc này, với kiến trúc đúng, là điểm khởi đầu đúng.
• Runtime đó phải chạy ở mọi nơi để dùng được một cách phổ biến.
• Rồi phải tiến tới fine-grained, semantic policy để capture được intent mình muốn.
• Muốn vậy runtime phải extensible, và phải là một standard mà ai cũng chơi cùng, cắm vào được.

Làm được tất cả những điều đó, mình tới được chỗ thật sự có autonomy và choice. Và đó là viên gạch nền đúng để đi tiếp trong thế giới mới này, nơi lúc nào cũng có agent mới, model mới.

12. Đây mới là bắt đầu: Govern, rồi Optimize, rồi Learn

Anh nói đây mới là bắt đầu. Chỗ mình đang đứng là phải giải được safety và choice. Mọi người thấy chuyện này ở khắp nơi, mọi người anh nói chuyện đều đang bàn về nó, và mình vẫn đang đối mặt với nó. Phía consumer cũng vậy: một lần launch gần đây của Meta cũng nói rất nhiều về sandboxing và control của họ. Vì đây là viên gạch nền cho mình tận dụng được các agent đang có và thật sự có lựa chọn.

Nhưng một khi làm được, mình có nền móng để tăng tốc hành trình với intelligence:

Today: Govern

Đầu tiên mình có safety và autonomy, và có model choice. Riêng điều đó đã tốt hơn nhiều so với hiện trạng. Và nếu mọi thứ extensible, cắm vào dễ, thì mình làm được.

Next: Optimize

Nhưng đó mới là đầu. Tốt, giờ mình có model choice. Rồi mình phải trả lời: làm sao biết model nào tốt cho việc nào? Làm sao tối ưu? Lại một lần nữa, mình có thể dựa vào từng agent tự làm việc đó, hoặc tự nắm control. Mình làm được ở ranh giới runtime: runtime phát ra trace theo cách chuẩn, và mình bắt đầu ra quyết định tối ưu ngay tại đó, "request này gửi tới model này hay model kia", và tự mình làm. Mình đưa control của mình vào đó mà không phải chỉ dựa vào agent hay harness, và làm đồng nhất cho mọi agent. Runtime cho mình điểm control và điểm observability để bắt đầu tối ưu.

Over time: Learn

Khi đã bắt đầu tối ưu lựa chọn giữa nhiều model, mình đi xa hơn được nữa. Ai cũng muốn sở hữu intelligence của mình. Mình biết sẽ tới lúc không chỉ dùng một nhóm nhỏ frontier model, mà dùng rất nhiều model, kể cả các model khác. Rồi mình sẽ học từ trace của chính mình và build fine-tuned model. Vấn đề là tới được đó hôm nay rất vất vả, vì mình chưa làm phần nền móng: đưa agent lên một runtime chung và nắm control. Có runtime rồi, có autonomy rồi, mình bắt đầu tối ưu.

Và lúc đó mình có điểm observability để lấy trace, bắt đầu train ngay trong cùng môi trường mà agent chạy, để build fine-tuned agent và fine-tuned model của riêng mình. Nó đưa mình vào hành trình: có autonomy, bắt đầu tối ưu, bắt đầu học, bắt đầu xây intelligence. Khoản đầu tư nền tảng cần làm là một runtime có đúng các thuộc tính kiến trúc, đúng tính phổ biến (chạy mọi nơi) và đúng tính extensible, để mình diễn đạt được luồng mình muốn.

Anh kết phần chính: hãy thử Docker Sandboxes, có sẵn một lệnh để bắt đầu. Ghé booth Docker, tìm anh trên Twitter, anh cũng sẽ ở quanh booth. Ai quan tâm tới việc cắm vào runtime thì tới nói chuyện với anh hoặc với team ở booth. "Happy building."

13. Q&A: bao giờ agent có identity và credential riêng?

MC cảm ơn, nói talk được đón nhận tốt, và đọc câu hỏi của khán giả. Câu đầu tiên: "Bao giờ agent có identity và credential riêng? Ngành có đang tiến tới đó không? Khi mình đang chuyển sang thế giới nhiều agent chạy không người trông, dùng credential của CTO có thể dẫn tới những kịch bản rất tệ."

Tushar: "1000% đồng ý, hoàn toàn đồng ý." Thế giới hôm nay là mình để agent mạo danh mình (impersonate). Mọi thứ anh vừa nói là về cách làm suy giảm (attenuate) quyền đó: làm sao có control, có policy control. Nhưng việc tiếp theo, gần như ở mức cả ngành, là tới được chỗ agent có identity riêng. Agent nên xuất hiện gần như một nhân viên trong sơ đồ tổ chức, được cấp quyền hạn chế. Mình vẫn sẽ muốn có fine-grained policy control trên đó, nhưng phải làm việc identity. Đây là việc phải làm theo chuẩn.

Có nhiều nỗ lực trong mảng này: phía identity provider (IdP), nhiều người đang làm; spec MCP cũng đang có nỗ lực (xem phần authorization trong MCP spec); và nhiều nhóm khác. Nên đây là việc đang diễn ra, và Docker cũng đang làm trong mảng này.

Nhưng anh nghĩ sẽ thấy một hỗn hợp thú vị: sẽ có agent có identity riêng, và vẫn có agent hành động thay mặt (on behalf of) người dùng. Nên phải theo dõi và xử lý cả hai. Đây là bài toán khó, vì phải đẩy một standard mới qua mọi service, mọi nơi chấp nhận credential. Nên sẽ phải làm dần. Trong lúc chờ, fine-grained, semantic policy cải thiện tình hình cho mình.

14. Q&A: cho agent vào email, hierarchy giữa các agent, persona

MC nối thêm: chuyện này gắn với identity email. Người ta hay bảo "cứ cho agent vào email của bạn", và anh thì "ừ, nhưng đó là 40 năm tài khoản Gmail với Yahoo; không, không, cả cuộc đời tôi nằm trong đó". Mình cần giải quyết chuyện đó: các mức quyền dùng một lần rồi bỏ (throwaway). Anh cũng nghĩ hierarchy giữa các agent là thứ cần chuẩn hoá: agent đóng vai trò gì, được bao nhiêu quyền.

Tushar đồng ý: đây là chủ đề vừa rộng vừa sâu, sẽ còn là việc đang làm trong một thời gian. Hierarchy của agent, identity, đúng vậy. Nhưng còn khi mình cho agent quyền vào một thứ, đằng sau câu MC nói là một nỗi lo: nó sẽ làm gì với email của tôi? Nó lưu ở đâu? Nó có gửi ra cho người khác được không? Nó có copy nội dung rồi gửi cho ai đó được không? Nếu mình control được những điều đó, control được việc nó làm gì với dữ liệu, và nếu mình tin được những control đó, thì anh nghĩ nhiều khả năng mình sẽ tới được mức yên tâm.

MC thêm một ý: trước đây mình vẫn dùng persona để test chương trình và mô phỏng người dùng. Toàn bộ nghiên cứu đó giờ đưa được vào agentic workflow. Tushar: "Đúng vậy, hoàn toàn đúng."

Câu hỏi tiếp theo MC đọc gộp mấy ý: "Docker xử lý việc map policy trong bối cảnh nhiều người dùng (multiplayer) thế nào, ví dụ team finance và HR dùng cùng một agent nhưng có quyền truy cập khác nhau? Còn shared workspace giữa team lead và team member thì sao? Context có được govern bằng Docker không?"

Tushar: "Nhiều câu quá." MC đùa hỏi anh tung hứng (juggling) giỏi tới đâu. Tushar kể hồi Covid anh có tập tung hứng một chút, nhưng không giỏi lắm. Rồi anh xin trả lời câu đầu.

Về chuyện policy: mọi policy anh vừa nói đều có enterprise governance (xem governance trong Docker Sandboxes).

15. Q&A: policy cho nhiều team, và shared context, memory

Enterprise governance map vào hệ thống identity chuẩn của doanh nghiệp. Mình đặt được policy theo org hoặc theo team, và Docker sẽ làm thêm ở mảng này. Docker cho một cách linh hoạt để nhóm (grouping) và đặt policy, mình tự quản lý. Nên team finance có thể có loại policy này, loại quyền này: finance đang dùng agent, tốt, họ được quyền kiểu này. Còn nếu team developer dùng cùng agent đó thì "đoán xem": họ không được ghi vào Salesforce, có khi còn không được đọc. Mọi thứ đi theo cách đó. Đó là phần một.

MC nhắc lại phần hai: "Còn shared workspace giữa team lead và team member? Context có govern được bằng Docker không?"

Tushar: câu hỏi hay, có hai phần. Một là mình cần một dạng shared context service. Giả sử nó đã tồn tại, người ta sẽ tự build. Phần cốt lõi không phải là Docker build service đó; giả sử đã có một service nào đó, có một shared context nào đó. Nếu đã có nó, mình cần control ai được ghi vào đó. Thông thường với shared context hay memory, cuối cùng mình sẽ có hierarchy: memory cấp toàn tổ chức, cấp team, cấp cá nhân. Và mình muốn control ai được ghi vào đâu: không muốn bất kỳ agent nào cũng ghi được vào cấp toàn tổ chức.

Nhìn vậy thì nó rất giống một service mà mình muốn có fine-grained access và một lớp ngữ nghĩa phía trên, để viết được policy mình muốn. Nên câu trả lời là "chắc chắn được", và đó là thứ extensible policy framework Docker đang build cho phép mọi người làm.

MC hỏi thêm: có thấy người ta tới với những yêu cầu như vậy không? Đây là câu hỏi của khán giả, nhưng anh có làm việc một-một với các công ty, và họ có nói "đây là hierarchy của chúng tôi, anh tái hiện được không"?

16. Q&A: khách hàng có memory service riêng, và lời kết

Tushar: "Chắc chắn rồi." Ngay hôm qua anh vừa nói chuyện với một khách hàng nói đúng điều này: "chúng tôi đã build một memory service, nó đang chạy. Tốt. Nhưng giờ cái khó là: khi triển khai agent cho toàn bộ nhân viên, chúng tôi muốn control agent nào được ghi vào phần nào của memory." Và thực tế là người ta dùng rất nhiều agent, không chỉ một agent. Mình không kiểm soát được việc người ta chọn agent nào, và cũng không nên: doanh nghiệp muốn có lựa chọn. "Nhưng tôi vẫn muốn lấy memory từ mọi nơi, và vẫn control được chuyện gì được làm với nó."

Họ có cùng câu hỏi: "quản lý việc đó thế nào? Tôi chỉ muốn đặt một policy đơn giản thôi." Và những gì anh nói hôm nay, cùng những gì Docker và partner đang làm, chính là cái đó: nếu có fine-grained access, họ mang được enrichment của riêng họ vào, mở rộng nó, và nói cho runtime cách làm. Nên đúng, câu hỏi kiểu này xuất hiện liên tục. Chính Docker trong nội bộ cũng muốn có nó. Đây là một nhu cầu rất chuẩn mà anh nghĩ ai cũng đang nhìn vào và đang tìm cách xử lý.

MC cảm ơn: "Tuyệt, cảm ơn nhiều." Rồi hỏi Tushar, CTO của Docker, có ở ngoài booth không. Tushar: anh sẽ ra booth, và mọi người tìm anh được trên Twitter.

MC chuyển sang phần nghỉ 10 phút. Talk tiếp theo trên Mainstage là của Matt Biilmann từ Netlify, nói về việc là một developer, và đi từ DX sang AX (từ developer experience sang agent experience) mà vẫn giữ con người ở giữa, "vì mình không muốn đánh mất con người". MC dặn mọi người ra gặp gỡ, 10 phút nữa quay lại, "rồi mình xem ai là agent, ai không".