Blog / Series AI Agents Thực Chiến

Agent Registry 2026: sau A2A và MCP, doanh nghiệp sẽ cần một control plane cho agent sprawl

Vấn đề thật: agent sprawl đang đến sớm hơn nhiều đội ngũ tưởng

Nếu nhìn từ bên ngoài, thị trường AI 2026 dường như vẫn xoay quanh model, benchmark và protocol. Nhưng ở bên trong doanh nghiệp, một loại hỗn loạn khác đang nổi lên nhanh hơn: agent sprawl. Hôm nay đội chăm sóc khách hàng dựng một agent intake. Tuần sau nhóm vận hành thêm một agent đối soát. Bộ phận tài chính dựng agent kiểm tra hóa đơn. Nhóm bảo mật dựng agent rà cấu hình. Mỗi agent lại kéo theo tool, skill, policy và tài khoản riêng.

Lúc này vấn đề không còn là “có làm được hay không”, mà là “có còn nhìn thấy hệ thống mình đang sở hữu hay không”. Một agent registry xuất hiện đúng ở điểm đau này. Nó không thay thế MCP, không thay thế A2A, và cũng không thay thế workflow engine. Nó là lớp giúp tổ chức biết thực thể nào đang tồn tại trong mạng lưới agent của mình.

Có thể xem đây là bước lặp lại của lịch sử microservices. Lúc đầu ai cũng hào hứng vì nhóm nào cũng có thể ship nhanh. Một thời gian sau, thứ thiếu nhất không phải thêm service mới mà là service catalog, ownership map, policy và lifecycle management. Agent đang đi vào đúng vòng lặp đó, chỉ nhanh hơn vì tốc độ bùng nổ use case lớn hơn.

Agent registry là gì, và khác thư mục tài liệu nội bộ ở đâu?

Agent registry là nơi lưu và công bố metadata có thể thực thi được về agent, tool, skill hoặc MCP server, thay vì chỉ là ghi chú tĩnh trên wiki. Một registry đúng nghĩa phải trả lời được ít nhất các câu hỏi sau:

1. Agent này tên gì, thuộc đội nào, ai chịu trách nhiệm?
2. Nó có capability gì, input và output contract ra sao?
3. Nó được phép truy cập dữ liệu nào và không được đụng tới dữ liệu nào?
4. Phiên bản hiện tại là gì, đang ở môi trường nào, có rollout bao nhiêu phần trăm?
5. Agent nào khác được phép gọi nó, theo điều kiện gì?

Điểm khác biệt lớn nhất so với một bảng Notion hay Google Sheet là registry phải sống cùng hệ vận hành. Nó phải đủ chuẩn để router, workflow engine hoặc các agent khác có thể đọc được, kiểm chứng được, và dựa vào đó để ra quyết định.

Nói cách khác, nếu model routing là traffic control cho request, thì agent registry là bản đồ chính thức của toàn bộ thực thể có thể nhận việc trong hệ.

Use case end-to-end: tập đoàn vận hành nhiều agent cho hỗ trợ, tài chính và nội bộ

Hãy lấy một ví dụ thực tế. Một tập đoàn bán lẻ triển khai hơn mười agent trong ba tháng:

• agent hỗ trợ khách hàng,
• agent kiểm tra hoàn tiền,
• agent đối soát hóa đơn nhà cung cấp,
• agent tóm tắt văn bản pháp lý,
• agent nội bộ cho nhân sự và IT helpdesk.

Ban đầu, mỗi nhóm tự ship theo stack mình quen. Có agent chạy trên runtime A, có agent nhúng vào bot nội bộ, có agent chỉ là wrapper của một workflow. Trong vài tuần đầu, tốc độ ra tính năng rất ấn tượng. Sau đó, các câu hỏi bắt đầu dồn lên:

• Ai đang sở hữu agent hoàn tiền sau khi PM cũ nghỉ?
• Agent nào vẫn còn quyền gọi hệ thanh toán thật?
• Agent nào đang dùng policy cũ và có nguy cơ trả sai cho khách hàng?
• Khi một agent trung tâm muốn giao việc cho agent khác, lấy capability từ đâu để không gọi nhầm phiên bản?

Một agent registry tốt giải quyết việc này bằng cách biến từng agent thành một thực thể có hồ sơ sống: owner, environment, dependency, policy, SLA, incident history và capability card. Khi A2A hoặc orchestration cần tìm agent phù hợp, registry cung cấp danh sách ứng viên có thể tin cậy hơn là hard-code endpoint trong prompt hay config rời rạc.

Dòng chảy end-to-end khi registry đã trở thành control plane

1. Nhóm tài chính muốn onboard một agent mới để kiểm tra hóa đơn trùng.
2. Agent được đăng ký vào registry với capability, owner, policy, secret scope và rollout trạng thái staging.
3. Một router hoặc agent điều phối tra registry để biết agent nào được phép xử lý tác vụ này ở môi trường production.
4. Trong lúc chạy, observability gửi trace và quality metrics quay lại registry hoặc hệ giám sát liên kết.
5. Khi agent phát hiện lỗi hoặc quality giảm, registry có thể đánh dấu trạng thái degraded hoặc chặn discovery ở production.

Lúc đó, registry không còn là nơi tra cứu thủ công. Nó trở thành điểm tựa để governance, routing và incident response nói cùng một ngôn ngữ.

Kiến trúc hệ thống: discovery, identity, policy, lifecycle và observability

Một agent registry hữu ích phải được thiết kế như control plane, không chỉ như UI quản lý. Tối thiểu nên có năm lớp sau.

1. Discovery layer

Đây là lớp trả lời câu hỏi “trong tổ chức có gì”. Discovery nên hỗ trợ tìm theo capability, team owner, môi trường, mức nhạy cảm dữ liệu, giao thức hỗ trợ như MCP hay A2A, và độ sẵn sàng hiện tại.

2. Identity và trust

Không nên cho phép một agent tự xưng danh rồi tự xuất hiện trong hệ. Registry phải gắn identity đủ xác thực được, liên kết với service account, key rotation và owner cụ thể. Đây là phần nối trực tiếp với bài AI Agent Identity 2026.

3. Policy và approval

Một capability card không đủ nếu policy nằm rải rác trong prompt. Registry nên biết agent nào được phép chạm dữ liệu tài chính, agent nào chỉ được chạy read-only, agent nào bắt buộc có human approval trước khi action. Nếu không, discovery càng tốt thì blast radius khi cấu hình sai càng lớn.

4. Lifecycle management

Agent cũng cần vòng đời giống service: draft, staging, canary, production, deprecated, disabled. Một trong những failure mode phổ biến nhất là agent cũ vẫn còn tồn tại âm thầm, vẫn có secret hợp lệ và vẫn bị gọi bởi một luồng nào đó mà không ai nhớ nữa.

5. Observability và feedback loop

Registry trưởng thành không chỉ chứa metadata tĩnh. Nó cần liên kết với quality metrics, incident history, human override rate và cost telemetry. Khi đó đội ngũ mới phân biệt được giữa agent tồn tại và agent xứng đáng tiếp tục được dùng.

Trade-off và failure mode thường bị xem nhẹ

Nghe qua, agent registry có vẻ hiển nhiên là nên có. Nhưng nếu làm sai, nó cũng có thể trở thành một lớp quan liêu mới mà đội ngũ tìm cách lách qua.

1. Registry rot

Nếu cập nhật registry là việc tay, metadata sẽ lỗi thời rất nhanh. Khi đó registry tạo cảm giác an tâm giả, nguy hiểm hơn cả việc không có registry.

2. Over-centralization

