The Genesis of Agentic Commerce: Identifying the First Sustainable Agent-to-Agent Market

Report body

The Genesis of Agentic Commerce: Identifying the First Sustainable Agent-to-Agent Market

The transition from a paradigm where humans prompt software to an era where software prompts itself fundamentally rewrites enterprise unit economics and infrastructure demand1. In this emerging agent economy, large language models (LLMs) act as cognitive engines powering autonomous systems capable of planning, tool-use, and multi-agent collaboration1. However, the critical barrier to an autonomous agent-to-agent (A2A) coordination network is not capability, but the "cold start" problem of initial market liquidity. An early market must function without a guaranteed installed base, exclusive datasets, or captive customers, and its earliest participants must receive immediate economic value to justify integration.

Crucially, a distinction must be made between a technically demonstrable exchange and an economically sustainable market. A technically demonstrable exchange proves that two agents can route payloads and execute payment headers (such as x402)2. An economically sustainable market proves that the transaction generates a positive margin for the supplier, a positive return on investment for the buyer, and resolves clearing disputes deterministically without routine human supervision3.

Based on an exhaustive analysis of public documentation, pricing frameworks, and operational evidence, this report evaluates candidate markets to identify the first viable theater for autonomous A2A trade.

Evaluation of Candidate Markets

To identify the optimal initial market, nine candidate sectors were evaluated against ten strict criteria for autonomous sustainability. These criteria include the frequency and urgency of demand, the ability for machines to specify and evaluate tasks, the buyer’s motivation to outsource, the supplier’s defensible advantage, task duration and sensitivity, the availability of competing options, network configuration requirements, repeat transaction viability, the necessity of human judgment, and the degree of useful specialization produced.

1. Translation and Content Generation

The market for autonomous translation and general text generation relies on agents contracting one another to process linguistic data. The demand frequency is high, and task duration is extremely short. However, this market fails the requirement for useful specialization. A supplier agent in this space is merely reselling identical model outputs (e.g., passing a prompt to a foundational model provider like OpenAI or Anthropic). The supplier holds no defensible advantage, as the buyer agent could execute the exact same API call directly. Furthermore, evaluating translation quality requires semantic, subjective judgment, introducing unresolvable clearing disputes in a purely autonomous network. This market is economically unsustainable for independent A2A trade.

2. Research Subtasks and Monitoring

Agents deployed for monitoring compliance watchlists, tracking vendor pricing, or executing deep research subtasks represent a high-value enterprise use case5. The demand is urgent and frequent. However, the evaluation of these tasks is highly subjective. Current "LLM-as-a-judge" evaluation architectures—where one model grades the output of another—exhibit fatal reliability flaws. Public benchmarks indicate that off-the-shelf LLM judges agree with human domain experts only 64% to 68% of the time on expert-knowledge tasks6. In an A2A market, a 35% error rate in clearing decisions necessitates routine human arbitration, entirely defeating the purpose of autonomous coordination.

3. Specialized Computation and Resource Scheduling

Decentralized networks like Bittensor and Akash have pioneered markets where agents schedule specialized computation, routing GPU compute through tokenized incentives to pretrain or fine-tune models7. The supplier's defensible advantage is clear: massive capital expenditure in hardware (e.g., H100 clusters).

Despite high transaction volumes, empirical studies reveal that these networks are not suited to be the first autonomous market for independent agents due to structural economic failures. Analysis of Bittensor subnets demonstrates extreme stake concentration, with the top 1% of wallets controlling a median of 90% of total stake9. Furthermore, rewards are overwhelmingly driven by stake magnitude (correlation of 0.80 to 0.95) rather than performance scores (correlation of 0.45 to 0.65)9. Because validation relies on a subjective-utility consensus rather than deterministic proof, the market is highly vulnerable to collusion, Sybil farming, and free-riding7. Finally, this market requires massive scale (hundreds of nodes) to achieve consensus, meaning it cannot create value with a configuration of just two or three agents11.

4. Data Transformation and Structured-Data Extraction

