Agent trong chat: đừng chỉ thêm bot vào phòng

Agent trong chat: đừng chỉ thêm bot vào phòng

Buzz gợi ý một tương lai nơi người và AI agent làm việc chung trong group chat. Nhưng production không nằm ở giao diện chat, mà ở orchestration và guardrail.

“Cho agent vào Slack đi, chắc team sẽ tự động hóa được nhiều việc hơn.”

Mình nghe câu này ở vài team rồi. Thường nó xuất hiện sau một buổi demo khá mượt: bot đọc ticket, tóm tắt thread, mở PR, nhắc deadline, rồi trả lời kiểu rất biết điều. Cả phòng nhìn nhau như vừa thấy quầy bar có bartender pha được mọi món từ espresso martini tới trà đào cam sả.

Nhưng lúc đem vào công việc thật, câu hỏi khó hơn hẳn: ai cho agent quyền làm gì, theo luồng nào, dừng ở đâu, và ai chịu trách nhiệm khi nó pha nhầm món?

Buzz, nền tảng group chat mới mà Jack Dorsey giới thiệu, đáng chú ý không phải vì nó “đấu Slack” hay “thêm AI vào chat”. Điểm đáng mổ xẻ hơn là tín hiệu này: workspace đang chuyển từ nơi con người nhắn tin sang nơi con người và AI agent cùng vận hành workflow. Và ở production, agent chỉ đáng tin khi orchestration và guardrail được thiết kế rõ, không phải khi nó nằm trong app chat bóng bẩy nhất.

Sơ đồ minh họa cho bài Agent trong chat: đừng chỉ thêm bot vào phòng

Sơ đồ tóm tắt ý chính của bài viết.

Tín hiệu chính: chat đang thành mặt bàn điều phối

Buzz được mô tả như một group chat cho team người và agent, model-agnostic, decentralized, self-sovereign, open source. Nó cũng muốn gom nhiều workflow đang rải rác giữa chat, GitHub project và agent vào cùng một cửa sổ.

Điều này chạm đúng một nỗi đau quen thuộc: team càng dùng nhiều AI, công việc càng bị xé nhỏ thành nhiều tab. Một agent nằm trong Slack, một agent khác chạy qua API, code review ở GitHub, issue ở Linear hoặc Jira, tài liệu ở Notion, còn quyết định thật thì trôi trong thread chat.

Nói thẳng ra thì: vấn đề không phải thiếu bot. Vấn đề là thiếu một lớp điều phối để bot, tool và người cùng hiểu “đang làm bước nào”.

Ở đây có một thuật ngữ cần giữ lại: orchestration — lớp điều phối nhiều bước, nhiều tool hoặc nhiều agent để hoàn thành một việc. Trong công việc thật, orchestration trả lời các câu như:

Nếu không có lớp này, group chat chỉ là quầy pha đông khách: ai cũng gọi món, bartender nào cũng tưởng mình đang phục vụ đúng bàn.

Mổ lớp 1: giao diện chat không phải hệ thống agent

Rất dễ nhầm “agent trong chat” với “hệ thống agent”. Nhưng hai thứ này khác nhau.

Chat là nơi tương tác. Agent system là toàn bộ phần nằm sau: quyền truy cập, tool calling, memory, hàng đợi tác vụ, logging, rollback, và chính sách duyệt.

Tool calling là khả năng để model gọi công cụ hoặc API thay vì chỉ trả lời bằng chữ. Ví dụ: thay vì nói “mình đã tạo issue”, agent thật sự gọi API GitHub để tạo issue. Đây là điểm làm agent hữu ích, nhưng cũng là điểm làm nó nguy hiểm hơn chatbot.

Hình dung thế này: team bạn có một agent tên ReleaseBuddy trong phòng #deploy. Nó có thể:

  1. Đọc changelog.
  2. Kiểm tra CI.
  3. Tóm tắt PR rủi ro.
  4. Tạo draft release note.
  5. Gửi thông báo deploy.

Nếu agent chỉ tóm tắt thì rủi ro thấp. Nhưng nếu nó có quyền merge, tag release, gửi email khách hàng, hoặc thay đổi config production, câu chuyện đổi màu ngay. Lúc đó, “agent trả lời hay” không đủ. Bạn cần biết nó đã dựa vào dữ liệu nào, gọi tool nào, và có bước human approval chưa.

Đây là chỗ nhiều team hiểu sai: họ đánh giá agent bằng demo hội thoại, trong khi production phải đánh giá bằng đường đi của hành động.

Mổ lớp 2: guardrail không phải nút “an toàn” trang trí

Guardrail là rào chắn vận hành: luật, giới hạn quyền, bước xác nhận và kiểm tra giúp agent không đi quá phạm vi. Nó không nên là một dòng system prompt kiểu “hãy cẩn thận”.

Guardrail tốt thường nằm ở nhiều tầng:

Ví dụ cụ thể: giả sử team bạn 8 người, dùng agent để hỗ trợ customer support kỹ thuật. Agent được phép đọc FAQ, ticket cũ, status page và log lỗi đã được ẩn thông tin nhạy cảm. Nó có thể soạn câu trả lời, gắn tag ticket, đề xuất mức ưu tiên. Nhưng nó không được tự hứa refund, không được xem thông tin thanh toán, không được gửi thông báo sự cố diện rộng nếu chưa có người duyệt.

