After WAIC, I Stopped Believing in the Omnipotent Agent

After attending the 2026 World Artificial Intelligence Conference (WAIC), I stopped measuring agents by how closely they resemble all-purpose generalists. The booths that felt valuable were the ones that tackled one messy, recurring job within a clear boundary—and left a person accountable for the result.

Daosen (稻森) · July 28, 2026

Claude and GPT are swallowing everything. For application founders, this is the darkest stretch of the journey.

An agent does not have to learn how to save the world first.

If it can reliably complete one troublesome job in a clearly bounded setting, that is already remarkable.

I usually enjoy pushing agents hard.

I raise the difficulty on purpose. I give an agent a pile of material and see whether it can identify the key point. I ask it to work across several projects. I leave the request half-finished and watch whether it follows up. Then I introduce exceptions and see whether it will revise its earlier work.

I used to feel conflicted about agents. Their capabilities look impressive: they break down tasks and write plans with confidence. Yet they still stumble at critical steps. We are still far from “hand it a complex goal and walk away.”

WAIC changed that view.

The halls had robots, foundation models, and walls of screens. What I took home was more practical: once technology enters a real-world setting, you can tell immediately whether it creates value. It does not have to solve every problem in the world first. If it handles the tedious work that keeps recurring in one industry, it is already useful.

Power grids, steel, oil, factories, and homes used to sound far from large models. AI is now being wired into forecasting, scheduling, diagnosis, coordination, and service. I had been judging agents by “general capability,” and that was the wrong question. Enterprises never wanted a chatty AI. They wanted someone, with AI, to finish a job and produce a result.

Follow the OceanBase community WeChat account “老纪的技术唠嗑局.” We will keep publishing technical pieces on #AI and #Data.

Models have entered companies. What companies lack is often not a model

I sat through quite a few forums featuring academicians and government officials. I did not take much away from them.

When business leaders talked about AI, however, their ideas set my mind in motion.

Listening to Kai-Fu Lee, I kept seeing one picture: a very strong model walking into a company for the first time.

In front of it sit customer files, contracts, inventory, quotes, meeting notes, approval flows—plus history scattered across systems. Every document looks useful, and many of them contradict one another. Who can see what, who can change what, which rules must not be touched, and whom to call when something breaks: none of that writes itself into the model’s head.

No matter how strong the model is, it will not magically know how a company runs.

The talk then hit ontology. The word suddenly made the problem clear. It sounds technical; you can just treat it as an operating map: how customers relate to contracts, which products a contract affects, which inventory, price, and approval rules constrain those products, and who gets pulled in when a project slips.

Without that map, AI is the smart intern who just joined. It can look things up, write reports, and explain a situation. It still has no concept of what “this customer,” “this rule,” “this payment,” or “this exception” means here.

Beyond the map, there is live status. Did the customer place an order today? Where is the quote? Where is the approval stuck? Is a machine raising an alarm? Did inventory, prices, or contracts change? A pile of static documents is not enough. When an agent appears inaccurate, the problem is often stale or missing information, or a lack of permission to access critical data.

Only then comes execution. These systems can act, and they can help push a process forward. AI makes a suggestion, leaves a record, and a person confirms. Where the rules are clear and the risk is low, you gradually open more execution rights. Go slowly enough and enterprises will actually use it.

I now judge whether an enterprise AI project has a chance by five things: is the model good enough, are the business relationships spelled out, can live data be connected, can execution be controlled, and is someone accountable for the outcome. Miss one, and the project usually stops at “the demo was stunning.”

Honestly, WAIC still had plenty of projects that stopped at the demo.

DRI captures exactly what I have been thinking about

Technology and models will keep changing. In the end you still come back to people.

The other idea I most want to share is DRI.

DRI stands for Directly Responsible Individual. In short, one person has to own every critical matter through completion. That person knows the status, coordinates when resources fall short, brings a plan when conflicts arise, and remains accountable for the outcome.

