Design for Agents First, Humans Second

There’s a habit in platform development that goes mostly unquestioned: build the UI first, then expose an API later — usually when someone asks for it.

I followed that habit for years. It made sense. Users are human. Humans need interfaces. Start there — idea → UX/UI design → implement features based on what was designed.

But something has quietly shifted.

The user isn’t always human anymore

When I started integrating AI agents into my workflow, I noticed a specific kind of friction that felt different from normal bugs or missing features. The friction showed up whenever an agent needed to do something with a platform: authenticate, find data, take action.

The problem wasn’t that the API didn’t exist. Most platforms have APIs. The problem was that those APIs were designed as afterthoughts — built to match what the UI did, not built to be consumed cleanly by code. Rate limits with no clear feedback. Errors written for developers to read (yay, obviously). Pagination that made no sense without a visual context.

An agent doesn’t care about beautiful UI. It needs structure. Predictability. Machine-readable responses. Anyone who has worked with agents will know what I mean: one agent has output_key="destination", and every downstream agent just needs to know that exact key to grab what it needs — clean, no ambiguity. And it will hammer your API at 3am without apology.

What “agent-first” actually means

It doesn’t mean ignoring humans. It means flipping the design order.

Instead of: human UI → API as afterthought

You build: structured agent interface → human UI on top of it

If the agent can navigate your platform cleanly — can authenticate, discover capabilities, perform actions, and handle errors gracefully — then building a human UI on top of that foundation is straightforward. You’re just adding frosting on a cake that’s already solid. Sounds nice, right?

The reverse is painful. I’ve tried it. I dug up an old UI-first project and tried to make it agent-compatible — retrofitting every assumption the human-first design baked in. That was a proper nightmare, especially the tangled mess of APIs.

MCP changed something

The Model Context Protocol — now an open standard backed by Anthropic, OpenAI, and Google — is the clearest signal yet that this isn’t theoretical. When three competing AI labs agree on an interface standard for how agents connect to tools, the industry is telling you something — the same way W3C once emerged with recommendations for HTML, CSS, ECMAScript, and HTML5, ultimately eliminating fragmentation in web design and enabling the internet era to thrive. That’s what MCP is doing now.

Google releasing a Workspace CLI “designed for humans and AI agents equally” isn’t marketing. It’s a product decision that reflects where usage is heading.

CLIs are coming back — not because developers suddenly love terminal UIs, but because structured, scriptable output is exactly what agents need. JSON over beauty. Predictability over polish.

The uncomfortable part

Most of the platforms I use daily — the ones I’ve wired together into my workflow — were not built with agents in mind. Which means every time an agent tries to use them, there’s friction. Manual steps. Copy-paste bridges: I design something in Draw.io, then I have to screenshot it, paste it into my AI, and let it analyze. Oh, if only it could just stand next to me and look at the design directly.

That’s work. Real, recurring work that agents could eliminate — if the platforms were designed just a little differently. What if my agent could go to the Backlog and read the tasks? I need it to summarize that wall of text. Nope — at minimum, I still have to Ctrl+C and Ctrl+V.

Three years from now, the users of most platforms will be a mix of humans and agents. Probably more agents than humans — it takes nine months to produce one human and many more years before they’re on the internet, while agents scale on demand. I can spin up ten agents in a day to run tasks; no nine-month multiplier required. In terms of raw API calls, humans will certainly lose. Honestly, designing only for humans is starting to look like a structural mistake in modern software. It might be time for a different mental model of how the internet operates now that agents are in the picture.

The question isn’t whether to support agents. It’s whether to design for them from the start — or spend years retrofitting a platform that was never meant to serve them, these new users with new standards.

Có một thói quen trong phát triển platform mà hiện nay hầu như ít ai thắc mắc về nó: ta build UI trước, expose API sau, và thường là sau khi ta nhận yêu cầu expose.

Tôi đã theo thói quen đó nhiều năm. Và thật sự nó có lý do của nó, người dùng là con người, họ cần giao diện, thứ mà họ có thể quan sát được…Vậy tất nhiên ta sẽ bắt đầu phát triển từ đó thôi, idea => design UX/UI => implement tính năng dựa theo những gì đã thiết kế.

Nhưng tôi nhận thấy có điều gì đó đã và đang âm thầm thay đổi.

Người dùng không phải lúc nào cũng là con người

(Ờmmmm người âm không dùng internet đâu nhỉ?)

Khi tôi bắt đầu tích hợp AI agent vào flow công việc thường ngày, có một loại friction mà tôi thường gặp — khác hoàn toàn với bug bình thường hay thiếu feature. Friction đó xuất hiện mỗi khi agent cần làm gì đó với một platform: xác thực, tìm dữ liệu, thực hiện hành động nào đó.

Vấn đề không phải là API thiếu. Hầu hết platform đều có API. Vấn đề là những API đó được thiết kế như phần thêm vào cho có — build để khớp với những gì UI đã hoặc đang làm, chứ không được thiết kế đủ clean để các Agent/LLM sử dụng, đúng hơn là chưa đủ clean. Rate limit không có feedback rõ ràng. Error message viết cho dev đọc (yay tất nhiên rồi). Pagination không có nghĩa lý gì nếu không có context trực quan.

