Agent is moving from "answering a question" to "taking a job". Recently, the open-source AI Agent community openJiuwen provides a detailed interpretation of the HyperAgent architecture, explaining the eight characteristics that it should have for the next generation of Agent forms, as well as the open-source AgentOS sub-layer design that supports this form.
In September this year, the openJiuwen community released the HyperAgent architecture and synchronized architecture on the official website (openjiuwen.com). Last week, openJiuwen also revealed the progress of its beehive collaboration in WorkSwarm: persistent agents can access multiple IM cross-channel collaborations, people, digital employees and expert teams can collaborate in native chat rooms.
In recent years, many manufacturers and research institutions in the industry have begun to explore similar architectural directions. This interpretation is a complete explanation of the whole set of architectures: from the basic definition of Agent, the eight characteristics of HyperAgent, to the sub-layer architecture of AgentOS and the design ideas of each module, and gives corresponding open source implementations.
The "bivalent properties" of an agent
OpenJiuwen's understanding of Agent begins with a judgment: Unlike traditional applications, Agent has two properties at the same time.
On the one hand, Agent is a software program. To complete its tasks, it requires environments, data, and tools: writing code requires code warehouses, terminals, and test environments; handling business needs to connect private-domain data, complex workflows, and legacy systems; and performing physical tasks requires sensing and executing equipment. As software, it must also meet engineering requirements such as reliability, security, visibility, and traceability.
On the other hand, Agent is also an intelligent entity. It has general capabilities such as coding, office, and exhibits autonomy, personality, growth and collaboration, and capabilities and behaviors that change with the accumulation of experience. OpenJiuwen uses "digital intelligent organisms" to summarize this form of both application capability and characteristics of the entity.
HyperAgent: Thinking about the Future of Agents
In openJiuwen's view, there are two core drivers driving the development of the Agent: one is the continuous expansion of application boundaries, which places higher demands on operating environments and engineering capabilities such as DFx; and the deepening of the degree to which Agent replacements complete work, which places higher demands on the ability and autonomy of the Agent itself.
Along these two main lines, OpenJiuwen proposes that the Agent architecture should evolve from DeepAgent to HyperAgent. According to its definition, DeepAgent focuses on deep execution of complex tasks; HyperAgent further emphasizes continuous work, self-development, multi-subject collaboration, and reliable operation in real environments.
Figure 1: Two-dimensional properties and eight characteristics of HyperAgent
The eight features are as follows:
Activity: Moving from passive response to goal-driven and event-driven active execution. The agent is no longer just waiting for instructions, but working on business changes, device status, timely triggering and execution of feedback. It needs to combine long-term goals with the current environment to determine when to move forward, when to adjust plans, when to ask people to intervene.
Continuity: From Sessionful to Sessionless. The traditional Agent works as a "session" unit, the session ends, and the above context is interrupted. HyperAgent wants users to continue to interact with the Agent only around work. The system organizes meetings in the background, distributes tasks, searches for relevant contexts, identities, responsibilities, memories and outcomes so that conversations can continue across sessions, and the continuity of work is maintained by a persistent state.
Growth: from SI to RSI, then to CoRSI. SI: Self-Improvement, self-improvement) refers to the ability of the Agent to improve from feedback; RSI: Recursive Self-Improvement, recursive self-improvement) refers to the ability of the Agent to continue to participate in its own improvement after improvement; CoRSI is openJiuwen's proposed "synergistic recursive improvement, making the work product (Artifact), execution framework (Harness) and model (Model) all three mutually promote each other.
Collaborativeness: From single-agent to heterogeneous collaboration. Agents move from independent execution to multi-agent collaboration, and from the same team to "heterogeneous teams" using different models, tools and Harness. They need to discover each other's capabilities, clearly divide work, exchange results and deal with conflicts, and form ongoing working relationships around shared goals.
Determination: From the execution of individual tasks to the execution of reliable, verifiable tasks in complex environments. When the Agent moves from single to cluster, into critical business, state transitions, operating boundaries, abnormal recovery and execution records need to have a clear meaning, and execution time delays require corresponding monitoring and overtime strategies. Determination is implemented on these execution constraints, and the results generated by models are verified through business rules and validation mechanisms.
Extensibility: From "developer-friendly" to "RSI-friendly". Extensibility from access to components such as Skill, Connect, Plugin, to a combination of Agent, Agent Team and Agent App, and further to an RSI-friendly architecture. RSI-friendly refers to Harness with clear module boundaries, explicit configurations and interfaces that make it easy for RSI to understand and modify, Prompt, SkillTool, Rails, and execute strategies.
Openness: Access from the digital world to the physical environment, interacting with the Agent through tools, APIs, MCPs, CUAs, and equipment to operate digital systems and physical devices, and continuing to operate based on observation and feedback. Openness also includes Agent interacting: through open identities, capability descriptions, communication and task interfaces, supporting different frameworks, platforms and organizations in which agents discover each other, exchange information, delegate tasks and communicate outcomes, and form an interoperable Agent network.
Economics: Going from single call optimization to total cost optimization. Economics includes both Token consumption, tool call, multi-agent communication, repeat execution, deployment operation maintenance and artificial intervention. The goal of optimization is to improve the effective output of unit resources on the premise of meeting effects, time delays and concurrent requirements.
OpenJiuwen believes that these eight features need to be supported by a common infrastructure, and what openJiuwen AgentOS needs to address is how to connect development, operation, collaboration and evolution so that HyperAgent can continue to take on real work.
OpenJiuwen AgentOS overall architecture
OpenJiuwen positioned itself as AgentOS, not just a Harness framework. According to its interpretation, the general Harness framework is primarily responsible for model calling, context management, tool editing and execution cycles; AgentOS covers the entire lifecycle of the Agent from development, deployment to operation, observation, and continuous evolution, and beyond the framework, provides distributed runtime, system services, and system capability levels such as AgentOps. At the same time, openJiuwen aims to design future HyperAgent outputs that build architectures around its smart object properties and application properties, supporting active execution, continuous work, continuous growth, and multi-agent collaboration, and meet real business requirements for reliability, scalability, openness, and economics, supporting the deployment of multiple landscapes from individual desktop to enterprise deployments.
Figure 2: AgentOS logical layered architecture published by OpenJiuwen
The overall structure is divided into six levels from top to bottom:
In addition, there are two capabilities across all levels: asset market through Agent Hub, Skill Hub, MCP Hub, and Plugin Hub deployment, distribution, and repurposing capability assets; and AgentOps provides operational observation, impact assessment, identity authorization, and version governance, connecting development modulation, operational diagnostics, and continuous improvement.
HyperAgent is what it looks like in openJiuwen: a "former Agent-App".
In the design of openJiuwen, HyperAgent is modeled as a "sub-Agent-App": it can both work directly as an application and organize different types of agents internally, combining general and professional capabilities to suit different tasks and business scenarios.
Figure 3: Composition of the former Agent-App of HyperAgent
Specifically, the structure consists of four parts:
HyperAgent includes full front-end (multi-client, multi-channel) / back-end functionality, as well as built-in general capabilities such as coding, office, and can work directly as an Agent application.
HyperAgent provides expansion mechanisms such as Skill, plugins, and UI, making it easy to create an Agent App for specific scenarios and tasks.
HyperAgent is a multi-agent system that supports collaboration, containing both a Sessionful Agent that organizes tasks centered on a session, and a Sessionless Agent that works with a stable identity and continuous responsibility organization, i.e. a Persistent Agent.
HyperAgent's memory engine and RSI engine provide memory and evolutionary support for the Agent. Memory is used to accumulate work facts, user preferences and task experiences, and to co-support personalized behavior with role setting, behavior settings, and capability allocation. RSI revolves around Agent's mission trajectory and feedback, organizational evaluation, improvement, and verification, applying verification updates to Agent's skills and execution strategies to enable it to evolve continuously in continuous work.
From a deployment perspective, a HyperAgent consists of a frontend and an Agent Serving. The frontend provides user interaction input, typically running on the user end; an Agent Serving matches a HyperAgent backend instance one by one, carrying backend capabilities such as Gateway, Agents and its Workers, memory engines, and RSI.
Figure 4: Relationship between HyperAgent and Agent Serving
Agent Serving is the serviced carrying unit of a single HyperAgent back-end instance. Gateway, Agents, Workers, memory engine, and RSI together make up the back-end instance, where the required storage, sandbox, and reasoning resources are provided by the system service. The memory engine is responsible for memory processing and retrieval, while the MemoryStore provides a durable basis for memory data.
OpenJiuwen supports the distributed scheduling and operation of multiple Agent Serving through Distributed Executor, thus supporting the deployment of multiple HyperAgent.
Towards "Smart Subjects": Let Agents continue to work, collaborate and grow
With regard to intelligent subjects, AgentOS needs to support Agent to continue to assume responsibilities, maintain context in their work, collaborate with people and other Agents, and improve themselves through feedback. OpenJiuwen develops architectural design around dynamism, sustainability, growth and collaboration from the following four dimensions:
1. Activity: EDA architecture interacts with the entire workforce
When the agent moves from completing an instruction to assuming continuous responsibilities, the signals that trigger the work will extend to messages, timely tasks and changes in business status. During the execution process, there will also be continuous additional information, target adjustments and artificial intervention. The agent needs to be able to initiate actions proactively and continue to interact with people and the environment during the work process.
Figure 5: Event-driven and fully functional interaction architecture
OpenJiuwen uses EDA (Event-Driven Architecture, event-driven architecture) to organize input: continuous interaction paths are located above the Gateway, accepting front-end voice, image, and text input; messages, Cron, timely triggered and scenographically adapted business events are also accessed by the Gateway. Agents combine tasks, objectives, and context to determine when to act, and advance tasks within the scope of their authorization.
Both developers advance the front-end interaction, back-end task execution, and progress output separately. While agents execute tasks or wait for tools, users can still add requests, adjust directions, progress, and results to the original conversation via Gateway. Video-duplex has demonstrated the mechanism for front-end media interaction with the Core Agent to unravel tasks.
Asynchronous execution of tools to further organize the Agent execution path: to support asynchronous tools or backstage assignments, where the Agent submits calls after authorization, records task identification and status; the execution end advances work in the backstage, pushes back progress, completion or failure results through status queries or events. The TaskLoop aggregates these results and continues execution after the task is completed. Mechanisms such as open sessions_spawn, sessions_list provide backstage assignments and state management capabilities, and generic asynchronous tool links are shared by specific tools and execution backstages.
Additions and interruptions in execution are controlled by the FOLLOWUP, STEER and ABORT of the TaskLoop, which controls the semantic processing and controls the boundaries in effect accordingly. Asynchronously waiting for the interaction with the predecessor to unravel, task progression still follows tool dependence, permissions, and business constraints; the ability to unravel tool tasks is determined by the execution rear end.
2. Sustainability: Carrying out continuous work with Persistent Agent
Real work often spans multiple rounds of interaction, multiple tasks and longer periods of time. Users want long-term collaboration with the same Agent, allowing it to remember the background, master progress, and actively find relevant contexts. Work continuity needs to be maintained jointly by the Agent and the platform, reducing the burden of user management sessions, and moving backgrounds.
Figure 6: Internal mechanisms of the persistent agent
Persistent Agent is used to stabilize identity to associate tasks, behavior agreements, self-memory, task states and work areas, and to inherit built-in general capabilities such as Coding, Office, etc. After receiving input, it first identifies intentions, judges whether a new task is a continuation of an existing one, associates the task in a relevant context, and then distributes the task to multiple internal workers to execute it.
Worker advances tasks, generates progress and results; Agent saves task status, product references and submit summaries for follow-up work. The platform is responsible for Session allocation, concurrent coordination and contextual resource management, allowing users to continuously interact with targets around the Agent.
Sessionless refers to the fact that users do not need to organize a Session themselves, which is sought and associated by the Agent in the context; the internal persistence of the managed Session is maintained. The basis for continuity is the continuous preservation of identity, memory and working status, and the real end-to-end integration verification by deployment with the host link.
3. Growth: Promoting synergistic regression with the CoRSI
As the business environment, tools and mission objectives continue to change, Agent's execution strategies need to be improved. Memory can accumulate experience, and growth also needs to transform experience into verifiable capabilities. With the optimization of depth, the interaction between work products, execution mechanisms and model capabilities also requires a common set of feedback and evaluation mechanisms.
Figure 7: The target structure of the CoRSI
openJiuwen summarizes this path as going from SI to RSI and then to CoRSI: from self-improvement, development to improvement, Agent continues to participate in the next round of improvement, then develops to Artifact, Harness and Model synergistic regression evolution.
Among them, Artifact optimizes processes, papers, and work products; Harness optimizes Prompt, Skill, Tools, Rails and execution strategies; Model-side improves data and model capabilities through mission feedback. Three pathways revolve around common mission goals and collaborative assessment to evaluate the impact of improvements on overall performance.
The architecture is used to execute trajectories, product and user feedback to generate candidate schemes for input, evaluation and diagnosis, verify quality and cost in isolated environments, and then release versioned results through verification. After the improvements, Agent continues to participate in diagnosis, program generation and verification, forming recursive closures. Currently, openJiuwen has unveiled Artifact optimization interfaces and AutoHarness mechanisms, with model-side collaboration evolving in a zero-line architectural direction in the diagram.
4. Collaborativeness: Collaboration with Agent isomorphism in bee cluster structure
Complex work often spans research, development, analysis, and verification, requiring collaborative expertise. Existing agents in the enterprise may also use different models, harnesses, and tools. As the scope of work expands, agents need to be able to understand the division of labor, interconnect products, negotiate progress, and accomplish goals with people and other agents.
Figure 8: Structure of collaboration between heterogeneous groups of bees
openJiuwen collaborates with the Swarm Engine Organization: share the objectives, history and work products in the context of the group, coordinators work according to roles, task dependence and acceptance conditions, messages are directed to awaken members. Specialist agents or expert teams perform tasks separately, reassemble results, verify, and bring feedback back to the collaboration space.
Asynchronous collaboration is accomplished through member adaptation and collaboration contracts. Different models, harnesses, executors, and professional tools can be accessed through supported external CLI, team MCP, and communicate messages, mission status, and products by appointment. Access scope is determined by the specific adapter and authorization configuration.
In this architecture, the worker within the agent performs the sub-tasks of the agent; the beehive organizes the collaboration between the independent agent and the agent team. The two layers of mechanisms combine to allow the hyperagent to perform both single-unit generic capabilities and specialized work around complex target organizations.
Application Attributes: Bringing Agents into the real business environment
To get HyperAgent into a real business, it needs to be adapted to complex systems, continuous expansion capabilities, and stable operation in clustered and multi-calculus environments. To meet these application requirements, openJiuwen builds a corresponding operating infrastructure and system services around certainty, scalability, openness and economics.
1. Reliability: Support for reliable execution in distributed operation
Enterprise tasks often span multiple systems and last longer, requiring response to concurrent requests, resource fluctuations, wait and failures. Businesses are concerned both with whether tasks are completed and with execution delays, failure recovery and process tracking. Here, certainty is expressed as execution reliability, behaviour controllability, state verifiability, and operational process observability.
Figure 9: Logical architecture of distributed running time
OpenJiuwen uses the idea of separating computing from persistent states: on-demand scheduling of computing instances, work files, business records, and checkpoints; Checkpoint, a snapshot of the operating state that can be restored; stored by the application; work at the application level based on the task state; continuity of the product with the historical record; and operating environments based on checkpoint recovery; two types of separate state management.
Elastic sandboxes combine task needs, simultaneously limiting execution resources with node capacity allocation, and regulating capacity through preheating, on-demand creation, and vacuum recycling. Meeting pros and cons with concurrent control management of execution orders, metrics, logs, and call chains help locate clogs and failures, verify operations, and restore results. Key business operations also need to be combined with real business status verification to form manageable execution locks.
2. Extensibility: Extensibility of the controllable plug-in mechanism with "RSI Friendly"
Enterprise Agents need both access to new skills, systems and collaboration units, and to improve their own Harness based on feedback. The expansion mechanism is therefore geared simultaneously to developers and RSI: to make the capabilities easier to access, combine and manage, and to make Harness easier to understand, modify and verify, effectively improving continuous embedding into replicable versions.
Figure 10: Controllable plugin mechanisms with RSI friendly expansions
The controllable plug-in mechanism supports Skill, Connect, Plugin, Agent, Agent Team, and Agent App to access and combine according to their respective contracts, achieving on-demand installation through declaration, registration, versioning, and lifecycle management. Rails and authorization strategies restrict specific calls in operation, and the execution rear end provides corresponding operating boundaries to maintain manageable expansion capabilities.
RSI-friendly expansion point design focuses on the convenience of RSI modifying Harness. Prompts, context processing, Skills, Tools, Rails, and execution strategies are organized into boundary-clear, configurable, locally replaceable modules, and provide locationable execution trajectories and evaluation inputs. RSI identifies problems, selects location modification, configuration or component implementation, and reduces the cost of understanding and modifying Harness.
Modifications are completed in independent workstations, forming candidate versions through contrast evaluation and regression verification, and then extending packets or code PR into the controlled release process. Evaluation results, version differences and the subsequent iteration of running feedback support, allowing the expansion point to serve both artificial development and continuous evolution of the RSI.
3. Openness: Increased control of the digital world and the physical world
As the Agent takes on more practical tasks, it needs to be able to access business systems, operate software interfaces, and perceive the state of the device and drive the device's actions.
Figure 11: Open architecture
In the digital world, Agents connect data sources and business systems through Connect, tools, APIs and MCPs, and through CUA operate browsers and desktop application interfaces; business services such as accounts, payments can also be accessed on a case-by-case basis.
In the physical world, the device access and execution channels are responsible for associating the specific device, converting the action request of the agent into the device command, and returning the device status and execution results to the agent. The architecture continuously expands the terminal, external, and other device types through adapters, with specific execution capabilities determined by the device interface and backend.
AopenJiuwen also proposed the ADF Agency Device Foundation's infrastructure direction to provide a unified abstraction of capabilities for description, device access, action calling and state feedback. CUA, tool and system connectivity, device control, and other capabilities together form the "observation, action, action, feedback" environmental loop that supports Agent to continue the task based on actual execution results.
4. Economics: Optimizing task costs through computational proficiency and modeling
The costs of agents are distributed across multiple domains, such as reasoning, tool execution, environmental preparation, and data access. KV replication, sandbox preparation, and general computational scheduling in multitasking tasks are intertwined, and different tasks require different modeling capabilities.
One is computational affinity: computational intelligence, storage and computational synergy, which is the process of guiding, coordinating computational intelligence, storage and computational resources, reducing the costs of repeated computation, environmental preparation, and data transfer at the stages of Agent tasks.
Figure 12: Three types of collaboration in arithmetic
Intelligent computing collaboration: with reasoning at the core of active KV management, combined with Agent's reasoning, tool execution and waiting phases, planning logical KV capacity and context growth, by requiring access, suspending and restoring KV reuse opportunities, reducing pre-filled repetitions. Model execution and physical KV blocks are allocated and recycled by the reasoning engine.
Storage synchronization: focus on sandbox scheduling, incorporating storage locations of environmental snapshots, recoverable nodes and caching reuse conditions into the distribution of the environment. Based on the type of snapshots and back-end capabilities, organize sandbox recovery and node selection, and connect to workstations and durable data access, reducing environmental reconstruction and data transfer. Further combining cross-data to optimize the cost of access to sandbox locations is an extension of this synchronization mechanism.
Calculative synchronization: focusing on scheduling tasks with general computing resources, executing resource arrangements based on concurrent needs and resources conditions such as CPU, memory, combining node constraints, session proximity, instance preheating and vacuum recycling, improving Agent rear-end, tool execution and resource utilization in sandbox environments.
The second is model routing: matching tasks with model capabilities, that is, choosing the right model for each call at each step. The strategy can revolve around task capability requirements, delays, budget and model availability design, matching call targets in local, private and cloud models, and deploying and evolving according to business scenarios.
Figure 13: Selection of model routes and feedback loops
Model Router receives requests via the route, reads state snapshots provided by the StateProvider, and generates model selection results by the AlgorithmProvider. Algorithms and states can be accessed through their respective interfaces, allowing them to switch strategies according to tasks and deployments.
The actual model calls are executed by the host. After the host receives a response, the call results, delays and available cost statistics are backed up by a report; model calls, retests and task advances are still organized by the host. Strategic effects are assessed based on the success rate of the complete task, resource consumption and end-to-end time delays.
OpenJiuwen's typical deployment method
Based on the same set of HyperAgent modeling and AgentOS sub-layer, openJiuwen can organize individual desktop and enterprise distributed deployments according to the scenario. The two formats use different resource organizing methods, following a modeling relationship of "a HyperAgent consisting of a front end and an Agent Serving".
(1) Personal desk: for everyday coding and office
Personal desktop deployments focus on coding, office and personal knowledge processing scenarios. The front end can run on the same device as Agent Serving, Serving carries backend capabilities such as Gateway, Agents and their internal Worker, memory and RSI, and users interact with HyperAgent continuously through the client.
Figure 14: Personal desk deployment of references
(2) Distributed enterprise: multi-applied and scalable
Enterprise deployments focus on multi-person collaboration, multi-business applications, and continuous running tasks. The user runs through front-end or Channel access, the HyperAgent rear-end runs in an enterprise cluster. Each Agent Serving carries a single HyperAgent rear-end instance, and the Distributed Executor provides distributed support for multiple Serving operations.
Figure 15: Corporate distributed deployment references
Clusters will separate the computing from the sustainability status of the organization: operating nodes take on the computation, storage services save work data, task records and memory data, and manage the app-named space and access boundaries. Sandbox and execution environment allocate resources according to task needs, supporting scale execution through capacity management, concurrent control and recycling mechanisms.
The model reasoning service and the corresponding hardware resource pool are deployed independently, accessed via model interfaces, and routed via real-world hosts and compatible reasoning back-end configuration models with computational parity. The AgencyOps focus provides operational observation and diagnosis to help analyze task effects, resource consumption and execution time. Business capabilities, Agency operational capacity and reasoning resources can be extended according to their respective loads.
Flexible combination of location and resource selection
Agent backend, model services, tools and device execution can be deployed separately. HyperAgent on the desktop can call remote models, and HyperAgent in clusters can also access external systems or devices via an adapted connection. CUA's native adaptations and interface operations need to be configured in the target desktop environment and meet the corresponding connection, session and authorization conditions.
What is the meaning of this verse?
From the launch of the architecture in September, to recent groundbreaking progress in beehive collaboration, and this full interpretation, it can be seen that openJiuwen's starting point is to see Agent as a "digital subject" that needs to run for a long time and continue to grow, rather than just a one-time call process. Around this judgment, it takes into account the needs of active execution, cross-session continuation, self-improvement, heterogeneous collaboration of these "intelligent subjects" with reliable execution, controllable expansion of the environment, cost optimization of these "engineering" applications, and the integration of the same set of AgentOS sub-layer architectures.
The interpretation also makes a clear distinction between open-source implementation and the target architecture: for example, the model-side collaboration of CoRSI is still evolving, and the end-to-end integration of some components is also subject to deployment-scenario verification. As Agent gradually enters critical enterprise business, open-source exploration of OpenJiuwen AgentOS, and its location in real-world scenarios, deserve continued attention.
Related links
OpenJiuwen's official website (including HyperAgent architecture):
WorkSwarm website and download:
GitHub is open source:https://github.com/openJiuwen-ai
AtomGit has opened a source code warehouse:
