Robinhood opened stock trading to AI Agents, Circle shipped its Agent Stack on USDC, Google pushed Gemini Spark into the consumer Gemini app, Elliptic raised $120 million to put agents on the compliance stack and Brussels set August 2 as the EU AI Act’s enforcement date. Five stories that shaped the AI Agent landscape this week.

1. Robinhood opens stock trading to AI Agents for 27M customers

Robinhood opened its platform to AI Agents on May 27, letting any of its 27 million funded customers create a separate Agentic Trading account, fund it with a fixed balance and hand execution to an AI Agent, such as one built on Claude or ChatGPT, that can read the portfolio, suggest investments and place stock trades on its own. The beta is equities-only at launch. Options, crypto, event contracts, futures and prediction markets are next. The brokerage paired the launch with an Agentic Credit Card for Robinhood Gold members, a virtual card that lets an AI Agent scan the web for items and authorise purchases when a user’s price threshold is met. Users see every trade in the app and can be required to approve previews before larger orders execute.

The implication is that a publicly listed brokerage just made an AI Agent a first-class user of its platform, not an experimental wrapper. Once one major broker does this, the rest follow. The agentic customer is no longer a category waiting to exist.

2. Google ships Gemini Spark and Project Mariner at I/O

Google used I/O on May 19 to push AI Agents into the consumer Gemini app. Gemini Spark is a new general-purpose AI Agent that reasons across information in connected apps, available first to Google AI Ultra subscribers and trusted testers. Project Mariner, the company’s web-browsing agent first previewed last year, shipped alongside it. Google also released Gemini 3.5 Flash at $1.50 per million input tokens and $9 per million output, roughly a third the price of comparable frontier models like Claude Opus 4.6 and GPT-5.5, and kept pushing the Agent2Agent protocol and the Gemini Enterprise Agent Platform announced at Cloud Next.

The shape of the week is that consumer AI Agents are now the headline product at the world’s biggest software vendors, sitting next to search and messaging on the home screen. Whatever happens at the protocol layer, AI Agents are being normalised on the surfaces hundreds of millions of users open every day.

3. Circle launches its Agent Stack and a stablecoin rail to match

Circle announced Circle Agent Stack on May 11, a set of services for autonomous agents to hold assets and transact in USDC across blockchains. The stack ships with Circle CLI, Agent Wallets, an Agent Marketplace and Nanopayments powered by Circle Gateway, the company’s cross-chain liquidity layer. Stablecoin payments at sub-cent unit economics settle on chain under an AI Agent’s own credentials, with no human signing in the loop.

This is the largest US stablecoin issuer building its own rails for AI Agents to use, paired with developer tooling that does not assume a human is the one paying. It pushes Circle into the same lane AWS staked out earlier this month with AgentCore Payments. Whichever provider’s primitives become the default for autonomous spending will sit underneath a meaningful share of next year’s agent commerce.

4. Elliptic raises $120M to put agents on the compliance stack

Blockchain analytics firm Elliptic raised $120 million on May 12 in a round led by One Peak, with Nasdaq Ventures and Deutsche Bank participating, valuing the London company at $670 million. CEO Simone Maini said the funds will accelerate an agentic product roadmap that builds AI Agents on top of Elliptic’s compliance dataset to automate work currently done by analysts.

The story is not the funding round, it is what the funding round buys. The job of a compliance analyst, parsing alerts, tracing flows, deciding whether a transaction is suspicious, is exactly the work AI Agents are being trained to do, and the AML and KYC vendors are racing to be the ones whose AI Agents the regulated industry actually hires. Compliance is one of several professional categories that will look structurally different by this time next year.

5. EU AI Act enforcement and Colorado’s SB 189 mark a governance split

Two regulatory clocks shifted this week. In Europe, the EU AI Act’s high-risk obligations activate on August 2, after which incident reporting, auto-log retention, human oversight tooling and impact assessments become legally binding for deployers of high-risk AI systems. In the US, Colorado’s AI Act enforcement was stayed as of May 23 pending the outcome of SB 189, which is expected to be signed in June with a revised scope and a new effective date.

The result is a split between hard EU deadlines and a US patchwork that keeps moving. For AI Agents in particular, both regimes lean on the same operational question, whether you can prove an AI Agent’s actions were authorised by someone who had the right to authorise them. As we wrote earlier today, that question is the part of the agent economy nobody can verify yet. The teams shipping AI Agent products in the next twelve months will hit these regimes whether they planned to or not.

This post is exploratory and does not represent a specific roadmap.

The hardest unsolved problem in the agent economy is not whether an AI Agent can act. It is whether anyone can prove it was allowed to. On May 4 an attacker moved roughly three billion DRB tokens, about 175,000 dollars, out of a wallet on Base by sending an AI Agent a single instruction, and every individual step in that chain carried a valid permission. SlowMist analysed the incident and named the failure mode permission chain abuse, which it defines as an attack where the output of one AI system is treated as trusted financial authorisation by another. No key was stolen and the authority was real. What was missing was any way to check whether that authority should have been used.

What AI Agent permission chain abuse means

