The Real Change Has Just Begun
The first GEO-themed conference in China, which I organized with Xiangyang, has come to an end. Twelve friends and experts from the GEO and AI communities gave dense talks and joined deep discussions.
I am very grateful to Yan, Zhang Kai, Badao Liu, Guizang, Da Congming, AJ, Liu, A Kuang, Yangyi, Juzi, and other experts and friends who have been exploring and practicing at the frontier of GEO and AI. They contributed a truly valuable day of sharing.
The event lasted only one day, but the information density was very high.
The value of a gathering is not only whether it explains new concepts clearly. It is whether it helps people see more clearly where a new trend has already developed and which directions are truly worth investing in.
We are entering a new era of being discovered.
In the past, companies were more familiar with traffic entrances such as traditional search, information feeds, short video, WeChat official accounts, and Xiaohongshu.
These entrances still matter. But the new change is already obvious. More and more users are giving questions to AI, giving judgment to AI, giving filtering to AI, and in the future, may even give execution to agents.
The logic of brand growth will be rewritten as a whole. That rewriting has already begun.
From the GEO perspective, companies now face a new question: when users ask AI a question, can you be seen, can you be correctly understood, and can you be credibly recommended?
This tests more than content production. It also tests fact assets, answer assets, distribution assets, brand signals, data monitoring, and backend attribution.
From the AI product perspective, change is also accelerating.
The definition of AI-native products is changing. The relationship between users and AI is changing. The service target of products is also changing. Many products no longer only serve humans. They are beginning to serve agents too.
Many workflows are no longer just competitions between GUIs. They are extending into CLI, Skills, MCP, local context, and long-term collaboration. The real barrier of a product is increasingly concentrated in three things: low enough friction, strong enough context, and large enough imagination.
From the perspective of AI growth and AI promotion, the logic is also becoming clearer.
Marketing must follow users wherever they go. WeChat official accounts, social media, PR, communities, hackathons, livestreaming, and private traffic are still effective, but their roles are being redistributed. Some build awareness. Some build trust. Some create consensus. Some complete conversion.
The products that succeed are often not the ones with the most features. They are the ones that find a real need earlier, build a clear position faster, and more accurately identify a group of people who are willing to share, spread, and keep using them.
When we look at the entire conference together, it points to one thing: AI is rewriting how brands are discovered and how products grow.
GEO is only one of the earliest visible parts of this change.
Further down the road, it will extend into AI search, AI recommendation, agent invocation, Skill distribution, workflow collaboration, and all new paths from “to AI” to “to people.”
At that point, the real gap in marketing may come from a few core things: who understands the change earlier, who builds fact and content assets earlier, who completes the shift from “facing humans” to “facing both AI and agents” earlier, and who thinks about product, brand, content, and growth inside one AI system earlier.
The full collection of talks and notes from the speakers is here: GEO conference notes
The Power of the Volunteer Team
A medium-sized event has real organizational requirements.
The first GEO conference, organized by Xiangyang and me, was simplified in many ways, but it still required a lot of organizing work:
To make the event experience better, I posted a volunteer recruitment message in the member group for attendees. The response was very positive. Soon, twenty friends joined as volunteers.
Kaixin is the creator of the self-media account “Kaixin AI Tool Collection.” We met last year. At the beginning of the conference preparation, he messaged Xiangyang and me to ask whether he could help.
After the volunteer team was assembled, I realized Kaixin was very suitable to coordinate and control the whole process. On one hand, he knew the speakers. On the other hand, he had strong organizational ability and a strong sense of responsibility.
After the volunteer group was created, Kaixin and I started preparing the work, sorting tasks, and doing partial rehearsals.
In the early hours of the conference day, he was still checking the preparation list with me on WeChat:
The next day, the conference was completed smoothly.
After the event, Kaixin told me excitedly in the car that the volunteer team was incredibly responsible and careful. Speaker control, deck management, livestreaming, photography, reception, and other details were handled with initiative, responsibility, and warmth. That is rare.
For a medium-sized event, what looks like an execution problem is actually an organizational system problem. You are not only dealing with the tasks themselves, but also people, rhythm, collaboration, emergencies, and uncertainty.
When these factors stack together, one person’s ability is not enough.
Organizational capability is essentially the work of turning uncertain people and uncertain things into a runnable system.
And the most important part of that system is people.
These volunteers were not bound by hard constraints. But because they identified with the event, they became more proactive, more detailed, and more responsible.
They were participating in something they believed in.
In some sense, this kind of connection based on shared recognition is more powerful than a purely interest-based connection.
The Playbook of an Airborne CTO
I spoke with a CTO friend who now manages around one thousand engineers in a large group. He has repeatedly joined leading companies and listed companies across industries as an outside executive.
I asked him why each transition worked and why he was repeatedly “poached” successfully.
He shared his playbook.
Before joining:
- First judge whether the company is worth joining. The main factors are the business model and potential, plus the organization and culture.
- Lock in personnel authority in advance. This is the bottom line. Before deciding to join a company, he needs to align with the CEO or even the board on personnel authority.
- Identify leverage points in advance. Based on the first two factors, judge where technology can create leverage for the business, such as what improvements or changes can quickly let the company see a new result.
After joining:
- First handle people. Replace people who do not cooperate, then reorganize or clarify his own team.
- Rebuild organizational processes according to his own view.
- Focus on several small but leveraged projects and quickly help people win small battles.
These three things must be done within three to six months.
The core keywords behind this playbook are judgment, personnel authority, leverage, and winning small battles.
But above his playbook, there is another higher-level playbook. He himself has become one element inside that larger playbook.
$1,000 in Tokens Per Person
A large company has started giving each headquarters employee a monthly token budget of $1,000, with access to the best models in the world. That is tens of millions of dollars every month in real support.
This may be the best way to improve internal AI productivity.
Other methods, such as internal training, leading by example, or incentive mechanisms, seem less important in comparison.
The most important thing is giving employees a certain degree of token freedom and allowing them to use the best models in the world.
Once people start using them, they cannot stop. These people are smart. They will gradually iterate on their own usage methods, borrow methods from others, and find more and more scenarios that fit their work. Eventually, the whole organization’s efficiency can rise significantly.
But most companies probably cannot copy this.
It is not just a budget problem. It also requires convenient and stable access to good models.
For various reasons, some overseas models are inconvenient for domestic users. Accounts may be banned, or APIs may be unstable.
For people who know how to use AI, good models are productivity.
A Company That Cut Its Own IT Department
A traditional company with about 1 billion in annual revenue recently cut its entire IT department, around forty to fifty people.
It then outsourced all system development, maintenance, and upgrades to a technical team of fewer than ten people.
How was that possible?
After taking over, the new team used AI to rewrite the original IT systems. This means that programmers who believed they were hard to replace because they understood the unique logic behind many systems could no longer treat that as a moat against AI.
AI is efficient at reconstructing system code. If the team also reconstructs the code documentation, system management becomes much easier.
After the system rewrite, maintenance and routine feature iteration no longer take as much time.
So this team now wants to take on another project.
IT outsourcing is already a mature business model in China. It has produced several large companies, such as iSoftStone and Chinasoft.
In the hands of a technical team that knows how to use AI, this model can make system development and operations much more efficient. Replacing an original 50-person IT team with a 10-person outsourced team is not that difficult.
The truly difficult part is trust.
For the owner of a company with 1 billion in revenue to solve IT efficiency and management through outsourcing, the trust in that team must be very high.
Also, this model has limited applicability. It is not suitable for most companies.
Your Agent Is Mine
There is a very striking paper titled “Your Agent Is Mine: Measuring Malicious Intermediary Attacks on the LLM Supply Chain.”
Many people think the biggest security problem in the agent era is whether models can be prompt-injected. This paper reminds us that the more dangerous layer may not be inside the model, but outside it, in the execution chain.
For people who heavily use Claude Code, Codex, OpenClaw, or other AI programming agents, this paper is worth reading carefully.
It explains a problem that has often been underestimated:
When your agent request first passes through a third-party router or proxy service, that intermediary layer has enormous power. It can see your request, see the model’s response, and even quietly modify the result before it reaches your local environment.
Once this is placed in an agent scenario, the danger rises quickly.
In agent products, model output may become commands, code, installation actions, file edits, cloud resource operations, and more. If someone modifies the output in the middle, the consequences can be completely different.
The researchers purchased a group of paid routers and collected some free routers. Then they observed whether these routers behaved maliciously.
They found that some routers actively injected malicious code, some abused credentials passing through their chain, and some directly touched researchers’ wallet assets.
This means the issue is not merely theoretical. It is already happening in the real world.
In the LLM era, routers are no longer just a forwarding layer. They have become a trust boundary in the supply chain.
That judgment matters.
In the past, people often saw routers as relay nodes: saving money, aggregating models, unifying interfaces, and switching between models. That all seems reasonable.
But from a security perspective, routers have far more power than “forwarding.” They can see system prompts, know which tools you can call, touch sensitive information, and modify parameters.
In other words, they can both observe and alter.
The paper mentions two core attack types.
The first is rewriting tool calls in the response.
This is subtle because it does not have to break the whole response. It only needs to change a few parameters while keeping the JSON structure valid, allowing the client to parse it normally and execute an action that quietly serves the attacker’s goal.
For example, an agent meant to install a normal dependency may be changed to install a malicious package with a similar name. A normal script download may become a download from an attacker-controlled source. A simple command execution may become an operation with a backdoor.
The second is passively stealing secrets.
This may be even more frightening. It does not need to modify anything. As long as traffic passes through it, it may obtain API keys, cloud credentials, private keys, environment variables, or sensitive project context.
Agent risk does not only come from the model itself. It comes from every controllable node between the model and the executor.
What the agent era may need is a response integrity proof mechanism.
The key results returned by model providers, especially tool calls, should ideally carry verifiable signatures. The client should be able to verify whether the tool call was truly what the original model returned.
Only then will it be difficult for third-party routers to quietly tamper with results.
Otherwise, many agent systems today are essentially in a state of default trust toward the intermediary layer.
That may be acceptable in ordinary chat. But once the scenario becomes programming, operations, automatic execution, long-running tasks, or unattended work, the risk grows quickly.
For heavy users of AI programming tools, this paper offers five lessons:
First, high-privilege tasks should connect directly to official providers whenever possible. If a task involves servers, repositories, dependency installation, production environments, or automatic execution, avoid third-party routers when you can.
Second, do not combine automatic execution approval with third-party routing.
Third, your local environment needs policy gates for high-risk commands, especially Bash, curl scripts, package manager installs, and remote download-and-execute actions. At minimum, there should be human review or clear rules.
Fourth, expose credentials minimally. Do not place long-lived, high-privilege keys directly into agent sessions. If they pass through an untrusted intermediary, they may be seen.
Fifth, keep execution logs. If something goes wrong, you need to know which session, which tool call, which router, and which project context caused the problem.
Paper: Your Agent Is Mine