# Grok Bot cho admin: guardrail, bảo mật, rollout và chi phí

[Jon Eide Johnsen](https://homus.dev/speakers/jon-eide-johnsen) · [Grok](https://homus.dev/orgs/grok), [Rohan Chandra](https://homus.dev/speakers/rohan-chandra) · [Grok](https://homus.dev/orgs/grok)

> Đội Grok Bot hướng dẫn admin đặt guardrail, rule và hook, cấu hình VM an toàn, rollout theo nhóm với Team Bot, và theo dõi usage, chi tiêu.

Topics: Grok Bot, Security, Agents

Canonical: https://homus.dev/talks/grok-bot-for-admins

## 1. Mở đầu: Rohan, Jon và bốn chủ đề cho admin

Workshop mở đầu bằng lời của Rohan Chandra. Anh làm trong đội **go-to-market** của Grok Bot, về cơ bản là giúp các công ty tìm cách đưa Grok Bot vào tổ chức của họ, kéo mức sử dụng lên, và "rất nhiều thứ vui" quanh chuyện đó. Rồi anh chuyển lời cho Jon.

Jon Eide Johnsen giới thiệu mình là product manager, làm phần **Grok Bot for Enterprise**. Công việc của anh là nói chuyện rất nhiều với admin và đội bảo mật ở các công ty lớn. Anh nói rất mong được chia sẻ những gì đội đã xây cùng với chính các khách hàng của mình.

![Slide tiêu đề Grok Bot for Admins với tên Jon Eide Johnsen và Rohan Chandra](https://homus.dev/photos/NhrXdX_93Hc-0003.jpg)

Slide mở đầu "Grok Bot for Admins", thứ Tư 21 tháng 10, 10:00 tới 10:30 sáng giờ Thái Bình Dương. Hai người dẫn: Jon Eide Johnsen, Product Manager, và Rohan Chandra, Grok Bot GTM. Góc phải trên là khung camera của hai người, các nhân vật tròn nhiều màu là hình ảnh của các bot.

Rohan lo vài việc "housekeeping" trước. Người xem có thể đặt câu hỏi qua chức năng Q&A. Jon sẽ là người dẫn chính, còn Rohan lo phần câu hỏi, nên anh mời mọi người cứ hỏi. Anh nói hy vọng còn thời gian cho Q&A ở cuối và muốn buổi này có tương tác thật sự, nên anh nhắc lại: cứ nhảy vào hỏi. Sau buổi, đội sẽ gửi thêm tài liệu cho mọi người.

Jon nói rõ đối tượng: buổi này chủ yếu dành cho **admin** của Grok Bot. Anh nói hai người sẽ đi qua những gì một admin cần nghĩ tới khi rollout Grok Bot cho tổ chức của mình. Có bốn chủ đề:

- cách đặt **guardrail** cho những hành động mà bot được phép làm;

- cách giữ cho dữ liệu luôn an toàn;

- cách đội khuyên rollout Grok Bot cho team, kể cả cách tạo các bot dùng chung có thể làm việc cho cả team;

- và cuối cùng, cách hiểu usage: team của bạn đang dùng Grok Bot ra sao, và đâu là những thứ đẩy chi phí lên.

Nhưng trước hết, Jon nói, Rohan sẽ giới thiệu nhanh Grok Bot là gì.

## 2. AI maturity curve: từ chatbot, agent tới AI teammate

Rohan muốn đặt nền một chút cho cách đội đang nghĩ về Grok Bot. Anh quay lại năm 2022, khi hàng loạt chatbot ra đời; trên slide, ô "Chatbots" ghi ví dụ là ChatGPT và Claude. Đó là ý tưởng hỏi và đáp qua lại: bạn hỏi, nó trả lời.

Bước tiếp theo là **agent**. Theo Rohan (video đăng ngày 21/10/2026), đây là chỗ phần lớn sản phẩm đang đứng. Bạn vẫn có thể chat, nhưng giờ bạn khởi động được một task: nó có thể gửi một email, đọc tài liệu Notion của bạn, gửi một tin nhắn Slack, tức là một chút hành vi kiểu agentic hơn. Anh nói kiểu này rất, rất phổ biến trong các use case kỹ thuật, và nhiều mảng khác đang bắt đầu đuổi theo.

![Slide The AI maturity curve với ba bậc Chatbots, Agents và AI teammates](https://homus.dev/photos/NhrXdX_93Hc-0158.jpg)

"The AI maturity curve" (slide trong video đăng ngày 21/10/2026): đường cong năng suất đi lên qua ba bậc. Chatbots (ví dụ ChatGPT, Claude): bạn hỏi, nó trả lời. Agents (ví dụ Codex, Claude Cowork): bạn giao một task, nó làm. AI teammates (Grok Bot): chạy công việc của cả một team từ đầu tới cuối và kéo bạn vào khi cần.

Còn Grok Bot, theo cách đội nhìn nhận (video đăng ngày 21/10/2026), là một bước nhảy rất lớn. Thay vì bạn giao một task rồi nó làm, ý tưởng ở đây là **AI teammate**: một đồng đội AI có thể chạy công việc của bạn, của cả team bạn, từ đầu tới cuối, và chỉ kéo bạn vào khi cần.

## 3. Lead Bot: một yêu cầu sales inbound chạy từ đầu tới cuối

Rohan nhấn mạnh đây là một sự chuyển dịch lớn về tư duy mà anh muốn mọi người nắm: theo anh (video đăng ngày 21/10/2026), Grok Bot không chỉ là một phiên bản khác của chatbot, hay thậm chí của hành vi agentic, mà là một AI teammate có thể hoàn thành công việc từ đầu tới cuối. Rồi anh chuyển sang vài ví dụ nhanh.

Anh muốn nghĩ cả tới các use case ngoài kỹ thuật, và một use case lớn là xử lý **sales inbound**, việc xảy ra rất thường xuyên. Nhìn cột bên trái của slide, cách làm hôm nay, theo Rohan (video đăng ngày 21/10/2026), là thế này: SDR (Sales Development Rep) nghiên cứu công ty và kiểm tra xem lead này đã có ai phụ trách chưa; rồi đánh giá nó theo ICP (ideal customer profile); rồi viết thư trả lời, có thể nhờ chatbot, đặt lịch họp, và chuyển nó cho một Account Executive (AE). Sau đó AE lại phải tự ghép nhặt context trước cuộc gọi.

![Slide so sánh quy trình sales inbound hôm nay và với Grok Bot](https://homus.dev/photos/NhrXdX_93Hc-0302.jpg)

"From doing the work to running it end to end" (slide trong video đăng ngày 21/10/2026): cột Today là bốn bước SDR và AE tự làm; cột With Grok Bot là bốn bước Lead Bot làm: nhận từng lead, nghiên cứu và gộp trùng; chấm điểm theo ICP và điền CRM; soạn thư trả lời cá nhân kèm link đặt lịch để AE duyệt trong Slack; gửi brief ngắn cho AE trước cuộc gọi. Dòng cuối: hôm nay một SDR dùng công cụ AI mất nhiều ngày cho mỗi lead; với Grok Bot, AI teammate xếp lịch lead trong vài phút và AE chỉ việc duyệt.

Với Grok Bot, Rohan nói (video đăng ngày 21/10/2026), bạn có thể tạo một bot duy nhất, tạm gọi là **Lead Bot**, làm hết chỗ việc đó. Nó nhận từng lead, nghiên cứu lead, chấm điểm theo ICP của bạn, soạn một thư trả lời mang tính cá nhân, rồi đăng một bản brief và chủ động gửi cho AE. Nó làm tất cả những việc này ở chế độ **always on**, luôn chạy, thật sự làm trọn công việc từ đầu tới cuối và chỉ kéo AE vào khi cần.

Ý nghĩa của chuyện này, theo Rohan (video đăng ngày 21/10/2026): hôm nay bạn có thể có một SDR dùng các công cụ AI mà vẫn mất nhiều ngày cho mỗi lead. Với Grok Bot, một AI teammate xếp lịch cho lead trong vài phút, và AE chỉ cần duyệt.

## 4. Support Bot: cách SpaceX SI mở rộng đội support

Lead Bot là một task khá tập trung. Ở slide tiếp theo, Rohan cho xem những gì đội đã làm trong nội bộ, ở một mức trừu tượng cao hơn hẳn. Theo Rohan (video đăng ngày 21/10/2026), họ tạo một bot nội bộ tên **Support Bot**. Bot này lấy dữ liệu từ Plain, Linear, Datadog, tức là đủ loại nguồn khác nhau, và làm rất nhiều việc khác nhau: nó điều tra, nó theo dõi hàng đợi, nó còn nhìn cả tín hiệu trên X, nó làm cả quality review, và nó thử giải quyết vấn đề trước tiên.

Khi cần, theo Rohan (video đăng ngày 21/10/2026), nó escalate lên người thật, kéo người vào cuộc, nhưng phần lớn công việc từ đầu tới cuối là nó làm.

![Slide How SpaceX SI scaled support 175% without hiring với sơ đồ Support Bot](https://homus.dev/photos/NhrXdX_93Hc-0413.jpg)

"How SpaceX SI scaled support 175% without hiring" (slide trong video đăng ngày 21/10/2026): Grok Bot đăng nhập vào các công cụ đội đang dùng (Plain cho ticket, Linear cho known issue, Datadog cho lỗi backend), nhận ba việc (Investigation, Queue watch, Quality review) và học từ feedback trên mỗi ticket, với đội support làm "human in the loop". Các nhánh tiếp theo trên slide: help center, trả lời khách, refund, X signals, incident, bot coaching, weekly summary, product themes. Ba ô dưới cùng: 175% more support tickets, $2M in salary savings, No engineering required.

Theo số liệu nội bộ Rohan đưa ra (video đăng ngày 21/10/2026), nhờ ba việc này, đội đã mở rộng được 175% mà không cần tuyển thêm người, và tiết kiệm hai triệu đô tiền lương. Điều lớn nhất, theo anh, là thật sự không cần đến kỹ sư: tất cả chỉ là tạo bot ngay trong nền tảng.

Đó là lý do anh muốn mọi người neo suy nghĩ vào các workflow **end to end**, từ đầu tới cuối.

## 5. Workflow nhiều người: một đợt launch marketing trong Slack

Ở slide tiếp theo, Rohan đi thêm một bước: không chỉ là workflow end to end, mà là workflow end to end theo kiểu **multiplayer**, nhiều người cùng làm. Lần này ví dụ chuyển sang marketing.

Bên trái là cách làm "trước đây": một PM viết brief, chuyển cho một marketer soạn kế hoạch, rồi tới content manager, designer, và cứ thế. Rất nhiều lần chuyển tay, và rất nhiều người khác nhau phải làm việc cùng nhau.

![Slide A marketing launch, before and after, với thread Slack của Launch Bot](https://homus.dev/photos/NhrXdX_93Hc-0523.jpg)

"A marketing launch, before and after" (slide trong video đăng ngày 21/10/2026): bên trái là sáu vai và năm lần chuyển tay (PM viết brief, marketer soạn kế hoạch, content manager viết các biến thể, designer làm asset, social media manager lên lịch bài, analyst báo kết quả). Bên phải là một thread Slack mẫu trong kênh ios-launch với Launch Bot: các nhân vật trong thread là ví dụ minh hoạ trên slide.

Bên phải là một thread Slack (ví dụ trên slide trong video đăng ngày 21/10/2026). Maya, một marketing manager, mở thread: bản launch app iOS bị dời sang thứ Năm. Priya, một PM, gọi Launch Bot và hỏi nó có thể chạy việc này từ đầu tới cuối không. Launch Bot soạn ra ba artifact: brief cho đợt launch, các biến thể copy và hero creative. Jordan, designer, góp ý: làm cho nó trông "enterprise ready" hơn. Launch Bot sửa theo. Cuộc trao đổi có thể tiếp tục qua lại như thế. Maya duyệt, Jordan duyệt, Launch Bot lên lịch các bài đăng.

Và hai ngày sau, Launch Bot chủ động quay lại báo kết quả, kiểu như "đã có 42.000 impressions". Trên slide, tin cuối của bot ghi 42K impressions, 1,8K click, CTR 6%, và blog là nguồn giới thiệu nhiều nhất. Đây là các con số của ví dụ minh hoạ trên slide trong video đăng ngày 21/10/2026.

Đó, theo Rohan, là tầm nhìn của đội với Grok Bot: nhiều người cùng cộng tác với nhau và với bot. Theo video đăng ngày 21/10/2026, cách làm này có sẵn trong Slack, và sắp có trong Microsoft Teams. Đây chính là tầm nhìn anh muốn mọi người nghĩ tới.

## 6. Giao diện Grok Bot: bot cho từng việc, chia sẻ bot và routine

Vì buổi này không có demo đầy đủ, Rohan cho xem nhanh giao diện của Grok Bot. Theo Rohan (video đăng ngày 21/10/2026), bạn có thể tạo bot cho những việc khác nhau, nhắn tin cho bot như nhắn cho đồng đội, và điểm mấu chốt là bot giữ được context và memory.

![Slide Introducing Grok Bot với giao diện app và các chú thích tính năng](https://homus.dev/photos/NhrXdX_93Hc-0612.jpg)

"Introducing Grok Bot" (slide trong video đăng ngày 21/10/2026): cột trái là danh sách bot (Sales Outbound, Chief of Staff, Inbox Manager, Website launch, Debug và vài bot khác). Ở giữa, người dùng giao cho Sales Outbound việc "overnight pipeline generation and outbound", bot tạo một routine và báo cần đăng nhập Salesforce trên computer của nó. Cột phải là chi tiết bot với hai routine "Morning outbound queue" và "Reply chase". Các chú thích: tạo bot cho từng việc, nhắn bot như đồng đội, bot giữ context trong memory, dễ dàng chia sẻ bot, đặt automation và routine, đăng nhập bot vào công cụ của bạn để nó dùng như bạn.

Prompt mẫu hiện trên slide, trong khung chat của bot Sales Outbound:

```
Overnight pipeline generation and outbound. Pick eligible prospects from Google Sheets, research them on the web, grab context on contacts and accounts from Hex and Salesforce.
```

Có hai thứ Rohan đặc biệt muốn chỉ ra (video đăng ngày 21/10/2026). Thứ nhất là chức năng ở góc trên bên phải: khả năng **chia sẻ bot với team**. Bạn có thể tạo những bot dùng chung cho cả team, với context chung, memory chung, và ai cũng có thể nhắn cho chúng. Bạn, với vai trò leader hay admin, có thể tự tay dựng chúng.

Thứ hai là đặt **automation và routine**. Quay lại ý về workflow end to end anh vừa nói, theo anh (video đăng ngày 21/10/2026) đây là phần cực kỳ quan trọng: có thể nghĩ ra các workflow từ đầu tới cuối và cài automation, routine cho chúng. Rồi Rohan chuyển lại cho Jon để nói về các công cụ quản trị.

## 7. Kiến trúc: client mỏng, VM riêng và agent harness trên cloud

Trước khi vào các công cụ quản trị và bảo mật, Jon muốn đưa ra một cái nhìn nhanh về kiến trúc của Grok Bot. Theo mô tả của anh trong video đăng ngày 21/10/2026, kiến trúc có ba phần chính.

![Sơ đồ kiến trúc Grok Bot runs completely in the cloud](https://homus.dev/photos/NhrXdX_93Hc-0700.jpg)

"Grok Bot runs completely in the cloud" (slide trong video đăng ngày 21/10/2026): bên trái (Customer side) là app Grok Bot trên desktop và mobile, đi qua Team policies. Ở giữa (SpaceX cloud) là Bot computer (một VM cho mỗi thành viên, đặt tại Mỹ), SpaceX Servers chạy agent harness, và Connected apps qua Tool calls. Bên phải (Third parties) là Web apps & SaaS (bot hành động như thành viên đã đăng nhập, qua Network policy), Model providers (qua Zero Data Retention) và MCP servers như Slack, Gmail, GitHub (qua Auto Review).

Phần thứ nhất là **client**, tức app desktop hoặc mobile, nằm ở bên trái sơ đồ. Theo Jon (video đăng ngày 21/10/2026), đây là một client mỏng: Grok Bot chạy hoàn toàn trên cloud, không có gì diễn ra cục bộ trên máy tính hay điện thoại. Ở phía này, với tư cách admin, bạn định nghĩa các **team policy**, phần anh sẽ nói kỹ hơn sau.

Nhìn sang phía cloud, mỗi người dùng có một **VM** riêng để các bot dùng. Đó là một máy Linux có thể duyệt web, chạy ứng dụng, và làm việc như bạn làm trên một máy tính bình thường. Theo video đăng ngày 21/10/2026, VM này được đặt tại Mỹ, và bạn có thể định nghĩa các **network policy** khác nhau để kiểm soát những đích nào VM được phép kết nối tới. Thường thì các bot dùng computer này để vào cả website lẫn các ứng dụng SaaS trên web.

Phần thứ ba là **agent harness**, tức vòng lặp agent chính. Nó gọi tới các nhà cung cấp model, và theo Jon (video đăng ngày 21/10/2026), ở chỗ này đội áp dụng **zero data retention**. Agent harness cũng kết nối được với các MCP server, thường là những công cụ bạn đã dùng sẵn, như Slack, Gmail, GitHub, v.v.

Với các tool call, theo Jon (video đăng ngày 21/10/2026), bạn định nghĩa được tool call nào được phép. Ngoài ra còn có khái niệm **auto-review** chạy trên mọi hành động của bot, phần anh sẽ quay lại để nói cách định nghĩa rule. Điều cốt lõi cần hiểu, Jon tóm lại: Grok Bot chỉ chạy trên cloud, và ngoài các MCP server, bạn có một VM, một computer, mà các bot dùng được.

## 8. Part 1: guardrail cho plugin, MCP, máy local và network

Phần đầu tiên Jon nói là cách đặt guardrail cho những gì bot được làm. Theo Jon (video đăng ngày 21/10/2026), đây thường là việc đầu tiên bạn làm khi bắt đầu dựng Grok Bot cho tổ chức. Có ba quyết định chính: bot được dùng những plugin và MCP nào; bot có được làm việc trên máy local của người dùng không; và những đích network nào bot kết nối tới được.

Ba guardrail đầu tiên admin quyết định, theo slide "Bots can only use the tools you allow" (video đăng ngày 21/10/2026): plugin và MCP nào được dùng (và tool nào trong đó), bot có được chạy trên máy local của thành viên không, và network allowlist cho computer của bot.

Về plugin và MCP: nếu bạn đã dùng Cursor, nhiều khả năng bạn đã định nghĩa một số plugin và MCP server tuỳ biến cho team. Theo Jon (video đăng ngày 21/10/2026), chúng cũng có sẵn trong Grok Bot, nên bạn không phải cài đặt gì thêm. Bạn còn có lựa chọn đi vào từng MCP server và định nghĩa tool nào được phép. Ví dụ, bạn có thể tắt các tool mang tính phá huỷ trong Google Drive MCP.

Về chạy trên máy local: theo Jon (video đăng ngày 21/10/2026), việc cho bot truy cập file local có thể hữu ích, nhưng bạn có thể tắt nó nếu không muốn người dùng làm vậy.

Cuối cùng, computer của Grok Bot có một trình duyệt và một terminal. Nếu muốn giới hạn những đích mà computer này tới được, bạn đặt một **network allowlist**. Khi đó, theo Jon (video đăng ngày 21/10/2026), mọi network call từ computer và mọi tool call MCP đều phải theo allowlist đó.

## 9. Rule và hook: Team Rules, Auto-Review Rules, Inference Hooks

Nhóm tính năng thứ hai để kiểm soát hành động của bot là **rule và hook**. Một điều quan trọng Jon muốn nói trước: theo anh (video đăng ngày 21/10/2026), mọi hành động nhạy cảm đều cần người dùng duyệt, và việc đánh giá một hành động có nhạy cảm hay không được làm tự động bởi một review model mà đội gọi là **AutoReview**. Model này luôn chạy trên mọi bot, nhưng bạn có thể thêm rule và cấu hình nếu muốn.

![Slide Use rules and hooks to control bot actions với ba cột Team Rules, Auto-Review Rules, Inference Hooks](https://homus.dev/photos/NhrXdX_93Hc-1043.jpg)

"Use rules and hooks to control bot actions" (slide trong video đăng ngày 21/10/2026): hành động nhạy cảm luôn cần người dùng duyệt, do một review model độc lập tên Auto Review đánh giá. Ba cột: Team Rules (rule áp cho mọi bot, được chèn vào system prompt), Auto-Review Rules (áp cho mọi hành động của bot, chọn "Allow automatically" hoặc "Ask first"), Inference Hooks, ghi "beta" trên slide (gửi mỗi prompt tới server AI security của tổ chức để nhận phán quyết allow/deny trước inference, cho deterministic control).

Loại đầu tiên (video đăng ngày 21/10/2026) là **Team Rules**: các rule toàn team, áp cho mọi bot trong tổ chức. Chúng được chèn vào system prompt của bot, nên luôn có mặt trong context. Ví dụ một team rule: không bao giờ gửi email ra một công ty bên ngoài mà chưa được người dùng duyệt.

Loại thứ hai (video đăng ngày 21/10/2026) là **Auto-Review Rules**. Với tư cách admin, bạn có thể bắt auto-review chạy trên mọi hành động của bot: cả câu trả lời, cả tool call MCP, lẫn những gì bot làm trên computer. Bạn có hai hướng: chọn một số hành động được cho phép tự động, tức là nới lỏng policy; hoặc bắt bot luôn hỏi người dùng trước khi làm một hành động nhất định.

Cuối cùng, theo Jon (video đăng ngày 21/10/2026), đội mới ra mắt **Inference Hooks**. Tính năng này cho phép nối Grok Bot với endpoint của chính bạn, thường là một phần mềm bảo mật như Palo Alto Networks hay Zscaler. Mọi prompt của người dùng được gửi tới đích của bạn, và đích đó trả về là cho phép hay từ chối, trước khi bất cứ thứ gì được gửi tới nhà cung cấp model. Nhờ vậy bạn vừa áp được các control mang tính deterministic, như so khớp regex, vừa có thể chạy inference ngay trên endpoint của mình để quyết định một hành động có được phép hay không.

Inference Hook theo mô tả của Jon (video đăng ngày 21/10/2026): mỗi prompt của người dùng đi qua endpoint bảo mật của công ty trước, endpoint trả về allow hoặc deny, và chỉ prompt được allow mới đi tiếp tới nhà cung cấp model.

Theo video đăng ngày 21/10/2026, Inference Hooks đang ở giai đoạn **early access** (slide ghi "beta"), và đội sẵn sàng bật cho bạn nếu bạn liên hệ account manager của mình.

## 10. Part 2: cấu hình VM bằng setup script và team secret

Phần thứ hai là cách giữ dữ liệu an toàn. Như đã nói, computer của bot là một Linux VM, và theo Jon (video đăng ngày 21/10/2026), bạn có thể cấu hình nó bằng chính các công cụ của mình, ví dụ VPN của công ty hay phần mềm EDR như CrowdStrike. Cơ chế là **team setup script**: các script luôn chạy mỗi khi VM khởi động.

![Slide Set up the VMs with your own software với team setup scripts, team secrets và network controls](https://homus.dev/photos/NhrXdX_93Hc-1303.jpg)

"Set up the VMs with your own software" (slide trong video đăng ngày 21/10/2026): Team Setup Scripts cài công cụ sẵn có (VPN như Tailscale, EDR như CrowdStrike); Team Secrets là key cho các script đó, được mã hoá, đọc dưới dạng biến môi trường và không bao giờ đưa cho bot. Cả hai đổ vào Bot computer, VM của từng người, được dựng giống nhau cho mọi thành viên, admin có thể tạo lại hoặc huỷ hàng loạt. Network Controls: allow all, defaults cộng team allowlist, hoặc chỉ team allowlist; đặt theo nhóm hoặc khoá cho mọi người.

Use case điển hình là cài VPN hoặc EDR. Bạn cũng có thể định nghĩa các **secret** dùng để cấu hình những công cụ đó. Theo Jon (video đăng ngày 21/10/2026), các secret này không bao giờ được đưa cho bot.

Với computer của bot, theo Jon (video đăng ngày 21/10/2026), bạn có thể **force update**, tạo lại, hoặc xoá sạch các VM, và làm việc đó hàng loạt. Ví dụ, khi bạn vừa cài một bộ script mới, bạn có thể buộc khởi động lại toàn bộ VM trong tổ chức. Và như đã nói, bạn có toàn quyền quyết định những đích nào computer này tới được thông qua network control.

## 11. Audit log, OTEL export, vòng đời VM và Admin API

Về mặt bảo mật, đội cũng cung cấp khả năng giám sát hoạt động của bot. Theo Jon (video đăng ngày 21/10/2026), có **audit log** chứa mọi hành động của con người trong sản phẩm, và còn có thể thiết lập **OTEL export**, bao gồm mọi hành động của bot, kể cả prompt, câu trả lời và tool call MCP. Dữ liệu này được export sang OpenTelemetry collector của bạn.

![Slide Monitor activity and manage VMs and data với ba cột Audit Logs, VM mgmt, Admin API](https://homus.dev/photos/NhrXdX_93Hc-1403.jpg)

"Monitor activity and manage VMs and data" (slide trong video đăng ngày 21/10/2026): giám sát hoạt động và quản lý VM, dữ liệu người dùng qua admin dashboard hoặc API. Ba cột: Audit Logs & OTEL export (ghi mọi hành động của người và bot, gồm prompt, câu trả lời, tool call MCP; export sang OpenTelemetry collector), VM mgmt and data lifecycle (tạo lại hoặc huỷ VM, xoá vĩnh viễn dữ liệu Grok Bot của thành viên; xoá VM không hoạt động sau 30 ngày ngủ đông), Admin API (áp team policy và chạy thao tác hàng loạt trên VM hoặc dữ liệu người dùng bằng code).

Theo Jon (video đăng ngày 21/10/2026), bạn cũng quản lý được các VM trong tổ chức một cách dễ dàng, và có thể đặt **retention policy** cho VM, ví dụ tự động xoá VM sau 30 ngày không hoạt động.

Cuối cùng, đội cung cấp một **Admin API** cho phép áp dụng các thao tác này bằng code (video đăng ngày 21/10/2026). Theo Jon, điều đó mở ra những cách làm như: cho OTEL export của bạn theo dõi một số hành động nhất định, và khi thấy chúng thì kích hoạt một thao tác dọn dẹp ở phía VM.

Ví dụ Jon nêu cho Admin API (video đăng ngày 21/10/2026): OTEL export theo dõi một số hành động của bot, và khi gặp chúng thì gọi Admin API để chạy thao tác dọn dẹp trên VM.

## 12. Part 3: rollout từ một nhóm pilot tới cả công ty

Vậy rollout Grok Bot cho team ra sao? Theo Jon (video đăng ngày 21/10/2026), với khách hàng gói **Teams**, Grok Bot được bật mặc định; còn ở phía **Enterprise**, admin phải bật thủ công.

Anh kể đội đã onboard rất nhiều khách hàng trong mấy tháng qua (tính tới video đăng ngày 21/10/2026), và điều họ thấy hiệu quả là thường nên bắt đầu với một nhóm nhỏ, trong lúc bạn dựng guardrail và các policy bảo mật. Đội cho phép chỉ cấp quyền truy cập cho một số member group trước khi rollout ra toàn công ty. Bạn có thể dùng các SCIM group đã có sẵn, hoặc tạo một **pilot group** và thêm một số ít người vào đó.

Ba bước rollout trên slide "Roll out Grok Bot to your organization" (video đăng ngày 21/10/2026): bắt đầu với quyền truy cập theo nhóm, mở rộng việc cấp seat, rồi mời toàn bộ tổ chức.

Về quyền truy cập, theo Jon (video đăng ngày 21/10/2026), mọi người dùng đã có seat Cursor đều tự động có quyền dùng Grok Bot. Nhưng nếu muốn mời một phần lớn hơn của tổ chức, bạn cần cấp seat cho những người đó. Làm xong bước này, bạn có thể mời cả team: hoặc chia sẻ một invite link dùng được cho mọi người, ví dụ đăng lên Slack, hoặc gửi lời mời qua email cho người dùng mới.

## 13. Team Bot: một bot dùng chung thay cho một trăm bản sao

Điều cuối cùng Jon muốn nói trong phần đưa Grok Bot vào tổ chức là cách dùng **Team Bot** để việc mở rộng automation và bot trong tổ chức trở nên đơn giản hơn. Cách đội nghĩ về chuyện này, theo Jon (video đăng ngày 21/10/2026): thay vì một trăm người trong tổ chức mỗi người tự dựng cùng một automation với bot riêng của mình, sao không tạo một bot dùng chung mà cả một trăm người đó cùng dùng? Khi đó chỉ một người quản lý bot này và đảm bảo nó chạy thật tốt.

![Slide Scaling Grok Bot across your org với ba bước Partner, Build, Power users](https://homus.dev/photos/NhrXdX_93Hc-1643.jpg)

"Scaling Grok Bot across your org" (slide trong video đăng ngày 21/10/2026): xây Team Bot và đặt chúng làm mặc định cho tổ chức. 01 Partner: leader từng mảng (Marketing, Sales, Finance, Recruiting, Product, Support) cùng đội Grok Bot thiết kế workflow. 02 Build: Team Bot dùng chung để chuẩn hoá workflow (Content Launch Bot, Pipeline Bot, Month-End Close Bot, Hiring Loop Bot, Product Status Bot, Support Bot), chỉnh instruction, tool và approval. 03 Power users: những người dùng nhiều lan toả nó ra cả team; ai cũng dùng cùng bot chung, bot học từ mỗi lần sửa, cải tiến tới mọi người cùng lúc.

Theo những gì đội thấy (video đăng ngày 21/10/2026), thường sẽ có một **functional leader**, leader của một mảng, cùng làm với đội Grok Bot để thiết kế các workflow này. Rohan đã nhắc tới support và sales, hai mảng mà họ thấy nhiều use case thú vị. Leader đó sẽ xây Team Bot.

Theo Jon (video đăng ngày 21/10/2026), một Team Bot là tổ hợp của quyền truy cập vào các tool, các **skill** và các **instruction**. Xây xong, bạn có thể chia sẻ nó với cả tổ chức hoặc với một số thành viên.

Với tư cách admin (video đăng ngày 21/10/2026), bạn còn có thể chọn một Team Bot và đặt nó làm **mặc định** cho cả tổ chức hoặc cho một nhóm thành viên. Ví dụ, nếu bạn tạo một bot **deal desk** hữu ích cho người làm sales, bạn có thể tự động chia sẻ nó cho cả khối sales, để mọi người mới trong đội sales bắt đầu dùng Grok Bot đều có bot này ngay từ lúc mở sản phẩm lần đầu.

## 14. Part 4: usage analytics, mức tự động hoá và quản lý chi tiêu

Phần cuối của Jon là cách hiểu usage và chi phí. Theo anh (video đăng ngày 21/10/2026), đội cung cấp hai nhóm khả năng. Nhóm đầu về usage, gọi là **usage analytics**: hệ thống đi qua mọi task mà team bạn dùng Grok Bot để làm, và phân loại chúng theo một bộ phân loại cố định.

![Slide See usage, track cost, and manage spend với biểu đồ Work Type và Level of Automation](https://homus.dev/photos/NhrXdX_93Hc-1816.jpg)

"See usage, track cost, and manage spend" (slide trong video đăng ngày 21/10/2026): bên trái là hai nhóm tính năng, Usage Analytics (loại việc team làm với Grok Bot, mức tự động hoá, phân tách theo member group) và Spend Management (theo dõi chi tiêu theo team, nhóm, người dùng; đặt spend limit theo team và người dùng, có control riêng cho on-demand). Bên phải là biểu đồ mẫu: Work Type top 3 gồm Sales & Pipeline 35,5%, Engineering & Product 17,2%, Setup & Exploration 12,2%; Level of Automation gồm Not automated 53,2%, Semi-automated with human review 17,5%, Fully automated 29,3%.

Ví dụ ở đây, Jon nói, là số liệu nội bộ: sales mới là nhóm dùng Grok Bot nhiều nhất, còn engineering và product đứng thứ hai. Trên biểu đồ của slide (video đăng ngày 21/10/2026), Sales & Pipeline chiếm 35,5%, Engineering & Product 17,2% và Setup & Exploration 12,2%.

Còn có một thước đo về **mức tự động hoá** của các task mà Grok Bot đang làm, chia làm ba mức. **Not automated** là kiểu chatbot: bạn hỏi gì đó, Grok trả lời. **Semi-automated** là khi con người duyệt một thứ trước khi bot hành động. Và **fully automated** là một workflow chạy 24/7. Trên slide, ba mức này lần lượt là 53,2%, 17,5% và 29,3% (số liệu nội bộ trong video đăng ngày 21/10/2026).

Về quản lý chi tiêu, theo Jon (video đăng ngày 21/10/2026), bạn theo dõi được chi tiêu cho Grok Bot theo team, theo nhóm và theo người dùng. Bạn có thể đặt **spend limit** cả theo team lẫn theo người dùng, kể cả control riêng cho phần dùng **on-demand**.

Một người trong hai nói thêm: đội đang tìm thêm cách thể hiện usage và **ROI**, như số giờ tiết kiệm được hay mức chi tiêu, và liên tục cải thiện phần này vì nó thật sự rất quan trọng. Người còn lại đồng ý, và kể rằng (tính đến video đăng ngày 21/10/2026) nội bộ đã có một prototype tính thời gian tiết kiệm được nhờ dùng Grok Bot rồi đặt cạnh mức chi tiêu; đội đang làm việc này cùng một số design partner.

## 15. Q&A: memory, context compaction và memory của Team Bot

Rồi hai người chuyển sang Q&A. Rohan đọc những câu được hỏi nhiều. Câu đầu tiên: nên nói về memory của Team Bot để mọi người biết nên kỳ vọng gì. Một câu khác rất giống: context window của một phiên chat với bot có được compact không, và sau khi compact thì có bị phình ra không. Nói chung là chuyện memory và lượng token bị đốt.

Jon trả lời: vì model có context window giới hạn (tính đến video đăng ngày 21/10/2026), Grok Bot có **context compaction**. Cách làm là biến context của người dùng, cùng với những hành động bot đã làm, thành một **memory**. Bạn có thể hình dung memory là một tập các sự kiện, dữ kiện và những điều bot đã học được về bạn.

Memory này lớn dần theo thời gian. Nhưng với tư cách người dùng, theo Jon (video đăng ngày 21/10/2026), bạn không thật sự phải nghĩ cách quản lý context với Grok Bot, và anh coi đó là một trong những điểm rất dễ chịu khi dùng sản phẩm. Anh kể mình có những bot dùng mỗi ngày từ đầu tháng Bảy, và chưa gặp vấn đề nào với chuyện bot nhớ các dữ kiện, hay làm khác đi so với điều anh đã dặn từ trước.

Hai loại memory của Team Bot theo Jon (video đăng ngày 21/10/2026): hội thoại trong kênh Slack đi vào shared memory; DM riêng hoặc nói chuyện qua app Grok Bot đi vào memory cá nhân của từng người.

Còn một câu hỏi về memory của Team Bot. Jon giải thích (video đăng ngày 21/10/2026): với Team Bot có hai loại memory, **shared memory** và memory riêng cho từng người dùng. Một Team Bot có thể được dùng trong Slack chẳng hạn: bạn thêm bot vào một kênh Slack và nhiều người có thể nói chuyện với nó. Những hội thoại đó đi vào shared memory. Bạn cũng có thể DM thẳng cho Team Bot, hoặc nói chuyện với nó qua app Grok Bot; những hội thoại này đi vào memory cá nhân của bạn. Vậy là giữa các memory có sự tách bạch rõ ràng.

## 16. Q&A: quyền của Team Bot, Microsoft Teams, bot cá nhân và bot team

Rohan nói có rất nhiều câu hỏi chung về Team Bot và bot dùng chung. Anh nói thêm cho rõ bối cảnh: đội đang thay đổi khá nhiều ở phần này, nên tuần sau (tính từ video đăng ngày 21/10/2026) sẽ có thêm cập nhật. Còn bây giờ, anh nhờ Jon nói một chút về cách phân quyền của Team Bot: có thêm được nhiều người khác nhau vào không, và cụ thể là có dùng được **service account** không, câu được hỏi khá nhiều.

Jon trả lời: theo anh (video đăng ngày 21/10/2026), bạn có thể cấu hình Team Bot dùng service account, nhưng mặc định, một Team Bot sẽ dùng các **connector cá nhân** của chính người đang tương tác với nó. Điều đó có nghĩa là bạn không mất quyền kiểm soát với những gì một người dùng có thể khiến Team Bot làm.

Theo Jon (video đăng ngày 21/10/2026): mặc định, Team Bot hành động bằng connector cá nhân của người đang nói chuyện với nó, nên một người không làm được qua bot những gì họ không có quyền; service account là một cấu hình tuỳ chọn.

Về chia sẻ và quyền truy cập với Team Bot, theo Jon (video đăng ngày 21/10/2026), bạn toàn quyền quyết định người dùng nào được nói chuyện với Team Bot. Bạn cũng có thể thêm **manager** cho Team Bot, để nhiều người cùng làm được những việc như dựng skill, sửa instruction, hay thêm tool mà Team Bot nên dùng.

Câu tiếp theo, Rohan nói anh đã trả lời câu này rồi nhưng vẫn nhắc lại: rất nhiều người hỏi về việc hỗ trợ **Microsoft Teams**. Theo Rohan (video đăng ngày 21/10/2026), nó đang tới, đội đang làm và đang beta test nội bộ. Anh không thể đưa ra một mốc thời gian cụ thể, nhưng nó sẽ ra; mốc anh có thể nói là khoảng vài tuần tới.

Rohan lướt qua thêm vài câu, rồi nhờ Jon nói thêm về tài khoản cá nhân và tài khoản team. Jon giải thích (video đăng ngày 21/10/2026): ở sidebar của Grok Bot, bạn có cả bot cá nhân lẫn Team Bot. Ở nhiều mặt, khác biệt duy nhất giữa một Team Bot và một bot cá nhân là Team Bot được chia sẻ cho nhiều người.

## 17. Q&A: chi tiêu theo bot, khi chạm spend limit, và self-hosted

Rohan xin lỗi vì đang lướt tìm câu hỏi, rồi đọc tiếp: phần thông tin chi tiêu theo từng người có thể cho biết những dòng usage nào gắn với bot nào của mình không? Câu trả lời là hiện chưa (tính đến video đăng ngày 21/10/2026), nhưng đội đang làm việc này ngay lúc đó, nên sẽ có thêm thông tin sau.

Câu tiếp: chuyện gì xảy ra khi chạm giới hạn chi tiêu? Rohan nhận trả lời câu này. Theo anh (video đăng ngày 21/10/2026), bạn sẽ hoặc dùng Grok Bot chậm lại, hoặc có thể không dùng được nữa. Khi đó, nếu bạn là admin, bạn chỉ cần nâng hạn mức credit lên; nếu không phải admin, bạn về cơ bản phải tìm tới admin để nhờ tăng. Anh nói đây thường là spend limit theo tháng, nên cách còn lại là chờ tới cuối tháng. Còn anh thì thường sẽ tìm tới admin để nhờ tăng.

Câu trả lời của Rohan và Jon về spend limit (video đăng ngày 21/10/2026): admin tự nâng hạn mức; người dùng thường nhờ admin hoặc chờ sang tháng mới. Kết quả cụ thể còn tuỳ admin có bật on-demand spend hay không.

Jon bổ sung (video đăng ngày 21/10/2026): thật ra nó còn tuỳ admin có bật **on-demand spend** hay không, và admin cũng kiểm soát được spend limit theo tháng. Nên câu trả lời phụ thuộc phần nào vào cách tổ chức của bạn được thiết lập.

Rohan nói có một câu mà anh biết là chưa có lời giải, nhưng vẫn đưa ra vì rất nhiều người hỏi: nhiều người muốn có worker riêng tự host, tức là chạy Grok Bot trên hạ tầng của chính họ. Anh nói đội đang nghĩ về chuyện này nhưng chưa có mốc thời gian (tính đến video đăng ngày 21/10/2026), và nhờ Jon chia sẻ thêm về cách đội nghĩ và triết lý ở đây.

Jon nói cách đội nghĩ là Grok Bot phải triển khai được ở bất kỳ công ty nào, kể cả những công ty khắt khe nhất về bảo mật. Vì vậy, theo anh (video đăng ngày 21/10/2026), đội đang tích cực làm việc và trao đổi với khách hàng để tìm ra hình dạng phù hợp cho các lựa chọn triển khai mà họ sẽ cung cấp cho Grok Bot.

## 18. Q&A: Grok Bot và Cursor, rule theo phòng ban, và lời chào

Câu hỏi tiếp theo: Grok Bot và Cursor có quan hệ gì? Jon trả lời: Grok Bot và Cursor đều là sản phẩm của cùng một công ty, SpaceX SI. Theo anh (video đăng ngày 21/10/2026), giữa hai sản phẩm có vài tích hợp rất hay. Nếu bạn dùng **cloud agent** của Cursor, bạn chỉ cần bảo bot của mình khởi động một cloud agent. Một use case kỹ thuật rất hay ở đây là dùng Grok Bot để quản lý các coding agent của bạn. Grok Bot còn có thể đưa bạn link tới các PR, cùng ảnh và video xem trước của những gì cloud agent đang làm.

Tích hợp Jon mô tả (video đăng ngày 21/10/2026): bạn bảo bot khởi động một cloud agent của Cursor, rồi Grok Bot gửi lại link PR cùng ảnh và video xem trước công việc của agent.

Rohan nói thêm: đội đã thấy những use case rất tốt của Grok Bot cho engineering, nhưng anh muốn nói thật rõ một điều: theo anh (video đăng ngày 21/10/2026), Grok Bot đặc biệt tốt cho người không làm kỹ thuật. Những use case hàng đầu đội thấy nằm ở sales, marketing, operations, tài chính, HR, IT, tuyển dụng; đó mới thật sự là "cơm ăn hằng ngày" của Grok Bot. Anh thấy bước nhảy lớn nhất là ở mảng không kỹ thuật.

Lý do, theo anh: dân kỹ thuật đã có những công cụ như Cursor và của các công ty khác, những công cụ agentic coding rất, rất tốt, nên khoảng cách từ đó lên Grok Bot có thể không lớn bằng. Grok Bot vẫn rất có giá trị cho họ nếu họ muốn, chẳng hạn, khởi động cloud agent của Cursor. Nhưng anh thật sự khuyến khích mọi người nghĩ tới những mảng khác, nhất là khi, theo anh (video đăng ngày 21/10/2026), các công cụ đang có hay từng có cho những mảng đó chưa đạt cùng mức agentic và hành vi kiểu AI teammate.

Rohan nói đã gần hết giờ, còn cả loạt câu hỏi nên anh xin một giây để lướt qua. Câu tiếp theo: có thể đặt team rule theo từng phòng ban trong công ty không? Jon trả lời: theo anh (video đăng ngày 21/10/2026), mọi control anh đã nói đều cấu hình được ở mức **group**. Nghĩa là bạn có thể có một SCIM group gồm các thành viên của một phòng ban cụ thể, và đặt cho nhóm đó những rule khác với những gì bạn đặt cho cả team.

Một người trong hai lướt thêm, bỏ qua một câu đã trả lời. Rồi Rohan đọc câu cuối: có thư viện chứa tutorial, video và câu hỏi mới nhất không? Anh trả lời là có: các guide của Grok Bot trên mạng có rất nhiều thông tin hơn, và bạn cũng xem được các use case. Trang x.ai/bot là nơi có tất cả những thông tin đó, và anh rất khuyên mọi người dùng chúng. Theo anh (video đăng ngày 21/10/2026), đội sẽ tiếp tục ra thêm tutorial, guide và cả bot template để giúp mọi người bắt đầu.

Anh nghĩ đó là một điểm hay để kết thúc. Theo anh (video đăng ngày 21/10/2026), đội liên tục ship tính năng mới, và ship rất nhanh, nên anh khuyên mọi người tiếp tục tham dự những workshop như thế này và để mắt tới các bản ra mắt mới. Anh nói rất hào hứng được thấy mọi người dùng thử Grok Bot nếu chưa dùng, và đưa nó vào doanh nghiệp của mình. Hai người cảm ơn mọi người đã tham gia.

## Nguồn và liên kết

- Tên gốc: Grok Bot for Admins
- Sự kiện: [YouTube](https://homus.dev/events/youtube)
- Video gốc: [https://www.youtube.com/watch?v=NhrXdX_93Hc](https://www.youtube.com/watch?v=NhrXdX_93Hc)

- Kênh YouTube Grok (Jon Eide Johnsen & Rohan Chandra): [youtube.com/channel/UCxgo0OMZU9SiaYpJsuZKWkQ](https://www.youtube.com/channel/UCxgo0OMZU9SiaYpJsuZKWkQ)

- Dành cho admin: [Grok Bot for teams and enterprises](https://docs.x.ai/grok-bot/teams-and-enterprises) (đọc ngày 22/10/2026: gói Teams bật Grok Bot mặc định, gói Enterprise do admin bật trong dashboard rồi giới hạn theo nhóm bằng Manage Group Access)

- SSO và SCIM: [Configure identity and access](https://docs.x.ai/grok-bot/identity-and-access) (đọc ngày 22/10/2026: hướng dẫn cho admin dùng Okta hoặc Microsoft Entra ID)

- Bot dùng chung: [Team Bots](https://docs.x.ai/grok-bot/team-bots) (đọc ngày 22/10/2026: một bot cả team cùng nói chuyện, owner dựng một lần với plugin, secret, skill, file rồi publish cho team)

- Approval: [Approvals, security, and privacy](https://docs.x.ai/grok-bot/approvals-security-and-privacy)

Nguồn: https://homus.dev/talks/grok-bot-for-admins · cập nhật 2026-10-22