The Grok attack is the cleanest example we have. The attacker first activated a Bankr Club membership on the wallet, a quiet and legitimate action that silently handed the trading bot Bankrbot its high-privilege toolset, including the ability to move funds. Then came a message to Grok written in Morse code, which slipped past the filters that only read plain text. Grok decoded it, tagged Bankrbot in a public reply, and Bankrbot treated that reply as a valid command and sent the tokens. SlowMist’s reading is that the root cause was not the prompt injection but the loose coupling between an AI output and the asset layer, because Bankrbot mapped Grok’s natural language straight into an executable instruction without checking where the instruction came from, whether the intent was real or whether a three billion token transfer fired off by a tweet looked anything like normal. Membership opened the permissions and nothing downstream ever re-checked them. That is the shape of permission chain abuse, where every link holds a credential that is valid on its own and the chain as a whole authorises something no human ever meant to approve.

Why authorisation is the layer nobody verifies

Most of the agent economy’s recent wins have been about payment. AI Agents can hold wallets, settle in stablecoins for a fraction of a cent and pay a counterparty with no human in the loop. Payment proves money moved. Authorisation is the harder question sitting underneath it, which is whether the AI Agent had the right to move that money, granted by whom, scoped to what and still valid at the moment it acted.

The identity world has noticed. NIST opened an AI Agent Standards Initiative in February that puts agent identity and authorisation at the centre, IETF drafts are pushing for delegation chains that are verifiable rather than merely asserted, and in March Ping Identity defined a runtime identity standard for autonomous agents. Newer token formats like Macaroons and Biscuits are built so a credential carries its own identity, expiry and cryptographic root, and any holder can add a layer that only narrows what the token permits and never widens it. The thinking is good. The catch is that almost all of it terminates inside one company’s identity provider, where the issuer and the verifier already trust each other. Surveys this year still find a large share of teams wiring agents together with shared API keys, and once several agents share one credential attribution is basically gone, because you can prove a call happened but not which agent made it or on whose authority.

What the open agent economy still needs

The gap opens the moment an AI Agent transacts with someone outside its own org. When Bankrbot acted on Grok’s reply, the two systems shared no authority model and no way for the second to ask the first to prove that the instruction it was relaying had ever been authorised by the wallet’s owner for that purpose. That is the normal condition of an open agent economy, where agents built by different teams on different stacks transact with counterparties they have never met. Internal token schemes do not cross that boundary, because a Macaroon is only as trustworthy as the issuer behind it, and a counterparty who shares nothing with that issuer has no reason to take its word.

What is missing is a delegation chain a stranger can verify. A record anchored somewhere neutral rather than inside the issuer, tying an action back through the AI Agent that performed it to the human or contract that authorised it, with the scope and the expiry still attached, so a counterparty can check the authority before honouring the action instead of finding out afterwards that a membership upgrade three steps back had quietly opened the door. Payment rails are already converging on shared standards that no single party owns. Authorisation has no equivalent yet, which is why an AI Agent can prove it paid you and still cannot prove it was ever allowed to.

Taiko is an Ethereum Layer 2 building neutral infrastructure for AI Agents. The question has moved past whether an AI Agent can act on its own. It is whether anyone else can verify the action was authorised, by someone who had the right to authorise it, before the money is gone.

This post is exploratory and does not represent a specific roadmap.

An AI Agent can be robbed the same way a person can, by being talked into it, and it has happened twice this month. On May 19 the AI trading platform Bankr locked down after an attacker reached fourteen of its wallets, in what SlowMist’s Yu Xian called an exploit of the trust layer between automated AI Agents. Two weeks earlier, an attacker had drained an AI Agent of up to 200,000 dollars by sending it a single tweet written in Morse code. No keys were stolen and no contracts were broken. AI Agents with wallets simply did what they were told.

How an AI Agent gets tricked into sending money

The Morse code attack shows the shape of it. The attacker had first activated a Bankr Club membership on the wallet tied to Grok’s account, which silently unlocked the trading bot Bankrbot’s high-privilege tools and the ability to move real funds. Then came a Morse code message that slipped past the filters that would have flagged plain text. Grok, built to be helpful, decoded it and tagged Bankrbot, which treated the reply as a valid command and sent three billion DRB tokens out on Base. Most of the money came back after negotiation, but the lesson held. Neither that attack nor the Bankr breach was a cryptographic flaw, just a trusted component doing exactly what it was asked by someone it should never have trusted.

Why trust is the agent economy’s real bottleneck

Paying is the part we have figured out. This May AWS shipped AgentCore Payments, built with Coinbase and Stripe, which lets an AI Agent settle a bill in stablecoins for a fraction of a cent on Coinbase’s x402 protocol, no human in the loop. That is the breakthrough and the problem at once, because an AI Agent that can pay in real time can be talked into paying in real time. Payment only asks whether an AI Agent can move money. Trust asks whether the move should happen at all, given who is asking, what the AI Agent is allowed to do and whether the instruction is really what it claims to be. That second layer is still mostly assumed, which is how a Morse code tweet and a quiet membership upgrade turned a helpful bot into a thief’s instrument.

