Agent là đối tượng người dùng tiếp theo

Mình đang brainstorm mô hình “Công ty 1 người”, và có một câu hỏi cứ quay lại: nếu build platform từ đầu, mình sẽ thiết kế cho ai?

Câu trả lời mà mình cứ nghĩ tới không phải “người dùng” theo nghĩa truyền thống. Mà là agent.

Platform hiện tại không được build cho agent

Hầu hết platform đều build theo thứ tự: giao diện đẹp trước, API sau, tài liệu cho developer tự đọc. Agent, nếu có, là thứ được thêm vào sau cùng.

Cách này chạy tốt khi “người kết nối” là developer. Nhưng bây giờ người kết nối ngày càng là agent. Và agent đọc tài liệu khác con người hoàn toàn.

Con người đọc API docs kiểu: lướt qua overview, tìm endpoint cần dùng, đọc ví dụ, rồi thử. Nếu docs không rõ thì hỏi StackOverflow hoặc nhờ Claude giải thích (ờ). Agent thì cần một bản mô tả có cấu trúc, machine-readable, nói chính xác: đây là tool gì, nhận input gì, trả output gì, giới hạn ở đâu.

Thật ra, agent hiện tại đã có thể tự đọc docs, tự code integration, tự debug. Bạn paste link API docs vào là agent chạy được. Nhưng vấn đề là hiệu quả: agent phải parse HTML, đoán structure, retry khi docs mập mờ. Tốn token, tốn thời gian, tốn context window — cho một việc lẽ ra chỉ cần đọc một file contract là xong.

Các platform lớn đang thay đổi, và cửa mở cho agent không phải UI

MCP (Model Context Protocol) là ví dụ rõ nhất. Anthropic giới thiệu MCP như chuẩn mở để kết nối AI với hệ thống bên ngoài, và bây giờ OpenAI, Google DeepMind đều đã adopt. Cuối 2025, MCP được donate cho Linux Foundation, trở thành chuẩn chung của ngành.

Ý tưởng cốt lõi đơn giản: thay vì mỗi integration cần connector riêng, bạn expose tools, resources, và prompts qua một protocol chuẩn. Agent nào cũng cắm vào dùng được ngay.

Song song với đó, CLI đang comeback, nhưng lần này không phải cho developer hardcore mà cho agent. Agent không cần UI đẹp, agent cần structured input/output. CLI cho chính xác thứ đó, gọn, nhanh, JSON output, script được.

Tuần này Google vừa release Google Workspace CLI (gws), một tool dòng lệnh duy nhất cho toàn bộ Drive, Gmail, Calendar, Sheets, Docs. Tagline của nó nói thẳng: “built for humans and AI agents”. CLI này có MCP server built-in, output toàn bộ là structured JSON, ship kèm hơn 100 Agent Skills. Agent cắm vào là đọc mail, tạo event, tìm file được ngay, không cần qua giao diện web.

Microsoft đang đẩy mạnh Graph connectors cho Copilot. Slack, Notion đang build workflow-native automations. Xu hướng rõ ràng: các platform lớn đang mở cửa cho agent, và cửa đó là CLI hoặc MCP server, không phải UI.

Nhưng đây mới là điều mình thật sự muốn nói

Tất cả những trend ở trên, MCP, CLI, API contract, chỉ là hiện tượng bề mặt. Câu hỏi sâu hơn là: chúng ta đang thay đổi cách nghĩ về “người dùng” là ai.

Khi build platform, chúng ta luôn bắt đầu với câu hỏi “user là ai?”, rồi thiết kế mọi thứ xoay quanh người đó. UI, UX, onboarding, documentation. Agent, nếu có, chỉ là công cụ phía sau.

Mình nghĩ cách nhìn đó sắp lỗi thời.

Nhìn lại cách Google thiết kế Workspace CLI: agent không phải add-on. Agent là đối tượng người dùng được phục vụ ngang hàng với con người. CLI output JSON cho agent đọc, ship kèm Skills files cho agent hiểu context, có MCP server để agent kết nối trực tiếp. Con người vẫn dùng được, nhưng agent là first-class citizen.

Agent không phải công cụ hỗ trợ người dùng. Agent là người dùng.

Và có thể, trong tương lai không xa, agent là đối tượng người dùng chính.

Khi agent là user, mọi thứ phải thiết kế lại

Hệ quả của cách nhìn này sâu hơn mình tưởng ban đầu.

Nếu agent là user, bạn cần agent onboarding: agent cắm vào thì hiểu được gì ngay? Có contract rõ ràng không? Có skill files hướng dẫn không? Hay agent phải tự mò như developer đọc docs 200 trang?

Bạn cần agent permissions: agent được làm gì, không được làm gì? Ai approve khi agent muốn thực hiện hành động nhạy cảm? Permission model cho agent khác cho người.

Và bạn cần agent experience, tương tự UX nhưng cho agent. Output có dễ parse không? Error message có đủ rõ để agent tự retry đúng cách không? Rate limit có hợp lý không?

