CodeKasten là một nền tảng để một nhóm tự dựng công cụ mình làm việc trong đó. Bạn mô tả những thứ cần theo dõi — dự án, ticket, khách hàng — thành các record type, và nền tảng dựng sẵn cho mỗi kiểu một danh sách, một biểu mẫu, một trang chi tiết, bộ lọc, view lưu sẵn, lệnh, một GraphQL API và cả tool cho agent. Giao diện được vẽ lại từ định nghĩa mỗi lần, không phải sinh ra một lần rồi để đó. Tài liệu CodeKasten
Chúng tôi viết về CodeKasten vì cách nó trả lời một câu hỏi mà chúng tôi theo đuổi suốt mấy tháng qua: khi để AI agent làm việc trên hệ thống thật, nên cho nó quyền ghi tới đâu, và ai là người quyết định phần nào được giữ lại.
Ý tưởng nền: mọi thứ đều là một bản ghi
Một dự án là một bản ghi. Định nghĩa của kiểu Project cũng là một bản ghi. Từng trường của kiểu đó, một view, một workflow, một mục trên thanh bên — tất cả đều là bản ghi.
Đó là mẹo cấu trúc khiến mọi thứ còn lại chạy được. Vì cùng một dạng nên cùng branch được, commit được, merge được, dịch được và đóng gói được như nhau. Định nghĩa xong một record type là có ngay danh sách, biểu mẫu, bộ lọc, trang riêng, API và tool cho agent — không có schema nào phải migrate.
Workspace có nhánh như một repository
Một workspace có các nhánh giống kho mã nguồn. Bạn đổi thứ gì đó trên một nhánh, commit, rồi merge. Nhánh main được bảo vệ mặc định, nên nhóm có thể bắt buộc mọi thay đổi phải được xem trước khi vào.
Cách làm được khuyến nghị trong tài liệu là cách một đồng nghiệp cẩn thận vẫn làm: tạo một nhánh cho agent và một khóa trên nhánh đó, để agent làm việc và commit, agent gọi request_merge để hỏi những người có quyền merge, rồi một người xem các commit và quyết định. Một chi tiết nhỏ nhưng chỉnh chu: khi một tool từ chối thao tác, lời từ chối quay về như kết quả của chính tool đó và được viết cho mô hình đọc, nên agent hiểu vì sao mà tìm cách khác. Tài liệu Agents (MCP)
Agent kế thừa danh tính và quyền hạn của người dùng
Đây là chỗ CodeKasten đưa ra một lựa chọn đáng chú ý. Agent dùng một khóa API, nên nó chính là người đã tạo ra khóa đó: trên nhánh của khóa, với vai trò của người đó trong workspace. Agent của một người chỉ có quyền đọc thì cũng chỉ đọc được. Khóa trỏ tới một nhánh mà người đó không còn quyền đọc thì ngừng hoạt động.
Đặt cạnh specialist dots của OpenAI thì đây là hai câu trả lời ngược nhau cho cùng một câu hỏi. OpenAI cấp cho mỗi agent một danh tính và bộ thông tin đăng nhập riêng, biến nó thành một chủ thể mới trong mô hình phân quyền — và vì thế cần công cụ quản trị riêng. CodeKasten thì không tạo ra chủ thể mới nào cả.
Cách này làm việc thu hồi quyền trở nên đơn giản: cắt quyền của người là agent dừng theo, không còn tài khoản máy nào phải nhớ. Nhưng khả năng truy vết thì ngược lại, có thể phức tạp hơn: trong nhật ký, một hành động của agent trông như hành động của chính người giữ khóa. Muốn phân biệt được ai hay cái gì đã thay đổi một bản ghi, bạn phải tự dựng thêm lớp ghi nhận. Với ngành bị quản lý chặt, đó có thể là điều kiện không bỏ qua được.
Phê duyệt trước hay hoàn tác sau?
Trong quá trình tìm hiểu CodeKasten, chúng tôi cũng chú ý đến Claude Duet, một sản phẩm được Anthropic giới thiệu dưới dạng research preview. Duet là trợ lý AI chủ động, hoạt động trên máy tính đám mây riêng, tổng hợp những việc cần người dùng chú ý, tiếp nhận yêu cầu qua tin nhắn và thực hiện công việc thông qua các kết nối sẵn có.
Khác với mô hình cấp danh tính độc lập cho từng agent của OpenAI Dots, Duet sử dụng tài khoản Claude của người dùng, cùng bộ nhớ, kỹ năng và các kết nối đã thiết lập.
Tuy nhiên, điểm khác biệt đáng chú ý hơn nằm ở cách kiểm soát hành động của agent. Với Duet, những thao tác nhạy cảm như gửi tin nhắn hoặc thực hiện thanh toán cần được phê duyệt trước khi thực thi. CodeKasten tiếp cận từ hướng khác: agent được phép thay đổi trong một nhánh riêng, ghi nhận bằng commit, rồi gửi yêu cầu hợp nhất, và những thay đổi đó được xem xét trước khi trở thành trạng thái chính thức của hệ thống.
Đặt CodeKasten, OpenAI Dots và Claude Duet cạnh nhau, có thể nhận ra hai nguyên tắc kiểm soát chứ không phải ba.
Kiểm soát trước khi thực thi phù hợp với những hành động tạo ra tác động bên ngoài hệ thống: gửi email, chuyển tiền, phê duyệt giao dịch, điều khiển thiết bị. Khi hành động đã xảy ra, việc hoàn tác có thể rất khó khăn hoặc không thể thực hiện.
Cô lập thay đổi và kiểm duyệt trước khi hợp nhất phù hợp với những thay đổi trạng thái dữ liệu có thể được lưu giữ, so sánh và xem xét trước khi đưa vào môi trường chính thức.
Hai cơ chế này không loại trừ nhau. Ngược lại, chúng bổ sung cho nhau và cần được kết hợp trong những hệ thống agentic có yêu cầu cao về an toàn và quản trị. Một agent có thể tự chủ thực hiện hàng loạt thay đổi trong vùng làm việc riêng, nhưng trước khi những thay đổi đó được hợp nhất hoặc kích hoạt các tác động không thể đảo ngược, hệ thống cần có điểm kiểm soát phù hợp.
Từ đó rút ra một nguyên tắc kiến trúc: không phải mọi hành động của agent đều cần con người phê duyệt, nhưng mọi hành động có rủi ro đáng kể phải nằm trong một cơ chế kiểm soát có thể xác định và kiểm chứng.
Cũng cần phân biệt phạm vi của các sản phẩm. Claude Duet hướng tới trợ lý cá nhân chủ động, trong khi CodeKasten là nền tảng xây dựng ứng dụng và quản lý dữ liệu theo phiên bản. Vì vậy so sánh ở đây tập trung vào triết lý kiểm soát agent, không phải so sánh trực tiếp tính năng. Duet hiện ở research preview: danh sách chờ, dành cho gói Pro và Max tại Mỹ, chưa có Team và Enterprise; Anthropic ghi rõ Duet có thể đọc sai một luồng hội thoại, đánh giá sai mức khẩn, và bỏ sót việc đến vào giữa hai lần kiểm tra.
App là gói, workflow là dữ liệu
Record type được dựng trong một app workspace rồi publish thành release. Một release không đổi nữa sau khi đã publish, nên mười nhóm cài cùng một app Helpdesk mà mỗi nhóm vẫn giữ ticket riêng; nâng cấp là một release mới, nhóm nào sẵn sàng thì lấy. Apps và packages
Workflow cũng là dữ liệu: vẽ trên canvas, biên dịch thành một plan, và chạy bởi workflow engine khi trigger kích hoạt. Phần đáng chú ý là nó chạy trên Temporal, nên một bước chờ dài một tuần vẫn sống qua lần khởi động lại. Workflows
Điều gì mới thật ở CodeKasten
- Đưa version control xuống tầng dữ liệu và định nghĩa, không chỉ mã nguồn. Đây là phần khó, và là lý do mẹo “mọi thứ đều là bản ghi” tồn tại.
- Thay đổi dữ liệu của agent được cô lập trên một nhánh riêng và có thể bị loại bỏ trước khi hợp nhất.
- Agent không sinh ra một chủ thể mới phải quản trị riêng — khác hẳn hướng mà phần lớn nền tảng agent đang đi.
- Release bất biến cho phép phân phối cùng một bộ công cụ tới nhiều nhóm mà không khóa chung lịch nâng cấp.
Có một điểm chúng tôi muốn nói riêng, vì nó không phải giới hạn của riêng CodeKasten mà là giới hạn của chính mô hình nhánh. Merge dữ liệu không giống merge mã nguồn. Trả lại một commit mã là chuyện của kho mã. Nhưng một email đã gửi đi, một khoản đã chi, một lệnh đã đẩy xuống thiết bị thì không “trả lại” được bằng một nút revert. Mô hình nhánh bảo vệ rất tốt trạng thái nằm trong hộp; nó không bảo vệ được tác động đã xảy ra bên ngoài hộp.
Nói cách khác, nhánh là một hàng rào tuyệt vời cho dữ liệu, và chỉ là nửa hàng rào cho workflow có tác dụng phụ. Đây đúng là chỗ chúng tôi vẫn nhắc rằng chính sách kiểm soát phải độc lập với agent và được thực thi ở lớp nghiệp vụ hoặc lớp tích hợp, chứ không nằm trong công cụ mà agent đang chạy. Phần nào gây tác động ra thế giới thật thì phải có điểm dừng của riêng nó.
Cơ hội nhìn từ phía doanh nghiệp Việt Nam
Khi một agent được phép ghi vào hệ thống thật, câu hỏi thiết kế đầu tiên luôn là: nhánh của nó nằm ở đâu, và ai merge? Phần lớn doanh nghiệp trả lời câu này bằng cách tự dựng vùng đệm — bản nháp, hàng đợi phê duyệt, một môi trường riêng — rồi tự viết thêm lớp so sánh, lớp phê duyệt và lớp ghi vết quanh nó. Đó là vài tháng công sức trước khi agent kịp tạo ra giá trị nào.
Điều làm CodeKasten đáng thử là nó giao sẵn phần đó. Nhánh, commit, merge, nhánh main được bảo vệ, lịch sử có lý do kèm từng thay đổi, yêu cầu hợp nhất gửi vào Inbox của đúng người — tất cả có sẵn từ ngày đầu, cho dữ liệu chứ không riêng mã nguồn. Bạn định nghĩa record type là có ngay danh sách, biểu mẫu, bộ lọc, GraphQL API và tool cho agent, rồi đóng gói thành app cài đi nhiều nơi.
Với doanh nghiệp Việt Nam, chúng tôi thấy ba nhóm hợp nhất: đội muốn dựng nhanh công cụ nội bộ mà không mở một dự án phần mềm đầy đủ; đội đã dùng Claude Code hoặc một MCP client khác và cần chỗ cho agent làm việc an toàn; và đội phải phát hành cùng một bộ công cụ cho nhiều đơn vị thành viên, mỗi nơi một nhịp nâng cấp.
Cách tìm hiểu rẻ nhất là đọc tài liệu, xem cách họ hình dung agent và con người làm việc cùng nhau, rồi mở thử ứng dụng và nối Claude Code vào qua MCP server. Một buổi chiều là đủ để biết mô hình này có hợp với cách nhóm bạn làm việc hay không.
Chúng tôi chọn đúng hướng đó khi làm MaiStudio, công cụ nội bộ của Mobino cho lập trình Mendix: mỗi agent làm trên workspace và nhánh git riêng, người duyệt xem khác biệt ở mức model rồi mới cho vào project. Việc một sản phẩm độc lập đi tới cùng kết luận từ một hướng hoàn toàn khác là tín hiệu đáng ghi nhận về mẫu thiết kế này.
Gói lại thành một câu để mang đi: agent có thể tự chủ trong quá trình thực thi, nhưng không được tự quyết định vượt qua ranh giới kiểm soát. Ranh giới đó do con người đặt, nằm ngoài tầm với của agent, và phải kiểm chứng được sau khi mọi việc đã xong.
Nếu nhóm của bạn đang thiết kế những luồng như vậy, xem trang tự động hóa và AI của chúng tôi.
Nguồn: What is CodeKasten · Agents (MCP) · How your team and AI agents work together