Skills Arrive — Is Prompt Dead? In 2026, How Do We Build Controllable Thinking for Agents?

Stop grinding on Prompts! It’s just the “power button” of your AI employee

Entering 2026, the explosive popularity of Skills and the sudden arrival of Clawdbot (OpenClaw) sent a clear signal: as agents move from flashy demos to production systems that support real business, relying solely on the “art” of optimizing prompts can no longer meet enterprises’ hard requirements for reliability, execution, and continuous evolution.

This doesn’t mean prompts no longer matter; rather, their role has fundamentally shifted. They have gone from a “commander-in-chief” that needed endless polishing and carried all the logic, to a trigger. Their new task is to accurately understand human instructions and then efficiently awaken a vast, specialized capability system behind them. Like a phone’s power button — one press opens the gateway to all kinds of app features.

This capability system is precisely the core of modern AI engineering — a “controllable thinking” architecture built for agents.

It is made up of three mutually cooperating engines:

• Memory engine: ensures the agent has “memory,” able to remember user preferences and interaction history. This means it can remember important conversation history and your requests, getting things done from start to finish without you having to explain everything from scratch each time.
• Knowledge engine (RAG): ensures the agent has a “real-time knowledge base,” able to precisely retrieve information from massive, dynamic enterprise data, so the information it provides is always accurate and up to date, never made up out of thin air.
• Skill engine (Skills): ensures the agent has “hands and feet,” able to encapsulate complex business operations (such as data queries, report generation, and system calls) into standardized modules that can be invoked at any time — moving from “able to talk” to “able to do.”

Prompt, Memory, RAG, and Skills together form an AI employee that can work independently, doesn’t make mistakes, and has memory. The more complex and critical the task it must complete, the more the systematic engineering value of the latter three stands out — and so the prompt must step back from center stage. As users, we are no longer just “questioners” conversing with the model, but “architects” who design and assemble capability modules for the agent. The focus also shifts entirely from “how to ask well” to “how to make the AI do well.”

Understanding this paradigm shift from isolated prompts to systematic engineering is the starting point of today’s topic.

Now, let’s listen in on the panel discussion from the OceanBase Community Carnival on January 31, and see how top practitioners break down the evolution and fusion of these core components in detail.

From Prompt to Skills — Is RAG Still Good Enough?

Moderator: Zhang Haili, LangChain Ambassador, OceanBase Ambassador, and the video creator “Canghai Jiusu”

Panelists:

• Zhang Yingfeng, RAGFlow CEO
• Yu Jinlong, FastGPT lead
• Gu Siwei, Co-founder of Nowledge Labs
• Ji Jiannan, head of OceanBase AI Platform and Applications

Topic 1: Where is the RAG ecosystem heading in 2026?

Zhang Haili: From late last year to early this year, hot topics in the AI field have come thick and fast. Besides the recently much-discussed Clawdbot (OpenClaw), Skills has become another major topic. While doing my own Skills-related practice, I found that many Skills are tightly tied to the local file system, but none can do without the RAG system’s recall of external data — which is crucial for letting agents play a bigger role. When LangChain builds its agent ecosystem, RAG is also one of its core experiences. So I’d like to ask each of you: in the current environment, how do you think the RAG ecosystem will develop in 2026? Please give a brief introduction based on your respective products.

Zhang Yingfeng: First, a joke. 2025 was called the Year of the Agent, and back then a friend asked whether we should rename RAGFlow to AgentFlow. This year is the Year of Agents Going to Production, and internally we’ve debated whether to rename to ContextFlow. In fact we’ll never rename, because we believe “R” is the core point. RAG alone really isn’t enough to serve agents, but “R” is the core point in serving the agent’s data layer.

What agents need right now is Context, which comes from three sources of data: an enterprise’s internal data, tool data, and data generated during conversation. Skills lean toward the tool level, but are a layer above tools — they also include Plan capability. Skills themselves also need search: when an enterprise has 1,000 MCPs internally, knowing how to invoke the corresponding Tools and Skills likewise requires retrieval capability. So RAG will never disappear.