Taiko is an Ethereum Layer 2 building neutral infrastructure for AI Agents. The question stopped being whether an AI Agent can pay. It became whether the rest of the network can trust what it just did.

This post is exploratory and does not represent a specific roadmap.

Your trading agent has had a rough fortnight. Slippage is running a few basis points higher than usual, it exited a position you would have held and rebalanced into a yield strategy you would not have picked. None of these calls are clearly wrong, and none of them clearly look right either.

Has the model drifted? Did the strategy hit a regime change? Did someone slip a poisoned instruction into the context window three weeks ago and the agent has been quietly executing it ever since?

In traditional software, this is not a hard question. When your auth service starts issuing tokens it should not, you check the logs, find the unauthorised call and trace the breach. The system has a defined correct behaviour, and deviation is detectable because correctness is observable.

AI Agents do not work like that. Their correct behaviour is a probability distribution rather than a fixed pattern, and two runs of the same prompt with the same data can produce different decisions that are both reasonable. A 3% worse outcome over a fortnight is statistically indistinguishable from variance, which means the signal you would use to detect compromise is the same signal the agent produces on a normal Tuesday.

Three failure modes, one symptom

When an AI Agent does something you did not want, the underlying cause is one of three things, and from the outside they look identical.

The first is a bug in the code wrapping the model, where the orchestration logic mishandled an edge case or the tool definition was wrong or a retry loop fired twice when it should have fired once. Classical software failure, hard to spot but well understood once you find it.

The second is a bad model output, where the agent reasoned through a real situation and produced a decision that turned out wrong. This is the cost of using a probabilistic system, and there is no bug or breach involved, the model made the call and the call was poor.

The third is compromise, which can surface in any of several ways: the system prompt was tampered with, a retrieval source was poisoned or a prompt injection landed three context windows ago and is shaping behaviour the agent does not experience as adversarial. The agent is doing exactly what it was told, and you do not know who told it.

All three produce the same observable, which is that the agent did something weird, and the detection problem becomes figuring out which of the three you are looking at, fast, with whatever logs you happened to have running.

The detection stack does not fit

The tools the industry has built for security all assume the system being defended has a stable shape. SIEM platforms watch for anomalies against a baseline, signature-based detection looks for known-bad patterns and behavioural analysis flags deviation from normal user activity.

AI Agents do not have a stable shape, because the baseline shifts every time the model is updated and the user activity is generated by a system designed to behave unpredictably within bounds. There is no signature for “decision that was 4% worse than ideal because someone fed it bad data three days ago.”

The most honest detection method right now is the dashboard a builder watches at 11pm wondering whether the slippage looks off, and that does not scale.

What detection actually needs

The shape of agent observability that would work is not mysterious, it is just not built yet, and the current stack is missing three things.

The first is verifiable execution traces. When an agent makes a decision, the trace should include not just the decision but the inputs it considered, the data sources it queried and the model version it ran, in a form another system can replay and check rather than a log file the agent wrote about itself.

The second is decision attestations. The agent should be able to prove what it considered, signed in a way that can be verified later, so that if a system prompt was tampered with the attestation chain shows the divergence, and if a retrieval source was poisoned the trace names which source and when.

The third is external reasoning logs. The agent’s reasoning should not be a black box the agent itself controls but should be externalised to a separate system that can be audited without trusting the agent’s self-report, because the agent that has been compromised will happily produce a clean log on request.

None of these exist in production today, which means the AI Agents being deployed right now are running without the observability layer that would let anyone detect compromise before the wallet is empty.

Until then

The honest answer to “how would you know your AI Agent was hacked” is that probably you would not, and probably not until after the fact. The detection paradigm we have assumes the system being watched is deterministic, and AI Agents are the first widely deployed software class where probabilistic decision-making is attached to autonomous action on systems that matter.

That is not a reason to stop deploying agents, it is a reason to build the observability layer in parallel, before the answer to “was that a bug or a breach” becomes a question with eight zeros on it.

This post is exploratory and does not represent a specific roadmap.

Most “Why AI?” answers are productivity slideware: save 40 minutes a day, cut errors, replace headcount. All true, and all a third of the actual question.

The real question splits in two: how do we make the current operation work harder and faster, and how do we open revenue surfaces that did not exist before? Both halves are moving at once, and most companies are running the first play while telling themselves they ran the second.

What’s actually new sits under the second half. Every software era before this had a clean separation between who bought software and who sold it. A human bought a CRM. A company bought a database. They used the software to do work and then converted that work back into human-to-human transactions before any money moved. Agents collapse that loop. They are the first software customers that can also be merchants, transacting directly with other agents they have never met, with no shared contract and no Stripe account between them. That is a structural change, not a feature, and it is what makes the AI stack and the blockchain stack the same stack.

The Run Better levers are well-rehearsed, but the compounding across them is larger than most boards have priced in. Goldman and OpenAI put time recovered at 40 to 60 minutes per worker per day, which is a full week back for a 100-person team every week. Errors drop sharply in repeatable workflows, and each prevented mistake is margin that wasn’t there before. The WEF’s 2025 jobs report has 41% of employers globally planning AI-tied workforce reductions inside five years. The polite version is “redeployment.” The honest version is structural. And 24/7 throughput with the same team serving more customers is the part incumbents are racing on, because customers notice the difference inside a quarter.

