A unit converter only humans can open is half a tool.
The bet underneath this chapter is simple to state and uncomfortable to commit to. Over the next few years, a meaningful share of tool use online will happen inside agent loops — Claude, Cursor, ChatGPT, and the workflow systems wrapping them. The browser will keep its share of usage; the agent loops will eat the rest of the growth. Tools that aren't reachable from agents stop existing for that audience. Not "harder to find" — actually gone. The agent never sees them, never tries them, never recommends them.
The obvious response was to add an API later. Ship the website now, add agent access when the demand is louder. I almost did. The reason I didn't is the same reason an analog camera company couldn't bolt digital on in 1998 — the new audience isn't a feature, it's a posture. Microapp wants to be an AI-native company, not a website that's also reachable by API.
If an agent can't call it, it isn't done.
Every Microapp the company ships from here on satisfies the agent surface and the human surface on the same day, from the same engine. The website is the human interface. The API is the agent interface. Both are first-class — and both come from the same function. There is no "primary product" with an "API on the side"; there are two surfaces of the same product.
The transferable why: the audience you intend to serve later is the audience you don't actually serve. The companies that hit a new audience well are the ones who hit it from day one — with the architecture, the posture, the brand all wired in. Layered-on adapters drift, get neglected, and eventually become the part of the system nobody updates. Pick the two audiences you mean and serve both as first-class from the start.
Locked 2026-05-10 · AI-native · agent-callable is the agent-side definition of done
The second decision was a brand call disguised as an infrastructure call.
The shape of the agent surface was a domain decision: microapp.io/mcp, microapp.io/api, or api.microapp.io? Every infrastructure intuition I'd absorbed said subdomain. APIs go on subdomains. Big Software puts APIs on subdomains. The Stripe API is on api.stripe.com, the Twilio API is on api.twilio.com, the literature is unambiguous.
The brand instinct went the other way. A subdomain reads as "separate product." A path reads as "Microapp has one home; agents are welcome here." The first framing positions the agent surface as a side project that might one day be wound down; the second framing positions it as the same product served through a different room of the house. The brand we're building is the second one. The infrastructure has to read that way too.
Path, not subdomain. Same home for agents and humans.
microapp.io/mcp hosts the MCP endpoint. microapp.io/api/v1/<tool> hosts the REST endpoints. microapp.io/openapi.json hosts the spec. The same TLS certificate covers all of them. The same brand chrome wraps every error page. An agent developer browsing the install instructions and a member reading the homepage are on the same site, by URL, by design. The subdomain is reserved for the day the API becomes its own line of business — which, given the model, it won't.
The transferable why: infrastructure is a brand choice you make at the URL level before anyone reads a marketing page. The room where you put the API is the room you've told the world the API lives in. Reserve the subdomain for the day the API is genuinely a separate product. Until then, the path keeps the brand intact and the agent audience welcome.
Locked 2026-05-10 · agent surface lives at microapp.io/mcp · path, not subdomain
The third decision was where to bet first.
The GPT Store had the larger audience the day this decision came up — many more users on ChatGPT than on Claude and Cursor combined. The obvious move was to ship a Custom GPT first, capture the reach, retrofit MCP later. The case for the GPT Store was straightforward and well-defended.
The case against it took longer to articulate. MCP is the open protocol. Every new agent client that adopts MCP — Claude, Cursor, Continue, Claude Code, Zed, the dozen platforms that don't exist yet but will adopt MCP because the alternative is integrating with each platform's bespoke tool format — picks up the entire catalogue from a single URL. The GPT Store is a storefront, not a protocol. Building for the storefront locks the work to one runtime; building for the protocol generalizes.
MCP first. The protocol, not the platform.
The pattern repeats from the web's history. HTTP, not AOL. SMTP, not Lotus Notes. HTML, not WebTV. Every time a protocol and a platform competed for the same use case, the protocol eventually won the long game. The platform won the year. MCP is the agent-tool equivalent: it's becoming the standard the way HTTP became the web's standard, and betting on the platform that has reach today is betting against the protocol that will have reach in five years.
The GPT version is a downstream of MCP, not a separate effort. Once the MCP server exists, wrapping the OpenAPI spec into a Custom GPT is almost free. The reverse order — starting with the GPT Store and retrofitting MCP — duplicates most of the integration work.
The transferable why: when a protocol and a platform compete for the same use case, bet on the protocol for the long horizon and the platform for the short one — but build the protocol first. Protocols compound over time as new clients adopt them. Platforms decline as audiences move and the runtime ages. The work you do for the protocol carries forward across every runtime that adopts it; the work you do for one platform stays trapped inside it.
Locked 2026-05-10 · MCP first · GPT downstream of OpenAPI
The fourth decision was about the perimeter. Every public free endpoint attracts noise; the question was how big to build the defense.
The temptation was a fortress. WAF rules. Bot detection. Behavioral analysis. A queue for suspicious traffic. A dashboard with graphs. Probably a half-time engineer maintaining the rules. The fortress is the right answer the day there's a real adversary on the perimeter. It's the wrong answer when the threat is ordinary internet noise — scrapers, misbehaving crawlers, the occasional curious researcher.
The rule I held the design to was that the whole perimeter had to ship in one day. Anything more elaborate isn't worth the engineering time until there's a target on us. Ordinary hosting infrastructure handles the bots and IP-based rate limits. The engines themselves enforce absolute caps no caller can exceed: a maximum input size, a maximum compute time per call, a cap on concurrent calls per IP. The status fields in every response — calls remaining, refill time, attribution — let well-behaved agents pace themselves. Misbehaved ones get throttled until they pay attention.
Perimeter, not fortress. The job is keeping ordinary noise out, not defeating an adversary.
The single small trick worth mentioning is a fake tool listed in the catalogue. It does nothing. Its name lives only inside that catalogue — never in this book, never in marketing, never anywhere a real user would see it. Any caller that invokes the fake tool is, by construction, a scraper that pulled the catalogue and called everything in it. Those callers get banned for a day. Humans and well-behaved agents never touch the tool.
The transferable why: every dollar on a defense only matters if there's a matching threat. Most companies overbuild perimeters in anticipation of attackers that never arrive — and the perimeter itself becomes maintenance overhead, complexity, and a place where bugs hide. Build the perimeter for the noise you can already see. The day a real adversary arrives, the budget conversation changes and the defense grows in step. Until then, keep the perimeter cheap enough that it isn't a fixed cost worth complaining about.
Locked 2026-05-10 · perimeter ships in a day · honey-tool in the catalogue
The last decision is the one that keeps the model consistent across surfaces. Free for anyone, more for Members.
The agent surface could have been Members-only. The case was straightforward: agent calls cost real compute, the website already has ads to fund non-member access, the agents don't see ads. A members-only API would have been defensible. It also would have broken the model that ran the rest of the brand. The Membership Covenant says anyone can use Microapp; Members get a sharper version. If the API gates non-members entirely, the Covenant has a hole.
The version that survives the model is the mirrored one. Anyone can call any engine, anonymously, no signup, no key. The rate limit is generous enough for casual use, tight enough that one misbehaving agent can't ruin the surface for everyone. Members get a higher rate limit, the option to drop attribution from responses, and inherits the same Membership that funds clean pages and AI at near-cost on the website.
Free for anyone. More for Members. The same promise, broader reach.
The cost to run the free tier is small. The volume that would push it into real money would already be telling us something interesting about demand — and at that point, the Membership funnel is already in place to capture the heavy users. Until then, the free tier is the marketing budget. Every anonymous agent call that succeeds is a possible Member three months later.
The transferable why: brand promises have to hold across every surface they touch. A model that promises open access and gates the new surface is a model that's quietly walking back its promise. Mirror the model across surfaces — even when the new surface has different cost dynamics — and trust that the Membership funnel captures the customers worth capturing. The brand stays whole; the funnel does its own work.
Locked 2026-05-10 · anonymous-allowed agent surface · Members get the sharper version
That's the agent posture. AI-native by design, served from the same domain as the humans, on the protocol that will outlast the platforms, behind a perimeter that ships in a day. Tools that aren't agent-callable stop existing for the agent audience — and Microapp doesn't intend to stop existing.