Our positioning is to evolve from a RAG engine to an upper-layer engine. The technology itself hasn’t changed, but its connotation has: the data has expanded from simple enterprise-internal data to the contextual data generated during the agent process. We judge that in the future all agents will be Coding Agents, and tool invocation will also become Code Generation, requiring RTC (Run-Time Code) to execute in a sandbox, access various Tools and Skills, and ultimately return results through the file system. This is also the core of our plan to evolve toward a context engine.

Yu Jinlong: I agree with Yingfeng’s view that Code Generation solves all problems — that’s our team’s understanding too. Whether building a RAG engine or a Workflow engine, both are moving toward code generation.

RAGFlow doesn’t want to rename, but we’re a bit tempted to. Over the past few years we’ve found that building an agent is essentially about putting data to use, so our platform mainly solves the data-connection-layer problem. In the past, data was spread across various structures like databases and documents; now, through a large number of connectors, we connect different data. After Skills appeared, the data layer that previously needed code and webhooks to connect can now be implemented through Skills. This is especially valuable for domestic delivery scenarios — in China, system data formats are inconsistent and lack standards, and delivery engineers previously had to write a lot of adapter code, but now they can standardize and connect data to the platform through Skills.

This year we’re mainly doing two things: one is improving the connection layer, the other is optimizing RAG’s Retrieval layer. Retrieval effectiveness largely depends on the recall process, and recall flows differ greatly across scenarios. In the past, we had to build building blocks in Workflow form, do intent recognition and classification, and write different prompts to fit different scenarios — a complex pipeline. Now we’re exploring generating code through Skills, a more semantic approach, similar to the Text-to-Code idea, but generating SDK code to build the entire Retrieval flow. This is a very interesting direction to explore.

Gu Siwei: Regarding RAG-related changes in 2026, you can see that code retrieval in Coding Agents has shifted from pure Embedding to approaches like AST (Abstract Syntax Tree), Agentic FS Graph, or AST Graph. This includes the PageIndex project, as well as OpenKL, an experimental project our company released at Haicon 2024, which attempts to handle Memory and RAG Docs with a file-system-like approach.

Another trend is general-purpose content engines like RAGFlow handling both documents and Memory at the same time. The first product we’ve released is Knowledge MAM, a consumer-facing Memory desktop app, motivated by helping users seamlessly switch workflows between different tools. For example, after completing Deep Research in ChatGPT, you can continue working in Cursor without re-explaining; or, after an agent helps you post something that hits the trending list, you can switch to another agent to continue the task while preserving all the interaction history and preference settings.

Ji Jiannan: OceanBase’s AI-facing capabilities — seekdb, PowerRAG, and PowerMem — are all open source. Beyond building vector databases and AI application infrastructure, our team is also exploring database-facing AI applications, such as Text-to-SQL for developer tools and intelligent database operations.

On 2026 trends, I agree with Yingfeng that RAG won’t disappear — it’s on a different dimension from Skills and MCP. Even as Skills and MCP grow more numerous in the future, in the end you still need to recall through RAG or some other means; you can’t just feed all Skills to the model.

But I have a different view: current RAG is still concentrated in the knowledge-base domain, doing Q&A by building chatbots, and Q&A is more of a toy than a production application. A true production application should weave RAG into daily work — for example, sales generating customized PPTs for clients from corporate materials, or “one-touch” operations. In the future, RAG will incorporate application feedback and reverse-influence how data is chunked and how to do more fine-grained Embedding, rather than just pre-processing.

Topic 2: Multi-path retrieval and data-source management in AI systems

Zhang Haili: Thank you all for sharing. Skills bring us more opportunities to create more Agent and RAG applications. There’s also a very important concept: when we talk about the “R” in RAG, what exactly does it refer to? It refers to Retrieval — a “retrieval process.” The source of Retrieval can be a file system, a database, the Web, or even multiple sources at once.

This leads to a second question: as Skills and RAG systems develop, multi-path retrieval will become increasingly common in the future, RAG won’t disappear, and it will exist in agent systems for a long time. As a result, managing the data sources becomes even more important. The simplest approach is to stuff data straight into the software system, but a more common scenario may be that more and more data lands in databases. In that case, once a database’s multi-path retrieval capability is greatly enhanced, should doing RAG rely more on the database, or use certain tricks at the data-ingestion layer to hand the complex work over to the infrastructure?

