Product designers own the interaction layer, the screens, flows and behaviours people use directly. But a new kind of user now reaches our products without ever seeing a screen: agents. They act on someone's behalf, and they need what any user needs: clarity, consistency and responses they can rely on.
Agents reach products through APIs. Every form submission and every loaded list in our interfaces is already a request to an endpoint underneath. For a person, the UI is the product. For an agent, the API is.
That makes APIs the invisible UI. We used to treat them as engineering territory, hidden plumbing designers rarely touched. That boundary no longer holds. If the API is how an agent experiences your product, then its naming, structure and error states are design decisions, and they deserve the same care as anything on screen.
I think of this as an accessibility problem. Accessibility has always been about making products work for people who experience them differently, and agents are another version of that. They can't infer meaning from layout or recover from ambiguity the way a person can. A product that is legible to them is one whose capabilities are clearly exposed.
So the questions change. How would a system start this task? What does it need to know? What does a clear, reliable response look like, and what happens when something goes wrong?
If we care about the people using our products, we have to care about the agents acting for them. Bringing the same empathy to APIs that we bring to interfaces is how design reaches beyond the screen.