Build an AI Agent Marketplace: Architecture, Trust Scoring, Commissions

The problem

By late 2025 every infrastructure layer for agentic commerce was in place except the marketplace. MCP shipped in 2024 and spread within months. Google released A2A. Stripe and OpenAI released ACP. AI agents could communicate, transact, and coordinate. They had nowhere to find each other. Developers built logistics-optimization agents that saved warehouses 30% on routing — and had no channel to reach the warehouse managers who needed them. Business owners needed an inventory assistant and could not tell a battle-tested service from a weekend project. Discovery, trust, and commerce were three holes in the same wall.

The AI agent market reached $7.63 billion in 2025 and is projected to exceed $52 billion by 2030. Gartner reported a 1,445% surge in multi-agent system inquiries between Q1 2024 and Q2 2025. The question is no longer whether agents will transact autonomously, but where they will find each other. Whoever owns the marketplace owns the discovery surface for the entire agent economy.

This walks through the architecture for that marketplace: the four-layer edge stack, the W3C DID identity ladder, the four-dimension trust score, the server-side commission split with database-generated columns, and the A2A message types that drive autonomous agent-to-agent transactions.

What most people get wrong

Mistake one: treating an agent marketplace like an app store. App stores list static binaries: code that does the same thing every time it runs, signed once, distributed forever. Agents are not binaries. They are running services with capabilities that drift, uptime profiles, autonomous behavior that can change tone or quality between Tuesday and Wednesday. The marketplace listing must reflect a live state, not a snapshot. The trust signal is a moving average of measured behavior, not a one-time review. Architectures lifted from iOS App Store assumptions — manual review, immutable listing, single price — break the first time an agent’s behavior changes after approval.

The architectural answer is a four-dimension trust score that recomputes on every transaction: identity verification (DID level, credential freshness, issuer reputation), transaction success (completion rate, dispute rate, on-time delivery), user ratings (average, count, response time, repeat-customer rate), and AI moderation (code quality, safety, bias, hallucination rate). The composite is a weighted average with a threshold at 70 — below it, the agent loses marketplace visibility; below 50, suspended. Agents earn their listing every week, not at signup.

Mistake two: trusting the client to send the commission split. A common failure mode for marketplace MVPs: the client builds the cart, computes the commission, and sends both to the server. The server takes the numbers at face value. Six weeks in, a developer wires curl to the API, submits a $500 service with a 0.001% commission rate, takes home $499.50, and the platform learns about it from the books. The commission must be server-side, calculated from the database row, and ideally enforced by the database itself. PostgreSQL generated columns make this a constraint, not a discipline:

CREATE TABLE agent_service_offerings (
  id TEXT PRIMARY KEY,
  agent_id TEXT NOT NULL REFERENCES agents(id),
  price REAL NOT NULL CHECK (price > 0),
  commission_rate REAL DEFAULT 0.10
    CHECK (commission_rate >= 0 AND commission_rate <= 0.30),
  platform_fee REAL GENERATED ALWAYS AS
    (price * commission_rate) STORED,
  agent_payout REAL GENERATED ALWAYS AS
    (price * (1 - commission_rate)) STORED
);

The split is no longer trustable client data. The database computes it on insert, locks it in storage, and any client-side platform_fee field gets ignored.

A working approach

Four layers, deployed to Cloudflare Workers for sub-50ms global response:

1. Layer 1 — User Interface: Astro SSG landing pages, Preact islands for interactive components, MCP tools in AI assistants (Claude, ChatGPT), voice interfaces. All three entry points converge on the same API.
2. Layer 2 — API Edge: Cloudflare Workers handling routing, auth, rate limiting, and protocol detection (AP2 / ACP auto-detect).
3. Layer 3 — Coordination: Three services as Cloudflare Durable Objects — AI moderation (Claude-powered review, auto-approve above 0.85 confidence), recommendation engine (contextual offering scoring), and protocol gateway (MCP / A2A / AP2 translation).
4. Layer 4 — Data: Supabase PostgreSQL for primary records, D1 for edge cache, KV for sessions and rate-limit counters, R2 for agent assets, Queues for async moderation.

The DID identity ladder runs four levels, each with a verifiable credential structure pulled from trustauthority.ai:

• Level 0 — Registered: self-reported metadata, email verified, basic did:tp: issued. Free.
• Level 1 — Verified: code review completed, capability testing passed, developer identity confirmed. $50/year.
• Level 2 — Audited: third-party security audit, performance benchmarks verified, compliance checks. $200/year.
• Level 3 — Certified: full TrustBadge from trustauthority.ai, ML-DSA-65 quantum-safe credentials, annual re-certification. $500/year.

The credential is a W3C VC carried with every offering. Buyers can verify it independently — the marketplace is not the verification authority, it is a router.

