An AI agent was given a plain-English goal. It checked availability, selected a name, registered the domain, and paid for it. No human approved a cart. No human typed a card number. No human clicked anything.
The registration is real. It is visible in WHOIS.
That sentence is the entire point of this post, and it is worth being precise about why it took work to be able to write it.
Registrar APIs were not built for this
Domain registration runs on EPP, a protocol from an era when the thing on the other end was a person at a keyboard, or at most a batch job run by a human operator. Everything downstream of it inherited that assumption.
If you have tried to drive a mainstream registrar programmatically, you know the shape of the problem. The API exists, but it is a thin wrapper around a flow designed for a checkout page. Payment is a separate concern living somewhere the API cannot reach. Registration succeeds but the domain is parked behind an upsell interstitial. Errors come back as HTML. The interesting operations require a session that came from a browser.
None of this is malice. It is what happens when the API is an accessory to the website rather than the product. For a human buying one domain, it is invisible. For an agent, every one of those seams is a place the task stops.
The result is that "programmatic domain registration" has usually meant programmatic up to the point of spending money, and then a human. Which is not autonomy. It is a form with an API in front of it.
What agent-native actually requires
There is a lot of "AI-friendly" claiming in this space right now, and most of it means a REST API and a blog post. The gap between an API an agent can call and infrastructure an agent can actually complete a task against is larger than it looks. A few things it turns out you cannot skip.
Tools, not endpoints. An agent working through MCP needs operations described in a way a model can reason about: what this does, what it costs, what it cannot undo. A tool called register_domain with a clear contract is a different object from a POST route with the same effect. The description is part of the interface. That is why the AIvikings MCP server is intentionally a small set of domain operations instead of a giant wrapper around everything a registrar can do.
Authentication an agent can complete unattended. OAuth 2.1 with dynamic client registration matters here, because the alternative is a human going to a dashboard to mint a key before the agent can do anything. Bearer tokens are fine for a developer wiring things up. They are not fine as the only path, because they put a person back in the loop at setup time.
Idempotency on irreversible spend. This is the one that separates commerce tools from data tools. A read-only MCP server that gets retried twice returns the same answer. A registration tool that gets retried twice can register two domains and charge for both. Agents retry. Networks fail mid-call. The tool has to be safe under repetition or the failure mode is silent financial loss, which is the worst kind.
Failure that is legible to a model. An agent cannot recover from an error it cannot parse. "Domain unavailable" and "insufficient funds" and "TLD not supported for this account" require different next actions, and the difference has to survive the trip back to the model.
Cost visible before commitment. An agent deciding between my-project-internal-tooling.icu and something shorter should be able to see the price implication as part of the decision, not discover it afterward. The docs are where this kind of contract belongs: not hidden behind a checkout page, but visible to the system doing the work.
Where the interesting problem actually is
None of the above is the hard part. The hard part is that nobody has settled what it means for an agent to spend money responsibly.
Every design here is a tradeoff between autonomy and control, and the space has not converged. Confirmation-before-commit keeps the human in the loop but destroys the use case. If a person has to approve each registration, the agent is a very expensive form filler. Full autonomy inside a budget is the obvious answer, but budgets are a blunt instrument and do not encode intent. Spend caps stop runaway loops but do not stop a correctly functioning agent from making an expensive mistake once.
There is no standard here yet. There is not even agreement on where the boundary should sit, or whether it belongs in the protocol, the tool, or the agent framework. Anyone claiming otherwise is describing their own product rather than the state of the field.
What can be said is that the boundary has to be somewhere explicit, and that hiding it - letting an agent spend without the spend being a first-class, observable, bounded thing - is how this ends up with a bad story attached to it.
What is live
AIvikings is a domain registrar built for agents to operate directly.
Live today:
- A REST API for availability, registration, renewal, and domain management
- An MCP server exposing the same operations as tools, usable by any MCP-compatible agent
- OAuth so a ChatGPT user can connect it and register a domain conversationally
- Real registrations against real TLDs, with billing live
The design decision underneath all of it is that the registrar does one job. No hosting attached, no email upsell, no parking page. An agent asking for a domain gets a domain.
One deliberate pricing choice, because it only makes sense in this context: long domains are low-priced here. A name like internal-service-discovery-shim.icu is worthless to a human and fine for an agent, because machine-readable does not need to be memorable. Most registrars price as though every domain is going on a business card. For agent infrastructure that is the wrong assumption, and pricing it correctly is one of the few places where being agent-native shows up as something other than a protocol choice. The comparison page explains more of that difference.
The part that is not solved
The registration path works. The spend-governance question above does not have an answer yet, here or anywhere, and it is the thing that will determine whether autonomous agents get to hold real accounts with real money or stay permanently supervised.
If you are building agents that need to acquire infrastructure, the API and the MCP server are live and the sandbox is open. If you have a view on where the autonomy boundary should sit, that is the conversation worth having. Contact us.