How to Make a Product an AI Agent Can Operate — A Practical Checklist
The last two posts were about trade-offs and architecture. This one is hands-on — a concrete checklist for developers: if you believe the thing getting work done for people in the future is an AI agent, how should you build your product so an agent can not just "see" it, but actually "use" it.
We did exactly this on UD House. The three outward-facing pieces below — REST API, OpenAPI, llms.txt — plus the web admin are all live right now; the MCP server and the Pin entry point are still in private beta, noted where relevant.
Why build for agents
Start with the bet: in the future, a lot of things won't be done by a person tapping buttons by hand — they'll be run by an agent on your behalf. Yours, or someone else's.
If that comes true, a "human-only website" isn't enough. Your product has to also be an interface code can read. I don't think that's a nice-to-have; it becomes table stakes.
Concretely, three things.
Piece 1: An open REST API (the action layer)
At the bottom, turn your product's capabilities into a clean set of programmatically-callable actions — not something hidden behind frontend buttons.
UD House's /api/v1 is that layer: create a listing, generate a draft from a photo, change status, generate promo copy, pull leads — each one an endpoint, authenticated with an API key (Bearer udh_…).
The key principle: anything a frontend button can do, the API must be able to do too. If a feature only lives in the UI, an agent can't touch it. Separate "action" from "interface," and the action becomes usable by humans and agents.
Piece 2: A public OpenAPI spec (the machine-readable contract)
Having an API isn't enough — how does an agent know which endpoints exist and what parameters to send?
The answer is to publish an OpenAPI spec (we host ours at /api/v1/openapi.json). It's a machine-readable contract: every endpoint, method, parameter, and response shape, spelled out. Any agent or tool imports it and instantly "knows" how to use the whole API — you don't have to write pages of prose for it to read.
Piece 3: llms.txt (LLM self-onboarding)
OpenAPI is for tools that already know they want your API. But when an agent / crawler first lands on your site, how does it know who you are and what you can do?
That's what llms.txt is for — a plain-text file at your site root, written specifically for LLMs: what this platform is, what it can do, where the API lives, how to start. It's to AI agents what robots.txt is to search crawlers — a conventional entry point.
UD House's social.8338.hk/llms.txt does exactly this: an agent reads it and knows this is a real-estate platform, that it has an Agent API, and where the spec is.
Tying it together: one SKILL.md as the source
The API + OpenAPI + llms.txt are three outward-facing surfaces. Behind them you want a single source of truth, or the three drift apart and stop agreeing with each other.
We use one SKILL.md: it declares the product's entities and the actions it supports. The OpenAPI, the llms.txt, the human admin, and the agent-facing MCP all ideally grow from that one file — change it once, the surfaces stay in sync.
(Honest note: UD House's API, OpenAPI, llms.txt, and web admin are all live; the MCP server and the Pin entry point are still in private beta. But they feed on the same SKILL.md — that source already exists.)
A worked example: how an agent runs the whole thing itself
Put the above together and an agent's flow looks like this:
1. Read social.8338.hk/llms.txt → knows it's a realty platform + has an Agent API
2. Read /api/v1/openapi.json → knows how to call each endpoint
3. With one udh_ key:
POST /api/v1/listings/from-photo → upload a photo, AI returns extracted draft fields
POST /api/v1/listings → create a listing from the draft, get a share_url
POST /api/v1/listings/{id}/promo → generate multilingual promo copy
GET /api/v1/leads → pull the leads the AI concierge captured
No human taps a single button anywhere in there. An agent (a realtor's own, say) can be told "list this photo, write the copy, and check if anyone's interested," read the docs, and run it end to end.
Closing: agent-ready isn't "bolt on an API"
A closing principle: making a product agent-ready isn't bolting an API on afterward — it's treating "operable by an agent" as a first-class citizen from the design stage.
That means: action separated from interface, a public readable contract, an entry point (llms.txt) written for machines, and every surface sharing one source.
Humans come in through the UI, agents come in through the API — same path. That's what I mean by "both humans and AI can read it." Do it now, and when agents actually become common, you're already inside the door.
Originally published on Ultra Lab — we build AI products that run autonomously.
Try UltraProbe free — our AI security scanner checks your website for vulnerabilities in 30 seconds: ultralab.tw/probe
Top comments (1)
Practical checklist — the separation between action and interface is the right mental model. I've been thinking about the flip side: once an agent has API access, it needs to know which mode to be in. Agents tend to jump straight to execution even when asked to brainstorm or plan. Put together Brainstorm-Mode (mehmetcanfarsak on GitHub) that adds three modes — divergent, actionable, academic — via PreToolUse hooks so the agent stays in ideation instead of immediately calling tools. Complements infrastructure-level agent design well.