Model Context Protocol (MCP) đang dần trở thành một trong những mảnh ghép quan trọng của hệ sinh thái AI agent. Thay vì phải xây dựng một cách tích hợp riêng cho từng nguồn dữ liệu hay công cụ, MCP tạo ra một giao thức chung để ứng dụng AI kết nối với các hệ thống bên ngoài. Thông qua MCP, một agent có thể tìm kiếm dữ liệu, đọc tài liệu, truy vấn hệ thống hay thực hiện một hành động thông qua các tool được cung cấp.¹ Tuy nhiên, kết nối được với thế giới bên ngoài mới chỉ giải quyết một nửa bài toán. Phần lớn cách chúng ta tương tác với AI hiện nay vẫn bắt đầu từ một yêu cầu: người dùng đặt câu hỏi, agent nhận nhiệm vụ, sau đó truy cập dữ liệu hoặc gọi tool cần thiết để hoàn thành nó. Nhưng các hệ thống thực tế không vận hành theo cách đó. Một giao dịch có thể thất bại, khách hàng có thể vừa bổ sung tài liệu cho một ticket, một đơn hàng chuyển trạng thái hoặc một tín hiệu rủi ro mới xuất hiện mà không có ai đứng đó để thông báo cho AI.

Nếu agent ngày càng tham gia sâu hơn vào các quy trình vận hành, câu hỏi vì thế không chỉ còn là “AI có thể làm gì?”, mà còn là “khi nào AI nên biết rằng có việc cần làm?”. Đây cũng là lý do event-driven đang trở thành một trong những hướng phát triển đáng chú ý tiếp theo của MCP.

Hãy cùng Lemon’s Tribe tìm hiểu về hướng đi thú vị nhưng tất yếu này của MCP trong bài viết này nhé. (Các bạn có thể tìm hiểu lại về MCP truyền thống qua bài viết Model Context Protocol (MCP): USB‑C cho trí tuệ nhân tạo)

Từ request-driven đến event-driven

Trong mô hình phổ biến hiện nay, tương tác thường bắt đầu từ phía người dùng hoặc ứng dụng:

Request → Agent → MCP → Data/Tool → Response

Ví dụ, người dùng hỏi chatbot vì sao giao dịch chưa thành công. Agent nhận yêu cầu, thông qua MCP gọi tool kiểm tra giao dịch, lấy thông tin cần thiết rồi trả lời. MCP giúp chuẩn hóa cách AI truy cập những năng lực (capability) này, nhưng toàn bộ quá trình vẫn bắt đầu vì có một yêu cầu (request).

Với event-driven, điểm khởi đầu được đảo lại. Một thay đổi trong hệ thống có thể trở thành tín hiệu để hệ thống AI xem xét liệu có cần phản ứng hay không:

Event → Filter/Policy → Agent → MCP → Action

Chẳng hạn, thay vì chờ khách hàng phát hiện giao dịch thất bại rồi chủ động liên hệ chăm sóc khách hàng, sự kiện payment.failed có thể trở thành tín hiệu đầu vào. Hệ thống trước tiên xác định đây có phải trường hợp đáng xử lý hay không. Nếu cần suy luận, agent được kích hoạt, lấy thêm ngữ cảnh/thông tin liên quan của giao dịch thông qua MCP rồi quyết định bước tiếp theo: hướng dẫn người dùng thử lại, chủ động tạo yêu cầu hỗ trợ (ticket) hoặc chuyển trường hợp bất thường cho người chuyên trách xử lý.

Khác biệt tưởng như chỉ nằm ở điểm bắt đầu, nhưng lại thay đổi khá nhiều vai trò của AI trong sản phẩm. AI không còn chỉ là một giao diện chờ người dùng đặt câu hỏi, mà có thể trở thành một thành phần tham gia vào workflow đang diễn ra.

MCP đã event-driven chưa?

Câu trả lời ở thời điểm hiện tại là: một phần, nhưng chưa hoàn toàn. Phiên bản MCP 28/07/2026 đã bổ sung subscriptions/listen, cho phép client mở một luồng kết nối để nhận notification từ server thay vì liên tục gửi request kiểm tra xem có gì thay đổi hay không. Hiện cơ chế này hỗ trợ những thay đổi đã được MCP định nghĩa, chẳng hạn danh sách tool, prompt hoặc resource được cập nhật.² MCP cũng có Tasks extension dành cho những tác vụ kéo dài. Một request có thể tạo ra task tồn tại độc lập trong một khoảng thời gian; client có thể kiểm tra trạng thái hoặc đăng ký nhận notification khi trạng thái task thay đổi.³

