The machine-native economy
Visual briefingSlide 1 of 9: The big picture
Jump to a slide
Sources & editorial notes
Read with context.
The Machine-Native Economy: How digital assets connect intelligence, commerce, and compute. BlackRock Digital Assets Research, September 2026. Will Su, Robert Mitchnick, Jay Jacobs, William Helm.
An independent visual summary prepared with AI assistance. No affiliation with or endorsement by BlackRock is implied.
The final chapter is Routercore’s interpretation. The report’s forecasts are possibilities, not established outcomes.
Agentic payments and liquid compute markets remain emerging. Traditional payment systems also support automation; digital assets are not a requirement for all AI commerce.
The diagrams simplify mechanisms to explain the concepts. They are not implementation specifications or demonstrations of Routercore capabilities.
Read the full text
Three layers. One task.
An agent needs intelligence to plan, services to act, and compute to run. These are different parts of the same system.
Model execution. Computing infrastructure runs the model that supports the agent.
Service request. The agent asks an external service to perform part of the task.
Result. The service returns a result for the agent to use.
The report explores how these layers could become more connected. This is an emerging direction, not an inevitable outcome.
First, define the task.
Imagine asking an agent to arrange a trip within a $2,500 budget. The goal and constraints travel together.
Trip + $2,500 limit. The person provides the objective and a spending constraint.
Proposed plan. The agent can present its plan. Approval requirements are an application design choice.
A spending limit is part of the instruction. A real system still needs a mechanism that enforces it.
The agent asks a tool.
MCP provides a way to connect an AI application with tools and context. Think of looking up information before making a decision.
Tool request · MCP. The application sends a request to an available tool.
Tool result. The tool returns data or a result. The application decides how it may be used.
Connecting a tool does not grant unrestricted permission to use it.
One agent can ask another.
A specialist can handle a bounded part of the task. Agent-to-agent coordination connects their work.
Scoped task · A2A. The planning agent gives the specialist a specific piece of work.
Subtask result. The specialist returns its result to the planning agent.
Delegation needs a defined scope, a responsible owner, and a traceable result.
Sometimes, the data has a price.
An x402 flow can let software pay for an HTTP resource. This simplified exchange shows the request and response sequence.
1 · Request resource. The agent requests a resource from the API.
2 · Payment required. The API returns payment requirements using HTTP 402.
3 · Payment payload. The client retries with payment authorization or proof, according to the supported scheme.
4 · Paid response. After the required verification and settlement steps, the service returns the resource. Those payment services are omitted from this simplified view.
This is one possible paid-resource mechanism. It does not mean every AI request needs a digital-asset payment.
An agent can reach a checkout.
An agentic checkout connects to merchant systems. Conventional payment infrastructure can still process the purchase.
Checkout request · ACP. The agent interacts with the merchant checkout through an agentic commerce interface.
Authorized payment. The merchant uses its payment infrastructure to process an authorized purchase.
Confirmation. The merchant returns the outcome. ACP does not imply a particular settlement network.
Agent-to-merchant coordination and payment settlement are separate responsibilities.
Close the loop with the person.
A completed task needs an understandable outcome: what happened, what it cost, and what still needs attention.
Outcome + spending record. The agent reports the task outcome and its associated spending.
A useful enterprise record connects actions, approvals and costs. This is our practical interpretation of the travel example.
Every action uses infrastructure.
The application calls a model. Computing capacity runs that model. The answer returns to the application.
Inference request. The application sends input to a model service.
Execution. The underlying computing infrastructure executes the workload.
Model response. The service returns the model output. This schematic omits internal infrastructure details.
The report also explores more standardized compute contracts. Hardware, region and performance make that an emerging proposition.
A rule needs a place to act.
Consider a request that would exceed its approved budget. A policy check should stop it before a service is called.
Request for approval. The proposed action reaches the policy decision point.
Blocked before execution. The action violates the approved limit. The flow stops here; no downstream call is made.
This is a recommended enterprise design, not a claim that the protocols above automatically enforce budgets.