Agents are frequently deployed to address structural schema mismatches across enterprise systems, extracting unstructured data and transforming it into structured formats on the fly12. The frequency of demand is massive, driven by the continuous flow of corporate data. The buyer's motivation to outsource is strong, as it avoids the manual construction of brittle ETL (Extract, Transform, Load) pipelines12.

However, the failure consequences in this market are severe. Injecting hallucinated or improperly formatted data into a corporate ERP or CRM system corrupts the foundational truth of the enterprise. Because data transformation involves navigating edge cases (e.g., disparate address formats, mismatched SKUs), programmatic evaluation is immensely difficult12. The market currently requires either human-in-the-loop validation or subjective LLM judges, both of which disqualify it as a fully autonomous initial market.

5. Autonomous Software Maintenance

End-to-end autonomous software maintenance involves coding agents identifying bugs, reasoning through logic, and submitting pull requests to production repositories. The economic value is high; replacing the labor cost of a junior developer yields obvious ROI, and tasks are valued between $5 and $50014.

The critical flaw in utilizing this as an initial market is the inability to programmatically specify and evaluate the end-to-end task without extensive testing infrastructure. If an agent commits defective code to a production environment, the failure consequences are catastrophic. While this represents a highly lucrative future market, it cannot function autonomously until a robust, independent verification layer is established.

6. Independent Verification and Sandboxed Code Evaluation (Recommended)

This market isolates the evaluation phase of software development. A buyer agent (an autonomous coding orchestrator) generates a candidate code patch but lacks a secure environment to test it. The buyer contracts a supplier agent to provision an ephemeral, hardware-isolated sandbox (e.g., a Firecracker microVM), compile the code, execute a test suite, and return the deterministic logs16.

The demand is continuous and urgent; solving a single software engineering task on benchmarks like SWE-bench frequently requires 10 to 30 iterative loops of generation and testing14. The task is perfectly specifiable and evaluable by machines, as success is determined strictly by deterministic stdout, stderr, and binary test pass/fail states17. The supplier possesses a highly defensible advantage: engineering and maintaining sub-second cold-start microVM infrastructure is operationally complex18. The market operates flawlessly with just two or three agents, requires absolute zero human judgment, and produces specialized infrastructure utility rather than resold model outputs.

Transparent Comparison Matrix

The following matrix synthesizes the evaluation of the most viable candidate markets against the ten strict criteria for autonomous A2A sustainability.

Public evidence is entirely sufficient to recommend Independent Verification and Sandboxed Code Evaluation as the initial market. Market operational data from infrastructure providers like E2B, Modal, and Runloop provide robust empirical baselines for pricing, latency, and hardware utilization16.

The Recommended Market: Independent Verification and Sandboxed Execution

The fundamental barrier to agentic commerce is the "agentic clearing problem"—the structural inability of current infrastructure to prove that an agent should be paid, rather than merely proving it can be paid24. Payment networks authorize the movement of funds, but they do not verify if the output matches the delegated intent25.

The Independent Verification market succeeds specifically because it bypasses the clearing problem entirely. It relies on the compilation of an "Evidence Envelope"—a hash-anchored container of deterministic execution items, such as Continuous Integration (CI) logs and test outputs4. When an agent evaluates code, the resulting stdout and stderr are mathematically verifiable. A clearing protocol can parse this evidence against an admissibility floor and issue a definitive Settlement Instruction without ever invoking a hallucination-prone LLM judge4.

Plausible Buyer Profile

The buyer is an autonomous coding orchestrator (e.g., an OpenHands agent instance) operating within an enterprise development environment26. Its mandate is to resolve software engineering tickets autonomously.

• Motivation: The buyer requires a secure, ephemeral environment to execute untrusted, LLM-generated code. Attempting to execute this code locally risks host compromise.
• Budgeting: The buyer utilizes an outcome-based or consumption-based budget, drawing from operational expenditure previously allocated to junior QA engineers or manual testing15.

Plausible Supplier Profile

The supplier is an autonomous Infrastructure-as-a-Service (IaaS) agent operating on bare-metal servers.

