Helping autonomous agents understand what they can buy
As software becomes capable of discovering, comparing and invoking paid services, those services need to be understandable to machines as well as people.
Atinamos proposes the term “Machine Contract Optimisation (MCO)” for the practice of structuring a machine-buyable service’s identity, capabilities, pricing, inputs, outputs, examples, evidence references and execution terms so autonomous agents can accurately discover, evaluate, select and invoke it.
The term arose from live experiments in agent discovery, comparison, payment and machine-service execution carried out during 2026.
Finding a service is only the beginning
SEO helps people and search engines find a service. MCO helps autonomous agents understand whether it fits the task and how to use it correctly.
SEO asks
Can the service be found by its intended audience?
MCO asks
Can an autonomous buyer understand enough to select and invoke it accurately?
This is an analogy, not a replacement for SEO. Human discovery still matters. MCO focuses on the additional decisions a machine buyer may need to make after a service has been found.
A new audience for service information
Websites and digital services have traditionally been presented to human customers or documented for developers. Autonomous agents introduce another possible audience: software capable of choosing between competing services and, in some environments, paying for one itself.
Our Render Check and later autonomous-buyer experiments suggest that a machine buyer may need explicit answers to practical questions:
- What does the service actually do?
- Does it match the task?
- What does one invocation cost?
- Which inputs are accepted?
- What outputs will be returned?
- Is execution synchronous or asynchronous?
- How are status and results retrieved?
- What independent evidence and limitations are available?
Not all AI agents currently operate this way. MCO describes an emerging requirement observed through Atinamos's machine-commerce experiments.
From existing to being used
A service can exist and be discoverable without giving a machine enough information to choose it confidently. MCO primarily concerns the decision stages between discovery and invocation.
- Service exists
- Machine discovers it
- Machine understands it
- Machine compares it
- Machine selects it
- Machine invokes it
The service worked. Its machine contract did not explain it well enough.
Atinamos Render Check was live, technically operational and discoverable in an x402 marketplace. An independent buyer running on AWS Bedrock AgentCore searched the wider marketplace and compared it with competing website-audit services.
The neutral buyer initially selected other services. We reviewed the machine-facing offer and improved its name, tags, capability description, output contract, absolute status URL, result capabilities and asynchronous result instructions.
We then reran the same neutral buyer test without instructing it to favour Atinamos. It ranked Render Check first for the defined task of independent pre-handover website verification.
Two separate tests: AWS AgentCore was used for independent marketplace discovery and comparison. A separate direct x402 test buyer made the successful $0.25 USDC payment. Later Atinamos work went further, including a bounded autonomous buyer selecting and purchasing an external service and an unattended external machine-service execution from a frozen plan. We did not demonstrate sustained organic third-party buyer demand at scale.
What a machine contract needs to make clear
The exact format will vary by service and ecosystem. The useful test is whether an autonomous buyer can interpret each part accurately.
- Identity
- What is the service called, and what category of problem does it solve?
- Capability
- What can it actually do? Specific behaviour is more useful than broad claims.
- Pricing
- What does one invocation cost, and which currency, network or payment mechanism applies?
- Inputs
- What exact information must the buyer provide, in which format, and within what limits?
- Outputs
- What will the buyer receive? Explicit schemas and examples reduce ambiguity.
- Execution terms
- Is the work synchronous or asynchronous? How long can it take, and how is status retrieved?
- Examples
- What do valid requests, accepted jobs, completed results and failures look like?
- Evidence
- What provenance, observations, receipts, limitations and independently checked claims are available?
Being machine-discoverable is not the same as being machine-selectable.
A marketplace listing made Render Check available to the buyer, but availability did not settle the decision. The buyer still compared relevance, specificity, outputs, task fit, price and execution clarity.
A precise contract does not guarantee selection. It gives the buyer better grounds for deciding whether the service is appropriate.
MCO was one part of a wider machine-buying experiment
A machine-readable contract can help an autonomous buyer understand what a service claims to do, what it costs and how to use it. That does not remove the need for payment authority, budget control or evidence about what actually happened during a test or transaction.
MCO helps a buyer understand the offer.
Later research explored how scoped evidence could be recorded without turning it into a universal trust score.
That distinction shaped later Atinamos research. Payment, fulfilment, correctness and quality were treated as separate observations rather than collapsed into a single reputation score.
On 7 September 2026, an Atinamos research experiment completed an unattended external execution from an already-frozen plan. It purchased a third-party x402 service, observed Base settlement and recorded scoped evidence about the transaction and deliverable.
The result was deliberately narrow: payment settled and fulfilment observed, while correctness and quality remained NOT_EVALUATED. The work is preserved as historical research rather than presented as a current commercial service.
Explore Atinamos Labs for the current research record covering agent commerce, process evidence and emerging machine-to-machine systems.
Autonomous buyers also need reliable controls around payment authority, budget state and procurement policy; those controls sit outside MCO itself.
Human documentation and machine contracts should agree
People and autonomous agents may encounter different representations of the same service. The substance should remain aligned.
Human-facing
- Clear explanatory copy
- Case studies and FAQs
- Screenshots and demonstrations
- Context and practical examples
Machine-facing
- Precise capability description
- Input and output schemas
- Price and execution model
- Status semantics and limitations
Good human documentation remains valuable. MCO does not require an entirely separate product story; it asks that structured metadata, schemas and examples describe the same service accurately.
Clarity cannot compensate for a weak service
- Simply adding “AI” keywords or stuffing marketplace tags.
- Hiding weak functionality behind a better description.
- A substitute for reliable APIs, schemas, documentation or execution.
- A complete payment-authority, budget-control or independent evidence system.
- A trust score, certification or universal safe-to-buy signal.
- A claim that autonomous commerce is already mainstream.
- An established standard that applies unchanged to every ecosystem.
MCO cannot make a poor service good. It can make a good service easier for a machine buyer to understand accurately.
Before publishing a machine-buyable service, ask:
- Can an agent identify exactly what problem this solves?
- Is the price explicit?
- Are accepted inputs unambiguous?
- Are outputs described precisely?
- Is synchronous or asynchronous behaviour clear?
- Does the buyer know how to retrieve a result?
- Are valid examples available?
- Are limitations explicit?
- Are relevant evidence references available?
- Would two independent buyers interpret the offer in the same way?
A principle grounded in the Render Check experiment
The original agent-commerce experiments documented how independent buyer evaluation changed after the machine-facing contract improved. That work is now preserved with the wider Atinamos Labs research record.
Building a service for autonomous buyers?
Atinamos can help examine whether its identity, capabilities, inputs, outputs and execution terms are clear enough for machines and people to interpret consistently.