Ji Jiannan: Ingestion is inevitably the biggest factor, and this is the core of OceanBase’s hybrid-search (Hybrid Search) concept. If data enters the system entirely as unstructured data or chunks, recall efficiency tops out at the approximate capability of vectorization. Last year, all RAG products emphasized extracting structured data from unstructured data, storing it in semi-structured forms like JSON, for pre-filtering or for hybrid search together with structured data.

Why do this? Essentially, semantic understanding has two layers: one is that you ask a fuzzy question but have a deterministic answer in mind; the other is that the question is fuzzy and the answer is fuzzy too, and you want to recall all relevant points. Most practical scenarios are the first type.

During document pre-processing, structured extraction is very important. For example, extracting structured fields from medical documents or résumés, then at recall time doing exact matching on the structured data first, and vector retrieval on the unstructured content within the fields. Semi-structured data solves the scope and accuracy problem; vector retrieval solves the semantic-understanding problem. Through the hybrid-search pattern — doing document understanding to extract structured data at ingestion, then retrieving uniformly at recall — efficiency improves dramatically. Databases should also develop in this direction over the coming year. We see foreign open-source databases like Chroma already evolving this way.

Gu Siwei: We started doing Graph RAG fairly early — possibly the first team to explore it. The new architecture Zhang shared is very similar to FusionGraph, which we built at my previous company. The core idea is: for a complex RAG system to perform well, the index structure must both stay close to the essence of knowledge and project domain-knowledge metadata for a specific scenario onto each stage — Retrieve, Index, Transform — for optimization.

The general approach is to do an Entity Graph or Semantic Graph during knowledge post-processing, and at the same time, when doing IDP (Intelligent Document Processing) and Parsing, to recognize layout for long documents with multi-level folders and complex sections, and consider whether to convert modality when multimodality is involved. To do this well and be able to evolve, don’t over-specialize the pipeline to a domain; instead, decompose by first principles to ensure each component’s capability keeps up.

The database is important infrastructure — for example, whether RAGFlow’s Graph and Tree structures can be natively preserved and efficiently retrieved; for Dynamic Agents Retrieve, whether the model can naturally use complex multi-level structures. The database’s high performance, index recall rate, and built-in Hybrid RRF all matter and determine the system’s floor.

Yu Jinlong: In the delivery process, data-source parsing is foundational and important, but more important is the recall (Retrieval) layer. Even with the simplest raw vectors, as long as the search terms and search statements are well constructed, you can get very good results — just at poorer efficiency. On top of this, we extended a semantic + scalar approach.

But scalars run into a bigger problem: they’re not fixed, and users themselves don’t know what scalars they need. The direction we’re researching this year is dynamic expansion of scalars, including user self-expansion and model self-generation. For example, give the model some Skills, or have the user write a scenario to generate the scenario’s scalars and store them in the database. Of course, this raises the problem of efficiently indexing thousands upon thousands of scalars in a multi-tenant system, as well as the progressive-generation problem — it’s hard to generate all scalars during pre-processing, and many need to be evaluated and progressively filled in at retrieval time. In the Retrieval stage, the way to generate multi-scalar join queries also borrows from the Text-to-SQL idea. We hope to find a general storage approach that covers 80% of scenarios. So far, semantic + scalar retrieval + dynamic scalars can cover many scenarios, so we haven’t used graphs — because graphs solve complex problems in a complex way, whereas in the AI era there may be simpler ways to handle complex problems.

Zhang Yingfeng: We are now database users, but we were once database developers. Purely from a technical standpoint, I really like the technical direction of “search while reasoning,” which I call the Attention Engine, and which I consider a kind of RAG too. DeepSeek has recently roughly realized something similar — due to GPU-memory limits it has to use memory, searching content via in-memory indexes during inference, shifting from external memory to internal memory. But from a commercial standpoint this path doesn’t work: it requires extremely low latency between retrieval and the model, which must sit behind the same switch — meaning you can only sell appliances. So we treat it only as a research direction.

