Designing APIs for Agents
2026-07-16 · 5 min read · Janaina Maia
There is a growing gap between what AI models can do and what interfaces let them do. This week made that gap visible from every direction.
Freestyle.sh published a sharp opinion piece arguing that APIs designed for humans break when agents consume them. Pagination, rate limits, authentication flows, and error messages all assume a human reading a screen. When an agent hits a 429 rate limit, it does not slow down and read the docs. It retries. When it encounters a multi-step OAuth flow, it does not open a browser tab. It stalls. The piece makes a compelling case that the agentic era needs a new kind of API contract — one designed for machines that act autonomously, not humans who click.
Thinking Machines AI, a company from the Philippines, released Inkling, a 10-billion parameter open-weights reasoning model with a built-in playground for voice, vision, and code. It is the first open-weights model from Southeast Asia that competes with global frontier releases on reasoning benchmarks. The model is good. The interfaces around it — the playground, the docs, the integration paths — are still built for human developers who want to evaluate it manually. The agents that could use it will need something different.
The EU's Intellectual Property Office rejected OpenAI's trademark application for "OpenAI" in Europe, ruling that the term is purely descriptive — "open" means freely accessible, "AI" means artificial intelligence, and combining them describes a category, not a brand. Whether you find this absurd or obvious, the ruling is a reminder: the language we use to describe AI products shapes who can participate in building them. If "open AI" cannot be a trademark, then the space for naming, branding, and differentiating AI products is narrower than most founders assume.
And Coasty launched a computer-use agent API that bypasses traditional API contracts entirely. Instead of calling your API endpoints, Coasty's agent opens a browser, navigates to your website, and interacts with your UI the way a human would — clicking buttons, filling forms, reading screens. It is the logical endpoint of the trend: if APIs are not designed for agents, agents will just use the interface designed for humans.
Four stories. One pattern: the agentic era doesn't just need better models. It needs better contracts between machines.
Why human-designed APIs break for agents
Most APIs in production today were designed with a specific consumer in mind: a human developer, sitting at a laptop, reading documentation, testing endpoints in Postman, and handling errors by Googling the status code. The assumptions baked into these APIs are invisible until an agent hits them.
Pagination is the simplest example. A human developer sees "page 1 of 47" and either fetches all pages or refines the query. An agent sees "page 1 of 47" and either makes 47 sequential requests (slow, expensive, and likely to hit rate limits) or gives up after page 3 (incomplete data). Neither outcome is good.
Authentication is worse. OAuth flows assume a human will authorize the app in a browser. An agent running in a server does not have a browser. It has a token. When that token expires at 2 AM, the agent does not get a push notification asking it to re-authorize. It fails silently, and whatever workflow it was executing stops.
Error messages are the quietest problem. APIs return human-readable errors: "You have exceeded your rate limit. Please try again in 60 seconds." A human reads this and waits. An agent reads this and retries immediately, or parses it incorrectly, or treats it as a fatal error and aborts. The API is speaking English to something that needs a machine-readable contract.
The Freestyle piece argues for a set of design principles for agent-ready APIs: machine-readable error schemas, streaming responses instead of pagination, idempotency tokens so agents can retry safely, and authentication that works without a human in the loop. These are not exotic requirements. They are the same principles that make APIs resilient for human developers — applied to a consumer that never sleeps, never Googles, and never asks for help.
Inkling and the democratisation gap
Inkling is significant not because it is the best model in the world — it is not — but because of where it comes from. Thinking Machines AI is based in Manila. The Philippines does not have the AI infrastructure, investment, or talent pipeline of San Francisco or London. Inkling's existence proves that the capability to build competitive models is spreading faster than the infrastructure to deploy them responsibly.
The open-weights release is important. It means anyone can run the model locally, modify it, fine-tune it, and integrate it without depending on a proprietary API. But "anyone can run it" and "any agent can use it" are different statements. The playground, the documentation, and the integration paths are all designed for human developers evaluating the model. The next wave of consumers — agents that will discover, evaluate, and integrate models autonomously — need machine-readable metadata, capability descriptors, and contract schemas that are not yet part of any model release.
This is the democratisation gap: the models are spreading, but the interfaces that would let agents actually use them are not keeping up.
OpenAI's trademark and the naming problem
The EU's rejection of OpenAI's trademark application is, on the surface, a legal story. The EUIPO ruled that "open" is understood as "freely accessible" and "AI" as "artificial intelligence," making "OpenAI" a generic term that describes a category of products rather than identifying a specific commercial source.
For product designers, this is more than a legal curiosity. It is a reminder that the language of AI products is still being settled. If "open AI" cannot be trademarked because it describes a category, then the competitive landscape for AI products includes everyone who describes their product as "open AI." The naming space is wider than incumbents want it to be, and the trademark system is not going to protect a generic descriptor.
More broadly, the ruling highlights something the Freestyle piece gestures at: the way we describe and categorise AI products is still tied to human vocabulary. "Open" is a human concept. "AI" is a human category. When an agent needs to decide which model to call, it does not read your marketing page and think "ah yes, open AI." It reads your API schema, your capability descriptors, and your pricing endpoint. The vocabulary of agents is not English. It is JSON.
Coasty's shortcut and the interface question
Coasty's approach — use a browser instead of an API — is both a practical solution and a design indictment. If your API is not designed for agents, agents will just use your website. They will click buttons, fill forms, and scrape screens. This works, sometimes, in the same way that driving a car by remote control works: it is possible, but it is fragile, slow, and error-prone.
Computer-use agents like Coasty are a symptom of the problem the Freestyle piece diagnoses. When APIs are not designed for agents, agents bypass the API and interact with the human interface. This creates a whole new class of problems: the agent sees different content depending on screen resolution, it breaks when the UI changes, it fails when a CAPTCHA appears, and it has no way to signal intent or handle errors gracefully.
The product implication is clear: either design your API for the agents that will use it, or accept that agents will use your website instead — and all the fragility that comes with it.
Why this matters for product design
- APIs are product surfaces, not just technical contracts. An API endpoint is a product interface. The same design thinking that goes into a button, a form, or a notification should go into your rate limit response, your authentication flow, and your error schema. If you are designing for agents, every response needs to be machine-readable, every action needs to be idempotent, and every failure needs a clear, structured path to recovery.
- Agents are users too. The Freestyle piece makes this point explicitly: agents are not edge cases. They are a growing class of users with distinct needs. They need structured error responses, not HTML pages. They need streaming data, not paginated lists. They need tokens that auto-refresh, not browser redirects. Designing for agents is not a technical afterthought. It is a product decision that determines whether your product works in the next era of computing.
- The naming layer is part of the interface. The OpenAI trademark ruling is a reminder that the language we use to describe AI products is not just marketing. It is part of the interface. When agents need to discover, compare, and select between models, they will not rely on brand names or marketing copy. They will rely on structured metadata: capability schemas, pricing endpoints, and contract descriptors. The companies that build this layer now will own the discovery surface for the agentic era.
- Computer-use is a fallback, not a strategy. Coasty's browser-based agent API is useful because most APIs are not designed for agents. But clicking buttons on a website is not a sustainable integration strategy. It breaks when the UI changes, it is slow, and it has no error handling. If you are building a product that agents will interact with, build the API they need — do not force them to impersonate a human clicking through your website.
My take
The agentic era is not coming. It is here. Agents are already calling APIs, browsing websites, filling forms, and retrying failed requests at 3 AM when no human is watching. Most of the interfaces they interact with were not designed for them.
This is not a technical problem. It is a product design problem. The same thinking that goes into making a human interface intuitive, resilient, and respectful needs to go into making a machine interface structured, recoverable, and explicit. Machine-readable error schemas instead of HTML error pages. Streaming endpoints instead of paginated lists. Token auth that auto-refreshes instead of OAuth flows that require a browser.
The companies that figure this out first will not just have better APIs. They will have better products — because agents that can use your product efficiently will choose it over a competitor whose API makes them guess, retry, and fail.
Design for the machines that will use your product, not just the humans who will evaluate it. The agents are already here. The question is whether your interfaces are ready for them.