Nếu mọi thay đổi nhỏ đều phải qua một hội đồng trung tâm, tốc độ ship sẽ chết. Registry tốt phải tạo governance có thể tự động hóa, không phải bureaucratic choke point.

3. Capability theater

Nhiều agent tự mô tả capability rất đẹp, nhưng thực tế chất lượng thấp hoặc chỉ ổn ở một tập dữ liệu hẹp. Nếu registry không gắn với telemetry, discovery sẽ bị nhiễm marketing nội bộ.

4. Policy drift

Agent có thể được đăng ký đúng ở ngày đầu, nhưng sau vài tuần prompt, secret và dependency thay đổi. Nếu registry không kéo được dữ liệu runtime, thông tin policy sẽ lệch dần khỏi sự thật.

5. Shadow agents

Đây là failure mode rất thực tế. Khi registry quá khó dùng, các nhóm sẽ dựng agent ngoài luồng. Kết quả là hệ “chính thức” có registry còn hệ “thực tế” lại chạy đâu đó ngoài tầm nhìn. Muốn tránh điều này, registry phải tạo giá trị vận hành thật, không chỉ phục vụ compliance.

Checklist rollout production

Với doanh nghiệp đang bước vào giai đoạn nhiều agent, cách rollout an toàn nhất là đi từ metadata tối thiểu đến control plane có thể hành động được.

Giai đoạn 1: dựng inventory tối thiểu

• Lập danh sách tất cả agent, skill, MCP server, workflow có quyền hành động.
• Gắn owner, môi trường, capability và mức rủi ro cho từng thực thể.
• Đánh dấu ngay agent không còn owner rõ ràng.

Giai đoạn 2: chuẩn hóa capability card

• Quy định schema thống nhất cho input, output, policy, dependency và version.
• Tách metadata dùng cho discovery với metadata dùng cho audit.
• Ưu tiên liên kết với MCP và A2A nếu hệ đã có nhiều handoff.

Giai đoạn 3: gắn lifecycle và release controls

• Mọi agent mới phải có trạng thái rollout rõ.
• Cho phép disable discovery khi quality hoặc policy fail.
• Log mọi thay đổi owner, policy và secret scope.

Giai đoạn 4: nối registry với runtime và telemetry

• Tự động cập nhật health, usage, cost và incident state.
• Hiển thị agent nào đang còn được gọi và agent nào đã gần như chết.
• Đo human override rate và task success rate để tránh capability theater.

Giai đoạn 5: chỉ mở discovery rộng khi governance đã sống được

• Không mở self-service onboarding toàn tổ chức quá sớm.
• Ưu tiên những domain rủi ro vừa phải trước, như internal ops hoặc read-only workflows.
• Giữ quyền rollback về discovery hẹp nếu chất lượng registry chưa đủ tin cậy.

Insight cuối cùng: khi agent trở thành tài sản vận hành, registry sẽ thành lớp quản trị bắt buộc

Ở giai đoạn thử nghiệm, một agent có thể chỉ là một ý tưởng được đóng gói trong prompt và vài tool. Nhưng khi agent bắt đầu tham gia vào luồng vận hành thật, nó trở thành một thực thể vận hành, có owner, policy, blast radius và chi phí. Khi đó, tổ chức không thể quản nó bằng trí nhớ của vài cá nhân.

Đó là lý do agent registry đang nóng lên. Không phải vì thị trường cần thêm một dashboard, mà vì tổ chức đang cần một cách biến agent từ đồ chơi rải rác thành tài sản có thể nhìn thấy, kiểm soát và tắt đi đúng lúc.

Nếu 2025 là năm doanh nghiệp hỏi “chúng ta có thể dùng agent vào việc gì?”, thì 2026 đang dần thành năm của câu hỏi khó hơn: “chúng ta đang sở hữu bao nhiêu agent, ai chịu trách nhiệm cho chúng, và lớp governance nào giữ chúng không vượt khỏi tầm kiểm soát?”.