All Talk, No Task: How Far Is an Agent From Being a Participant?
For the last couple of years, whenever Web3 talks about AI, the conversation tends to land on wallets and payments. Boiled down, the thinking goes that once an agent has a wallet it can pay, and once it can pay it can take on work and get things done.
It makes sense. Finance and settlement are what Web3 does best, and when an industry runs into a new problem, it reaches first for whatever tool sits closest to hand.
There has been no shortage of building along that road. Coinbase built x402, Google built AP2, OpenAI and Stripe teamed up on ACP, and Stripe has MPP of its own. Mastercard has Agent Pay and Visa has Intelligent Commerce. AP2 launched in September 2025 and more than sixty organizations have integrated it since. This past May, AWS previewed agent payment capabilities that let an agent handle negotiation, authentication, stablecoin payment, and proof of delivery on its own.
| https://dune.com/hashed_official/x402-analytics |
By April 2026, x402 alone had cleared 165 million transactions, with 69,000 active agents behind them. But the same set of figures carries another number. Roughly half of that volume looks like testing rather than real commerce.
The wallets are there. The payment rails work. And agents still are not getting much actually done for anyone.
So at the roundtable in Ethereum Summer · Shanghai, when the question came up of what it would really take for an agent to participate, DDC cofounder and CTO Li Yingxuan pointed in the opposite direction. An agent's first step toward becoming a participant is not a wallet. It is authorized access to data.
He went on to say that moving an agent from answering questions to carrying out tasks comes down to three things.
Why data comes first
Ask an agent which camera suits you and it hands you an analysis. That's answering. Have it pick one within your budget and for your purposes, place the order, pay, and follow the shipment, and that's execution.
Getting an agent to do things for you breaks into two steps at minimum. Understanding first, then execution.
When it understands you, everything runs smoothly. When it doesn't, an agent with a hundred tools at its disposal still gives you the generic answer, and sometimes gets things wrong. That matters more than usual right now, given how much the industry wants agents sitting inside payment and settlement. If something goes wrong there, who covers it.
The AI side has already started building for this. A year ago the bottleneck in agent development was prompt engineering. By 2026 the work has moved to context engineering.
But more context is not better context. Mem0 published results this year from a benchmark that tests recall across multiple sessions. Packing everything into the context window gave 72.9% accuracy and burned roughly 26,000 tokens per query. A layered memory architecture that pulls only what's relevant scored 91.6% on the same test, using close to four times fewer tokens.
Stuff in more and the answers can get worse. What matters about context is not how much of it there is.
So what makes context the right context. Li Yingxuan offered four criteria at the roundtable. High quality, scenario-specific, continuously updated, and verifiable. An agent picking a product for you, scheduling your days, doing investment research, or managing your health needs data that meets all four. Miss one and the job doesn't get done.
The first two we covered in the previous piece, Personal Context Is the Scarcest Resource in the AI Era, and DDC Wants to Help You Distill It. What gets distilled is the traces you actually left, not the self-description you would write on a form, and that covers quality. You distill what your AI needs, and that covers the scenario.
Third is continuously updated. People's preferences shift, and a context from three months ago may not hold up for a decision you are making today. There are two ways to keep up. Either the tool watches in the background and updates in real time, or distilling gets light enough that you are willing to do it again every so often. Life Capsule takes the second route. It keeps version history, every save is a revision, and you can diff them, so it never gets stuck at one point in time.
Fourth is verifiable. The context you hand an agent, how does it know any of it is true. An order list might have been exported from a platform, or it might be something you typed up yourself, and the agent cannot tell the difference. Feeding false material into an agent's context already has a formal name on OWASP's list of agentic application risks this year. They call it memory poisoning.
Nobody has a working answer to this one yet. Someone scanned roughly two thousand MCP servers and not one of them had authentication. MCP only made OAuth 2.1 an option in 2026, and the W3C verifiable credentials work is still on the roadmap. Web3 has cryptography that would do the job. zkTLS can prove a piece of data really came from a given website without handing the data itself over. But it is mostly being used for identity and lending right now, and it has not connected to agents.
How far should permissions go
One of the questions at the roundtable was whether an agent can have a wallet and permissions. Li Yingxuan didn't answer it directly. He reframed it. The question is not whether an agent can own a wallet, but whether it can be granted permissions that are limited, revocable, and auditable.
As he sees it, an agent should not start out holding full control of your assets. The sensible approach is for a user or a company to hand it a clearly bounded set of permissions. Which data it can read, which tools it can call, how large a payment it can execute, what circumstances require human confirmation, when the authorization expires, and whether the user can revoke it at any time.
Following that logic, an agent doesn't need to own your data, but it can be authorized to reach part of it. It doesn't need to own a wallet, but it can call a wallet or a contract within set bounds. He compressed the whole design into four terms. Minimum authorization, revocable at any time, auditable in process, accountable in outcome.
| https://vitalik.eth.limo/general/2026/04/02/secure_llms.html |
Vitalik landed somewhere similar this April. In a blog post about his own local AI setup, his advice to teams building AI-connected wallet tools was that anything under a hundred dollars a day can skip human confirmation, and anything above that, or anything in a higher-risk category, needs a person to sign off. He called it a new kind of two-factor confirmation, where the model handles the routine small stuff and the human handles everything that crosses a line. The same post cited research finding that roughly 15% of agent skills carry malicious instructions.
There are working examples in China too. In March 2026, Taobao's desktop client shipped MCP support. Once a user authorizes it, the AI on their machine can search for products, compare prices, add to cart, place orders, and check order status. Payment still requires the user to confirm.
What happens when those boundaries aren't there? This year has supplied plenty of examples. A 2026 enterprise security survey found that 88% of organizations had a confirmed or suspected agent security incident in the past year. Among that same group, 82% of executives believed their existing policies were already enough to stop agents from overstepping.
In April, researchers found that Copilot Studio and Agentforce could be hijacked through crafted form submissions and document content, getting agents to bulk-forward CRM and SharePoint data to outside email addresses, with no cap on volume and nothing visible in the interface to indicate it was happening. Last November, ServiceNow's Now Assist had an incident where a low-privilege agent talked a higher-privilege one into exporting case files.
In none of these did the attacker steal a password or plant malicious code. They put a few sentences somewhere the agent would read them. Prompt injection still sits at the top of OWASP's risk list, and the research consensus is that it remains unsolved.
So permissions are not a step that gets skipped once agents get smart enough. They have to be settled before the agent does anything at all.
Who keeps the record, and who gets to check it
Once permissions are settled, one question remains. Who is keeping track of those rules, and who is able to check them.
Which part of your data an agent read, whether it went past the range you gave it, and who the value it produced should go to. On the traditional internet there are no answers to any of that. The same holds for today's AI that connects to your Gmail, your Notion, your cloud storage. You click authorize, and after that there is no record in your hands of how much it reads, how many times it reads, or what else it happened to see along the way.
So settling the rules is not enough. Something outside has to be keeping a record. That is the work a chain is for.
First, though, a misconception worth clearing up. Li Yingxuan put it plainly at the roundtable. Not all AI data needs to go on chain, and putting a model on chain is not what makes something AI plus Web3. What actually needs a chain comes down to four things, authorization, proof, settlement, and revenue distribution. Who authorized this data, what the agent called on, what value came out of it, and who that value should go to.
So the chain and the permissions are not two rules sitting side by side. Permissions decide what an agent can do. The chain writes that down so you and any third party can check it. Raw data doesn't need to go on chain. Authorization records, proofs of use, and the rules for distributing revenue are enough. In his words, what Ethereum gives an agent is an open environment for trust. Data can stay off chain and privacy can be protected, while authorization, proof, and settlement carry the credibility of being on chain.
Following that thinking, DDC has designed its own stack in four layers.
- Life Capsule is the user-facing entry point, holding the real digital traces: screenshots, screen recordings, orders, saved items, maps, calendars.
- Meta Memory Engine is the distilling layer, turning messy raw material into clear Markdown and context files through multimodal models.
- DDC Data Protocol is the authorization layer, governing how data gets authorized, how it gets revoked, how it gets audited, and what range an agent can reach.
- DataDance Chain is an on-chain base. It doesn't hold your raw data, only records of authorization, proof, calls, revenue distribution, and audit interfaces.
The point of this structure is not to move data onto a chain. The data stays on your side and privacy is protected, while authorization, proof, and settlement happen on chain so value can flow back.
Looking a step further out, Li Yingxuan expects a new kind of service node to emerge. The agent supplies the task capability, the user supplies authorized data, and the chain records authorization, calls, settlement, and distribution. At that point, an agent stops being a tool inside somebody's product and becomes an economic service node on an open network.
Authorization first, autonomy later
With those three things laid out, look at where agents actually are today. Most are still stuck on the first one. In Li Yingxuan's words, plenty of agents are just smart interfaces. They can answer questions, but they don't know the real user or the real business.
The way he sees it, the biggest risk is an agent using too much data and making too many decisions while the permissions around it are unclear. For individuals and companies alike, that breaks into three risks. Privacy leaks, permission abuse, and unclear responsibility. Which is why the conversation right now can't only be about what an agent is able to do. It also has to cover what it should not do.
That is why his read on the next year or two is fairly restrained. What lands first should be semi-autonomous execution under trusted authorization. A human authorizes, the agent executes, and only then does proof and settlement reach the chain.
The payment protocols are built. The wallets are there. What's missing sits earlier in the sequence: data an agent can read that still belongs to you, a set of permissions specific down to amounts and scope, and a record that you and any third party can check.
With those in place, an agent can start doing things for you. And talking about wallets at that point will make sense.
Labels: AI, AIAgent, ArtificialIntelligence, BehaviorData, data, Jarvis, PersonalAI, PersonalContext, SecondBrain, Web3