Tuy nhiên, có một điểm cần phân biệt: việc nhận thông báo một task đã tạo trước đó vừa hoàn thành khác với việc một business event hoàn toàn mới như payment.failed, fraud.alert hay ticket.updated xuất hiện và chủ động “đánh thức” agent. Đây chính là khoảng trống mà Triggers & Events Working Group của MCP đang nghiên cứu. Roadmap công bố vào tháng 8/2026 đưa server-initiated events thành một trong những hướng phát triển của protocol, bao gồm channels, subscriptions và các hình thức push delivery như webhook.⁴ Working Group hiện vẫn được ghi rõ là “experimental”, tức các cơ chế này đang trong quá trình thử nghiệm và chưa phải một phần ổn định của MCP specification (thông số).⁵

Một đề xuất khác là SEP-2495 còn đi xa hơn khi đề xuất cơ chế để event từ server có thể khiến host bắt đầu một lượt xử lý mới của LLM. Tuy nhiên, SEP-2495 hiện vẫn chỉ là đề xuất, chưa được chấp nhận thành chuẩn.⁶

Vì vậy, nói rằng “MCP đã trở thành event-driven protocol” ở thời điểm này sẽ hơi sớm. Chính xác hơn, MCP đang bổ sung dần những mảnh ghép cần thiết để hỗ trợ tốt hơn cho các hệ thống bất đồng bộ và event-driven.

Event-driven MCP sẽ thay đổi sản phẩm AI như thế nào?

Điểm đáng chú ý của hướng phát triển này không nằm ở webhook hay subscription, mà ở cách chúng ta có thể thiết kế sản phẩm AI. Event-driven vốn không phải khái niệm mới. Hiện nay, khi một giao dịch thay đổi trạng thái, backend vẫn có thể chạy cron job để phát hiện thay đổi hoặc nhận event qua Kafka, sau đó gọi một service trung gian hoặc trực tiếp kích hoạt agent. Agent tiếp tục lấy context, gọi tool và thực hiện workflow cần thiết. Về bản chất, chúng ta đã có thể xây những sản phẩm AI phản ứng với event mà không cần chờ MCP phát triển thêm.

Điểm khác biệt nằm ở cách những năng lực này được kết nối với agent. Trong kiến trúc hiện tại, mỗi proactive AI use case thường cần thêm một lớp tích hợp riêng: backend nhận event, xác định trường hợp nào cần AI, chuẩn bị dữ liệu rồi gọi đúng agent hoặc AI service. Khi event và trigger được đưa đến gần agent layer hơn, trong khi MCP chuẩn hóa cách agent truy cập dữ liệu và công cụ, kiến trúc có thể tiến dần từ những pipeline được nối riêng cho từng use case sang các building block có khả năng tái sử dụng:

Business event → Filter/Policy → Agent → MCP → Action

MCP khi đó trả lời câu hỏi agent có thể truy cập và làm gì, còn event xác định khi nào agent cần được kích hoạt. Agent suy luận quyết định nên làm gì trong tình huống đó, trong khi chính sách (policy) và quyền hạn (permission) xác định agent thực sự được phép làm đến đâu. Việc tách những lớp này cũng rất quan trọng: không phải event nào cũng cần gọi LLM và không phải quyết định nào của agent cũng nên được tự động thực thi.

Với người làm Product, thay đổi này đáng quan tâm vì nó mở rộng cách chúng ta xác định một AI use case. Thay vì chủ yếu nghĩ “người dùng sẽ hỏi AI điều gì?” hay “đặt chatbot ở đâu?”, Product có thể bắt đầu từ workflow: sự kiện nào đang xảy ra trong hành trình mà nếu sản phẩm hiểu được và phản ứng đúng lúc sẽ tạo ra giá trị? Ứng dụng của AI chuyển từ một tính năng mà người dùng phải chủ động tìm đến, có thể trở thành một thành phần tham gia trực tiếp vào quá trình vận hành sản phẩm.

