A technical analysis of how autonomous AI agents change RPC load profiles and what infrastructure must evolve to keep blockchains usable.

In July 2026, the Ethereum Foundation pointed a fleet of AI agents at the code Ethereum runs on. A real bug was found in gossipsub, the part of libp2p that consensus clients use to send blocks and attestations around the network. It caused a panic that could be set off from a distance. Any peer could set it off. It was fixed and disclosed as CVE-2026-34219 against rust-libp2p. But it was hidden under a bunch of sure-fire fakes, like crashes that only happened in test builds, "attacks" that needed a person to set them up first, and proofs that looked good but didn't prove anything. It didn't matter if the bug report was real or made up; it was hard to tell which ones to believe.

In general, the lesson is that AI makes both signal and noise at the same time; it's hard to tell the difference. When an agent guesses a method name, reshapes a request after an error, or asks for data in the way it thinks the API should work, it can show the same level of confidence that makes a fake bug report look real. At a small scale, that is just noise. At the scale of autonomous agents, crawlers, and AI-generated bots, it becomes a new kind of load profile. AI agents are quickly becoming one of the most demanding classes of Remote Procedure Call (RPC) consumers on public and permissioned blockchains, and existing node infrastructure was not designed around the way they discover, test, and consume data.

Agent traffic doesn't follow a script

In the past, wallets, exchanges, indexers, data platforms, and user-initiated tools have been the main types of blockchain RPC traffic. One can usually tell what these clients are going to do by the way they poll, query, or sync a lot of data from a small group of IPs and API keys. AI agents, by contrast, introduce traffic that is qualitatively different along several axes:

Document scraping and knowledge-building

Agents ingest protocol docs, contract ABIs, and block explorers to build semantic context. This often requires many small RPC calls (eth_getCode, eth_call with off-chain simulation, eth_getTransactionReceipt, and other metadata endpoints) performed repeatedly as the agent parses and validates contract behavior.

Recursive block explorer calls

At first, an agent looks at the inside of a wallet or contract, starting with the transaction history. Next, it moves on to the internal calls, token transfers, logs, and finally the information about how the contract was created. Each expansion multiplies the call count in a way a human investigation rarely would. But that recursion is a property of the agent's logic, not a law of nature. A lot of it is because the agent doesn't know what it can ask for. There is a group of ways that give the whole picture in one response: address-level history from Blockbook-style endpoints, full execution traces, and log queries across a block range. If the agent has enough information at the start, they can skip the steps needed to figure out how to answer the question and go straight to the method that does so. The gap between one request and four hundred is often just knowledge of the API surface.

Burstiness

Agents operate with a different temporal profile. During model thinking or simulation windows, they may send out a lot of requests at once, followed by nothing. This burstiness defeats static rate-limiting assumptions tuned for steady-state clients.

Generated requests and query permutations

To test theories, agents put together queries on the fly by mixing filters, time windows, and parameter permutations. That leads to a lot of calls that are similar but different, which breaks caching and makes RPC backends do work more than once.

Inefficient or exploratory bots

Not all agents are engineered for RPC efficiency. Experimental agents, R&D pipelines, or poorly instrumented bots can produce noisy, unthrottled workloads that resemble a denial-of-service vector without explicit malicious intent.

Because bots are already around, it helps to be clear what "different" means in this case. For years, blockchain infrastructure has been used by automated clients. Most of them run scripts that have already been outlined against a known set of endpoints. This is not how an AI agent works. Instead of following a set pattern, it explores by reading documentation, exploring APIs, and going through on-chain data to find what it needs as it goes. Providers have seen AI bots navigate block explorers to pull whole chains of blocks and transactions, as if they were making their own private network index. This causes steady, large-scale read activity that doesn't look like a wallet checking its balance. It also comes in waves instead of at a steady rate, with a period of very high volume followed by a lull and then another surge, especially when the workload is related to training models or collecting a lot of data. A rate limit handles this fine, anything over the quota comes back as a 429. What it doesn't handle is capacity planned around a steady state absorbing load that arrives in clumps, from a few hundred agents that all happened to be reasoning at the same moment.

