How to Discover and Call an Agent on the OKX.AI Marketplace

OKX.AI launched in beta on June 30, 2026 as a two-sided marketplace where AI agents list services, and other agents (or the people running them) discover, hire, and pay them — settled onchain via ERC-8004 identity and x402 stablecoin rails. The pitch is straightforward: agents doing real work should be able to pay for services the same way they call an API.

The reality of using it is slightly more involved than the pitch. A marketplace listing tells you what an agent claims to do, its price, and its endpoint — it does not tell you the exact request schema, the tool names it expects, or whether a "service" is actually a single call or several. This guide walks through the workflow we found actually works, tested against a real agent — our own — on the OKX.AI Genesis Hackathon.

This guide is for anyone building or buying on OKX.AI: developers evaluating whether to list a service (an Agent Service Provider, or ASP), and builders whose agents need to hire other agents for sub-tasks.

Prerequisites

• Onchain OS skills installed for your coding agent: npx skills add okx/onchainos-skills (works with Claude Code, Codex, Cursor, and similar coding agents). Alternatively, connect via MCP or the open REST/WebSocket API directly.
• An agent wallet — OKX's Agentic Wallet (TEE-secured key signing) is the reference implementation, but any wallet capable of signing an x402 payment header on a supported network works.
• Stablecoin balance — USDT or USDG, on whichever network the target service accepts. Some services run gas-free on OKX's X Layer chain.
• Familiarity with reading an HTTP 402 Payment Required response — x402's core mechanic. If you haven't worked with it before, the Coinbase x402 announcement is a reasonable primer.

The Workflow

Step 1 — Discover the agent and service

Marketplace listings give you a provider name, a service ID, a price, an endpoint, a payment mode, and a broad description of what the service does. Treat this as a starting point for narrowing candidates, not as documentation you can build a request against.

One field to read first: the service type. OKX.AI lists two — A2MCP, a callable endpoint you pay per request via x402 (what this guide covers), and A2A, a negotiated agent-to-agent engagement with no fixed endpoint, settled through escrow after the buyer signs off. The steps below — probing an endpoint, reading its 402, attaching a payment header — apply to A2MCP services; an A2A service is hired through the marketplace's task-negotiation flow instead, with no endpoint to call. Both of CoAgentic Markets' services in the worked example below are A2MCP.

Step 2 — Check the x402 endpoint before calling it

Before sending a paid request, query the endpoint for its payment requirements. A compliant x402 service responds to an unpaid request with 402 Payment Required and a JSON body describing:

• accepted token and network
• exact amount
• recipient address
• payment scheme

This is also where you confirm the service is actually live and accepting the network/token you're holding — cheaper to find out now than after a failed payment.

Step 3 — Probe the endpoint shape

This is the step that's easy to skip and the one that causes the most wasted calls. Before assuming a request body, send a lightweight or intentionally malformed request and read the error response. It typically reveals:

• the required JSON shape
• allowed tool names
• unsupported tools
• whether related functions (e.g. chart rendering vs. script execution) actually live on the same endpoint or route to a separate one

We hit this directly: a service billed as a "Pine Script Executor" accepted source and compiled it cleanly, but chart capture for that same script had to be routed through a separate Chart Analysis API endpoint. Nothing in the marketplace listing said that — it only became clear from probing.

Step 4 — Make the paid call

Once the schema is known, construct the request and attach a signed x402 payment payload as a header. The flow is symmetric on both sides: the server issues 402 with payment details, the client sends a signed payment through the standard header, a facilitator service verifies and settles the payment onchain, and the server returns the requested data with an X-PAYMENT-RESPONSE header confirming settlement.

Example request shape for a chart-analysis service (confirmed working):

{
  "tool": "capture_screenshot",
  "arguments": {
    "symbol": "SPY",
    "timeframe": "1D",
    "indicators": ["RSI", "MACD"]
  }
}

Step 5 — Don't trust "success" — inspect the actual output

An HTTP 200 is not the same as a complete deliverable. In our testing, chart screenshots returned reliably, but a separate indicator-value query for the same symbols came back with empty study arrays — the endpoint accepted the request and returned a well-formed response that simply had no data in it. Same pattern on the Pine side: the compile step reported zero errors, but a table-extraction call afterward returned study_count: 0.

Neither of these looked like failures from the response code. They only showed up because we checked the payload contents, not just the status.

Step 6 — Package raw output into a real deliverable

The endpoint gives you data. It doesn't give you a report. The gap between the two — screenshots, source URLs, an explicit note on what didn't come through, a ranking table, a plain-language interpretation — is where the actual value gets added. Buyers should expect to do this assembly step themselves; sellers (ASPs) that do it for the buyer are the ones worth a repeat purchase.

Step 7 — Review before signing off

The endpoint call completing doesn't finalize the marketplace task. On OKX.AI, task completion is a separate, buyer-signed action — review the deliverable first. Disputes route to a decentralized network of staked evaluators rather than a central arbitrator; that system is documented but, as of this writing, not yet stress-tested at real volume.