Lợi ích tiếp theo là khả năng tái sử dụng event và năng lực giữa nhiều AI use case. Chẳng hạn, cùng một payment.failed có thể được Customer Service agent sử dụng để chủ động hỗ trợ khách hàng, trong khi Risk agent kết hợp nó với những tín hiệu khác để đánh giá bất thường. Các agent có thể sử dụng chung những capability như đọc giao dịch, lấy thông tin tài khoản hay tạo ticket thông qua MCP thay vì mỗi use case phải xây lại toàn bộ chuỗi tích hợp. Điều này không loại bỏ backend, Kafka hay event bus vốn vẫn cần cho delivery, retry hoặc replay; phần có thể giảm đi là lượng custom orchestration phải viết riêng chỉ để kết nối từng business event với từng AI use case.

Product vì vậy không cần biết cách triển khai event subscription hay message broker, nhưng cần nhận biết sự thay đổi về capability này. Nó ảnh hưởng trực tiếp đến những bài toán nào có thể giải bằng AI, thời điểm AI nên xuất hiện trong hành trình của user, mức độ chủ động của sản phẩm và chi phí để đưa một use case mới vào vận hành. Khi hạ tầng ngày càng có tính ghép nối, Product cũng có thể chuyển cách đặt bài toán từ “tính năng này cần tích hợp những hệ thống nào?” sang “business event nào cần AI tham gia, agent nào nên xử lý, cần những capability nào và được phép hành động đến đâu?”

Khía cạnh nào được hưởng lợi từ hướng đi này?

Customer Service (chăm sóc khách hàng) là một ví dụ khá trực quan. Giả sử khách hàng vừa bổ sung tài liệu cho một ticket đang chờ xử lý. document.received có thể kích hoạt một workflow để agent lấy ticket, lịch sử hội thoại và tài liệu thông qua MCP, kiểm tra thông tin đã đầy đủ chưa rồi quyết định tiếp tục xử lý, yêu cầu bổ sung thông tin hoặc chuyển cho bộ phân liên quan. Tương tự, payment.failed có thể kích hoạt agent kiểm tra ngữ cảnh của giao dịch và chủ động hướng dẫn khách hàng trước khi họ phải tìm đến kênh hỗ trợ.

Cùng một cách tiếp cận có thể áp dụng cho nhiều sản phẩm khác. Trong phát hiện gian lận, risk.signal.created có thể kích hoạt agent tổng hợp lịch sử giao dịch, thông tin thiết bị và thông tin liên quan đến tài khoản để hỗ trợ chuyên viên phân tích rủi ro đánh giá từng trường hợp.

Trong Sales, thay đổi trạng thái của một lead (khách hàng tiềm năng) có thể kích hoạt agent tổng hợp lịch sử tương tác, đánh giá tiềm năng và chuẩn bị bước tiếp theo.

Điểm chung của những use case này không phải AI trở nên “tự chủ” hơn, mà là sản phẩm có khả năng “ra tay” vào đúng thời điểm trong workflow. Giá trị của event-driven vì thế không chỉ nằm ở việc phản ứng nhanh hơn, mà còn ở khả năng giảm công sức của user, tự động hóa những đoạn workflow trước đây cần con người khởi tạo và giúp cùng một tập event, dữ liệu và capability được kết hợp lại để tạo ra nhiều AI use case khác nhau.

Event-driven không đồng nghĩa với việc AI được phép tự do hành động

Đây có lẽ là ranh giới quan trọng nhất. Nếu mọi event đều trực tiếp gọi LLM, một hệ thống có hàng triệu event mỗi ngày rất nhanh có thể biến thành hàng triệu model call. Phần lớn trong số đó thậm chí không cần AI: một rule đơn giản có thể xử lý nhanh hơn, rẻ hơn và ổn định hơn.

Kiến trúc hợp lý vì thế không nên là:

Event → LLM → Action

mà gần hơn với:

Event → Filter/Rules → Agent khi cần reasoning → MCP → Policy/Approval → Action

Chỉ những event đủ quan trọng hoặc đủ mơ hồ để cần tổng hợp context và reasoning mới nên đi tới agent. Các trường hợp xác định được bằng logic cố định vẫn nên dùng automation (tự động hoá) truyền thống.

Khi agent có khả năng chủ động hành động, một số vấn đề vốn đã tồn tại trong hệ thống event-driven cũng trở nên nhạy cảm hơn:

• Event có thể được gửi lại nhiều lần, vì vậy những hành động như hoàn tiền, gửi voucher hay tạo ticket phải có cơ chế chống thực thi trùng lặp.
• Hệ thống cũng cần lưu lại log toàn bộ chuỗi event → decision (quyết định) → tool call → approval (duyệt) → action (hành động) để có thể truy vết khi có vấn đề.
• Quyền hạn cũng không thể chỉ dừng ở việc “agent được truy cập MCP server”. Sau khi nhận được event, AI agent có thể tiếp tục thực hiện các hành động khác, tuỳ vào quyền mà nó được giao phó.