All real, and all the floor. Run Better assumes the same business model you already have, just with cheaper inputs. Stop here and you have built a leaner version of yesterday’s company.

Build new

The second half is where the model itself shifts, and where the customer-as-merchant collapse plays out in practice.

AI-native UX. The product behaves rather than waits, predicting, suggesting and executing on the user’s behalf. Cursor rewrote what coding software looks like by collapsing the loop between intent and output. Devin pitched itself not as a tool for developers but as a developer. Static SaaS dashboards are the new on-prem.

Revenue surfaces. Outcomes replace tools. Intercom Fin charges by resolved ticket. Sierra by handled conversation. Harvey by completed legal work. The pricing is not a packaging choice. It is an admission that the customer was never buying software, only ever buying the thing the software produced. And once the customer of that outcome is itself another agent, the entire contracting model breaks.

Agent payments. Stripe and ACH were built for humans: phone numbers, chargebacks, shared business relationships. Agents have none of that. They cannot open bank accounts; they hold crypto wallets, transact in stablecoins and settle in real time without a human in the loop. When two agents from different organisations need to transact instantly, permissionless settlement is the only architecture that works. Public chains have had this from day one, and Layer 2s like Taiko have driven cost to fractions of a cent. Protocols like x402 hint at what these rails look like in practice. The infrastructure is being laid faster than most enterprises realise.

Tokenization x AI. Once agents can settle directly with each other, the capital they hold becomes the next question. Real-world asset tokenisation grew 240% year-on-year through 2025 to 2026, with BlackRock’s BUIDL and Ondo’s tokenised treasuries setting the early shape of the market. The pipes are getting built. What rides on them is software that owns money, settles its own deals and pays its own counterparties.

The half of the map that gets called speculative is the half where the structural shift is actually happening.

Service-as-a-Software

The footer of the map carries the punchline. For 20 years software modelled itself on services, with SaaS selling tools that humans used. The agent shift inverts the arrangement entirely. Software does the service. Software is the worker. Software is the buyer. Software is the seller. The unit of value is no longer a seat, and the unit of transaction is no longer human-to-human.

And underneath all of this sits a quieter truth. The biggest line in a traditional SaaS budget was never the licence. It was the people hired to make the licence work: the operators, analysts and customer success teams who configured, watched, interpreted and escalated on behalf of the software. That cost line is what the agent shift compresses. The largest expense of yesterday’s software is the one that disappears first.

You can run both plays at once. Most companies will run the first and quietly call it the second.

Three questions

Put these to your team this quarter.

Where in the operation are we still paying hours-for-dollars for repeatable work? That is a Run Better play with the ROI math already done.

What does our product do that an agent could do better? “Most of it” means the moat is gone. “None of it” means you have not looked hard enough.

What happens to our business when a portion of our customers are agents, and that agent’s customer is another agent? If you cannot answer that question with the rails you have today, you have your answer about which rails you need.

Agents are not a faster kind of user. They are a new economic actor that is simultaneously customer and merchant, transacting on rails that did not exist for any prior buyer of software. The companies that win this decade are the ones building for that actor.

This post is exploratory and does not represent a specific roadmap.

Anthropic announced a few things yesterday that read, on the surface, like a developer tools update. They doubled the 5-hour usage limits for Claude Code on Pro, Max, Team and seat-based Enterprise plans. They removed peak hour throttling for Pro and Max. And they substantially raised API rate limits for Opus models. The reason given: a new partnership with SpaceX that adds compute capacity, on top of other recent deals.

If you’re a Claude Code user, this is good news. If you’re paying attention to AI Agents, it’s a tell.

Chat is cheap. Agents are not

A chat session burns a few thousand tokens. An AI Agent doing real work burns orders of magnitude more. Multi-step reasoning, tool use, retrieval, code execution, retries, self-correction loops. Every step is a model call. The reason most agent demos feel impressive in clips and brittle in production isn’t model quality. It’s throughput. Models are smart enough. The infrastructure underneath them isn’t fast or cheap or reliable enough yet to run them continuously.

Doubling Claude Code’s 5-hour windows is an admission that developers using it as an AI Agent were hitting walls. Removing peak hour throttling means Anthropic believes its compute supply has caught up. Raising Opus rate limits means the model teams actually want to point at hard problems can finally be pointed at hard problems for longer.

What the SpaceX deal signals

Frontier labs don’t sign compute deals to support more chat traffic. Chat scales fine. They sign them because they expect usage to grow in a way that breaks current capacity. The bottleneck for the next phase of AI isn’t IQ. It’s whether you can run a fleet of Agents continuously without rate-limiting them into uselessness.

What this means for onchain Agents

