Domains your agent can buy — and keep healthy

Agent Domains gives your AI agent domains it can buy, point, and monitor — four-layer health checks and alerts included. It is the domain product of Clize — Clize is a CLI and MCP server that gives AI coding agents real-world actions: domains, email, deploys, payments, and media generation. Registration is the easy half and several APIs already do it well. The half that decides whether your site is up next Tuesday is what happens after the purchase: delegation, DNS, binding, certificates, and someone watching all four.

Registration an agent can drive

The agent searches names and prices in one call, across more than 500 TLDs — .com, .app, .dev, .io, .ai, .co and the rest of the long tail. Which registrar is used is Clize's problem, not yours: Cloudflare where it supports the TLD, Vercel for the rest, and the nameservers are moved back to Cloudflare afterwards so mail and deploys work on the same name. Run clize domain tlds for the live list.

Money has a hard gate in front of it. clize domain buy example.com with no --confirm returns a quote and registers nothing; only the confirmed form charges, a monthly spend cap sits behind that, and repeats are idempotent so a retrying agent cannot double-register. Auto-renew is on by default, because an expired domain is the most avoidable outage there is. Naming stays a human decision — the agent proposes, you pick.

What breaks after you buy

In June 2026 we lost four domains for about four days. Not the sites — the domains. Their nameserver delegation disappeared from the registry at the registrar's end, so the TLD stopped answering for them at all: NXDOMAIN, the DNS equivalent of the name never having existed. Nothing on our side had moved. The DNS zone still said active, the registrar's own API still said verified, every deploy in that week returned a green checkmark and a live URL. Nothing flagged it: the outage was found by hand, days in, by someone who went looking. By then search engines had already started treating the four sites as gone.

The lesson is narrow and it changed the product: every status field a provider hands you is a cached opinion; the only trustworthy signal is what public authoritative DNS says right now. Everything below exists because of that week.

Four layers, checked from the bottom up

A domain that "doesn't work" is four independent things that must all be true, and they fail in ways that look identical from a browser. clize domain check example.com reports each one separately, in the order you fix them:

• 1 · Registry delegation — does the TLD still hand out nameservers for this name? Probed from public DoH resolvers (dns.google, with cloudflare-dns as the second source), never from a provider's status field. NXDOMAIN here means the name is gone from the internet's point of view; nameservers pointing somewhere else mean mail and hosting will not work no matter what else is configured.
• 2 · The DNS zone — is there an active zone on those nameservers, holding the records? A zone can read active in a dashboard while the layer below it is dead; when that happens the check says so instead of believing the dashboard.
• 3 · The binding — is the hostname actually attached to something that serves it? DNS can resolve perfectly to an edge that has never heard of your domain.
• 4 · The content — is anything deployed there? A bound hostname with an empty origin is a 404 with good DNS.

Bare clize domain check runs the fast version across every domain you have and returns the unreachable ones. The full method, including the dig and DoH commands to run it by hand on any domain, is on domain health check: four layers, one command.

Deploys verify themselves

"Uploaded successfully" is not the same claim as "reachable". Every clize deploy to a custom domain finishes by probing the domain from public DNS; if the delegation looks wrong the response carries a warning alongside the success, so the one moment you are definitely paying attention is the moment you learn the name is broken.

Alerts that assign blame correctly

A sweep runs every 30 minutes against every managed domain. Two consecutive failing rounds — roughly 25 minutes — are required before anything is sent, so DNS jitter does not page you; recovery gets its own email. The address is whatever you set with clize account email.

The harder question is which outages are outages at all, and getting it wrong is how monitoring dies. We learned that the other way round too: two external domains that pointed their nameservers elsewhere and ran nothing on Clize generated one alert each per day for fifty days. That is not a fault, it is the owner's choice, and a hundred emails of noise is how a real alert gets ignored. So the rule is explicit:

• Registered through Clize → always alerted. The delegation and the renewal are our responsibility.
• External domain carrying a site or an inbox on Clize → alerted. Your things are running here; a broken domain is a real outage. This is exactly the shape of the June incident.
• External domain with nothing running on Clize → recorded, never emailed. Pointing the nameservers elsewhere is a decision, not a failure.

Silence has to be able to prove it is not a miss, so clize domain check tells you in plain words whether a given domain would alert. A persistent fault backs off rather than repeating forever — daily, then every three days, then weekly — because a reminder that stops being read is the same as no monitoring at all. To bring a domain into scope, run something on it; to take one out for good, clize domain remove unmanages it (leaving the registration, nameservers, and DNS untouched), and it refuses while a site or inbox is still live rather than silently switching off the alarm on something that is still running.

Point it at a site, an inbox, or both

A domain on its own does nothing. clize deploy ./site --domain example.com puts a site behind it with a certificate issued automatically; clize domain canonicalize settles www against the apex with a redirect at the edge; clize dns handles records for anything else you run; and the same name can carry a working mailbox your agent sends from and receives into. Bringing a domain you already own is clize domain import plus a nameserver change at your current registrar.

Part of Clize

The domain, the site on it, the address at it, and the payments through it are one account with one set of safety gates — money quoted and confirmed, outbound mail approved by a human, inbound mail treated as data. If email is what you came for, that product is Agent Inbox; for the shape of the whole platform, see Clize's real-world actions or the walkthrough of letting an agent deploy a site. Weighing registrar APIs instead? We wrote the honest comparison: programmatic domain registration, 5 options.

$ npm i -g @clize/clize
$ clize login
$ clize domain search yourname   # names + prices, no charge
$ clize domain check yourname.com # four layers, one command