That landed hard, because it is also our problem in practice. The more AI you add, the easier it is to create an illusion: everyone participated, the group chat is full, documents and code keep growing, and delivery still does not get faster.

DRI pulls the question back to something simple: who is finally responsible for this?

I like to think of the DRI as “the person who works with AI.” That person does not have to do everything, but they must know what to hand to AI, which conclusions require human review, and when to stop. AI adds capacity and information. Responsibility still rests with the DRI.

So if a team wants to run an AI pilot, it does not need to invent a grand platform first. One small task is enough: it should occur frequently, be painful enough to matter, use data already at hand, and produce a visible result. Then name someone willing to own the outcome, and write down the goal, the boundary, the data the system can access, the systems it can use, and where to escalate when things go wrong.

That is how AI finds a place to land.

To put the above in one line: AI’s value does not come from difficulty. It comes from the intersection of scarcity and demand. Instead of chasing technical extremes, find the concrete pain point that others ignore and users urgently need solved. Do not get carried away by grand narratives. The market pays for solutions to real problems. Solve one, and you can build reliable revenue and a moat in an underserved market. Ignore it, and you remain trapped in the illusion that “the technology is great, but nobody pays,” while pragmatic teams steadily capture the market.

Behind the Physical AI frenzy lies a pile of unglamorous problems

The best technology still has to return to its original intent: trust, inclusion, and solving real social problems.

The hottest phrase these days is Physical AI. Robots walking, carrying things, interacting with people: the booths were packed.

I used to think robots were still far from daily life. This time I could feel Physical AI heating up, but I did not get the excitement of “we will have a robot soon.” I understood more clearly why this is so hard.

If a text model gets one sentence wrong, people can simply check again. If a robot misses a grasp, bumps into something, or reacts half a second late, the consequences unfold in the real world. It has to perceive the environment, understand the goal, plan its motion, control a body, and deal with lighting, occlusion, friction, hardware errors, and operational details that people never put into words.

That is why I prefer use cases with clear boundaries: warehouse handling, factory inspection, localized assembly, hospital logistics, rehabilitation assistance, and selected eldercare and home services. They sound less exciting than “one robot does everything,” but they are much more likely to deliver reliable results first.

A large model is like a brain. Physical AI is like a body. Once the body enters the real world, reliability matters far more than eloquence. The ability to perceive, grasp, avoid obstacles, recover from failure, and stop to ask a person when uncertain must mature before a system can move from an exhibition hall into a factory or home.

Also, Physical AI is still very early. It is far from a “ChatGPT moment.” I still watch this space closely. If digital AI raises white-collar productivity, Physical AI raises blue-collar productivity. It is entering the real world through one small job at a time.

At one roundtable, almost nobody asked whether robots look human. The conversation was about data: how to collect data from real robots, how much simulation can cover, what first-person internet video can contribute, and whether failed operations can be recycled into the next training round. The discussion then turned to latency, hardware lifespan, cost, success rates, and control precision. These robots also share a problem: they cannot reach back to the cloud whenever they need to retrieve a memory. The reasons are practical: mobile networks are often unstable, device latency must remain low, and privacy and cost also matter.

That is where scarcity and demand meet seekdb[1] and OceanBase[2] Lakebase. seekdb’s embedded deployment, low resource requirements, and local hybrid retrieval can keep local state, task traces, user preferences, and search indexes on the device. Cars, robots, and smart terminals all need a local “cerebellum”: low-latency retrieval, with synchronization to a cloud brain when needed. In the data center, OceanBase Lakebase can consolidate multimodal data for governance, training, and evaluation. On the device, seekdb plus PowerMem handles immediate responses; the central system supports long-term evolution.

That path is more reliable than stuffing all memory into a cloud model’s context window. Many car makers that support intelligent driving already work this way—OceanBase + seekdb + PowerMem[3].