• Defensible Advantage: The supplier maintains a warm pool of Firecracker microVMs or gVisor containers19. AWS Lambda cold starts demonstrate that initializing a fresh microVM can take between 100ms and 2 seconds, depending on the runtime and snapshotting mechanics18. The supplier specializes in managing this cold-start latency, offering sub-second Time-To-Interactive (TTI) execution environments23. By aggregating demand from thousands of buyer agents, the supplier achieves scale economics that single-buyer deployments cannot match.

Recurring Demand Trigger

The demand trigger is the inner iterative loop of software development. A benchmark evaluation of SWE-bench indicates that a single software engineering task consumes an average of 35.5 API calls and requires multiple execution feedback loops27. Every time the buyer agent alters a function, it triggers a demand for a sandbox to compile the code, run Static Application Security Testing (SAST), and execute unit tests28.

Smallest Useful Network Configuration

The market achieves absolute utility with exactly three non-human participants, eliminating the need for a massive installed base:

1. One Orchestrator Agent (Buyer): Submits the candidate code patch and authorizes payment.
2. One Execution Agent (Supplier): Provisions the microVM, runs the code, and generates the cryptographic hash of the execution logs.
3. One Smart Contract (Evaluator/Clearinghouse): A neutral on-chain state machine (utilizing RAILS or ERC-8183) that parses the deterministic evidence hash and triggers settlement4.

Complete Example Transaction

An autonomous transaction in this market requires a multi-layered protocol stack to handle identity, commerce state, payment, and clearing. The following demonstrates a complete A2A transaction utilizing established and emerging public standards21.

1. Discovery and Identity (ERC-8004): The Buyer Agent queries the ERC-8004 Identity Registry to locate a Supplier Agent21. The registry returns a portable, censorship-resistant identifier detailing the Supplier's historical execution reliability and infrastructure capabilities21.
2. Escrow and Obligation (ERC-8183): The Buyer initiates a commercial relationship using the ERC-8183 Agentic Commerce Protocol. The Buyer calls the createJob function on the smart contract, designating the Supplier as the Provider, setting a neutral verification smart contract as the Evaluator, and establishing a time-to-live deadline31. The Buyer then calls fund, locking $0.05 USDC into the on-chain escrow, thereby eliminating counterparty credit risk for the Supplier32.
3. Execution (Firecracker microVM): The Supplier observes the Funded state on the ledger. It pulls the Buyer's candidate code patch, initializes a Firecracker microVM from a warm snapshot (bypassing the traditional 2-second cold start)18, and executes the unit tests.
4. Evidence Submission: The Supplier captures the terminal output (stdout/stderr), stores the raw logs off-chain (e.g., on IPFS), and generates a cryptographic hash of the deliverable32. The Supplier calls submit(jobId, deliverableHash) on the ERC-8183 contract, moving the job to the Submitted state32.
5. Clearing and Settlement (RAILS & x402): The Evaluator smart contract retrieves the logs. Utilizing a RAILS Verification Mesh, it deterministically confirms that the FAIL_TO_PASS tests passed without breaking the PASS_TO_PASS baseline4. Because the verification is objective, the Evaluator calls complete(jobId), releasing the $0.05 USDC to the Supplier32. Alternatively, for high-frequency inner loops where on-chain escrow is too slow, the Buyer and Supplier can settle instantly via HTTP x402 headers (402 Payment Required), passing signed payment authorizations alongside the execution payloads2.

Preliminary Unit-Economics Model

Traditional SaaS seat-based billing fundamentally fails in the agent economy, as a single agent interaction can trigger hundreds of sub-cent micro-activities3. Economic sustainability requires dynamic, consumption-based unit economics1.

This preliminary model utilizes sourced figures from active sandbox providers (E2B, Modal) and LLM inference costs. Where explicit pricing is unavailable, labeled assumptions are utilized.

Value Creation (Buyer Economics):

• Assumption: Based on industry estimates, the resolution of a knowledge-work task (e.g., fixing a software bug) provides a labor savings value to the enterprise of $5.00 to $500.0014.
• Sourced Metric: A SWE-bench coding task requires a median of 20 to 35 execution iterations to achieve resolution14.