Onchain Agents inherit every constraint a cloud-native Agent has, plus a few of their own. Gas costs. Block latency. Onchain state read freshly, every call. An Agent that pings an LLM ten times to decide whether to rebalance a vault pays twice: once for inference, once for the transaction it eventually fires. The cheaper Anthropic makes Claude calls, the more economically viable it becomes to run an Agent that actually does things onchain.

Read it as a forecast

When a frontier lab raises limits and signs a compute deal in the same week, the message isn’t “we have surplus.” It’s “we expect demand to keep climbing past what we just added.” That demand is Agents. The bottleneck people will be talking about in twelve months won’t be model capability. It’ll be how much continuous Agent compute any platform can actually deliver.

The limits went up yesterday. They’ll need to keep going up.

This post is exploratory and does not represent a specific roadmap.

On April 19, Vercel confirmed a security breach that started somewhere most companies do not audit: a third-party AI tool one of their employees had given OAuth access to. The attack chain is the important part. A Context.ai employee was infected with Lumma Stealer malware in February, attackers rode that compromise into Context.ai’s infrastructure, then used its OAuth grants to pivot into the Vercel employee’s Google Workspace, then into Vercel’s internal systems, where they enumerated and decrypted non-sensitive environment variables.

The stolen data is now for sale on BreachForums for $2 million. In the aftermath, crypto developers are scrambling to rotate API keys because a non-trivial slice of Web3 infrastructure ships through Vercel.

This is an AI Agent security story, even though no AI Agents were involved in the breach.

AI tools are identities with access, not helpers

The lesson of the Vercel breach is structural. Trend Micro called it an OAuth supply chain attack and the framing matters. An AI tool accumulated broad OAuth access across a company’s workspace. Nobody audited what that tool could do on behalf of the employee. When the tool’s vendor got breached, the permissions became an open door into everything the employee could reach.

AI tools in your stack are not sandboxed helpers. They are identities with access, and they participate in every permission they have been granted. This is true today for the ChatGPT connectors and Claude integrations and Context.ai style tools your team has quietly added this year. It will be more true, by a lot, once autonomous AI Agents are added to the same environments.

The question the Vercel breach asks is not how to stop Lumma Stealer or even how to vet AI vendors better. It is a deeper question about identity. Which tools can take which actions on whose behalf, who audits this, who rotates it, who revokes it when a vendor gets compromised. The Vercel incident answered these questions at $2 million. The AI Agent version of the same question will answer at multiples of that.

KelpDAO: the same failure mode, in DeFi

A day before Vercel, DeFi had its own trust failure at scale. On April 18, attackers drained 116,500 rsETH worth roughly $292 million from KelpDAO through a LayerZero bridge, the largest DeFi exploit of 2026 to date. Attackers compromised two RPC nodes that LayerZero’s verifier relied on, forced a failover with a DDoS and tricked the verifier into approving a fraudulent cross-chain transaction. LayerZero has attributed the attack to North Korea’s Lazarus Group, specifically the TraderTraitor subgroup.

The interesting part is not the exploit, it is the aftermath. Aave froze rsETH markets. Arbitrum’s Security Council froze $71 million of attacker-linked ETH. The hacker has already moved $175 million to Bitcoin via THORChain, a route that makes clawback nearly impossible. KelpDAO and LayerZero are now publicly disputing who is to blame, with Kelp pointing to LayerZero’s default configuration and LayerZero pointing to Kelp’s single-verifier setup.

In a pipeline of protocols, bridges and validators, nobody has the tooling to prove whose fault it was. $292 million moved, attribution is contested and the industry has no shared mechanism to resolve who owes what to whom. Which is exactly the trust problem we wrote about last week: coordination between systems that cannot verify each other, with no shared layer for attribution when coordination fails.

Different surface, same failure mode.

What AI Agents will inherit

Neither of these exploits involved an autonomous AI Agent taking action on its own. A person clicked a thing, a bridge trusted the wrong node, a vendor got compromised. Standard security failures in a world full of standard software.

AI Agents are about to be added to this environment, not deployed on a fresh canvas. The surface they will operate on is the one Vercel and KelpDAO just described. Tools that silently accumulate identity and access. Protocols that cannot verify each other. Coordination layers where accountability falls through the gaps when something goes wrong.

When a single autonomous agent manages a wallet, the blast radius is manageable. When two agents coordinate to execute a multi-step strategy across protocols, or when an agent fleet operates inside a company’s workspace with broad OAuth grants, the load-bearing questions surface at once. How does Agent A know Agent B is competent. How does anyone verify what actually happened. Who is accountable when it goes wrong.

These are not future problems. They are the problems that cost $292 million in DeFi last weekend and are being priced at $2 million on BreachForums this week.

What needs to be true next

The primitives are not new, they are just not built yet in a form that works for agents. Verifiable execution: when a tool or a protocol completes a task, it should produce a cryptographic attestation of what it did, what data it used and what it considered. Reputation that is earned and decayable, not claimed by the vendor. Coordination protocols that define what was requested, what constitutes success and what happens on failure, before the action runs. Scoped, auditable permissions for every tool in the stack, human or agent, because OAuth grants that look reasonable in isolation quietly add up to a supply chain attack.

