How to Make a Product an AI Agent Can Operate: A Practical Checklist

Table of Contents

1. Why build for agents
2. Piece 1: An open REST API (the action layer)
3. Piece 2: A public OpenAPI spec (the machine-readable contract)
4. Piece 3: llms.txt (LLM self-onboarding)
5. Tying it together: one SKILL.md as the source
6. A worked example: how an agent runs the whole thing itself
7. Closing: agent-ready isn't "bolt on an API"

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 a real-estate platform we built. As of publication on 2026-06-12, the three outward-facing pieces below (REST API, OpenAPI, llms.txt) plus the web admin were all live; the MCP server and the Pin entry point were 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.

The platform's /api/v1 is that layer: create a listing, generate a draft from a photo, change status, generate promo copy, pull leads. Each one is an endpoint, authenticated with an API key (Bearer <api_key>).

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. It's 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.

At the time of writing, the platform's llms.txt did exactly this: an agent reading it knew this was a real-estate platform, that it had an Agent API, and where the spec was. (Update: as of 2026-09-27 that domain has been retired; the example below uses a placeholder domain.)

#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: as of publication on 2026-06-12, the platform's API, OpenAPI, llms.txt, and web admin were all live; the MCP server and the Pin entry point were still in private beta. But they feed on the same SKILL.md, and 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 example-realty.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 API 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.

FAQ

How do you make a product an AI agent can operate?

Build three outward-facing pieces: an open REST API that turns your product's capabilities into programmatically callable actions; a public OpenAPI spec as the machine-readable contract; and an llms.txt, a plain-text file at your site root written for LLMs as the entry point. Behind all three, keep one SKILL.md as the single source of truth, or they drift apart and stop agreeing with each other.

What is llms.txt?

llms.txt is a plain-text file at your site root, written specifically for LLMs: what the platform is, what it can do, where the API lives, and how to start. It's to AI agents what robots.txt is to search crawlers: a conventional entry point.

If I already have a REST API, why publish an OpenAPI spec?

An API alone doesn't tell an agent which endpoints exist or what parameters to send. An OpenAPI spec is a machine-readable contract that spells out every endpoint, method, parameter, and response shape. Any agent or tool imports it and knows how to use the whole API, so you don't have to write pages of prose for it to read.

What does a SKILL.md do in an agent-ready product?

It's the single source of truth: 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, so you change it once and the surfaces stay in sync.

Is making a product agent-ready just a matter of adding an API?

No. It 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 (anything a frontend button can do, the API must be able to do too), a public readable contract, an entry point (llms.txt) written for machines, and every surface sharing one source.