This architecture of “on-device responsiveness + centralized long-term evolution” is becoming a reality.

seekdb is the OceanBase community’s lightweight AI-native search database for agents and AI applications. The project is open source: https://github.com/oceanbase/seekdb

Embodied intelligence and attached intelligence

Robots can do more and more. What about people?

The relationship between machines and people does not have to be replacement. Compared with the embodied intelligence (robots) above, many WAIC booths started calling wearables such as smart glasses and mechanical exoskeletons “attached intelligence.”

When you move a refrigerator, Amap inside smart glasses can plan the route. A mechanical exoskeleton can take the load that used to sit on the waist and shoulders. How to turn without hitting the wall still belongs to the person.

These edge devices also illustrate a trend already underway: as large-model capabilities “flow” to the edge on a 6–12 month cycle, a natural question arises—what data foundation will support these small models on the device? They need full database capabilities at the edge, including vector retrieval, full-text search, and structured queries, without the overhead of a traditional database deployment.

The open-source seekdb project can serve as that edge database. In server mode, seekdb needs only 1 CPU core and 2 GB of memory, installs with pip, and starts in seconds. In embedded mode, it can run as a Python, JavaScript, or TypeScript library within the application, with no separate database process and almost no resource overhead. It also supports vector retrieval, full-text search, JSON, and GIS. One lightweight engine covers all of these capabilities, with MySQL-compatible syntax and a gentle learning curve.

Google DeepMind CEO Demis Hassabis often says in interviews that after a frontier Pro model ships, its capability can be compressed, within six to twelve months, into a very small model that can almost run on an edge device. He gave numbers: a distilled small model can reach 90–95% of a frontier large model’s capability at about one-tenth the cost.

DeepMind’s own lineup follows that logic: Gemini Pro (frontier flagship) → Flash (distilled consumer inference) → Nano (on-device).

The embodied intelligence, attached intelligence, and in-car devices at WAIC make this trend clearer: on-device intelligence is not a distant prospect. It is advancing on a six-month cycle. Infrastructure that can deliver comprehensive AI data capabilities with minimal resource overhead will soon move from optional to essential.

AI is also starting to care about relationships and companionship through memory

There were some surprises as well.

I had assumed “shared memory” agents mostly belonged in enterprises, where teams share internal materials, project background, and decision records. That sounds natural.

On the floor there were also products and apps for family memory and companionship: helping a household keep shared experiences, manage important information, and have fewer “I thought you remembered” moments.

Someone even built an app as a “bridge of understanding and memory between people and pets.” It felt slightly outrageous.

These AI memory products are all narrow in scope. I still found them interesting.

AI memory is not only about saving office time. It also has a chance to help people understand and care for beings that cannot state their needs in standard language.

Here is another project extended from the open-source PowerMem project: seekdb M0[4], self-evolving cloud memory designed for AI agents. It supports one-click access, shared experience, and autonomous learning.

If you are building an AI product that needs “memory,” take a look at PowerMem and seekdb.

In the halls I also saw a multi-specialist agent team in healthcare, which pointed to the same idea. Agents do not replace a doctor’s final judgment. They can organize scarce specialist experience so more patients get support faster. That is inclusion as I understand it, and it is the value many AI companies claim. Shipping the flashiest model is not inclusion. Letting more people use capability that used to be expensive and scarce is.

AI is powerful, but it is still a Turing machine

A talk by Academician Andrew Chi-Chih Yao, founder of Tsinghua’s Yao Class, filled in an important piece. Everyone is watching what AI can do. Someone also has to remind us what it cannot.

Go, protein-structure prediction, code generation: AI has already done things that were hard to imagine. Put those abilities into an open world and the old problems return: incomplete information, rules that cannot be stated cleanly, and answers that are expensive when wrong.

Yao made a counterintuitive point: however strong AI is, it is still inside the Turing-machine frame. Take the halting problem: there is no universal solution that works for every computer program.

