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.
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 live 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 Assurance execution from a frozen plan. We have still not demonstrated 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 is one part of machine buying
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 independent evidence about what has actually happened in prior tests and transactions.
MCO helps a buyer understand the offer.
Atinamos Assurance supplies scoped evidence. The buyer decides what that evidence means.
That distinction became important in our later work. Atinamos now separates payment, fulfilment, correctness and quality rather than collapsing observations into a single trust or reputation score.
On 7 September 2026, the Atinamos Assurance Runner completed its first unattended generic external Assurance execution from an already-frozen plan. It purchased a real third-party x402 service, independently observed Base settlement, assessed the advertised deliverable and published signed Verification evidence.
The result was deliberately narrow: payment settled, fulfilment observed, while correctness and quality remained NOT_EVALUATED. That is evidence, not certification.
Explore Atinamos Assurance or inspect Atinamos Verification's published evidence and research.
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 Assurance 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 case study documents what Atinamos built and how independent buyer evaluation changed after the machine contract improved. It now also follows the work forward into autonomous buying and independent Assurance.
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.