Thực tế Agent không quan tâm đến UI đẹp. Nó cần cấu trúc, tính nhất quán, response đủ clean để chúng hiểu. Ai làm việc với Agent chắc sẽ hiểu: ví dụ một Agent sẽ có output_key="destination", các Agent liên quan chỉ cần biết đúng key này để lấy phần data cần thiết — rất clean. Và nó sẽ hammer API của bạn lúc 3 giờ sáng mà không cần xin phép.

”Agent-first” thực sự có nghĩa gì

Không có nghĩa là chúng ta, những developers/builders, sẽ bỏ qua đối tượng con người như là user. Mà là đảo thứ tự phát triển.

Thay vì: UI cho người dùng → API thêm vào sau (nếu cần)

Bạn build: agent interface có structure rõ ràng → UI cho người đặt lên trên, như lớp kem phủ của một chiếc bánh vậy

Nếu agent có thể điều hướng trên platform của bạn mượt mà — xác thực được, tìm thấy capabilities, thực hiện actions, xử lý lỗi gracefully — thì build UI cho người dùng phổ thông trên cái sàn đó là việc tương đối đơn giản, vì chúng ta sẽ chỉ đang thêm kem lên một cái đế bánh chắc chắn rồi, nghe chill quá nhỉ.

Nỗi đau bắt đầu khi ta làm ngược lại, đúng hơn là giữ flow như cũ. Vào một ngày đẹp trời, tôi đào lại một project cũ, UI-first, và cố biến nó thành một project support Agent — việc cố biến một platform UI-first thành một thứ compatible với agent nghĩa là phải “retrofit” từng assumption mà thiết kế human-first đã baked vào…Ahhh đúng là địa ngục, nhất là cái đống API rối như tơ vò.

MCP thay đổi cuộc chơi

Model Context Protocol — giờ là open standard được Anthropic, OpenAI và Google cùng hỗ trợ — là tín hiệu rõ ràng nhất cho thấy đây không còn là lý thuyết. Khi ba công ty AI cạnh tranh nhau cùng đồng ý trên một chuẩn interface cho cách agent kết nối với tools, đó là thông điệp của cả ngành, như cách W3C ra đời và đưa ra khuyến nghị về standard cho website, HTML 2.0, CSS 1, ECMAScript (JS), HTML5,…mục đích cuối cùng là xóa bỏ sự phân hóa trong thiết kế website, giúp thời đại internet phát triển, đó là những gì MCP đang làm.

Google ra một Workspace CLI “thiết kế đồng cấp cho cả người và AI agent” không phải marketing. Đó là quyết định sản phẩm phản ánh hướng usage đang đi.

CLI đang trở lại — không phải vì developer đột nhiên yêu thích terminal, mà vì output có cấu trúc, có thể script được là thứ agent cần, JSON luôn tốt hơn một cái UI bóng loáng, tính nhất quán là yếu tố hàng đầu.

Phần khó chịu

Hầu hết platform tôi dùng hàng ngày — những cái tôi đã trộn vào nhau thành workflow đang dùng — không được build cho Agent, nghĩa là mỗi khi agent cố dùng chúng, có friction. Manual chút nhé, copy-paste: tôi design cái gì đó trên Draw.io, sau đó tôi phải screenshot, parse vào cô AI yêu quý và để nó phân tích, ấy da nếu nó có thể đứng bên cạnh và nhìn vào cái design thần sầu này thì đỡ tốn công hơn rồi nhỉ.

Và đó là một step thực sự, lặp đi lặp lại — công việc mà agent có thể loại bỏ — nếu platform được thiết kế khác đi một chút. Ví dụ Agent của tôi lên Backlog để đọc task thì sao, tôi cần nó summary cái đống text chết tiệt đó, yay tất nhiên là không được rồi, ít nhất tôi phải Ctrl+C và Ctrl+V.

Ba năm nữa, người dùng của hầu hết platform sẽ là sự pha trộn giữa người dùng thật và các agent. Có lẽ nhiều agent hơn người nhỉ, ta mất 9 tháng để tạo ra 1 người và nhiều năm nữa để nó sử dụng internet, Agent thì scaling thoải mái, ngày tôi đẻ ra 10 Agent để làm task, có cần nhân lên với 9 tháng không?, tính theo số lượng API call thì người chắc chắn thua rồi. Thật sự mà nói việc chỉ quan tâm đến con người theo tôi đang là một thiếu sót lớn, đúng hơn là một sai lầm trong thiết kế hiện đại, đến lúc ta nên có một cái nhìn khác về cách Internet vận hành sau khi các Agent xuất hiện.

Câu hỏi không phải là có nên hỗ trợ agent hay không. Mà là có nên thiết kế cho chúng từ đầu — hay mất nhiều năm để retrofit một platform vốn không được tạo ra để phục vụ chúng, những user mới và có những tiêu chuẩn mới.