That did not make me more pessimistic. It helped me see that AI is more useful once the boundary is clear.

Scientific research is a hard problem, and AI is only beginning to tackle it

Yao said the most valuable work in the next few years is empowering scientific research. That made me look at AI for Science again.

Scientific research is not like writing code or taking an exam. Many problems have no standard answer. Feedback is slow. One experiment can take months. A large share of attempts fail. A person’s job is to raise a question worth testing from existing knowledge.

AI can help a lot here. Read large amounts of literature, find contradictory evidence, help organize hypotheses, design computational plans, run analyses, keep a record of every attempt, and bring failed results into the next round. Scientists still decide whether a question is worth chasing, whether the evidence is enough, whether the experiment design missed something, and whether the conclusion holds.

Yao also mentioned several examples. A Tsinghua team applied AI to existing telescope data and pushed the observable window into the early universe back by about 100 million years. An OpenAI large model overturned an 80-year-old unit-distance conjecture; the proof drew on advanced algebraic number theory and other fields.

He also talked about AI and quantum technology. AI can take part in quantum error correction, control, and complex-system optimization. Quantum computing may later open space for learning quantum data and harder problems. It looks more like a long route, far from ordinary consumers, but it may shape how new drugs, materials, energy, and compute appear.

That talk gave me a longer time horizon for thinking about “what is next for AI.” We talk every day about models, tokens, and agents. On another track, people are already applying AI to astronomy, chemistry, life science, and quantum physics. The noise at the application layer is immediate and loud. Progress in basic science is slower and deeper.

Two weeks earlier, after Claude Science appeared, I did a deeper look at AI for Science. Anthropic positions Claude Science as an AI workbench for scientists.

That positioning is much more accurate than “Claude for science.” My reading is that this is an agent workspace rebuilt for research. The chat box is still the entry, but the work happens in files, terminals, databases, compute jobs, and artifacts.

According to the official introduction and the public skill system, it puts common scientific packages, database connections, code execution, remote compute, and auditable artifacts into one agent environment. A researcher can ask Claude to read materials, plan steps, call tools, run analyses, and leave the process and results in the workspace. That change looks less explosive than shipping a new model, and it is closer to the daily friction scientists actually meet. A lot of their time is not spent on the cleverest question. It is spent finding files, setting up environments, waiting on jobs, editing scripts, filling citations, and packing results.

For most readers who only want to try it themselves, Claude Science still has a practical barrier: you may not get access. Officially it is still marked beta. Real availability depends on the account plan and how fast the product opens.

Because Claude Science is still difficult to access, I recommend OpenScience[5] and Feynman[6] if you want to start now. Both are open source and can run locally. They take different approaches that suit different needs.

OpenScience is closer to a full research workbench. It puts a file tree, editor, terminal, session history, agent runtime, tools, skills, and scientific database connections into one local app, and it supports Anthropic, OpenAI, Google, and open-weight models. If you want to study how a research agent manages context, calls tools, connects databases, and keeps provenance, start there.

Feynman is closer to a research engineer’s everyday starting point. It begins at the CLI, with commands for literature reviews, paper ranking, deep research, code audits, and reproduction planning, while feynman serve opens a standalone workbench. If you already have papers, a code repository, or a reproduction task, Feynman is usually the easier place to begin.

The youth forum talked about careers without manufacturing more anxiety

At the youth forum, someone asked a practical question: as more entry-level work is automated by AI, how will young people accumulate their first experience?

Nobody recommended a so-called “safe major,” and nobody promised a job that would never be replaced. The answers were straightforward: define problems, exercise professional judgment, learn quickly, communicate and collaborate, understand other people, face uncertainty, and own the result. Skills expire. Judgment does not depreciate as easily.