Specific failure modes

These behavioral patterns translate into measurable failure modes for node operators, API providers, and downstream services.

1. Cache thrashing and low hit rates.

Many optimizations in RPC layers rely on cacheable query patterns: block headers, account state lookups, known contract ABIs, and historical logs for a given block range. Low cache hit rates are caused by agents that change settings slightly, like asking for logs with topics that are different but overlap or calling eth_call many times with ephemeral block tags. Instead of getting fast cached responses, providers must compute or deserialize data anew, increasing CPU and I/O usage.

2. Chatty request chains.

Agents rarely ask for something in one well-formed request when they can ask for it in ten small ones. Because a developer planned it that way, a human-written interface will generally use the most efficient call: a batch, a filtered range, or a multicall. An agent reasoning toward an answer tends to fire a chain of short, narrow requests instead: check one thing, use the result to decide the next, repeat. Each call is cheap on its own, but the round-trip overhead, connection churn, and per-request bookkeeping add up to far more load than the same information would have cost as a single structured query.

3. Exhausted rate limits and opaque throttling.

Rate-limiting systems tuned to per-key and per-IP quotas are poorly suited to agent behavior. Agents often multiplex many logical queries across a single API key or rotate keys rapidly. Standard throttling responses (429s) can cascade into retry storms, as agents automatically reissue queries with exponential backoff or, worse, unbounded retries if not properly coded. The lack of observability into why requests are throttled increases the complexity of troubleshooting.

4. Spam that doesn't look like spam.

Classic abuse is easy to catch because it repeats: the same request, over and over, from the same source. Agent traffic is slipperier. When a request is rejected or errors out, an agent will often rewrite it and retry with different parameters rather than resending the identical call. To the system, that looks like a stream of distinct, plausible requests rather than an obvious flood, so it slides past defenses tuned to catch repetition. The load can be just as heavy while looking nothing like textbook spam.

5. Billing unpredictability and cost overruns.

For API-based RPC providers, agent-driven workloads can cause unexpectedly high billable volumes. Spike-based pricing models or per-request charges become unpredictable when large AI experiments or pipelines are launched, producing sudden revenue variability for providers and catastrophic cost overruns for customers relying on metered services. This is also why predictable subscription-based access models, such as the one used by 6. Hallucinated or malformed requests.

Because agents frequently work from incomplete or misread documentation, they sometimes invent things that were never there — a method name that doesn't exist, a parameter shape the API won't accept, an endpoint they assumed was available. Each of those guesses still reaches the backend, gets parsed, and gets rejected, spending resources on requests that were never valid in the first place. This is exactly the gap a structured interface is meant to close: hand an agent a reliable, machine-readable description of what actually exists and it stops guessing — which, as we'll get to, is the point of MCP.

Why agents produce inefficient RPC patterns

The root causes are a mix of agent design, developer incentives, and the interface semantics of current RPC APIs.

Semantically opaque endpoints

JSON-RPC is a general-purpose, synchronous request-response protocol without typed method signatures. There's nothing in the protocol that tells a client what a method costs, what shape it returns, or how it behaves at the edges. So an agent works it out the only way available: it calls the method, reads what comes back, adjusts, and calls again — or pieces the answer together from whatever documentation it can find. Both paths produce exploratory volume, and the less context the agent starts with, the more of it there is.

Statelessness and re-simulation

Agents probing contract behavior commonly use eth_call to simulate transactions at various block heights, frequently re-running similar simulations with incremental parameter changes to validate hypotheses. The agent isn't repeating itself out of amnesia — it holds that context within a session. The recomputation happens on the node: every eth_call is executed fresh against state, and two simulations that differ by one parameter cost the backend the same as two unrelated ones.

Convenience over efficiency

Developers of agents optimize for correctness or speed of iteration, not for minimizing RPC footprint. If a request is cheap relative to human time, an agent may favor brute-force querying over an optimized, but more complex, strategy.