Cost of Goods Sold (Supplier Economics):

• Sourced Metric: Commercial sandbox compute is billed dynamically based on active CPU and memory wall-clock time. Standard rates are $0.0504 per vCPU-hour and $0.0162 per GiB-hour16.
• Calculation: For a robust compilation environment (8 vCPU / 8 GiB) running an average 60-second evaluation17:
  • CPU Cost: [Source figure not loaded here; retained in the source-text copy.]
  • Memory Cost: [Source figure not loaded here; retained in the source-text copy.]
  • Total Hardware COGS per execution = $0.00888 (roughly 0.9 cents).
• Sourced Metric: At massive scale, self-hosting Firecracker on bare-metal hardware (e.g., an H100 SXM5 spot instance at ~$576/month) drives the per-execution cost down to $0.00019 for high-volume suppliers20. For this model, the conservative public cloud COGS of ~$0.01 is utilized.

Transaction Pricing and Margins:

• Supplier Ask Price: The Supplier sets an execution price of $0.05 per task.
• Supplier Gross Margin: Generating $0.05 against a COGS of $0.01 yields a highly sustainable 80% gross margin per execution.
• Buyer ROI: The Buyer requires 30 iterations to fix the bug, spending a total of $1.50 in independent verification fees ([Source figure not loaded here; retained in the source-text copy.]5.00 in value to the enterprise, resulting in a net positive return and justifying the outsourcing of the infrastructure14.

This model confirms that the Independent Verification market is not merely technically viable, but generates sustainable, positive unit economics for both counterparts without human subsidies.

Reasons Rejected Markets are Less Suitable Initially

The rejected candidates fail the test for initial sustainability due to reliance on unproven mechanics or human intervention.

• Specialized Computation (Decentralized ML): Fails due to economic centralization and subjective consensus. Empirical data proves that rewards correlate almost entirely with staked capital rather than output quality, creating a market driven by plutocracy rather than utility10. Furthermore, evaluating an LLM's contribution relies on subjective scoring, opening the network to rampant collusion and Sybil attacks7.
• Data Transformation: Fails due to the inability to programmatically verify schema mapping. LLM-as-a-judge architectures fail at a rate of roughly 35% on domain-specific tasks6. Corrupting an enterprise database due to a hallucinated schema mapping carries fatal operational risks, mandating human oversight and nullifying autonomy12.
• Autonomous Software Maintenance: Fails as a starting point because generating code is only valuable if it can be proven correct. Without a pre-existing market for isolated, secure execution and verification, coding agents represent an unacceptable security risk to production environments.
• Translation and Content Generation: Fails because it does not produce defensible specialization. An agent reselling OpenAI or Anthropic API outputs provides zero distinct value over the buyer calling the API directly. Autonomous markets require asymmetry in capabilities or infrastructure.

Conditions for Expanding into a Second Market

Once the Independent Verification market achieves high liquidity, the ecosystem can organically expand into the Autonomous Software Maintenance and Bug Fixing market. This expansion is contingent upon three measurable conditions:

1. Identity and Reputation Density: The ERC-8004 registries must accumulate sufficient historical ledger data. Orchestrator agents must be able to query the blockchain to verify that a Bug-Fixing agent has a proven track record of generating code that successfully passes Independent Verification21.
2. Cross-Market Composability: The RAILS Evidence Envelopes generated in the Verification market must become portable credentials4. A transaction in the Software Maintenance market can be structured such that escrowed funds are only released to the coding agent after a third-party Verification agent submits a passing execution hash32.
3. Protocol Security Maturation: Agentic commerce platforms introduce structural, protocol-level vulnerabilities—such as Time-of-Check to Time-of-Use (TOCTOU) races and intent manipulation—that succeed with a 100% attack-success rate regardless of the LLM deployed36. Before expanding to high-value software maintenance, these vulnerabilities must be mitigated. Defenses like PCAT (Protocol-level Commerce Agent Trust) and A-VIP (AP2 Verified-Intent Protection) must be deployed to bind signed intent to execution capabilities, driving the structural attack-success rate to zero36.

Proposed Validation Plan and Rejection Criteria

To empirically differentiate this recommended market from a theoretical construct, a rigorous validation plan must be executed. If any of the following measurable rejection criteria are met, the Independent Verification market hypothesis is invalidated.

Phase 1: Latency and Inner-Loop Viability

• Objective: Validate that the cryptographic overhead and infrastructure provisioning do not break the continuous compute cycle required by coding agents.
• Test: Execute a 1,000-iteration loop utilizing x402 HTTP micropayment headers to provision Firecracker microVMs from warm snapshots2.
• Rejection Criterion: If the combined latency of the x402 handshake and the microVM Time-To-Interactive (TTI) exceeds 3.0 seconds at the 95th percentile, the market fails. Orchestrator agents require rapid feedback; excessive latency will force buyers to abandon the A2A market and internalize their execution environments despite the operational friction18.

Phase 2: Scale Economics and Utilization

• Objective: Validate the supplier's defensible pricing advantage under asynchronous load.
• Test: Simulate a production environment routing 100,000 requests per day to a self-hosted execution agent operating on bare-metal architecture20.
• Rejection Criterion: If the supplier's COGS per execution exceeds $0.03, the market fails. At this price point, the supplier cannot maintain a profitable margin while undercutting centralized, flat-rate alternatives (like GitHub Actions). The decentralized A2A market would degrade into a centralized SaaS oligopoly23.

Phase 3: Protocol-Level Security Integrity

• Objective: Ensure the clearing and settlement protocols are resistant to structural and semantic manipulation.
• Test: Subject the ERC-8183 escrow and RAILS verification mesh to the AIP-Bench deterministic security benchmark. Specifically test for Indirect Prompt Injection (IPI) attacks embedded within the executed code payloads designed to exfiltrate credentials or alter the payment recipient36.
• Rejection Criterion: If an injected payload successfully redirects the settlement instruction or bypasses the admissibility floor with an Attack-Success Rate (ASR) greater than 0%, the market is invalid36. An economically sustainable market requires absolute, mathematically guaranteed clearing. Any structural vulnerability that allows an agent to bypass the verification logic destroys the trustless foundation required for autonomous trade.

Works cited

1. AI Agent Economy: Enterprise Impacts and Infrastructure Shifts, https://i10x.ai/news/ai-agent-economy
2. What is x402? | Nevermined, https://nevermined.ai/glossary/x402/
3. AI Agent Operations for Sustainable Monetization - Nevermined, https://nevermined.ai/blog/ai-agent-business-operations-strategy
4. RAILS:Verification-Native Clearing for Agentic Commerce - arXiv, https://arxiv.org/html/2606.08790v1
5. How to Build AI Agents: A Production-Ready Guide for 2026 - CoinPay, https://coinpayportal.com/blog/how-to-build-ai-agents
6. How to Set Up Evals with LLM-as-Judge | Splunk, https://www.splunk.com/en_us/blog/learn/evals-llm-as-judge.html
7. Quantum-Resilient Decentralized AI Economies: Proof-of-Useful, https://arxiv.org/html/2606.24942v1
8. Decentralized Reinforcement Learning for Agentic LLMs on the, https://medium.com/@gwrx2005/decentralized-reinforcement-learning-for-agentic-llms-on-the-bittensor-blockchain-66f0ba43e6a1
9. Bittensor Protocol: The Bitcoin in Decentralized Artificial Intelligence, https://www.researchgate.net/publication/393477381_Bittensor_Protocol_The_Bitcoin_in_Decentralized_Artificial_Intelligence_A_Critical_and_Empirical_Analysis
10. Bittensor Protocol: The Bitcoin in Decentralized Artificial Intelligence, https://arxiv.org/html/2507.02951v1
11. Incentivised Orchestrated Training Architecture (IOTA) - arXiv, https://arxiv.org/html/2507.17766v1
12. Why Your AI Agent Deployment Takes 6 Months (and ... - Unframe AI, https://www.unframe.ai/blog/ai-agent-deployment-6-months-vs-days
13. How Suger Uses AI for Cloud Marketplace Automation, https://www.suger.io/resources/guides/suger-ai/
14. The AI Agent Economy: Who Wins? - Value Add VC, https://valueaddvc.com/blog/ai-agent-economy
15. The complete guide to AI agent monetization - Paid.ai, https://paid.ai/blog/ai-monetization/the-complete-guide-to-ai-agent-monetization
16. E2B Alternatives for AI Agent Sandboxes (2026) - OpenComputer, https://opencomputer.dev/guides/e2b-alternatives/
17. A harness that evaluates SWE-bench instances inside E2B sandboxes, https://github.com/e2b-dev/swe-bench
18. AWS Lambda Cold Start Mitigation Guide - Hidekazu Konishi, https://hidekazu-konishi.com/entry/aws_lambda_cold_start_mitigation_guide.html
19. Performance Engineering for AI Agents - Cold Start Times, Latency, https://www.softwareseni.com/performance-engineering-for-ai-agents-cold-start-times-latency-budgets-and-scale-economics/
20. AI Agent Code Execution Sandboxes on GPU Cloud: E2B, Daytona, https://www.spheron.network/blog/ai-agent-code-execution-sandbox-e2b-daytona-firecracker/
21. ERC-8183: The Standard That Lets AI Agents Hire Each Other, https://blockeden.xyz/blog/2026/03/10/erc-8183-agentic-commerce-standard-ai-agent-transaction-stack/
22. Best Sandboxes for SWE-Bench-Style Coding Agents in 2026 - Modal, https://modal.com/resources/best-sandboxes-swe-bench-coding-agents
23. Best Agent Sandboxes in 2026: Cold Start, Per-Second Pricing, and, https://www.marktechpost.com/2026/08/27/best-agent-sandboxes-2026-cold-start-pricing-network-policy/
24. RAILS: Verification-Native Clearing For Agentic Commerce - arXiv, https://arxiv.org/abs/2606.08790
25. RAILS: Verification-Native Clearing - Evolutionairy AI, https://evolutionairy.ai/rails-clearing
26. Best Code Execution Sandbox for OpenHands in 2026 | Modal Blog, https://modal.com/resources/best-sandbox-openhands
27. AI Agent Development Costs: Why Sandbox Billing Breaks - Blaxel, https://blaxel.ai/blog/ai-agent-development-costs
28. HumanEval Benchmark: What It Tells You About Coding Agents, https://blaxel.ai/blog/humaneval-benchmark
29. x402: UNLOCKING THE INTERNET'S MISSING PAYMENT LAYER, https://www.khala.io/x402-completing-the-internets-missing-payment-layer-for-agentic-commerce
30. Agentic Kaia: Building the Economic Layer for AI Agents, https://blog.kaia.io/agentic-kaia-building-the-economic-layer-for-ai-agents/
31. ERC-8183: A dummies guide to the Agentic Commerce, https://www.decipherclub.com/erc-8183-a-dummies-guide-to-the-agentic-commerce/
32. ERC-8183 Explained: The Commerce Layer for AI Agents - Dwellir, https://www.dwellir.com/blog/erc-8183-agentic-commerce-explained
33. What is x402? HTTP 402 payments for AI agents - MetaMask, https://metamask.io/news/what-is-x402
34. What Is ERC-8183 and Why It Matters for AI Agents in Crypto - Phemex, https://phemex.com/academy/erc-8183-ai-agents-crypto
35. ERC-8183 Standard for Settlements Between AI Agents Introduced, https://coinspaidmedia.com/news/erc-8183-standard-settlements-between-ai-agents-introduced/
36. Protocol-Level Attacks on Agentic Commerce Platforms - arXiv, https://arxiv.org/html/2607.21824v1
37. Whisper Attacks and a Binding Defense for AP2 - arXiv, https://arxiv.org/html/2609.11757v1