AI Agents Won’t Just Query Subgraphs. They’ll Create Them.
AI agents won’t always find the blockchain data they need in an existing dataset. What if they could inspect contracts, generate and deploy their own subgraphs, and continue the investigation themselves?
Subgraphs are usually built around a known set of contracts and queries. Before deployment, someone decides what to index, how to represent it, and the data queryable through GraphQL.
A protocol can make slight adjustments, like adding a contract, or a frontend can add another field, but the data model is largely designed before the application starts using it.
But agents introduce a less predictable way of accessing data. An agent tasked with risk analysis, looking into unusual USDC activity, might begin with transfer volume, then follow a handful of wallets into a lending market, and finally look for positions or transactions that were never part of the original dataset. What it needs next depends on what it finds.
At some point, there may be no existing subgraph with the right contracts, history, and relationships.
The way development works today requires someone to define the data required. That means finding the relevant contracts, checking their events and ABIs, deciding what state can be reconstructed, writing the schema and mappings, deploying the subgraph, and waiting for the required history to index.
There is no obvious reason that process has to remain entirely manual.
An agent that can inspect contracts and write code could also generate the subgraph it needs, deploy it, query the result, and discard it when the work is done.
Subgraphs would still support long-running applications, but they could also be created for questions that only become clear after an investigation has already started.
Existing schemas only take an agent so far
Giving agents access to subgraphs is already useful. GraphQL gives them a structured schema to inspect, along with well-defined entities and relationships. MCP and similar tooling make it easier to expose those capabilities to an agent.
The limitation today would be that the required data is not in the schema.
Consider an investigation into an increase in USDC transfers on Ethereum. Transfer history may answer the first question. Pool data may also help determine whether liquidity is moving at the same time, and wallet activity can point toward a lending market or another protocol.
In this case, the investigation will likely move outside the boundaries of the dataset that was available at the start.
An engineer can patch that up, but every handoff interrupts the agent’s work. Autonomous systems become much less autonomous if every new data requirement ends in an engineering ticket.
Allowing the agent to create the missing dataset is a natural extension of what subgraphs already do.
A subgraph describes which contracts matter, which events should be processed, how those events change stored entities, and how the resulting data should be queried. Most of that definition is expressed in structured code and configuration.
An agent capable of reading an ABI can identify relevant events, work out which entities are required, generate a schema and mappings, and submit the deployment. Once the requested block range has indexed, the agent can continue from the result.
Agents create less predictable data requirements
Application developers usually know the main queries their product will make. An agent may not know its next query until the current one returns.
A trading investigation illustrates the difference. Elevated volume may lead to a closer look at liquidity. Similarly falling liquidity may lead to LP withdrawals. Several large withdrawals may also point to a group of wallets. Those wallets may have positions elsewhere that explain the activity.
None of those later datasets need to exist unless the investigation reaches them.
Pre-indexing every possible combination of contracts and relationships would waste storage and compute. It would also be impossible to anticipate every direction an agent might take.
Creating data as it becomes necessary is a better fit for that kind of work.
Protocol state, transfers, pools, positions, and other heavily used datasets are better maintained continuously. Agent workloads simply add another category: datasets created for a particular task and kept only for as long as they are useful.
A subgraph created for one investigation might not be important an hour later, and another subgraph might turn out to answer a common question and remain online.
Usage can decide which datasets deserve to persist.
Writing the subgraph is only part of the problem
Generating a schema and mappings is relatively straightforward compared with deciding whether the result can be trusted.
Contracts do not always emit everything required to reconstruct their state. Historical queries may depend on contract calls as well as events. Proxy upgrades can change behavior halfway through the requested block range, and reorgs need to be handled correctly. A seemingly minor schema change can require a full historical reindex.
Backfill time matters as well. An agent asking a question that matters for the next ten minutes gains little from a dataset that takes six hours to build.
These problems already exist for developers building subgraphs by hand. Agent-generated deployments make them more important because there may be no engineer watching the job closely enough to catch a bad assumption.
The consequences also change when another automated system consumes the result.
Agent-created subgraphs therefore need strong checks around the generated code and the data produced from it. Indexing status, errors, chain progress, source contracts, and deployment versions all need to be available in forms software can interpret.
The agent also needs to know where the data came from
A result without provenance is difficult for an autonomous system to evaluate.
If an agent receives a figure for stablecoin inflows, it should be able to determine which contracts were indexed, which block range was covered, how current the index is, and which transformations were applied.
Provenance has to travel with the data.
For a generated subgraph, that could include the source chain, contract addresses, events processed, indexed block range, current indexing head, schema version, mapping version, and any external data used in the calculation.
Blockchain data on demand for agents
Subgraphs will continue to make sense when the data model is known and the same data needs to stay indexed over time. Protocol state, positions, transfers, pools, and other production datasets benefit from having that structure defined and continuously maintained.
The harder problem is what happens when an agent needs data that nobody prepared in advance.
At Ormi, we are working on blockchain data that can be requested on demand. Instead of requiring every dataset to exist before a task begins, an agent could ask for the data it needs, have the relevant contracts and history processed, and continue working from the result. If that dataset becomes useful beyond the original task, it can remain available rather than being rebuilt each time.
This does not replace subgraphs. It extends the same idea to workloads where the data requirement is discovered as the work happens.
Subgraphs give applications a durable, programmable view of blockchain data. On-demand data gives agents a way to create new views when the existing ones are not enough.
We are working on both, and there is more to come.
About Ormi
Ormi is the next-generation data layer for Web3, purpose-built for real-time, high-throughput applications like DeFi, gaming, wallets, and on-chain infrastructure. Its hybrid architecture ensures sub-30ms latency and up to 4,000 RPS for live subgraph indexing.
With 99.9% uptime and deployments across ecosystems representing $50B+ in TVL and $100B+ in annual transaction volume, Ormi is trusted to power the most demanding production environments without throttling or delay.