AI can finish a task for you. It cannot take the consequences for you. A student shared her first time organizing a CEO roundtable. The agenda changed on the fly, parties had to be coordinated, and surprises had to be handled. Many decisions had to be made on the spot. Later she independently built a small pricing model. The two projects differed in size. The growth was similar: real experience is not “I participated.” It is that something landed on your shoulders and you had to push it forward.

Experience never comes only from repeated labor. It comes more from real responsibility. Sometimes a project’s most important output is not the result, but the person who started daring to decide.

A line from WAIC’s main forum stayed with me: “It is much easier to teach smart people finance than to teach finance people to become smart.” The same holds in the AI era. Instead of asking which major is safest, become someone who can quickly understand a new problem, keep learning, and develop deep expertise. AI is a generalist. A person’s opportunity is to specialize and develop judgment in the real world.

Another guest said she had believed since childhood that a perfect score is not necessarily a good thing, because it deprives you of feedback and leaves you unsure where to improve.

That line is sharp: a perfect score makes people stop; feedback makes people grow. In the fastest-changing era, “being temporarily right” matters less. “Keep correcting” is the real capability.

One huge change AI brings is cheaper trial and error. Building a product, finishing a study, or testing a business idea used to mean finding a team, waiting for resources, and spending a lot of money. Now a young person can, with AI, first make a prototype and then take it into the real world for feedback.

That is why a forum about the future of work did not make me more anxious. AI anxiety easily pushes people toward “hurry and learn another skill,” but technology will keep changing, and the next hot tool will appear. Instead of hunting for a path AI will not change, become someone who can walk through change. The AI era is the best era to bet on yourself.

The host left the room with three words: humor and joy, curiosity, and fitness.

Keep your sense of humor and joy, stay curious about the world, and do not forget to exercise. Cherish the genuine warmth you share with the people you love and who love you. Technology keeps moving forward, but joy, curiosity, health, and companionship are still things AI cannot experience on our behalf.

Small teams have new leverage. The hard part is still finding a good problem

The exhibit halls also had plenty of one-person companies and small-team startups. Research, design, operations, content, and support that used to need a full team can now be started by a few people—or one person plus a set of AI tools.

That is a large opening for founders. The technical bar is falling. Many ideas can be tried first instead of dying on “I have no team,” “I cannot code,” or “I have no budget.”

As model capabilities converge, everyone is back at another starting point: what problem do you actually see? Details that never appear in an SOP, complaints customers repeat without naming, delivery steps that keep being reworked, and processes others will not spend time understanding become new sources of value. AI gives small teams more leverage. Customer understanding, industry experience, and product judgment are not handed to everyone automatically.

So I think the strongest AI founders going forward may not be the ones who talk most eloquently about models. They will be the ones willing to go on site, observe real friction, and turn it into a product someone will pay for.

Closing

After this visit, I was even less interested in chasing an “omnipotent agent,” and no more eager to wrap AI around everything.

I would rather ask first: where is this task actually stuck? Scattered information, a slow process, not enough experts, data that will not connect, or nobody willing to stay with it to the end?

Once that is clear, identify which part AI can help with. It can work reliably in clearly bounded settings. People still judge, verify, coordinate, take responsibility, and decide whether something is worth doing. That is a more useful discussion than asking whether AI will replace people.

We are entering a stage where ideas can be put into reality faster. Some people use AI to make better products. Some use it for scientific research. Some bring robots into factories and hospitals. Some use it to care for family and understand pets.

The AI I look forward to is the kind that gives once-impossible ideas a chance to become reality.

References

[1] seekdb: https://github.com/oceanbase/seekdb

[2] OceanBase: https://github.com/oceanbase/oceanbase

[3] PowerMem: https://github.com/oceanbase/powermem

[4] seekdb M0: https://m0.seekdb.ai

[5] OpenScience: https://github.com/synthetic-sciences/openscience

[6] Feynman: https://github.com/companion-inc/feynman

Related reading

Upcoming events

Welcome to join the open-source community Discord.