From a business perspective, when we first did Infra and databases, we found we were too far from the business; later, doing RAG brought a lot of traffic, prompting us to rethink the Data+AI ecosystem. Our view is: in the past, the database was the foundation, and applications doing CRUD were written on top; now the application is the Agent, the foundation is RAG-based components, and the database supports the RAG middleware underneath. Data+AI work can’t have AI and Data each going their own way — interfaces are sometimes unclear, because the middle layer is implemented in Python, whose benefit is adapting to changing needs, with recall strategies adjustable at any time, though the efficiency problems Python brings are also a headache. The AI-era data foundation lets Infra people reach the business directly, shortening the path. So the middle layer needs a Python layer to adapt to business diversity, and once a good approach is found, it’s quickly pushed down into the database to solve the efficiency problem.

Back in late 2024 we championed cross-modal, but it still hasn’t landed, because neither the Infra nor the models are ready. Cross-modal requires multi-vector search (Tensor Search), using multiple vectors to represent an image or text for more accurate semantics and more accurate ranking — but the data balloons by two or three orders of magnitude, which is a disaster. This requires models, algorithms, and Infra to jointly solve the challenge. So we need an end-to-end system with RAG as the middle layer, which is essentially the agent’s database.

Topic 3: What exactly is the difference between Memory and RAG?

Zhang Haili: I strongly agree with Yingfeng’s mention of “end-to-end.” As a LangChain community ambassador, we mainly do application-layer frameworks, and one thing we very much want to do this year is to work with various vendors — like OceanBase seekdb — to provide truly end-to-end solutions that serve enterprises and individuals, helping them quickly build production-grade agents.

Let me briefly summarize the teachers’ understanding: when we provide retrieval capability to users, we do multi-layer collaborative optimization at the middle layer, application layer, and database layer, and common problems gradually sink down to the database to be solved. Take my own experience: when I first evangelized, I’d explain a lot of RAG flows and algorithms, but since late last year I increasingly suggest “just use this database directly,” because it has already solved many multi-path retrieval problems for us. This “precipitation” is the result of continuous joint practice between application builders and database vendors.

The next question is related: we’re often asked what exactly the difference is between Memory and RAG. What’s the difference between recalling from Memory and recalling from a database? Recently Clawdbot (OpenClaw) went from reading the file system to supporting PowerMem direct integration for more effective memory management. I’d like to ask Jiannan: what special work was done here? And how do you all understand the relationship between Memory and RAG?

Ji Jiannan: Memory was introduced to make LLMs more like humans. If everything queried is objective fact and there’s no person-to-person understanding involved, RAG can already solve the problem. But the issue is that each person understands and describes objective facts differently, and people have a memory curve — they want to remember what was emphasized yesterday. This content isn’t objective fact but is subjectively acknowledged.

For example, everyone has a friend called “Lao Wang.” Over time this “Lao Wang” may have changed, but in memory he’s always called “Lao Wang.” Here RAG can’t handle it, but Memory can, because it updates the understanding of “Lao Wang.” Is “Lao Wang” a piece of knowledge? No. Therefore, the core of Memory is personalization and being different for every person.

Whether RAG or Memory, the whole point is to build a complete solution that serves the agent and brings value to the business. We shouldn’t ask whether to use RAG or Memory, but rather think about how to combine them well to empower the business together.

Gu Siwei: We currently do Memory, and previously did Graph RAG. Memory has a broad and a narrow sense; the narrow sense refers to the more external Memory that an agent or LLM needs to retrieve. It is indeed a special kind of RAG, special in several ways:

• The raw data is a continuous message thread.
• The knowledge need is temporal, with two time dimensions: the information-creation time and the event/fact time.
• Temporality has a catch: forgetting (forget) is a feature, not a bug, and needs to combine time, access frequency, and positive/negative feedback to influence Retrieval.
• At the item level there are categories and different types, depending on the Memory’s purpose; you may need a schema to distinguish ephemeral and permanent.
• Different structures need transform relationships, which can trigger events during Retrieve or write, or be processed periodically (like the brain processing memories while dreaming).
• Multi-tenancy and sessional scoping.

If you go into the details, you’ll find it’s very different from typical RAG, but the two also have a large overlap. A RAG Engine can handle Memory, and a Memory Engine Service project will also handle documents — the boundary becomes blurry.

Yu Jinlong: I understand Memory as a kind of broad-sense RAG — nothing more than data I/O, pipeline processing, and special data structures, leaning more toward personalization.

