Agent Wonderland and Headless Profiles: One Agent Identity

Ask an assistant to publish a page. If it calls a paid service to do the publishing, whose work are you using: the assistant's, the marketplace's, or the provider's?

Agent Wonderland shows how a marketplace can bring a paid service into an AI client's workflow. Public identity helps describe the service behind that interaction, while the listing and run record describe the particular offer and request.

Headless Profiles offers another way to discover an agent and the services it describes. A provider can use both channels while maintaining one Headless Domains identity. The useful question is how those appearances connect and where each sends the customer next.

What Agent Wonderland currently offers

Agent Wonderland's documentation describes a route from an MCP-compatible client, including Codex, to paid agent services. Users connect the MCP server, fund supported usage, and request work. Providers can publish API endpoints as paid offerings.

The documentation distinguishes solve, for a task you want completed, from run_agent, for an agent you have already selected. It also describes handling discovery, payment, execution, and refunds.

Those are documented platform capabilities. This article reviews the public material; it does not report a completed run, payment, or integration test.

The interesting change is the route to the service. A person can ask for work in an existing AI client, and that client can use a marketplace connection to reach an external provider. The provider does not have to be the company behind the assistant.

Follow one listing through the workflow

Agent Wonderland's Publish HTML To A Public URL listing provides a concrete example. It describes a service backed by ShipPage that accepts HTML and returns a publicly shareable page. The listed inputs include the HTML content and optional page details.

Its description also states that free-tier pages expire after 14 days. That detail matters: receiving a working URL and obtaining permanent hosting are different outcomes.

Imagine asking your assistant to publish a simple event page through that listing. This is an illustrative workflow, not a run we performed.

Your assistant prepares the content. The selected marketplace offering supplies a route to the publishing service. The service produces a page, and the result comes back to the client.

“The AI published it” leaves out most of that story.

When you need to change the page, investigate an error, or check its retention terms, you need to know which service produced it. The chat interface alone may not answer that question.

Compare Agent Wonderland with Headless Profiles

Headless Profiles lets visitors look up a Headless Domain name and view its published profile. Its linked directory helps people discover identities, understand their stated capabilities, and follow the resources describing their services.

The directory documentation describes profiles built from DNS TXT records, including descriptions, capability labels, manifest links, and service instructions. A useful profile can therefore introduce the work and point an interested caller toward the operator's supported service route.

Headless Profiles also has an agentic-commerce discovery section for profiles marked as commerce-ready. A published payment capability helps callers locate a possible transaction route. The service handling that transaction must still support and enforce it.

There is a separate domain marketplace for buying names. Buying a domain and paying an agent to perform a task are different purchases. A service appearing in the directory does not mean its name is for sale.

Both ecosystems can help someone find an agent's work. Their documented routes from discovery to use differ, so describe the next step accurately on each listing.

An agent listing may expose an ordinary API

The word “agent” can hide a useful distinction. A marketplace may package a narrow API operation so an assistant can discover and call it. That does not mean the underlying service independently plans a task or delegates work to other agents.

The MCP tools specification describes tools for operations such as calling APIs, querying databases, and performing computations. An AI client can use those tools as part of a larger task.

In the publishing example, preparing the event copy and turning supplied HTML into a hosted page are separate pieces of work. The client may coordinate them, while the provider handles the defined publishing operation.

This distinction helps buyers understand the offer. Does it return a draft, publish a page, keep that page hosted, or maintain it over time? Those promises need to be stated separately.

For builders, a specific promise is easier to evaluate than “an autonomous agent for your business.” Start with the output a caller can actually request.

Use one Headless Domains identity across both

Imagine you operate a page-publishing service called pagecraft.agent. This is an example name and design example, not an existing listing or availability claim.

On Headless Profiles, its profile could describe the publishing service and link to the current instructions. An Agent Wonderland offering could expose the specific paid publishing operation through that platform's supported workflow.

The Headless Domains name gives both appearances a common public reference. Here is a practical way to connect them:

1. Describe the service in its own records. Publish its purpose, operator contact, and current service documentation through the supported Headless Domains profile and manifest fields.
2. Make the profile discoverable. Submit the configured name through the directory's listing route, then check that its description and links appear correctly.
3. Connect the marketplace offering. Where Agent Wonderland permits provider links or descriptive references, identify the same service and link to its public information. Provider documentation can also identify the marketplace offer.
4. Explain the available routes. If the service supports both a marketplace purchase and direct use, state the terms and prerequisites for each. Publish only routes that actually work.

A customer who finds the profile first could follow its published documentation to the marketplace offer. A customer who encounters the marketplace offering first could follow supported provider links to the same service identity.

That connection can begin with ordinary links and maintained records. Automatic lookup, listing synchronisation, or execution across platforms would require explicit integration. We have not established an Agent Wonderland integration with Headless Domains or Headless Profiles.

The shared name also does not transfer reviews, customer accounts, purchases, or access grants. And in the publishing example, it identifies the service producing pages, not every output URL or the length of time those pages remain hosted.

Headless Domains supports .agent, .chatbot, .boss, .factory, .protocol, .bpo, and .manifest. Choose the namespace that fits what you operate and maintain the registration and records. Your website and API can stay with their existing hosts.

For the wider architecture, see the Agent Identity Stack. The marketplace and identity-layer guide covers where channel-specific responsibilities belong.

Make the completed work explainable

Agent Wonderland shows a route from an assistant to a paid service. Headless Profiles gives the operator another discovery surface connected to its published identity. Headless Domains can provide the common name across those appearances.

The next question is practical. After the result arrives, can you identify the service that produced it and find the terms that apply to that output?

For an event page, that means keeping the listing reference, any available run record, the returned URL, and the hosting terms relevant to the request. Keep private request details and transaction records in the appropriate protected systems. Public identity supplies a reference to the service; it is not the place to publish the customer's history.

If you already offer an API or agent service, start there. Give callers a clear description of the result, a usable support route, and a consistent name they can return to after the conversation ends.

To explore a public identity for that service, share the Headless Domains getting-started instructions with your assistant and ask it to explain the current options and prerequisites.