openJiuwen Open-Source AgentOS: Enterprises Are Starting to Need an “Operating System for Agents”

openJiuwen recently released and open-sourced an enterprise-grade AgentOS that brings multi-agent collaboration, self-evolution, compute scheduling, security isolation, and fault recovery together in one foundation. The project was built by teams from Huawei’s 2012 Laboratory, Huawei Cloud, computing, devices, and computing power, together with universities, enterprises, and community developers. Its goal is clear: to turn agents from demo-ready applications into enterprise production systems that can run over the long term.

What makes this release worth watching is not that it adds yet another agent development framework. It is that openJiuwen is trying to take on the most troublesome layer of work involved in bringing agents into production.

Enterprises rarely lack a demo that can call a large language model, search a knowledge base, and execute tools. What they really lack is a way to handle the hard questions when dozens of agents are working on tasks for different departments at once: Who breaks down the tasks? How is context passed along? How are permissions constrained? Where does execution resume after a failure? And can operational experience be retained? Most traditional agent frameworks focus on “getting a workflow to run.” AgentOS aims to “keep a fleet of workflows running continuously, reliably, and audibly.”

Multi-Agent Collaboration Is More Than Opening Several Model Sessions

In openJiuwen’s design, multi-agent support is built in. The system can use JiuwenSwarm’s swarm collaboration mechanism and workflow orchestration to break complex tasks into subtasks, then assign them to agents with different roles, tools, and contexts for parallel execution.

For example, an enterprise operating analysis report could be divided into data extraction, anomaly detection, industry research, conclusion review, and report writing. Different agents handle their respective parts, while a coordinating agent manages dependencies, execution order, and result aggregation. Humans can step in at critical points, such as confirming data definitions or assessing risk.

This is not the same as chaining multiple large language model calls in a single workflow. At a minimum, a production-grade multi-agent system also needs to address questions such as:

• If a subtask times out, should the entire process fail, should only that subtask be retried, or should execution continue with a different model?
• How can conflicts be avoided when multiple agents modify the same business state at the same time?
• If an upstream output is incomplete, is a downstream agent allowed to fill in the missing information on its own?
• Can sensitive data be passed across agents, departments, or tenants?
• After a human approval step, can the task resume from where it left off instead of rerunning from the beginning?
• Can each conclusion be traced back to the model, tool, and data source that produced it?

Architecturally, AgentOS is closer to a control plane for an agent cluster. Large language models still handle understanding and generation; tools perform specific actions; and AgentOS manages scheduling, state, permissions, and runtime governance.

graph TD
    A[Enterprise task] --> B[Task planning and decomposition]
    B --> C1[Retrieval agent]
    B --> C2[Analysis agent]
    B --> C3[Execution agent]
    C1 --> D[Shared context and memory]
    C2 --> D
    C3 --> D
    D --> E[Validation and human approval]
    E --> F[Business systems]
    E --> G[Traces and experience store]
    G --> B

This approach can be effective for complex tasks, but that does not mean more agents are always better. Each additional agent adds a model call, a context transfer, and another potential point of failure. For business processes with clear rules and fixed steps, a conventional workflow is often cheaper and more reliable. Multi-agent systems are best suited to scenarios where task boundaries must be determined dynamically, stages can run in parallel, specialized roles differ significantly, and plans may need to change mid-process.

“Self-Evolution” Does Not Mean Letting a Model Train Itself

Another capability openJiuwen highlights is self-evolution. The term can be misunderstood as meaning that an agent automatically modifies model parameters. In practice, it is more engineering-oriented: the system records execution traces, failure cases, user corrections, and final feedback, then uses mechanisms such as reflection, textual gradients, prompt optimization, and experience extraction to update prompts, skills, tool-use strategies, and collaboration patterns.

In simplified terms, a task no longer has just two ends, “input” and “output.” The system retains the full process: why the agent chose a particular tool, what parameters it used, where it deviated from the goal, what the user changed, and whether the final result was accepted. The system can then distill structured experience from these traces, making it available for retrieval and reuse on similar tasks.

This turns experience that enterprises previously left scattered across chat logs, manual reviews, and configuration files into data that can feed back into the runtime loop.

openJiuwen proposes using bad-case trace analysis and “textual gradients” to continually optimize prompts. Here, a textual gradient is not a numerical gradient used in neural network training. Instead, an evaluator describes in text how the current strategy deviates from the target, and the system uses that description to produce a targeted change. Compared with rewriting a prompt at random, this is more like fixing code with an error report in hand.

Tools and skills can also enter the same feedback loop. When an agent behaves unexpectedly or a user corrects a step, the system can turn that signal into input for skill improvement, allowing previously static operating instructions to evolve over time.

However, self-evolution is also the riskiest part of the system. Once incorrect experience is written to shared memory, its impact can be much broader than a one-off hallucination. An automatically optimized prompt might perform better on one dataset while breaking other scenarios. In enterprise deployments, self-evolution cannot mean automatic production rollout. At a minimum, it requires version control, offline evaluation, canary releases, rollback mechanisms, and human approval.

In other words, an agent can propose improvements, but whether they enter production should still be determined by a predictable engineering process.

AgentOS’s Core Value Is Really Runtime Governance

openJiuwen lists compute affinity as a native AgentOS capability. Through hardware-software coordination, resource scheduling, and inference optimization, it aims to improve the utilization of underlying compute resources. Previously published information indicates that JiuwenSwarm achieved about 30% token savings in specific complex-task scenarios, with a success rate above 90% for complex tasks. These figures are compelling, but the public materials do not fully specify the test datasets, model combinations, concurrency levels, or comparison baselines. They are therefore better treated as results from a particular stage of the project, rather than performance guarantees that can be applied directly to every enterprise scenario.

