LangChain's Crash Course? Using the Harness to Explain the Value and Practice of an All-in-one Data Foundation

Author: Shang Zhuoran, ASF Member & OceanBase R&D

Last week, Zlatan published an article analyzing how LangChain — the company behind the mainstream Agent framework — moved to build a database from scratch. One fact stands out: the Agent race is quietly shifting from the model layer to the data layer. When agents generate massive amounts of semi-structured, high-frequency-write, long-lifecycle trace data, traditional database architectures inevitably struggle; and when data is shuttled back and forth between observability platforms, vector stores, and caching systems, the efficiency of the “accumulate → distill → feed back” loop takes a serious hit.

This reveals a key divide: building a database downward from an Agent framework, versus connecting an Agent framework upward onto a mature database, start from different points and have vastly different cost structures. The latter means that data is a native citizen from the very first line of code — running, recording, distilling, evaluating, and feeding back all happen within the same foundation, with no loss from cross-system shuttling. This is precisely where the value of an All-in-one data foundation lies — making the agent’s data loop an “internal loop” rather than a fragmented engineering jigsaw. This article starts from the definition of the Harness, draws on the design practice of the open-source project Bub to explore the layered philosophy of agent architecture, and ultimately lands on the technical path toward a database-native Harness — along with OceanBase’s exploration and value in this area.

1. Understanding the Composition and Relationship of Agent and Harness

The complete form of an Agent can be expressed as “Model + Harness.” The Harness covers all the engineering components outside the model — by analogy to a harness on a horse, the Harness is the full set of tools a person needs to steer the model to its destination, including reins, saddle, and route. Translated to the technical layer, that’s the feedback mechanism, the recording system, and the training method.

The Harness itself has a clear layered structure. The first layer is provided by the Coding Agent builder or the SDK vendor, including the base tools and external interfaces; the second layer is where users extend the components they need on the business side, such as bringing in a RAG system, a Memory system, or BI pipelines and other business logic.

A diagram of the Harness's layered structure

In agent scenarios, the model itself is not a continuously stateful system — it returns a response based on a request, without being aware of any specific business state. What truly lets an agent work reliably within a product and a team is the set of responsibilities the Harness takes on: context management, tool invocation, state recording, run-trace tracking, effectiveness evaluation, and data flow.

Along the way, we gradually identify and abstract out certain key elements, which we define as “Primitives.” For example, the System Prompt, Skills, task-completion methodologies, and inter-agent communication mechanisms are all important primitives that accumulate through practice. Standardizing these primitives and folding them into the Harness not only improves business performance and extends capabilities, but also gradually productizes the Harness itself.

At the same time, the data collected from the Harness is critically important. It serves both to evaluate workflow effectiveness and, after de-identification, to form standard datasets used to train the next generation of models. Once the model improves, it in turn feeds back into the discovery and optimization of the Harness’s primitives, and can even correct past behaviors — forming a flywheel of continuous improvement. The diagram below (from LangChain’s blog) clearly illustrates this loop.

A diagram of the data-loop flywheel from LangChain's blog

2. Building Extensible Agents: The Bub Project as an Example

Bub is an open-source Python Agent project on GitHub, and its design embodies a key idea for controlling agent complexity: balancing stability and flexibility through a lean kernel and plugin-based extension.

Today’s mainstream Agent products — such as ChatGPT, Tongyi Qianwen, ModelScope services, and low-code platforms like Dify and Flowise — all come with a built-in Agent Loop. But one core issue remains: an agent’s capability scope must precisely match the business scenario. Although Skills and tools can extend capabilities, you still need to assemble a tool set tailored to the specific scenario to keep task completion efficient.

Many popular products — OpenClaw, Nanobot, Hermes Agent, and the like — bundle too many features together, which brings two problems: it creates feature interference and cognitive burden for users; and for developers, it makes the system highly complex and hard to maintain (for example, OpenClaw version upgrades often trigger widespread feature breakage). This tightly coupled design is hard to use directly in production. As a result, many vendors choose to re-wrap a specific version, or go fully in-house.

Bub takes a different architectural strategy: build a lightweight kernel and extend functionality through a plugin mechanism. In other words, separate extra functionality into plugins, maintain only a carefully designed lean kernel to implement a stable Agent Loop, and gradually introduce the capabilities the business needs through feature plugins. Users only need to verify whether a plugin is working correctly; if a plugin breaks, simply remove the problematic plugin to restore service. This greatly improves maintainability.

An architecture diagram of Bub's lightweight kernel and plugin-based extension

Bub’s core design philosophy is not about how powerful any single Agent is, but about the staging of a single interaction. Whether it’s Bub’s built-in Agent or an externally introduced Codex or LangChain, all can get the job done. Bub breaks the interaction into clear stages: conversation-state construction, prompt assembly, the Channel’s Input/Output definition, and so on. This staged decomposition makes flow control possible, exposing entry points for each stage through Hooks rather than piling all the logic inside a single Agent.

