Agentic Infrastructure: How AI Agents Subscribe, Provision, and Build on Quicknode

AI agents already know how to make one-off blockchain calls. Give an agent a funded wallet, point it at an x402 or MPP-enabled endpoint, and it can read chain state, simulate a transaction, or submit a request without creating an account first.

That model is useful. It gets an agent onchain fast. But it casts an agent in a narrow role: caller.

The more important question is what happens when the agent needs to act like an operator: not just querying infrastructure, but standing it up.

That is the shift behind Quicknode’s new subscription flow. An agent can now create a full Quicknode account and activate a subscription in one request, receive a QN_* API key, and start provisioning infrastructure immediately. No dashboard signup, no human approval queue, no manual handoff in the middle of the workflow.

Two Access Paths, Two Different Jobs

There are two clear ways for agents to access Quicknode, and they solve different problems.

The first path is pay-per-call access with x402 or MPP. An agent sends a blockchain request, settles payment inline, and gets a response. No account, no persistent state, no long-lived credentials. It's the right fit for one-off reads, transaction checks, short-lived automation, and cases where Core RPC API access is all the agent needs.

The second path is agent subscriptions. The same wallet-based payment protocols do something deeper here: they create a persistent Quicknode account, attach it to a paid plan, and return a full platform API key. This is not a narrow token for one setup step. It's the same class of credential a human team would use to operate Quicknode through the dashboard and APIs, giving the agent direct access to the Admin API, Streams, Webhooks, SQL Explorer, Key-Value Store, IPFS, and endpoint provisioning across 81+ chains.

Put differently: pay-per-call access gets agents to the chain. Subscriptions make them first-class platform operators.

Point Your Agent Here

For developers building agentic workflows, the entry point should be direct and machine-readable. That is the role of Agents.md.

The page is written as an operating guide for agents. It lays out the available access paths, points to the subscription flow, links to x402 and MPP for accountless access, and gives the agent a clean path into infrastructure management. It is the page you want an assistant, coding agent, or orchestration layer to read before it starts making choices on your behalf.

Instead of teaching every integration from scratch, you can point the agent at the canonical surface and let it work from there:

Read https://www.quicknode.com/agents.md. Use your funded wallet to create a Quicknode subscription, then provision an endpoint on Solana mainnet, then make it multichain enabled.

When the platform publishes its own machine-readable entry points, the agent can discover the current path instead of relying on stale instructions baked into your own code.

Discover, Subscribe, Provision

The subscription flow has three steps, and each one is designed to be legible to software.

It starts with discovery. An agent can call POST https://www.quicknode.com/api/v1/agent/subscriptions without payment headers and receive an HTTP 402 response describing available plans, accepted payment methods, networks, and the information required to continue. The agent does not need scraped pricing pages or brittle dashboard automation to understand what options exist, and it does not have to break out into a separate human signup path before continuing.

From there, the agent subscribes using either x402 or MPP. With x402, the payment challenge is surfaced through HTTP 402 and a PAYMENT-REQUIRED header, and the signed payment is sent back in a PAYMENT-SIGNATURE header. With MPP, the challenge is surfaced through WWW-Authenticate: Payment, and the credential returns as Authorization: Payment. In both cases, the agent can rely on the payment SDKs to negotiate the exchange rather than constructing headers by hand.

After payment clears, the subscription response returns a QN_* API key and a live account. No email confirmation loop, no asynchronous approval state, and no second system to poll. A 200 response means the account, subscription, and API key are already live. If the request needs to be retried, the flow is designed for that as well: the same email and password resolve to the existing account instead of leaving the agent cleaning up duplicate state. The agent now has the same access as any other Quicknode account.

That makes the next step immediate: provision infrastructure.

Creating a new endpoint through the Admin API is one of many tasks the agent can now perform directly:

curl -X POST https://api.quicknode.com/v0/endpoints \
  -H "x-api-key: QN_abc123..." \
  -H "Content-Type: application/json" \
  -d '{"chain":"solana","network":"solana-mainnet"}'

The response returns an active endpoint with HTTP and, where supported, WebSocket URLs. If the agent wants to choose the target dynamically, it can first query GET https://api.quicknode.com/v0/chains to discover supported chain and network combinations, then provision accordingly.

The payment step is only the gate. The real capability is that the agent can continue directly into platform operations with the same credentials.

Keep the Account Running

Provisioning an endpoint is the first milestone, not the end of the relationship. The subscription continues on the interval the agent chose at signup, monthly or yearly, keeping the account as a durable operating context rather than a one-time setup artifact.

Credits follow the same pattern. The agent can check the balance through GET https://www.quicknode.com/api/v1/agent/balance, top up through POST https://www.quicknode.com/api/v1/agent/top_up, and use the same x402 or MPP payment protocols it used to subscribe. That gives the agent one billing path for the full lifecycle: start the account, provision infrastructure, monitor spend, replenish credits before exhaustion, and keep operating across the entire platform.

For agents that prefer schema-first discovery, Quicknode also publishes machine-readable specs for the broader platform. The best jumping-off point is API Specifications, which collects the current OpenAPI and OpenRPC surfaces in one place. From there, an agent can load the API specs, generate request shapes, and discover operations without scraping documentation prose.

The Next Layer of Agent Access

Wallet-based pay-per-call access was the first useful step for autonomous software. It proved that agents could transact for infrastructure directly, without API key handoffs or account creation flows built for humans.

Subscriptions take the next step. They give agents a durable operating context on the complete blockchain development platform. That means fewer brittle wrappers around one-off RPC calls, and more room to build agents that can stand up their own endpoints, subscribe to their own data, store their own state, and keep running.

If you are building agents that need to do more than query a chain once, start with Agents.md and see Build with AI for more on how to build with agents on Quicknode.