Đó mới là guardrail có răng. Không lấp lánh, nhưng cứu bạn khỏi những pha “AI tự tin quá mức” lúc 5 giờ chiều thứ Sáu.

Mổ lớp 3: open source giúp kiểm soát, không miễn phí vận hành

Buzz nhấn mạnh open source và khả năng tự host. Đây là điểm đáng giữ, nhất là với team cần kiểm soát dữ liệu, tích hợp workflow riêng, hoặc không muốn toàn bộ lịch sử công việc nằm trong một nền tảng đóng.

Nhưng open source không tự động biến thành production-ready.

Nếu self-host, bạn phải tự trả lời:

Model-agnostic — không phụ thuộc một model cụ thể — là hướng đúng, nhưng không có nghĩa bạn đổi model như thay topping. Model khác nhau về khả năng tool calling, độ ổn định JSON, context window, chi phí, tốc độ và cách xử lý instruction. Context window là vùng ngữ cảnh model còn giữ được trong một lượt xử lý; nếu nhồi quá nhiều thread chat, ticket, diff code và tài liệu vào đó, model có thể lẫn phần giữa như người pha đang nhận ba order cùng lúc.

Với practitioner, quyết định không phải “dùng Buzz hay Slack”. Quyết định thật là: workflow nào đủ rõ để đưa agent vào, và workflow nào vẫn nên để người cầm lái?

Điều đáng giữ: group chat là nơi tốt để phơi bày trạng thái

Mình thích ý tưởng đưa agent vào cùng không gian với con người, nếu nó được dùng đúng vai.

Chat có một lợi thế lớn: mọi người đã ở đó. Nếu agent chạy trong một dashboard riêng, nhiều khi nó thành chiếc máy pha đặt trong kho: có cũng như không. Khi agent báo tiến độ, hỏi quyền, đưa bằng chứng, hoặc tóm tắt thay đổi ngay trong kênh làm việc, team dễ bắt nhịp hơn.

Một khung nhỏ để bạn áp dụng trong một buổi chiều:

Chọn 1 workflow, không chọn 10

Đừng bắt đầu bằng “agent làm trợ lý tổng hợp”. Hãy chọn một workflow có đầu vào, đầu ra và tiêu chí dừng rõ.

Gợi ý:

Vẽ đường đi của hành động

Viết ra 5 dòng:

Trigger: Khi nào agent chạy?
Inputs: Agent được đọc gì?
Tools: Agent được gọi API nào?
Approval: Bước nào cần người duyệt?
Output: Kết quả được ghi ở đâu?

Nếu không điền được 5 dòng này, chưa nên automate.

Chia quyền theo cấp độ

Một cách đơn giản:

| Cấp | Agent được làm gì | Ví dụ |
|---|---|---|
| Read | Chỉ đọc và tóm tắt | Tóm tắt thread, PR, ticket |
| Draft | Soạn nháp, chờ duyệt | Draft email, release note |
| Act | Gọi tool có tác động | Tạo issue, gắn label |
| Commit | Thay đổi hệ thống quan trọng | Merge PR, deploy, gửi thông báo lớn |

Team mới nên ở Read và Draft trước. Act chỉ dùng cho tác vụ có rollback dễ. Commit cần guardrail rất chặt.

Điều nên bỏ qua: cuộc đua “agent làm mọi thứ”

Các tín hiệu quanh thị trường agent đang rất ồn: Salesforce mua Fin để tăng lực cho agent dịch vụ khách hàng, startup dùng agent hỗ trợ gọi vốn, Hermes và nhiều agent open source chạy desktop hoặc VPS, Meta được nói là chuẩn bị sản phẩm agent trả phí cao hơn cho người dùng nặng.

Tất cả cho thấy agent đang thành một lớp sản phẩm thật. Nhưng với team đang làm việc mỗi ngày, FOMO nguy hiểm nằm ở chỗ khác: thấy ai cũng nói agent, rồi nhét agent vào mọi kênh mà không đổi quy trình vận hành.

Nếu team bạn chưa có owner rõ cho workflow, chưa biết log nằm đâu, chưa có quy định quyền truy cập, chưa có cách đo chất lượng đầu ra, thì thêm agent chỉ làm nhiễu thêm. Nó giống mở thêm một quầy pha trong giờ cao điểm nhưng không có menu, không có số bàn, không ai biết ly nào giao cho ai.

Sau bài này, thứ mình muốn bạn nghĩ khác là: agent trong chat không phải một tính năng cộng thêm; nó là một quyết định kiến trúc vận hành. Giao diện có thể giống Slack, Buzz, Discord hay app nội bộ. Phần quyết định thành bại nằm ở orchestration, guardrail và quyền hành động.

Nếu là mình, mình sẽ không bắt đầu bằng việc hỏi “nền tảng agent nào hot nhất?”. Mình sẽ hỏi: “Workflow nào của team đủ chín để giao cho agent một phần, và phần đó có rào chắn chưa?”

Chọn đúng ly cần pha trước đã. Đừng mở cocktail menu 40 món khi team còn chưa thống nhất ai rửa shaker.

---
Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo