In the previous article, "What Are Some Good Paths for Chinese Web3 Entrepreneurship? (Part 4)", Portal Labs first discussed how three types of Web3 teams, more focused on infrastructure, could migrate their capabilities towards the AI direction.
Data-oriented teams can look at the AI data layer, solving problems like authorized data, verifiable data, and compliant data calls. Identity and account teams can look at Agent permissions, accounts, and execution records. Payment and wallet teams can look at Agent automatic settlement, API micropayments, and accounting audits. These three paths share a common point: they all leverage the infrastructure capabilities that Web3 has accumulated over the past few years, placing them into the emerging new demands of AI Agents.
However, the directions Chinese Web3 teams can migrate to are not limited to data, identity, and payments. Two other types of teams are also worth examining separately.
One type is security and risk control teams. In the past, they served contract, wallet, fund flow, and on-chain risks. In the AI Agent stage, new security issues will appear in permissions, tool calls, automatic payments, data access, and execution records. The more an Agent can do for users, the more it needs someone to set boundaries, check for anomalies, and keep records.
The other type is application-layer and community-oriented teams. They may not need to transform into AI infrastructure companies, but they can integrate AI into their original product and operational workflows to enhance the efficiency of investment research, content, customer service, community management, education, and user conversion. For such teams, AI is more like a layer of capability enhancement, not a complete career change.
Therefore, this article will continue the logic from the previous one: how should security and risk control teams, and application-layer and community-oriented teams, respectively, migrate towards AI.
At the same time, Portal Labs also needs to clarify another matter. Not all AI directions are suitable for Chinese Web3 teams to enter. Some directions may seem hot, like general large language models, general Agent platforms, AI traders, and automated yield products, but in reality, they have high barriers, fierce competition, and may even encounter very sensitive compliance boundaries.
Whether a migration is possible shouldn't be judged solely by how hot AI is. What's more important is what capabilities the team originally possessed, whether those capabilities can be placed in real scenarios, and whether a clear paying party can be found.
Security and Risk Control Teams: From On-Chain Security to Agent Behavior Auditing
Security and risk control has always been a direction within Chinese Web3 teams that can better weather market cycles.
Regardless of market heat, Web3 projects need smart contract audits before launch, wallets need anti-theft measures, fund flows need monitoring, attack incidents need tracing, and KYT (Know Your Transaction) and AML (Anti-Money Laundering) tools always have demand. Many security teams survived on these practical needs.
In the past, such teams mainly focused on smart contract vulnerabilities, private key risks, wallet security, on-chain attacks, fund flows, and suspicious transactions. As AI Agents develop, security concerns will expand from on-chain assets to broader automated behaviors.
Because Agents will no longer just answer questions; they will begin to call tools, access data, execute processes, and even trigger payments and on-chain operations.
For example, a company integrates an AI Agent into its CRM, email, contract repository, internal knowledge base, and ticketing system, using it to organize customer information, generate meeting minutes, draft reply emails, query contract terms, and even automatically create tasks and follow up with clients. This scenario seems focused on improving efficiency, but behind it lies extensive permissions and data flows. Can the Agent read all customer data? Can it send contract content to external tools? Can it access employee emails? Can it automatically send emails to clients? If prompted or attacked, could it leak internal information?
These will become new security issues.
If companies start using AI workflows on a large scale, security needs will extend from model security to behavior security. Companies won't only care if the model's answer is correct; they will also care about what the Agent did, which system it called, which files it accessed, who it transmitted data to, and whether it complied with internal permissions and regulatory requirements.
This is precisely the direction security and risk control teams can migrate to.
Teams that previously worked on on-chain monitoring, auditing, risk control, and fund tracking can migrate their capabilities to Agent behavior auditing, permission anomaly detection, data call monitoring, automatic payment risk control, and enterprise AI security governance.
For instance, providing enterprises with Agent operation logs, making every tool call traceable; setting permission boundaries for AI workflows to prevent unauthorized access; establishing risk control rules for automatic payments to identify abnormal calls; and providing audit reports for internal data calls to help companies meet compliance requirements.
Such directions may not be highly viral, but they have clear B2B attributes.
The more companies adopt AI, the more they need security, permissions, and auditing. Especially in industries like finance, healthcare, government/enterprise, legal, and education, AI cannot pursue only efficiency; it must also be controllable, verifiable, and accountable.
For Chinese teams, the security and risk control direction is also easier to avoid high-risk narratives. It doesn't require directly touching tokens, managing user funds, or promising returns. As long as it addresses the real risks in the enterprise AI usage process, there is a chance to form sustainable service revenue.
However, this direction also has barriers.
Agent behavior auditing cannot be simply understood as "on-chain monitoring with a new name." It requires understanding enterprise permission systems, AI tool calls, data security, log analysis, and business processes. If Web3 security teams want to enter this area, they need to supplement knowledge in AI engineering and enterprise security; they cannot just apply their original smart contract audit methods.
But in the long run, this path is worth watching. The more AI enters real business, the less security issues will remain at the model level alone. Whoever can help enterprises see what Agents are doing, which behaviors pose risks, and how to trace problems when they occur, may become an important service provider in the AI infrastructure.
Application-Layer and Community-Oriented Teams: From Web3 Products to AI-Enhanced Products
These teams include content platforms, investment research tools, trading tools, educational products, community products, growth tools, and user operations products. They may not be suitable for directly building AI infrastructure, but they are well-suited to embed AI into their original business.
The easiest mistake for application-layer teams is to rush to transform themselves into AI companies as soon as they see the AI hype. Previously doing community? Now claim to do AI social. Previously doing content? Now claim to do an AI content platform. Previously doing investment research? Now claim to do an AI investment advisor. It sounds like a big change, but without real scenarios and paying demand, it can easily become just a new packaging.
A more practical approach is to integrate AI into the original product to solve problems that users already have.
There are already some references for these directions. For example, products like Kaito are essentially not simply building an "AI chat tool," but rather, around the problem of Crypto information overload, they organize project dynamics, social media, narrative heat, content dissemination, and user attention, allowing researchers and project teams to see what the market is discussing faster. The inspiration it gives application-layer teams is that AI doesn't necessarily have to be a standalone product; it can become a layer of capability for information filtering, semantic organization, and signal discovery.
Another example is some Crypto Copilots and investment research assistants. They don't judge for users whether a project is good or not out of thin air, but instead organize announcements, whitepapers, governance proposals, on-chain data, financing information, and market dynamics into more digestible content. For investment research tools, this is more valuable than simply making a "Q&A bot." Because the real pain point for users isn't the inability to ask questions, but having to process too much information daily, from scattered sources, with high judgment costs.
The same logic applies to community and operations tools. Project teams deal with user questions, activity feedback, community content, KOL data, and growth leads daily. If AI is just placed in Telegram or Discord to answer a few common questions, its value is limited. But if it can help project teams organize frequent community questions, tag users, identify active contributors, categorize activity feedback, and generate operational reviews, then it becomes a tool truly embedded in the operational workflow.
Educational products can be viewed similarly. The hardest part for Web3 beginners isn't necessarily finding content, but that there's too much content, the barriers are too high, and information is hard to verify. AI can generate learning paths based on user level, explain terminology, organize case studies, provide Q&A practice, and break down complex content into versions more suitable for beginners.
Therefore, for application-layer teams, AI is better suited as an amplifier for product and operational capabilities.
Content platforms can use AI for information filtering, summarization, recommendation, and multilingual distribution. Investment research tools can use AI to explain on-chain data, monitor projects, organize market information, and provide risk alerts. Community products can use AI for automated Q&A, user segmentation, activity operations, and content moderation. Educational platforms can use AI for personalized learning paths, course generation, and Q&A. Trading tools can use AI for data analysis, risk reminders, and strategy assistance.
These directions may not sound as grand as the "Agent Economy," but they are easier to implement. Because application-layer teams already have users, content, scenarios, and operational experience. Adding AI solves problems that already existed in the original product, like too much information, users not understanding, high customer service costs, slow content production, low investment research efficiency, and heavy community operations.
The key to this type of migration is not to detach from the original user scenario.
If a Web3 investment research tool already serves traders and researchers, then AI can help users understand announcements, whitepapers, on-chain data, and market changes faster. If a Web3 education platform already serves novice users, then AI can do personalized Q&A and learning paths. If a community product already serves project teams, then AI can help project teams with user segmentation, community maintenance, and activity outreach.
These are all real demands.
Application-layer teams often don't need to pursue "transformation." Integrating AI as a new capability into the original product makes it easier to leverage the existing user base, content, and business foundation, and also avoids entering a completely unfamiliar AI battleground.
Of course, this path shouldn't stop at just adding a chatbot.
The so-called AI-ization of many products today is often just adding a Q&A window. There's no significant improvement in user experience or business efficiency. This kind of AI-ization is hard to form long-term value.
Truly effective AI enhancement should be embedded in the user's original workflow. It should either save the user time, improve decision quality, reduce operational costs, or increase conversion and retention. If it doesn't achieve these, the AI function will quickly become a mere decoration.
Therefore, for application-layer and community-oriented teams, the most realistic migration method is to first use AI to make the original product and operations more effective. Whether users understand information more easily, whether project teams operate communities more easily, whether researchers make judgments faster, and whether customer service and growth save more manpower—these are more important than "whether to transform into AI."
Which Directions Are Best to Avoid?
After discussing teams suitable for migration, it's also necessary to clarify which directions are best approached with caution.
First, building general large language models from scratch.
This direction requires model capabilities, computing resources, training data, research teams, and long-term capital investment. It's already a highly competitive market. Large model companies, internet giants, and AI-native startups are all in it. Without particularly strong technical and resource accumulation, Chinese Web3 teams will find it hard to gain an advantage by forcing their way in.
A more realistic problem is that the advantages Web3 teams have accumulated in the past are usually not in model training. Many teams are truly skilled in protocols, data, wallets, payments, security, communities, and overseas markets. If they directly switch to building general large models, it's equivalent to discarding their original accumulation and entering a heavier, more crowded, and more capital-intensive track.
Second, starting directly with broad AI Agent platforms.
Many Agent platforms sound grand, seemingly capable of handling any task. But when actually landing, what users care about is often not how big the platform is, but whether a specific task can be completed stably. Whether it can integrate into real workflows, reduce manual costs, guarantee result quality, and find willing payers—these questions are more important than "platform narrative."
Without clear tasks, delivery standards, and paying parties, Agent platforms can easily remain at the demo stage. They may look advanced but are hard to integrate into daily user use.
Third, directions like AI traders, automated yield, and intelligent investment advisors.
This type of product easily gains virality within the Web3 circle because it naturally aligns with user expectations for returns. AI automatic trading, AI making money for you, AI replacing your investment decisions—all sound very attractive.
But the problems with this direction are also the most complex. It easily touches user funds, return promises, asset management, investment advisor compliance, and trading risk control. Even slightly aggressive product messaging can slide from "tool assistance" to "return promise." For Chinese teams, this direction is particularly sensitive and difficult to maintain as a long-term, stable entrepreneurial path.
Fourth, simply putting an AI shell over the original project.
Previously doing NFTs, now adding AI-generated images. Previously doing GameFi, now adding an AI NPC. Previously doing a wallet, now adding an AI chat assistant. Previously doing a community, now adding an AI Bot. Such modifications might bring short-term buzz, but if they don't improve product value, it's hard to retain users and convince genuine paying customers.
AI can be an entry point for capability migration, but it cannot solve the fundamental problem for a project lacking real demand.
If the original business had no users, no revenue, and no scenarios, just switching to an AI narrative will likely end up back at the same question: Why do users need it? Who will pay continuously? What problem is the team actually solving?
Therefore, for Chinese Web3 teams, judging whether an AI direction is worth pursuing shouldn't rely solely on its hype. What's more important is whether it has real scenarios, clear paying parties, reusable capabilities, and relatively clear compliance boundaries.
Final Thoughts
The AI cycle has arrived. Of course, Chinese Web3 teams should look, and they should look closely.
But what's truly worth looking at isn't which concept is hot again, but whether the capabilities accumulated over the past few years still have new landing points.
From data, identity, and payments, to security, risk control, and application-layer products, what Web3 teams can migrate are actually things already solidified in their original businesses. AI provides new scenarios for these capabilities, but it won't make up for the foundation of a project lacking real demand.
So, for Chinese Web3 entrepreneurs, switching to AI isn't the key; whether their capabilities can migrate is the key.
If what was accumulated in the past is data, accounts, payments, security, operations, and user scenarios, then AI might be a new path.
If what existed in the past was only narrative and packaging, switching to AI is just switching to a hotter term.