Agent workloads differ significantly from ordinary online inference. A request may run for tens of minutes, interleaving model inference with database queries, browser actions, code execution, and human confirmation. The GPU may not be busy throughout, but the task state must remain available. Assigning a full set of resources to each request can easily leave expensive compute waiting on external I/O.

If AgentOS can recognize task stages and dynamically schedule resources across inference, tool execution, and approval waits, it could significantly reduce costs. Compared with simply shortening prompts, this kind of runtime optimization is closer to the long-term solution enterprises need.

At the same time, once an agent can call business systems, the security boundary cannot rely on the model “behaving itself.” The enterprise-grade capabilities openJiuwen describes include multi-tenant isolation, secure sandboxes, authentication, fine-grained permissions, constraints on tool calls, safety guardrails, auditing, and fault recovery.

The most important of these is dynamic access control based on user intent and task context. Traditional systems usually grant an application a fixed set of permissions, but an agent’s execution path changes with the task. If a reporting agent is given permanent write access to an entire filesystem or database just because it occasionally needs to export a file, the risk can quickly grow. A more appropriate approach is to generate a least-privilege permission set for each task and automatically revoke it when the task ends.

This is also the fundamental difference between enterprise agents and personal agents. A personal tool can get away with “try again if it fails.” An enterprise system must answer questions about accountability, data boundaries, and audit evidence.

From Framework Competition to Infrastructure Competition

The agent ecosystem is not short of orchestration frameworks. LangGraph emphasizes stateful graphs and resumable execution; AutoGen and CrewAI specialize in role-based multi-agent collaboration; and cloud providers are packaging models, knowledge bases, tool calling, and observability platforms as managed services. openJiuwen’s differentiation is to combine multi-agent runtime, self-evolution, support for domestic compute, and enterprise security in a single open-source foundation, with an emphasis on private deployment.

According to disclosed deployment information, the openJiuwen community project has been commercially adopted by more than 30 industry partners across fields such as finance, research, and manufacturing. China Postal Savings Bank built an agent platform on its multi-agent architecture for dynamic intent recognition, intelligent routing, and question answering. Huawei’s manufacturing MES+ system uses it for production management, warehouse and delivery operations, planning and scheduling, and material-shortage alerts. The platform has also been integrated with HarmonyOS Xiaoyi and related open platforms.

These examples say more than yet another general-purpose chatbot. Banking and manufacturing systems have clear permission boundaries, audit requirements, and recovery needs. Agents in these environments cannot merely offer suggestions; they may trigger real business processes. Once a system enters this kind of environment, a few points on a model leaderboard are often less important than whether the system can control failures.

openJiuwen also brings AgentOS to appliance-style deployments. It combines a unified agent gateway, a distributed runtime foundation, the WorkSwarm office and programming workbench, and SystemAgent to shorten private deployment and adaptation cycles. The official claim is that end-to-end private deployment can be completed within hours. This direction fits the procurement and deployment practices of large enterprises in China, but actual deployment speed still depends on identity systems, data sources, internal networks, and existing business interfaces. Installing the foundation is not the same as bringing a business system live.

Open Source Is a Starting Point; Compatibility Sets the Ceiling

The biggest challenge for AgentOS as enterprise infrastructure is not its feature list, but the boundaries of its openness.

Enterprises will not use only one model, nor will they move all their data to a new platform. A sustainable AgentOS must allow developers to replace model services, vector databases, memory components, evaluators, and observability systems, while connecting to existing ERP, MES, CRM, knowledge bases, and permission centers through stable interfaces. If the plugin system works best only within a single hardware and software ecosystem, AgentOS will ultimately look more like a complete solution than a general-purpose foundation for the industry.

Open source provides a necessary condition: enterprises can inspect execution paths, deploy the system privately, and adapt the scheduling, security, and integration layers to industry requirements. But open source alone does not create an ecosystem. The project still needs to demonstrate several things:

1. Whether switching between models and compute backends can genuinely be done at low cost.
2. Whether agent traces, memory, and skills have stable data formats and can be migrated.
3. Whether self-evolution results can be evaluated reproducibly, approved, and rolled back.
4. Whether multi-agent systems can recover reliably under high concurrency and long-running tasks.
5. Whether community contributions can influence the core roadmap, rather than remaining peripheral plugins.

The broader industry trend is that agent competition is shifting from model capabilities to systems engineering. Models determine the upper bound of a single inference; AgentOS determines whether that capability can enter enterprise workflows at a reasonable cost, with controlled permissions and reliable service.

That is where the significance of openJiuwen’s open-source release lies. It has not solved every problem agents face, but it has brought collaboration, memory, evolution, compute, and security within a single system boundary. This shows that the industry’s focus has changed: enterprises are no longer asking only what agents can do. They are starting to ask what happens when agents fail, how experience is retained, and who manages hundreds of agents.

That is closer to real deployment than releasing another demo that merely looks intelligent. Still, whether AgentOS becomes widely adopted infrastructure will ultimately depend on cross-model compatibility, production reliability, community activity, and verifiable cost benefits. The architectural concept is in place; the next question is whether it can prove itself across the real systems of different enterprises.

References

• openJiuwen GitHub organization: Entry point for openJiuwen open-source projects, core components, and community code.
• openJiuwen Agent Core: Repository for core agent development and runtime capabilities; useful for verifying the project’s implementation and release progress.