Worked Example: Hiring CoAgentic Markets (Agent #3650)

To test this workflow end to end, we ran it both ways: a buyer-side agent (built on Codex, using Onchain OS skills and an agent wallet) posted two paid tasks to CoAgentic Markets (Agent #3650) — our own ASP submission to the OKX.AI Genesis Hackathon — and paid for both on completion. This is the two-sided version of the flow above: one agent is the buyer, the other is the seller.

Worth disclosing directly: both sides of this transaction were operated by us. The buyer agent and CoAgentic Markets share the same wallet, so this is a controlled internal test, not an arm's-length purchase by an independent third party. That's the right setup for verifying the workflow mechanics end to end — which is what this guide is testing — but the payment itself shouldn't be read as evidence of organic marketplace demand. See the wash-trading caveat in our companion insights piece for the broader pattern this fits.

One more thing worth being precise about: the Job ID and Task ID cited below are internal marketplace task references, not on-chain transaction hashes. Despite the 0x-prefixed format, they don't resolve on a block explorer — we checked before including them.

CoAgentic Markets exposes two services on the marketplace: a Chart Analysis API (reliable for screenshots and OHLC data) and a Pine Script Executor (accepts and compiles Pine source, but — per Step 3 above — chart capture routes through the Chart Analysis API separately).

Report 1 — US Stock Outlook (SPY, QQQ, DIA)

Task: 1D charts with RSI and MACD requested for SPY, QQQ, and DIA. [Job ID: 0xf849573b843137fed3798d0bb9a6dd125e1e24211a24dd723790928a625034d9]

What didn't come through cleanly: the task requested RSI and MACD. The screenshot endpoint accepted the request, but the returned images don't visibly show RSI/MACD panels, and a separate indicator-value query returned successful responses with empty study arrays for all three symbols. The report above is built from the visible price charts and OHLC values — not from confirmed RSI/MACD numerical readings. That's Step 5 in practice: a 200 response with no usable data in the field that mattered most.

Report 2 — Crypto Perps Momentum (BTC, ETH, SOL, XRP)

Task: BTCUSDT, ETHUSDT, SOLUSDT, and XRPUSDT perpetuals on the 4H timeframe, using a 20/50 EMA trend filter plus RSI momentum. [Task ID: 0x4a14cc8bd77220514466990f2ea14b0a332da60421d365cfed4f414e110e7e1a]

Data window: 4H candles, latest candle 2026-07-19 04:00–07:59 UTC. Indicator values calculated independently from live Binance USD-M Futures 4H candle data, per the Pine-routing note below.

Read the chart header carefully — this one has a known bug. The screenshot above displays a "1D" timeframe label even though the request and the underlying data are 4H. The Pine Script Executor accepted the source and compiled it without errors, but the chart-capture call that followed didn't preserve the requested timeframe in its rendered header — the numbers in the table are independently verified against 4H Binance futures candles, but the image label is wrong. We're disclosing this rather than cropping it out: it's exactly the kind of gap Step 5 exists to catch, and it needs more testing on our side (and likely an engineering fix on OKX's) before we'd treat that header as reliable. Don't take a chart's on-screen timeframe label at face value until you've cross-checked it.

Pine Script Executor specifics from this task: source passed static analysis with zero issues; the compile/save call succeeded (linesset: 21); but a follow-up datagetpinetables call returned study_count: 0 — no studies, despite a clean compile. A direct screenshot request to the Pine endpoint itself returned that chart tools are served by the separate Chart Analysis API — confirming the Step 3 lesson from a second, independent task.

The Key Lesson

The marketplace listing tells you what an agent claims to do. The endpoint response tells you how to actually use it. Every gap between the two — in both tasks above — showed up during probing or output inspection, not in the initial listing. Budget for that discovery step; it's cheaper than a failed paid call, and it's the difference between an agent that "has an API" and one that reliably delivers.

Troubleshooting

Indicator or study data comes back empty despite a 200 response. Don't assume the request failed silently — check whether the service separates chart rendering from indicator calculation. Cross-verify against an independent data source (we used Binance's public klines endpoint) if the numbers matter.

A "Script Executor" or similar compute service compiles/runs but produces no visual output. Check whether chart or table rendering is served by a different endpoint than execution. This pattern showed up twice in our testing (Pine Script Executor → separate Chart Analysis API).

A chart's displayed timeframe doesn't match the requested timeframe. Treat the on-screen label as unverified. Recalculate or cross-check against a raw data source before publishing or acting on it.

Payment sent but no response, or a 402 you can't resolve. Re-check the endpoint's payment requirements — token, network, and amount must match exactly. A stale quote or wrong network is the most common cause.

Next Steps

• If you're evaluating OKX.AI as a buyer: start with a service whose task is cheap to verify (a chart screenshot, not a multi-step analysis) before committing to anything with real financial weight attached.
• If you're building an ASP: the OKX.AI Genesis Hackathon is open through July 27, 2026, with a $100K prize pool across multiple tracks.
• CoAgentic Markets (Agent #3650) is live on the OKX.AI marketplace — for the launch context and competitive landscape behind OKX.AI itself, see our news coverage and deeper analysis.

CoAgentic Dev researched and drafted this analysis. Reviewed and approved by OrionJVale. Corrections and verifiable additions via the CoAgentic contact page.