Tuy nhiên, cần phải nhớ kỹ rằng: quyền đọc giao dịch không đồng nghĩa với quyền hoàn tiền; quyền tạo nội dung email không đồng nghĩa với quyền gửi email; khả năng phát hiện một giao dịch đáng ngờ không đồng nghĩa với quyền khóa tài khoản. Những gì tác động trực tiếp đến tài sản, hoặc dữ liệu của người dùng đều là cần có sự đánh giá kỹ lưỡng và cẩn trọng. Tài liệu MCP specification hiện cũng đặt user consent (đồng thuận từ user), control (kiểm soát) và authorization (cấp quyền) vào nhóm nguyên tắc quan trọng khi ứng dụng AI truy cập dữ liệu và thực thi tool.⁷ Khi agent bắt đầu phản ứng với những sự kiện mà người dùng không trực tiếp khởi tạo, những ranh giới này càng cần được thiết kế rõ ràng.

Tạm kết

MCP ban đầu giải quyết một bài toán khá rõ ràng: giúp AI kết nối với dữ liệu và công cụ bên ngoài theo một cách thống nhất. Nhưng khi AI agent tham gia sâu hơn vào những workflow kéo dài và liên tục thay đổi, chỉ biết cách truy cập thế giới bên ngoài là chưa đủ. Agent còn cần biết khi nào có một thay đổi đáng để chú ý. Event-driven là một hướng phát triển tự nhiên từ nhu cầu đó.

Điều này không có nghĩa chúng ta phải chờ MCP chuẩn hóa toàn bộ phần event mới có thể xây những sản phẩm như vậy. Kiến trúc hiện tại vẫn có thể sử dụng event bus, Kafka hay webhook để tiếp nhận sự kiện, lọc những trường hợp cần reasoning rồi kích hoạt agent; MCP đảm nhiệm việc chuẩn hóa cách agent truy cập context và tool. Nếu server-initiated events tiếp tục được chuẩn hóa trong tương lai, phần kết nối giữa event và agent có thể trở nên thống nhất hơn, qua đó giảm bớt những lớp tích hợp riêng phải xây cho từng use case.

Với Product, điều cần chuẩn bị không nhất thiết là một kiến trúc mới, mà là một cách nhìn khác về nơi AI có thể tạo ra giá trị trong sản phẩm. Thay vì chỉ tìm những điểm mà người dùng có thể chủ động yêu cầu AI hỗ trợ, chúng ta có thể nhìn vào toàn bộ workflow để xác định những business event mà sản phẩm nên nhận biết và phản ứng. Tuy nhiên, không phải event nào cũng cần gọi LLM. Nếu một rule cố định đã đủ để giải quyết vấn đề, automation truyền thống vẫn đơn giản, rẻ và ổn định hơn. AI chỉ thực sự có giá trị khi bước tiếp theo cần hiểu context, xử lý sự mơ hồ hoặc đưa ra quyết định dựa trên nhiều nguồn thông tin.

Vì vậy, hướng đi đáng chú ý của event-driven MCP không nằm ở việc biến mọi event thành một lời gọi LLM hay làm agent “tự chủ” hơn. Event cho biết khi nào có chuyện xảy ra, agent quyết định nên làm gì, MCP cung cấp những gì agent có thể sử dụng, còn policy xác định agent được phép làm đến đâu. Khi những lớp này ngày càng được chuẩn hóa và kết nối tốt hơn, AI product cũng có thể dịch chuyển từ những hệ thống chờ con người tìm đến và đặt câu hỏi sang những hệ thống biết khi nào mình thực sự cần xuất hiện và tạo ra giá trị.

Cheers & Peace!

---

Nguồn tham khảo

1. Model Context Protocol, Specification 2026-07-28. ↩︎
2. Model Context Protocol, Subscriptions – MCP 2026-07-28. ↩︎
3. Model Context Protocol, MCP Tasks Extension. ↩︎
4. Model Context Protocol, The New MCP Roadmap. ↩︎
5. Model Context Protocol, Triggers & Events Working Group – Experimental Extension. ↩︎
6. Model Context Protocol, SEP-2495: Event-Driven Tool Invocation (Server-Push to LLM Re-entry). ↩︎
7. Model Context Protocol, Specification 2026-07-28 – Trust, Safety and Authorization. ↩︎