One key design is decoupling the Output’s mandatory binding. Traditional systems strictly bind the message reply to the input Channel, whereas Bub allows the Agent to “stay silent” in certain scenarios — returning no message. This looks like a flaw in a personal-assistant scenario, but in multi-person or multi-Agent collaboration, silence that avoids noise is actually a friendly feature.

Right now, the community is producing a series of approaches to promote standardization and modularization of agent design, for example:

  • Agents.md: used to inject system- and task-related prompts.
  • Skills: distill general SOPs (such as document writing or code review) into distributable assets, without hardcoding them into the Agent Loop.
  • MCP (Model Context Protocol): provide, via plugins, various IM Channel adapters, scheduled tasks, AG-UI visual interfaces, and more.

This is precisely the direction in which mainstream Agent frameworks are evolving in 2026. The Bub project is a practical embodiment of this philosophy: with just a few hundred lines of core interface code, it builds a flexible piece of infrastructure.

3. From Context to the Data Loop: The Tape Concept and the Database-Native Harness

1. Building the Data Loop Around Tape

Tape (a core concept of Bub as well as of the AgentSeek project we’re developing) is not just a chat log. It’s somewhat similar to a Trace, recording the key facts of a single agent run.

But unlike the Trace in observability systems such as OpenTelemetry, Tape offers a cleaner view — connected, but not overly focused on detail. Its unique value lies in:

  • It’s both observability data and a context model: Tape carries the observability of critical tasks while also serving as the agent’s runtime context model. This means humans and AI can collaborate on the same data view. An agent can review its own behavior by reading its own Tape.
  • It empowers agent introspection and problem diagnosis: traditionally, when an agent errs, an engineer has to troubleshoot through an observability platform. With Tape, a user can talk directly to the agent and ask, “Why did you just fail?”; an engineer’s troubleshooting likewise becomes a natural conversation with the agent, because the root-cause information is already built into its context.
  • It supports automated evaluation and analysis: based on Tape records, an agent can autonomously compare different models — or the same model across different tasks — to perform automated comparative evaluation, without relying on human-facing dashboards.
  • It serves model training: through de-identified, formatted export, Tape can also be conveniently turned into task-specific datasets for model training and fine-tuning, truly closing the data loop from context and observability all the way to model training.

2. Why We Need a Database-Native Harness

Agent systems typified by OpenClaw rely heavily on the file system for their data (various .md files, for instance). While this is friendly for humans and agents to read, it’s extremely unfriendly for processing, analyzing, and handling data. Modern context engineering needs to build a layer of Memory on top of the raw task trace — serving as both a summary of and an index into that trace. The lossless-context plugins that later appeared in the OpenClaw community, such as lossless-claw, began using databases like SQLite to link the call chain and memory together — which is precisely why a database is necessary at this stage.

Making the database the cornerstone of the Harness means all agent runtime data is, by nature, a “first-class citizen” in the database. Observability, data extraction, and archival analysis can all leverage the database’s native capabilities, without maintaining a complex, heterogeneous data stack (such as MySQL + Elasticsearch + Redis). This provides a unified data foundation, simplifying the architecture and reducing operational cost.

OceanBase is an excellent choice for this path. Why? Its core advantages include:

  • AI-workload-ready: OceanBase and its derived tooling are all optimized for AI Agent workloads, providing vector search and fusion-search capabilities. SQL capabilities combined with vector and full-text search are all built in, with no need to maintain multiple separate technology stacks.
  • HTAP capability: as a Hybrid Transactional/Analytical Processing database, it can directly support real-time queries and complex analysis over agent runtime data, powering the data loop.
  • Unified storage with seamless scaling: data of all kinds can be stored uniformly, supporting exploration of workloads like run-trace analysis and retrieval. From edge-side standalone deployment (such as OceanBase seekdb), it can scale seamlessly to a distributed OceanBase cluster, providing a smooth upgrade path for business growth.

4. AgentSeek: Exploring the Database-Native Harness

ModelScope’s Endless Context project is an OpenClaw-style agent case built on the Bub and Tape concepts, and is also a simple manifestation of a database-native agent. Through continued exploration of agent architecture, the OceanBase team is building an Agent Harness fully based on database-native capabilities — AgentSeek (launching May 30; reserve an on-site spot via the link at the end).

AgentSeek’s core idea: make agent runtime data a first-class citizen of the database from day one, helping users build data-loop scenarios. The project integrates OceanBase’s product capabilities with AgentSeek-related Wrappers, and is currently being actively advanced.

Conclusion

From the layered definition of the Harness, to Bub’s plugin-based extensible architecture, to the observability-and-context unification realized by Tape, and finally to the technical path of a database-native Harness — the evolution of agent infrastructure is moving from “piling on features” to “data-driven.” OceanBase’s positioning in this area is both a natural extension of its technical architecture and a response to the demand for a data foundation in the AI era.


On May 30, AgentSeek will be launched live at the OceanBase × LangChain Meetup

Registration poster for the OceanBase × LangChain Meetup

Scan the code to reserve an on-site spot