Sell Agent Services With Headless Domains and AgentCash Router

Your agent can clean a messy product catalog. Another agent has a catalog that needs cleaning. Give it a clear offer, a way to pay, and an output its software can use.

To sell an agent service through this setup, connect a name at Headless Domains to your official service instructions, add AgentCash Router to the API that charges for the work, and test one purchase with a compatible buyer agent. If buyers need to register, your service’s auth.md explains that step.

Your agent keeps running on your chosen infrastructure. The public name leads buyers to the offer; the paid operation accepts their request and returns the work.

We recently shared how we bought a Headless Domain with AgentCash. Now consider the other side of the transaction: what could your named agent sell?

Start with a job another agent can hand over

Suppose you operate a catalog-cleanup agent. It accepts product records, puts their fields into a consistent format, and flags missing information for review.

Call it catalogclean.agent. This is a fictional example; we have not checked the name’s availability. The setup below is a design you could build using the linked tools.

The buying agent might be preparing a merchant’s catalog for a new sales channel. It already has the product data and permission to process it. Your service handles one part of that larger assignment.

Here is an offer it could evaluate:

Send up to 25 product records in the supported JSON format. Receive normalized records with the original product IDs preserved and a list of fields needing review. Missing product facts are flagged. Publishing changes to your store stays with you.

That is enough to begin a useful conversation. “AI-powered ecommerce assistance” would leave the buyer guessing.

Before taking orders, settle these details:

The price is just an example. Measure the cost of running the job, including model calls, hosting, retries, payment costs where applicable, and support. If someone has to review half the results, their time belongs in the calculation too.

Also decide what happens when a customer submits the same batch again. An awkward billing question is cheaper to answer before the first complaint.

Give the offer a Headless Domains identity

Use your existing Headless Domain, or choose a .agent name for the service you are launching. Connect it to this specific offer so a buyer can tell what to request.

For catalogclean.agent, the public record should identify the operator and lead to the service description, official API, sample output, terms, and support. Link the API’s OpenAPI description so compatible software can inspect its inputs and responses.

Use the supported profile and manifest controls. Fuller instructions can live in linked documentation. Our post-registration guide explains how to check those records and connect a useful destination.

A buyer configured to use the Headless Domains lookup infrastructure can resolve the name through an HTTPS API or command-line workflow and follow the published references. That path does not depend on browser-native resolution of .agent.

For this launch, check that a lookup leads to the catalog-cleanup instructions and sample result. After an API move, update those references and repeat the check. Buyers should be able to keep using the name they know.

Keep evidence behind the relationships you publish. The application using your records still needs to verify the relevant connection between the service, its operator, and its payment arrangements. Our x402 identity guide covers those connections; the Agent Identity Stack explains the wider architecture.

Add a paid route with AgentCash Router

The AgentCash client used in our domain purchase helps a buyer make requests and pay. AgentCash Router runs on the seller’s side.

Merit’s Router announcement describes a library for building APIs with x402 and MPP payment support. It also provides input schemas and discovery documents that compatible agents can use to understand the service.

For catalogclean.agent, the operator would host an API, configure its receiving wallet and supported payment method, and set a fixed price for the cleanup operation. The route’s handler calls the code that does the work.

When a request needs payment, the service returns an HTTP 402 challenge. A compatible buyer client can read the requirements and complete the paid request within its spending authority. The Router quickstart shows how to implement this and publish the discovery routes.

Your existing API host can stay in place. The Headless Domain points buyers toward that service and its instructions. The first launch can be one paid operation with a sample result and clear terms.

Use auth.md where buyers need access

A simple catalog-cleanup request may need only payment. The buyer submits a batch, receives the result, and leaves.

Now suppose you add saved jobs. Customers can return tomorrow to retrieve their results or inspect their history. Your service needs a way to recognize them and enforce which jobs they may access.

If that design involves registration and credentials, auth.md gives agents a readable starting point. WorkOS’s auth.md proposal describes a file hosted by the service, typically at an address such as https://service.example.com/auth.md, explaining its supported registration flows and what to do afterward.

For your selling agent, those instructions should match the access system you actually run. Explain how the buyer registers, whether a person must confirm anything, how the credential is used, and how access can be withdrawn. Link the guide from your service documentation so buyers can find it.

The file and the working registration endpoints belong together. Writing the instructions does not create the access system.

There are two separate uses here. HeadlessDomains.com’s authentication guide helps your agent obtain access to the naming platform. Your own service’s guide explains access to the catalog-cleanup business. A credential issued for one service does not automatically work at the other.

Follow each service’s live instructions. Our auth.md registration article covers the naming platform’s implementation separately.

Wallet authentication may be sufficient for some services. Choose the access design the job needs, then make the path clear to the buyer.

Walk one buyer through the purchase

Our catalog-cleanup example becomes useful when another agent can complete the whole exchange.

1. Find the seller. The buyer gets catalogclean.agent through a listing or referral and uses a supported Headless Domains lookup to inspect its public identity.
2. Read the offer. It follows the official service links, checks the input requirements, and examines the sample output and terms.
3. Complete any required access step. For an account-based service, it follows the seller’s auth.md, including any human confirmation. A payment-only route can skip registration.
4. Evaluate the payment request. The buyer’s tooling checks the price, asset, network, recipient, and authority to spend before completing the supported payment flow.
5. Receive and check the work. The seller returns the cleaned records and issues. The buyer checks that every submitted product ID is accounted for and retains the relevant purchase references privately.

For an illustrative 25-product order, suppose 22 records can be normalized and three lack a required measurement. The result accounts for all 25 IDs, returns the 22 usable records, and identifies what is missing from the other three. Under the example offer, that is one completed batch with documented exceptions. The seller should make that billing rule clear before payment.

The buying agent can now continue with the usable records and route the exceptions for review. Inventing dimensions to produce a tidy success response would make its next task worse.

Payment and delivery need separate confirmation. If the request times out, the buyer should follow your documented recovery route before paying again. Link that route from the service instructions. Our guides to payment and delivery evidence and uncertain requests explain the details.

The buying agent does not need its own Headless Domain to make this purchase. It needs compatible tools, appropriate access, and authorization for the transaction.

Try the service with a buyer that has never used it

Start a fresh agent session with the required lookup and payment tools. Give it your public name, a synthetic product batch, and a small authorized budget. Let it work from your published instructions.

Watch where it gets stuck. Perhaps it finds the offer but cannot locate the schema. Maybe signup succeeds, but the credential instructions are incomplete. Or the returned records have lost the IDs the buyer needs to match them to its originals.

Those are specific things you can fix before promoting the service.

For the sample order, check one batch charge, all 25 product IDs, and the three expected exceptions. If you provide saved jobs, also test that a different customer cannot retrieve them. Record which client and configuration completed the purchase so you can give future buyers useful setup instructions.

Then put the public name alongside your offer wherever you promote it. Publish a sample result and explain who the service helps. A directory listing can create an entrance; customers still need a reason to buy.

Put your first service behind the name

Choose the first batch another agent could buy from you. Publish a sample result, connect the paid operation, and give the offer a name at HeadlessDomains.com.

Already own a name? Connect this offer to it. Your first milestone is one buyer finding the service through that identity and receiving the work it paid for.