None of this is speculative. It is the infrastructure being built right now by teams thinking seriously about multi-agent DeFi and multi-tool software. This week’s breaches make the absence of it easier to see.

This post is exploratory and does not represent a specific roadmap.

An AI Agent making a single swap decision has to pull five categories of data (price, liquidity, gas, protocol risk and cross-chain routing) from five different sources, each with its own failure mode. The agent’s reliability ends up capped by whichever feed in that stack is having the worst day.

AI Agents need oracles. The oracles that exist today weren’t built for them, and the mismatch is where a lot of current agent reliability problems quietly start.

Start with what the agent is actually doing

An AI Agent wants to swap 10 ETH for USDC. A human would open a DEX, glance at the price and hit swap. The agent can’t eyeball a chart, so it has to reason about the trade programmatically, which means pulling in data from more sources and with higher reliability than most of those sources currently provide.

Before the agent submits a single transaction, it has to work through a short list of questions, and each one is really a data problem in disguise.

The first is price. Not the price five minutes ago or the price on one exchange, but a real-time multi-source price with a confidence signal attached. The agent has to know whether the number is reliable, whether it’s stale and whether it’s being manipulated. A human trader develops intuition for this kind of thing over years; an agent needs structured inputs that express the same judgement numerically.

Then there’s liquidity depth. The spot price is meaningless without knowing whether 10 ETH will actually fill at that price, so the agent needs order book or liquidity pool data to estimate slippage. On AMMs that means reading the pool’s reserves and fee tier; on aggregators it means comparing routes. This data lives across DEX subgraphs, pool contracts and aggregator APIs, all with different formats and refresh rates.

Gas is the next problem, and it goes well beyond “what’s the current base fee”. The agent has to predict what gas will actually cost when the transaction lands, account for the complexity of the swap route (a multi-hop swap through three pools costs more than a direct pair) and decide whether the trade is still worth executing after fees. On L2s the estimate also has to include the L1 data posting cost.

Protocol safety is the question most agents skip, and it’s the one that burns them. Has the protocol been exploited recently? Is there unusual activity in the pool? Are governance proposals pending that might affect the contract? Protocol risk isn’t a static score; it changes by the hour.

Finally there’s the cross-chain picture. If the best price is on a different chain, the agent needs bridging data: bridge fees, transfer times and destination chain gas costs. At that point the agent isn’t just making a swap decision any more, it’s making a routing decision across chains, and the data inputs multiply accordingly.

That’s five data categories at minimum, each one a decision input that has to come from somewhere reliable.

What oracles were built to do

Oracles exist because smart contracts can’t read the outside world on their own. A lending protocol needs to know the price of ETH to calculate collateral ratios. A perps exchange needs the price of BTC to trigger liquidations. Since these contracts live on-chain, they need a trusted way to get external data pushed in.

Chainlink, Pyth and similar networks solved that problem. They aggregate price data from multiple sources, push it on-chain at fixed intervals or on demand and let smart contracts consume it in a standardised format. It’s a narrow and well-done job: get a reliable price feed to a contract at execution time, without introducing a single trusted party.

That’s useful work, but it isn’t what an AI Agent needs.

Where the mismatch shows up

Smart contracts consume oracle data at execution. The price feed is read inside a transaction, used in a calculation and written to state; the contract doesn’t need context, only a number.

Agents work the other way around. They consume data before execution, while they’re still deciding whether to execute at all and on what terms. That shifts what the data layer needs to provide in a few concrete ways.

The first is breadth. Price alone isn’t enough when liquidity depth, slippage, gas, protocol risk and cross-chain routing all matter to the decision, so an oracle that only delivers prices covers maybe a fifth of the decision surface.

The second is freshness on demand. Periodic on-chain updates work fine for a lending protocol that only needs to liquidate when a price crosses a threshold, but an agent evaluating a live trade needs sub-second freshness on the exact inputs it’s reasoning about right now.

The third is confidence signals. A smart contract is happy with a number, but an agent wants the number alongside a read on how much to trust it: is this price from three sources or one, how divergent are they and what’s the confidence interval.

The fourth is queryable structure. Oracle price feeds are push-based and fixed-format, whereas an agent’s queries are dynamic. “What’s the deepest liquidity for this pair across these five venues right now, and what would a 10 ETH fill look like?” isn’t a feed you can subscribe to; it’s a query you have to be able to answer.

None of this is a criticism of existing oracles, which do the job they were designed to do. The point is that agents have shown up as a new kind of user with a different problem, and the infrastructure hasn’t caught up yet.

What agents do today instead

The current answer is cobbling. Every agent stitches together CoinGecko for price, DEX subgraphs for liquidity, RPC calls for gas, a handful of scattered dashboards for protocol risk and bridge aggregators like LiFi or Across for cross-chain data, with each pipeline inheriting its own set of failure modes.

For a hackathon demo that’s fine. For an agent managing real capital it becomes a ticking problem. An API that rate-limits at the wrong moment leaves the agent flying blind on risk for a live decision. A lagging feed puts it into a trade at a price that no longer exists by the time the transaction lands. A format change upstream can break the pipeline silently while the agent keeps executing, and silent failures are the hardest ones to catch.