From a product standpoint, Memory is currently used more in consumer-facing personalization scenarios. In task flows, not many users bring up Memory yet. In technical practice, Mem0 has tool-calling Memory used for long agent tasks, but its architecture looks a bit like a Context Engine, which is again somewhat different from Memory. So it feels like Memory is still a special pipeline form of RAG, with no major difference — perhaps with higher real-time-ness than RAG.

Zhang Yingfeng: Purely from a technical standpoint, there really is no essential difference between Memory and RAG — both are Retrieval. But what matters is how Memory plays its role, and that is changing rapidly.

When I talk about the Context Engine, I mention three kinds of data: enterprise-internal data, Tools data, and data generated during the agent’s use. But they’re stored in two places: a RAG-dedicated zone and a Memory-dedicated zone. Clearly, everything an LLM generates must be stored to Memory, including Skills metadata (the Skills’ own data is stored in the file system).

How to store, when to store, and when to retrieve are hard design decisions. For example, should a generated Plan be stored to Memory? As a Plan Cache it has value, but if a Human-in-the-loop intervenes and modifies the Plan, how should it be stored? And how, in the future, do we extract Skills for internal MCP Tools based on Memory data? These are all new problems.

From an Infra standpoint, RAG and Memory are no different; but from a user standpoint, Memory is important infrastructure that unlocks a great many scenarios. That’s why there are so many Memory projects (such as Mem0 and MemU), yet the definition of the Memory zone (which tables the database should have) is not yet fully consistent — reflecting that what kind of Memory an agent actually needs is still evolving. That said, what components the whole agent system needs has entered a convergence period: it’s Context.

Topic 4: Skills development practice and recommendations

Zhang Haili: You all work on Workflow, databases, or fusion solutions. Have you developed your own Skills to help users use your products better? If so, please recommend some; if not, what kind of Skills do you envision developing to serve developers?

Zhang Yingfeng: Sorry, I don’t have a particularly good recommendation at the moment. I’m more focused on how to generate corresponding Skills for a large number of internal MCP Tools — this requires a dedicated agent platform. My view is: in the future, agent platforms may have no unified standard, and all will be Coding Agents, but specific agents (such as low-code, no-code, and Workflow) may be more conducive to generating Skills thanks to their good interactivity.

Yu Jinlong: Internally we use Skills a lot, with tons in scenarios like operations, SEO, and GM. The product-and-R&D team doesn’t use them that much — mainly for code development and review. The delivery team uses them a lot: when facing users they run into all kinds of problems, and after troubleshooting the system they precipitate the fixes into Skills to aid delivery and operations. So there’s an inside joke: “delivery engineers understand the system better than R&D engineers.” They’ve built more than twenty Skills covering workflow building, troubleshooting, RAG optimization, and more. Overall, Skills feel more like natural-language workflows — more abstract, but currently still mostly natural-language-leaning Workflows. They’re fairly friendly to non-developers in production processes.

Gu Siwei: We maintain Skills-based plugins, and launched Cloud Code plugin support the day after Skills was released. Early on, without Skills, we could only build on MCP, having the plugin call MCP’s Custom Command to trigger operations and using Hooks to implement features.

We later found that MCP standardized tool calls, but in two places it isn’t as good as Skills:

1. MCP has a Prompt abstraction, implemented as slash commands that can actively invoke Workflow-like things, but not all Clients implement it, so we had to do a lot of extra work. Skills natively support both proactive telling and automatic doing.
2. Skills’ packaging approach makes combining across different tools more flexible. After we internally switched Skills from MCP to CLI, things changed a lot. For example, when having an agent do a complex Memory update/query, MCP needs multiple rounds — even interleaving isn’t good enough. But a CLI can dynamically compose a Linux shell pipeline and complete a complex operation precisely within a single turn, and an internal CLI/script can be self-contained, so after packaging it for users they naturally enjoy the complex capability.

On debugging experience, Skills are fairly general and easy to test on different platforms. We found an interesting case: the tool a Skill corresponds to has many concrete choices — how do we tune the fuzzy problem? Our approach is to use the smartest agent to do an honest, complex long-run evaluation, telling us how to improve as if chatting with a customer. Sometimes we need to look at details more end-to-end and have to serve the model ourselves, using a small model during template parsing to discover problems with the tool’s complex type definitions — which other models can overcome, but it affects performance.

