Most agents today are brilliant amnesiacs. They can plan, call tools, and write code in a single session, but the moment the chat ends, the lesson is gone. Run the same industry-research task ten times and the agent starts from scratch on the eleventh. The user’s corrections, the dead-end paths, the workflow that finally worked — all evaporate.
HugAgentOS, an open-source project from Zhejiang University’s Provincial and Ministerial Co-construction Collaborative Innovation Center for Artificial Intelligence, treats that amnesia as an operating-system problem. It does not just give the agent a longer memory stick. It builds a stack that turns execution traces into reusable capabilities, composes those capabilities into workflows, and wraps the whole process in attribution, replay verification, and rollback. The goal is not a smarter turn, but an agent that becomes more competent the more you use it.
What problem is actually being solved?
The HugAgentOS team argues that raw memory is not enough. Experience only becomes ability after four conversions:
- Retention — the trace of a successful run must be kept, not buried in a chat log.
- Structuring — recurring paths must be lifted out as explicit, reusable assets.
- Transfer — single skills must be composed into end-to-end workflows for whole task classes.
- Closed-loop feedback — improvements must be attributed, verified in isolation, approved, and reversible.
Long-term memory solves retention, but it skips the other three. That is why agents keep repeating the same mistakes and the same planning loops. HugAgentOS builds all four conversions into the OS.
The three self-growing engines
The system splits the agent harness into three engines that can each improve from experience.
1. Memory engine — keep what matters, forget the noise
The memory engine stores execution traces, merges duplicate content, and fades stale information. It is not a dump of every token ever generated; it is a managed record of what actually happened. That record becomes the training set for the next two engines.
2. Skill engine — turn accident into playbook
When the same kind of task succeeds repeatedly, the skill engine distills the common path into a reusable skill, similar to a SKILL.md file. The asset includes checkpoints and failure notes, so the agent knows not just what worked, but what previously failed. In the project’s own example, a repeated industry-research request produced a “Industry Research Playbook” with three hard rules: unverified companies do not enter the table; positive sentiment does not equal no risk; patent count does not equal technical strength. Those rules came from the user’s own failure history, not from a generic prompt.
3. Orchestration engine — compose skills into default plays
Real tasks need more than one skill. A research report may require a search skill, a visualization tool, a document-generation skill, and a reviewer sub-agent. When these four repeatedly succeed together, the orchestration engine packages the combination as the default workflow for that task class. Next time, the agent does not ask “which tool first?” It shows up with the whole stack.
Memory → skill → orchestration is the compounding flywheel: experience stays, becomes ability, and abilities team up.
Two guardrails for self-improvement
Self-improvement without control is recursion without brakes. HugAgentOS adds two guardrails.
Attribution gate — one failure, one owner
When a run fails, all three engines could try to fix it. The memory engine wants to record the bad state. The skill engine wants to add a verification step. The orchestration engine wants to swap the data source. If all three update at once, the result is conflicting patches.
The attribution gate sits in front of them. Its job is not to decide how to fix the failure, but whether to fix it and which engine owns it. A single failure may trigger only one responsible layer. The gate also has the right to reject the update entirely when the root cause is outside the engines — for example, a missing knowledge-base entry, a model format limitation, or an external API change.
Only after isolation replay and user confirmation does the change enter production. The user can see the evidence, the affected historical tasks, and the proposed diff in an evolution console, and can roll it back.
Ontology boundary — machine-readable guardrails
The second guardrail is a domain ontology written as executable rules. It defines concepts (e.g., company entity, risk event), relations (a risk event needs at least one evidence source), constraints (a risk query requires a verified company ID first), and workflows (high-risk analysis goes to a review committee).
Before an LLM even runs, a deterministic gate checks the action against the ontology. If the agent tries to query risk without verifying the company, the gate blocks it, cites the rule number, and returns a concrete fix path. This gate costs no tokens and responds in milliseconds. It also constrains evolution itself: new memories, skills, and workflows must pass ontology validation before they are promoted.
Analogy: from sticky notes to a playbook factory
Think of a typical long-memory agent as an employee who keeps every sticky note from every meeting. They can find old notes, but they still plan each project from zero.
HugAgentOS is closer to a living operations manual. Every project updates the manual: successful sequences become standard procedures, recurring tool combinations become default playbooks, and every proposed change goes through a lightweight change-control process — who owns it, what evidence supports it, whether it was replay-tested, and how to undo it.
Why this matters beyond the lab
Agent adoption in enterprises has been bottlenecked by two things: the cost of repeated failure and the inability to audit why an agent did what it did. HugAgentOS attacks both. If you are comparing agent tooling, pair this with our agent tool directory and Manus hands-on review.
- Compounding, not recurring cost. Every completed task leaves an asset, not just a transcript. Over time the marginal cost of repeat tasks falls because the agent already knows the playbook.
- Auditability by design. Attribution, replay, and rollback turn the black box into a version-controlled capability stack. That matters for regulated or high-stakes workflows.
- Open infrastructure. Because the project is open source, the pattern can spread into agent frameworks, observability tools, and compliance products rather than remaining a single vendor’s feature.
If the first half of 2026 was about bigger context windows and cheaper inference, the second half looks increasingly about capability infrastructure: how agents remember, improve, and stay bounded. HugAgentOS is a concrete signal of that shift.
How to try it
- Code: github.com/ZJU-REAL/HugAgentOS
- Releases: GitHub Releases (desktop clients for Windows, macOS, Linux)
- Site: hugagentos.com
A practical starting loop:
- Pick a repetitive task, such as a weekly industry scan or competitor brief.
- Run it five to ten times with the self-evolution layer enabled.
- Review the distilled skill in the skill library and edit the checkpoints if needed.
- Turn on the attribution gate so only one layer changes per failure.
- Define one small domain constraint — for example, “every risk claim must cite a source” — and let the deterministic gate enforce it.
The point is not to replace the LLM. It is to make the LLM’s output accumulate into something the team can own, review, and reuse.