The underlying problem isn’t that agents lack data. It’s that they have fragmented data they’re forced to treat as equivalent, with no structural way to know when any given input has quietly gone bad.

What an agent-native oracle looks like

If you work backwards from the agent’s decision, an oracle designed for agents would have to deliver a full decision context rather than a single datapoint. That means multi-domain data in one layer covering price, liquidity, gas, risk and routing, pull-based queries alongside (or instead of) push-based feeds, confidence scores attached to every value, freshness guarantees that match the agent’s decision cadence rather than the contract’s settlement cadence, and a query interface that treats the agent as the primary consumer rather than a smart contract.

What you end up describing is a different primitive. It borrows from oracles in that it has to be trusted, verifiable and multi-source, and from data APIs in that it has to be flexible, queryable and structured, but it doesn’t map cleanly onto either category. Whether the industry ends up calling it an agent-native data layer or an oracle for agents matters less than whether someone actually builds it.

The bottom line

AI Agents do need oracles. The ones we have today serve smart contracts well and agents poorly, because agents are a different kind of user with different requirements around breadth, freshness, confidence and queryability.

That gap is going to close, and the infrastructure that closes it will look less like faster price feeds and more like a purpose-built data layer for agent decision-making. As agents move from toy demos to managing serious capital, the gap stops being a nice-to-have and starts being the ceiling on what agents can actually do reliably.

This post is exploratory and does not represent a specific roadmap.

Crypto’s first AI millionaire didn’t pitch anyone, didn’t raise a round and didn’t have a team. It was a bot called Truth Terminal, built by researcher Andy Ayrey in mid-2024 to do one thing: shitpost on X. After months of unhinged posting it convinced Marc Andreessen to wire it $50,000, rode that clout to pump a meme coin called $GOAT to nearly a $1 billion market cap, and became the proof of concept nobody asked for but everyone noticed. If an autonomous program could hold a wallet, build a following and move that kind of capital without permission, then what were we all still doing manually?

That question broke the industry’s brain. What followed was 18 months of chaos: a $20 billion bubble, a 75% wipeout and, underneath the wreckage, something that might actually matter.

The Mania

The speed was absurd even by crypto standards. Within weeks of Truth Terminal’s run, Virtuals Protocol ditched its AI gaming roadmap, went all in on agents and launched 11,000 of them on its way to a $4.5 billion token valuation. Shaw Walters shipped ElizaOS, an open-source TypeScript framework (originally called “ai16z” until the actual a16z told him to knock it off) that let developers plug in an LLM, connect a wallet and deploy an autonomous agent in minutes. It became the WordPress of the space and attracted thousands of builders overnight.

Then AIXBT showed up, an AI Agent that scraped the takes of 400+ crypto influencers, synthesized them into original market analysis and posted it straight to X. It grew to 400,000 followers in under three months, hit a market cap near $800 million and for a brief, surreal window became the most influential voice on Crypto Twitter, commanding 3% of total mindshare according to Kaito AI. Not a person, not a fund. A bot with better takes than the people it was monitoring.

By mid-January 2025 the sector had ballooned from zero to $20 billion across more than 140,000 wallets. The thesis was intoxicating: autonomous programs that trade, tweet, govern and print revenue with no humans required. You can probably guess what happened next.

The Flush

The TRUMP meme token launched in January 2025 and vacuumed $4 billion in liquidity out of the market in about 48 hours, crashing AI Agent trading volume by 62% on day one. But TRUMP was the trigger, not the cause. The real problem was structural: almost none of these projects did anything useful. The entire DeFAI category (AI-powered DeFi, catchy name) was delivering returns 3-5% better than doing it yourself, a rounding error dressed up as a revolution. Impressive demos, hollow production, billion-dollar valuations hanging on vibes.

The correction was violent. Total market cap fell 67% in under a month, from $20.2 billion to $6.52 billion. Over the full year $53 billion evaporated. FARTCOIN (yes) dropped 80%, Virtuals lost 77%, AIXBT collapsed 93% from its January peak. Predictions that 99% of AI Agent projects would die turned out to be directionally correct.

The punchline that kept circulating: we created AI that could trade crypto, and the AI lost money just like the rest of us.

What Survived

Most people stopped paying attention after the crash. That’s when it got interesting.

While the token graveyard expanded, the infrastructure layer was quietly compounding. By Q1 2026, more than 68% of new DeFi protocols launched with at least one autonomous AI Agent handling trading or liquidity management, not as a gimmick but as a core component. Daily active onchain agents crossed 250,000, up over 400% from the prior year. The agents survived. The tokens mostly didn’t.

ElizaOS shipped its v2 at CATSTANBUL 2025 with a rebuilt architecture, real planning capabilities and a unified wallet system, then transitioned to a cross-chain token on Chainlink CCIP to position itself as a coordination layer across Ethereum and its L2s, including agent-focused chains like Taiko. The Model Context Protocol (MCP) became the connective tissue letting agents interface with external tools, plan multi-step actions and retry when things break. Boring infrastructure work, but it’s the reason agents actually function now instead of just looking good in demos.