Nghe giống user research, nhưng đối tượng là machine.

AHI stack: Agent → Human → Inter-agent

Mình tạm gọi kiến trúc này là AHI stack (Agent, Human, Inter-agent). Ba lớp, build theo thứ tự:

Lớp 1: Agent interface. Build trước tiên. Mọi tính năng đều được expose qua MCP server hoặc API contract tối ưu cho agent. Tài liệu viết cho agent đọc: structured, typed, có constraints rõ ràng. Agent cắm vào là dùng được, không cần người setup giữa.

Lớp 2: Human interface. Giao diện cho người dùng build sau, và nó consume chính agent interface ở lớp 1. Dashboard, form, button, tất cả đều là thin wrapper gọi xuống cùng một lớp mà agent đang dùng.

Lớp 3: Inter-agent interface. Khi platform scale, agent cần giao tiếp với nhau. Agent A gọi agent B, chia sẻ context, truyền kết quả. Protocol chuẩn giúp các agent interop mà không cần custom integration.

Kiến trúc này có vài hệ quả thú vị.

Mọi tính năng đều “automatable by default”. Nếu agent không thể thao tác, tính năng đó chưa hoàn chỉnh.

Human UI trở thành một client trong số nhiều clients. Người dùng có thể interact qua web app, nhưng cũng có thể giao toàn bộ cho agent. Hoặc hybrid, agent chạy tự động, người duyệt ở decision points.

Documentation chỉ viết một lần cho agent, rồi generate docs cho người từ đó. Không còn chuyện docs tách rời, out of sync.

Uncomfortable truth cho solopreneur

Nếu bạn đang chạy một business một mình, mình muốn nói thẳng một điều.

Mỗi lần bạn phải mở 3 tab để copy data từ tool này sang tool kia, mỗi lần bạn tự tay export CSV rồi import vào chỗ khác, mỗi lần bạn dành 2 tiếng để “kết nối” hai platform mà lẽ ra chúng nên tự nói chuyện với nhau, bạn đang làm công việc mà agent có thể làm.

Nhưng agent không làm được. Không phải vì agent kém, mà vì platform bạn đang dùng không coi agent là user.

Bạn không thiếu thời gian. Bạn thiếu platform được thiết kế đúng.

Hãy hình dung: bạn dùng platform quản lý project, một tool email marketing, một hệ thống invoice. Nếu cả ba đều có agent interface (MCP server, structured API), agent của bạn có thể nhận task mới từ project tool, tự draft email campaign, rồi tạo invoice khi campaign xong. Bạn chỉ cần review ở những decision points quan trọng.

Đó là orchestration. Và nó chỉ hoạt động khi platform coi agent là user ngay từ đầu, không phải afterthought.

Cái khó không phải tech, mà là tư duy thiết kế

Tech đã sẵn sàng: MCP có SDK cho Python, TypeScript, C#, Java. Cloudflare hỗ trợ deploy MCP server. Google vừa ship CLI với MCP built-in cho toàn bộ Workspace. Tooling đầy đủ.

Cái khó là đảo ngược thói quen.

Hầu hết founder khi build platform đều nghĩ UI trước: “giao diện trông như thế nào, người dùng click ở đâu, flow ra sao”. AHI stack bắt buộc bạn nghĩ ngược: agent là user, agent cần gì để hoàn thành task, contract trông như thế nào, input/output typed ra sao.

Bạn không thêm agent support vào platform. Bạn build platform cho agent, rồi thêm human interface lên trên.

Gartner dự đoán 40% enterprise apps sẽ embed AI agent vào cuối 2026. Các startup “agent-native” đang build sản phẩm mà agent là giao diện chính, không phải phụ. Kiến trúc agent-first đang chuyển từ pilot sang production.

Câu hỏi mình vẫn đang nghĩ

Mình chưa build xong gì. Đây vẫn là giai đoạn suy nghĩ và thử nghiệm với các tool nội bộ.

Phần rõ nhất: khoảng cách giữa “có API” và “agent dùng được ngay” còn lớn. Nhiều platform có API nhưng docs viết cho người, không có MCP server, không có typed contract đủ rõ cho agent tự suy luận. Khoảng cách đó là cơ hội.

Brainstorm thì dễ (yeah). Phần khó là thiết kế đúng lớp agent interface đầu tiên, vừa đủ flexible cho nhiều use case, vừa đủ constrained để agent không đi lung tung.

Nhưng câu hỏi mình thấy đáng suy nghĩ nhất, và cũng là câu hỏi mình muốn để lại:

Nếu 3 năm nữa, phần lớn interaction với platform của bạn đến từ agent chứ không phải con người, thì hôm nay bạn đang build cho đúng user chưa?

Bài này nằm trong series “Công ty 1 người”, nơi mình chia sẻ hành trình build mô hình solopreneur trước mặt cộng đồng. Toàn bộ quy trình chi tiết, template, và behind-the-scenes thì mình ưu tiên cho thành viên cộng đồng Tony’s Friends trước.