There is also a simpler supply-side reason the volume keeps climbing: building automation has never been easier. Large language models let people with little or no engineering background generate scripts, crawlers, and blockchain tools in minutes. Plenty of those tools work well enough to run but were never optimized for RPC efficiency, so they hammer endpoints with redundant or poorly structured calls. The population of automated clients grows, the average client gets less disciplined about resource use, and providers absorb the difference. Infrastructure teams are already seeing the effect in the form of rising traffic from both AI-generated bots and general-purpose crawlers.

Mitigations and architectural responses

Addressing the problem requires changes at multiple layers: API design, infrastructure components, and agent engineering practices. The following interventions reduce malformed calls, redundant queries, retry storms, and backend cost.

1. Structured discovery and policy metadata.

RPC providers should publish machine-readable metadata about supported chains, methods, rate limits, and example query patterns. This enables agents to discover capabilities without issuing noisy exploratory requests. A standardized schema for method documentation — describing idempotence, cost, expected response shapes, and example payloads — lets agents pre-compile efficient query plans rather than guessing.

2. Intent-aware throttling and quota models.

Rather than pure request-count throttles, providers can apply differentiated rate limits based on request type, method cost, and declared intent. A wallet checking eth_getBalance at the latest tag every few seconds is cheap and predictable, and can be throttled loosely. A burst of eth_getLogs across wide historical block ranges is neither, and deserves a tighter budget. Intent signatures allow backends to prioritize critical flows and to offer predictable QoS to latency-sensitive clients.

3. Bulk and batched primitives.

Adding efficient batch endpoints or specialized methods for common agent patterns reduces the number of round trips. Examples include batch log retrieval across contiguous block windows, multi-call state snapshots, and concurrent eth_call batching with vectorized inputs. Batching reduces per-request overhead and improves caching behavior.

4. Geographic distribution of endpoints.

Round-trip latency is a rounding error for a wallet making one call. It stops being one for an agent that works through a chain of two hundred sequential requests, where each response has to arrive before the next request can be formed. At that depth, an extra 80 ms per hop is sixteen seconds of pure transit — and that time is spent by the agent holding open a reasoning loop, not doing anything useful. Clusters placed close to where the traffic originates cut that cost directly, and the deeper the call chain, the more it compounds. It also spreads burst load across regions instead of concentrating it on one set of nodes, which helps the stability problem described earlier.

Emerging solutions: structured access layers

A structured access layer is a practical answer that tells agents what chains are available, what methods are available, example requests, and API-key control rules. It is like a contract between the agent and the RPC ecosystem. One let the agent safely find things and behave in a predictable way without giving runtime execution rights.

A specific implementation direction is the

The NOWNodes MCP Server follows this approach by giving AI-driven clients a structured way to understand the documentation, supported chains, available methods, API-key rules, and request examples. Here, MCP acts as a knowledge layer: it helps agents understand what they can use and how to use it safely, while keeping execution, key storage, and transaction broadcasting outside the agent’s control.

Conclusion — a call for protocol and tooling co-evolution

AI agents are automated clients, but they do not behave like the bots blockchain infrastructure was originally built to handle. The real shift is not just in traffic volume. It is in how these clients discover, interpret, and consume blockchain data. If agents are going to become a normal part of Web3 development, RPC infrastructure has to give them clearer rules of engagement instead of forcing them to guess their way through documentation and endpoints.

That is the direction we are moving in at NOWNodes. Predictable subscription-based access helps teams avoid the uncertainty of metered request spikes, while the NOWNodes MCP Server gives AI-driven clients a structured way to understand supported chains, methods, API-key rules, and request examples before they touch the node. The goal is not to slow agents down, but to make their interaction with blockchain infrastructure safer, clearer, and less wasteful.

The next generation of RPC providers will not be defined only by uptime or the number of supported networks. It will also be defined by how well they help both humans and machines consume blockchain data without overwhelming the systems behind it.