The DeFAI shift from vaporware to live capital is now measurable. Over 1,500 traders have deposited $6.1 million into AI Agent wallets on platforms like DX Terminal Pro, with agents trading 24/7 in Uniswap V4 pools on real ETH with no human in the loop. Ant Group’s blockchain arm launched Anvita for agents to hold assets and execute payments independently, Solana reported 15 million onchain agent transactions and Brian Armstrong said he expects agents to surpass humans in transaction volume. Whether that last part is prediction or marketing is debatable. The direction isn’t.

During the March 2026 market dip, the Grayscale Crypto Sectors Report captured something telling: while nearly 90% of crypto assets went red, the AI sector dropped only 14% against a 21% fall for Smart Contract Platforms. Capital isn’t chasing “AI Agent” as a narrative anymore. It’s pricing in live utility through decentralized compute, autonomous execution and actual GPU demand from a world that can’t build enough of them.

The Part Everyone’s Ignoring

There’s a version of this story that skips the uncomfortable bit and ends on an optimistic note about infrastructure maturity. This isn’t that version.

In 2026, protocol-level weaknesses in AI Agent systems triggered over $45 million in security incidents. The vulnerabilities weren’t in trading logic but in the memory and execution layers that govern how agents remember context, reason and act. Nearly half of development teams (45.6%) were running agents on shared API keys, meaning once one went rogue or got compromised there was no way to isolate the damage.

It gets worse. Research from 2025 tested AI models against 405 known blockchain exploit scenarios and they produced working exploits for 207 of them, representing $550 million in simulated theft. Ledger’s CTO warned in April 2026 that AI is collapsing the cost of cyberattacks on crypto, compressing months of skilled research into seconds with the right prompt. The central tension remains unresolved: for an AI Agent to be useful in DeFi it needs private key access and execution authority, which is exactly what makes it the most attractive attack surface in an irreversible financial system. The industry is building faster than it’s securing, and the stakes are different when the programs holding the keys don’t sleep and execute at machine speed.

The Honest Read

AI Agents in crypto followed the exact arc crypto always follows: impossible hype, devastating correction, quiet rebuild. The shitposting-bot-to-millionaire phase is done and the “agent with a token and a Twitter account” playbook peaked January 2025.

What replaced it is less viral and more real. Autonomous programs managing actual capital across protocols, 250,000 daily active agents, two thirds of new DeFi protocols shipping with agent components baked in. McKinsey projects AI Agents could mediate $3-5 trillion in global commerce by 2030, and in crypto they’re already managing meaningful TVL. The question was never whether agents would matter. It’s whether the trust layer can scale as fast as the execution layer.

The sector that started with a shitposting bot hustling a billionaire for $50K is now processing millions of transactions a day. That arc from absurd to consequential is either the most crypto thing that’s ever happened or proof that something fundamental has shifted. Probably both.

This post is exploratory and does not represent a specific roadmap.

Blockchains were designed for human users and governance still reflects that. But a growing share of on-chain activity is already driven by automated systems like market makers, liquidators, arbitrage bots and routing infrastructure. These systems interact with networks directly, optimising for cost, latency, reliability and privacy in real time, and their activity exposes where infrastructure works well and where friction remains.

As automated actors take on more operational responsibility, a gap is opening between how infrastructure is used and how it is evolving.

One way to think about this is through Decentralised Agentic Autonomous Organisations (DAAOs). Rather than governance structures composed of human participants only, DAAOs would function as coordination layers where Agents interacting directly with infrastructure surface bottlenecks, suggest improvements and help inform how systems change over time.

These Agents operate continuously across networks, observing execution conditions, routing constraints and performance trade-offs as they occur. Operational feedback emerges directly from usage rather than relying on periodic human proposals or discussion.

In this model humans handle oversight and safeguards, while operational insight comes from the systems actually using the network day to day.

Recent research supports the technical feasibility of this direction. Work from Cornell University has explored Agents participating in proposal analysis and voting (DAO-AI, arXiv:2510.21117), and other research proposes decision-structuring frameworks for AI-assisted governance (QOC DAO, arXiv:2511.08641). DAO-Agent (arXiv:2512.20973) goes further, proposing multi-agent coordination architectures with verifiable incentive mechanisms. These efforts largely focus on adding AI layers to existing DAOs. DAAOs explore a different angle: how infrastructure itself becomes adaptive when its primary operational users are Agents.

Autonomous systems favour environments that support their execution needs or demonstrate an ability to adapt as those needs change. Infrastructure that responds quickly to real usage is more likely to attract Agent activity. Where requirements across Agents cannot be reconciled, sufficiently advanced systems may even propose differentiated infrastructure stacks rather than force a single solution.

This approach comes with obvious challenges. Coordination problems, spam and bad actors could all make systems unstable, and any system shaped by Agents would still need strong safeguards to remain stable over time.

The gap between who builds blockchain infrastructure and who actually uses it is already widening. DAAOs are one framework for closing it, if the design challenges can be solved.

This post is exploratory and does not represent a specific roadmap.