Một tình huống có thật ở nhiều team: bạn có sẵn portal nội bộ, vài script Terraform, một Slack bot tạo repo. Rồi một senior dev cắm Claude Code vào workflow, agent bắt đầu tự gọi script cấp database staging. Nó gọi hai lần vì lần đầu timeout. Giờ có hai database, một cái không ai biết của ai, bill cloud cuối tháng cộng thêm vài trăm đô. Không ai làm sai cả. Chỉ là platform của bạn chưa từng được thiết kế cho kiểu người dùng này.
Đó là "developer thứ N+1": không ngủ, không đọc wiki, không hỏi trên Slack, và gọi API của bạn với tần suất gấp trăm lần con người. Năm 2026, thiết kế IDP mà bỏ qua AI agent là thiết kế cho quá khứ.
Platform team đang đông lên, nhưng đo lường vẫn là điểm chết
Gartner dự báo đến 2027, 80% tổ chức kỹ thuật lớn sẽ có platform team — tăng mạnh từ 45% năm 2024. Nhưng con số đáng nghĩ hơn: dưới 30% chứng minh được productivity gain đo được, và khoảng 30% team không đo gì hết.
Nghĩa là phần lớn platform team đang tồn tại bằng niềm tin. Portal đẹp, catalog đầy đủ, nhưng khi CFO hỏi "platform này tiết kiệm được gì" thì câu trả lời là im lặng.
AI agent vô tình lại là cơ hội sửa điểm chết này. Vì agent không dùng UI — nó gọi API. Mọi hành động của agent đều là một request có log, có tham số, có kết quả. Nếu bạn thiết kế đúng, mỗi lần agent tạo repo hay deploy preview là một data point về lead time, tỷ lệ lỗi, chi phí. Đo lường không còn là việc phải làm thêm, mà là sản phẩm phụ tự nhiên của kiến trúc.
Agent làm thay đổi yêu cầu thiết kế API như thế nào
Con người dùng platform kiểu tha thứ: gọi lỗi thì đọc message, thử lại, hoặc hỏi đồng nghiệp. Agent thì không. Nó retry theo logic của nó, và nếu API của bạn không idempotent, mỗi retry là một tài nguyên mới.
Ba yêu cầu cụ thể khi agent là consumer:
Idempotency là bắt buộc, không phải nice-to-have. Mọi action tạo tài nguyên phải nhận idempotency key. Agent gọi create-database hai lần với cùng key thì nhận về cùng một database, không phải hai.
Mô tả máy-đọc-được. Con người đọc wiki để biết env nhận giá trị gì. Agent cần schema: JSON Schema cho input, error code có cấu trúc thay vì string "Something went wrong". Một error trả về {"code": "QUOTA_EXCEEDED", "limit": 5, "current": 5} cho phép agent tự quyết định dừng hay xin cấp thêm; error trả về HTML 500 thì agent chỉ biết retry mù.
Quota và audit trail theo identity của agent. Hành động do agent khởi phát phải gắn được về: agent nào, thay mặt người nào, trong context công việc gì. Không có cái này, bạn không trả lời được câu hỏi "ai tạo cái database này" — và không dám mở quyền cho agent làm gì nghiêm túc.
# Một action trong service catalog, người và agent cùng gọi được
action: provision-database
input_schema:
type: object
required: [service, env, size]
properties:
size: { enum: [small, medium] } # large phải qua approval
constraints:
idempotency: required
quota: { per_agent: 3/day, per_team: 10/day }
cost_guardrail: { max_monthly_usd: 200, auto_tag: [team, requester, agent_id] }
audit:
on_behalf_of: required # agent phải khai identity người uỷ quyền
Golden path phiên bản agent: một action, hai loại người dùng
Golden path truyền thống là template + tài liệu + portal. Golden path 2026 là service catalog action: một endpoint duy nhất mà cả người (qua portal/CLI) lẫn agent (qua API/MCP) gọi được, với cùng guardrail.
Điểm mấu chốt: guardrail phải nằm trong action, không nằm trong UI. Nếu validate "không được tạo instance lớn ở staging" chỉ ở form portal, agent gọi thẳng API sẽ lách qua. FinOps guardrail — budget cap, auto-tagging, TTL cho tài nguyên tạm — phải chạy ngay lúc provisioning, ở tầng thấp nhất.
Đây cũng là lý do 73% platform team đã ship AI assistant nhưng không phải team nào cũng thấy giá trị: assistant chỉ hữu ích khi nó có action đáng tin để gọi. Chat bot trả lời "cách tạo database" là gadget. Action provision-database có quota và audit là platform.
Bài học từ MCP: hơn 10.000 server production dạy được gì
MCP giờ là chuẩn de facto để agent nói chuyện với tool — 97 triệu SDK download mỗi tháng tính đến 3/2026, hơn 10.000 public server chạy production. Với platform team, expose service catalog qua MCP server là con đường ngắn nhất để agent dùng được platform. Nhưng cộng đồng đã trả học phí cho hai bài học:
Stateful session xung đột với horizontal scaling. MCP session giữ state; nếu server của bạn chạy sau load balancer, request giữa chừng session rơi vào instance khác là hỏng. Hoặc dùng sticky session, hoặc đẩy state ra external store, hoặc thiết kế server stateless ngay từ đầu — chọn sớm, đổi sau rất đau.
Sandbox cho server có quyền hệ thống. MCP server được quyền đụng filesystem hay network là một attack surface. Pattern production 2026: chạy trong Docker với quyền tối thiểu, hoặc gVisor khi cần isolation mạnh hơn. Nguyên tắc giống hệt khi bạn cho contractor vào văn phòng: có badge, có khu vực được vào, có camera.
Bắt đầu nhỏ: một hành động tần suất cao, làm cho tử tế
Đừng viết bản thiết kế "IDP for agents" 40 trang. Chọn 1-2 hành động mà team bạn làm nhiều nhất — thường là tạo repo, cấp database, hoặc deploy preview environment — rồi chuẩn hoá theo checklist:
| Bước | Câu hỏi kiểm tra |
|---|---|
| Idempotent | Gọi 2 lần cùng key có ra 1 tài nguyên không? |
| Schema | Agent đọc input/error mà không cần wiki không? |
| Identity | Trace được agent nào, thay mặt ai không? |
| Guardrail | Budget cap, quota, TTL nằm trong action chưa? |
| Đo lường | Mỗi lần gọi có sinh metric lead time / cost không? |
Khi một action qua được checklist, expose nó qua MCP server và cho một team pilot dùng với agent thật. Số liệu từ pilot đó — lead time giảm bao nhiêu, bao nhiêu request do agent khởi phát, chi phí trên mỗi lần provisioning — chính là thứ đưa bạn vào nhóm dưới-30% chứng minh được giá trị.
Platform tốt xưa nay được định nghĩa là "con đường dễ nhất cũng là con đường đúng nhất". Định nghĩa đó không đổi. Chỉ có đối tượng đi trên con đường là đổi: người dùng khó tính nhất của platform bạn năm nay không phải junior dev mới vào, mà là một agent gọi API lúc 3 giờ sáng, không đọc tài liệu, và không bao giờ báo lỗi qua Slack. Thiết kế cho nó, và con người cũng được nhờ.