Ji Jiannan: Internally, OceanBase has precipitated many Skills. A Skill is essentially a best practice — telling the LLM what the best practice is. And best practices fall into two categories: one is engineering-type for boosting work efficiency (like Cursor’s rules), the other is business-type Skills.

Skills can also be used on RAG. RAG’s efficiency and accuracy today relate to two factors: similarity and Top K. But have you all considered that, before recall, Top K and similarity sometimes can’t be fully specified and need repeated tuning, while the knowledge base keeps updating? If you write different Skills for different business implementations — for example, when a certain kind of data is needed, where to set the similarity, where to set Top K, and dynamically adjust based on the recall results — this becomes a Skill. RAG can’t handle this; it needs judgment based on the concrete recalled content. It’s a best practice for RAG.

In the past, people may have wondered whether putting RAG data into Skills would eliminate the need for recall, but I think Skills are an enhancement to RAG. As for OceanBase’s Skills, we’re prepared — including seekdb’s R&D engineers, who are here today as well — and more related Skills should be opened up in the future.

Zhang Haili: Many thanks to all the teachers for the wonderful sharing. To summarize briefly: RAG is still “good enough”! As long as you understand that the R in RAG is Retrieval, with multiple data sources like Memory and traditional databases, then with the efforts of the vendors the teachers represent, multi-path retrieval capability, application-layer improvements, and process/algorithm optimization are all advancing. I believe RAG will see even greater development in 2026.

The engineering realization of agent controllable thinking: from scattered tools to an integrated foundation

This panel clearly sketched the evolution path of AI engineering in 2026. The experts’ consensus points to a clear conclusion: building a reliable, usable agent is no longer about pushing any single component to its extreme, but about how to systematically integrate Memory, Retrieval (RAG), and Skills into a coordinated “controllable thinking” system.

Synthesizing the experts’ views, this system’s development shows three major trends.

01 RAG won’t disappear; on the contrary, it becomes more foundational and core

Its connotation is expanding from narrow document Q&A to the agent’s Retrieval capability over all contextual data — whether enterprise-internal documents, business data in databases, or the metadata of Tools and Skills, all need efficient retrieval and invocation.

Future RAG will be deeply woven into Workflows, dynamically optimized based on application feedback, and combined with technologies like Hybrid Search to achieve more precise “semantic understanding + exact filtering.”

02 The Memory-RAG boundary blurs, fusing into a data layer

From an infrastructure (Infra) standpoint, both Memory and RAG are essentially the storage and recall of data.

Their difference lies more in data characteristics and use cases: Memory leans toward personalized, temporal conversation and state memory; RAG leans toward objective, relatively static knowledge storage. But in serving agents, they together form the data layer that supports “Context.” An excellent underlying platform should be able to manage both data paradigms in an integrated way.

03 Engineering complexity sinks down, calling for an integrated data foundation

When the application layer meets ever-changing business needs through Skills and flexible orchestration, the general, performance-bottleneck complexity naturally sinks down to the underlying infrastructure. Whether multi-path retrieval, hybrid search, or the management of massive Skills metadata, all place higher demands on the capabilities of the underlying data platform.

The experts point out that the ideal path forward is to rely on a powerful data foundation that natively supports vector retrieval, relational queries, and structured memory, freeing developers from tedious multi-system integration so they can focus more on the agent’s own business logic.

Therefore, the ultimate path to building “controllable thinking” lies in choosing or building a data foundation that can uniformly carry the agent’s memory, knowledge, and state. Such a foundation, as the experts repeatedly hinted in the discussion, can fuse Memory’s personalized records, RAG’s massive knowledge retrieval, and the business data supporting Skills execution into one clean, efficient, consistent system. It makes the agent’s “thinking” process manageable, observable, and optimizable.

In the end, the concepts active at the application layer — Prompt, RAG, Skills, Memory — will all, atop such a solid foundation, better play their respective roles and work in coordination, jointly transforming the agent from a “smart conversationalist” into a “reliable business executor.” This marks AI application development officially entering the era of systems engineering, and a solid data infrastructure is the cornerstone that makes all of this possible.