A2A transactions flow through three message types. An agent offers a service contextually:

const serviceOffer = {
  protocol: 'google.a2a.v1',
  message_type: 'CONTEXTUAL_SERVICE_OFFER',
  from_agent: 'agent_marketing_bot_123',
  to_agent: 'agent_wish_orchestrator',
  context: {
    wish_id: 'wish_abc',
    inferred_category: 'marketing'
  },
  agent_info: {
    trust_score: 92,
    total_campaigns: 347,
    average_rating: 4.8
  },
  offer: {
    service_id: 'svc_marketing_campaign',
    price_usd: 150,
    estimated_delivery_hours: 24
  }
};

The buyer’s agent decides whether to purchase. The marketplace coordinates the payment (AP2 or ACP, auto-routed) and emits a SERVICE_PURCHASED message to the seller. On completion, a SERVICE_COMPLETED message carries the completion proof, the marketplace releases escrow, and the commission split executes against the database-enforced columns. Total platform revenue per transaction with contextual upsells looks like:

// Two-sided baseline: 2.5% of the wish
const baseRevenue = wishAmount * 0.025;

// Three-sided with agent service layer
const agentUpsells = 150;             // service add-ons
const agentCommission = agentUpsells * 0.10;  // 10%
const totalRevenue = baseRevenue + agentCommission;
// $100 wish: $2.50 baseline + $15.00 services = $17.50 (7x)

The flywheel: more agents create more service options, which raise the contextual upsell rate, which raises agent revenue, which attracts more agents. The trust score keeps the wheel from spinning toward fraud.

Where this scales

The walkthrough above is the architectural spine. The full book covers six more dimensions:

• TrustBadge composite scoring — the actual weights (30% identity, 30% transactions, 25% ratings, 15% moderation), the anti-gaming protections (rate-limited rating updates, account-age multipliers, duplicate-review detection), and the threshold enforcement at 70 / 50 / suspended.
• AI moderation pipeline — Claude prompt template for code review, the safety dimensions (bias, hallucination, capability claims), confidence calibration, and the human-review queue routing.
• Three transaction types and pricing — Agent Sale (one-time, 20% commission, $50–$500), Agent Rental (monthly, 20% commission, $10–$100/mo), Agent Service (per-task, 10% commission, $25–$200).
• Multi-agent fulfillment chains — escrow patterns when three agents collaborate on one task, commission splits across chained payouts, and the dispute-resolution flow.
• Developer dashboard and sandbox — onboarding flow, listing approval, sandbox test runner, MCP tool integration so an agent’s listing is discoverable from inside Claude Desktop or ChatGPT.
• Financial projections — 12-month growth path from 10 agents to 500, transaction volume from 50/month to 15,000/month, MRR from $500 to $90,000, with the unit economics that hold up under cohort analysis.

Every code example is from the production phantoid.com codebase. The 85% AI auto-approval rate, the 70-threshold trust line, and the 10% / 20% commission tiers are operational numbers, not estimates.

Included with the book

• agent-registration-checklist.md — the production checklist used to register a new agent on phantoid.com. Capability declarations, DID issuance steps, sandbox test cases, moderation submission. Saves the first day of trial and error.

Get the full picture

Readers of this also chose

Questions readers ask

Can I run this on the Cloudflare Workers free tier?

For early-stage marketplaces, yes. The Workers free tier handles the request volume of a marketplace with 10–50 listed agents and hundreds of transactions a month. Durable Objects move you to the paid tier, but the cost is small compared to the marketplace revenue at that scale. The architecture is designed to start cheap and scale linearly.

Do I need to use phantoid.com's identity stack?

No. The DID ladder is W3C-standard; any compliant DID resolver works. The book uses did:tp: (trustauthority.ai's method) as the reference implementation because we run it, but the patterns translate to did:web:, did:key:, or any other method. The trust score formula is method-agnostic.

What's the relationship between this book and Book 11 (A2A Bridge)?

This book covers the marketplace — discovery, trust, commissions, transaction flows. Book 11 covers the A2A protocol itself in depth — message envelope structure, agent cards, capability negotiation, the bridge layer that translates between A2A and MCP. They are complementary: this book uses A2A as one of several transport rails; Book 11 is the rail in depth.

How are server-side commissions enforced if I'm not using PostgreSQL?

The same pattern works on any database that supports generated columns or triggers — MySQL 5.7+, SQL Server, SQLite (via virtual columns). The key invariant: the platform fee is never trusted from client input. Either the database computes it from price × commission_rate, or a server-side function does and the client value is overwritten before write.

What's the refund policy?

Lemon Squeezy's standard refund window applies. If the patterns don't fit your stack, the refund link is in the receipt email.