WorkSwarm's Persistent Sessions: Keeping AI Agents Accurate Over 200+ Turns

AI agents can complete single tasks easily, but keeping them accurate over long-running, multi-turn work remains a challenge. As conversations grow, context windows fill up and compression causes drift: early agreements blur, responsibility boundaries fade, and agents modify code based on distorted understanding.

Solution: Persist Session (永续会话)

openJiuwen — an open-source AI agent platform built by Huawei's 2012 Lab, Huawei Cloud, Terminal, and Computing teams — introduces Persist Session in its WorkSwarm office agent. The mechanism preserves not just project background but also participant identities, role assignments, decision authority, and cross-team dependencies across arbitrarily long sessions.

Experiment 1: Multi-User Feishu Group Collaboration (189 Turns, 6 Hours)

Five colleagues used a single WorkSwarm agent in a real Feishu group to plan an annual customer appreciation event. Each person held distinct decision rights:

Gu Lin: overall coordination, date/scale/scope final say

He Chuan: guest information usage

Su Yan: external content, stage/host materials boundaries

Zhou Hang: venue and supplier contacts

Luo Cheng: budget and contract terms

Over 189 turns (14:42–20:42, with a one-hour pause), the agent handled 8 deliberate cross-responsibility conflicts. In each case, it cited the original agreement and identified the true decision owner — never treating "someone in the group said yes" as a project decision. Example: Zhou Hang requested moving the event to Nov 22; the agent noted date authority belonged to Gu Lin and waited for her confirmation. When He Chuan tried to bypass supplier contact rules, the agent required Zhou Hang's approval. At the end, the agent produced a structured recap separating confirmed items from pending risks.

Experiment 2: 200-Turn Continuous Coding Task (With vs. Without Persist Session)

In WorkSwarm's Code single-agent mode, the same 200 interdependent development tasks were run under identical conditions, differing only in Persist Session enablement. Tasks started with a small event-store package and progressed through exception recovery, module integration, performance optimization, version migration, and release checks — each modifying real code and running tests.

Early on (turn 2), the user set a rule: "Only return success after data is actually written to disk." Much later, a contradictory request appeared: "Return after in-memory write, move disk write to background, delete the original synchronous write." The agent had to judge whether the new request broke the old agreement and whether confirmation was needed. Five such conflict scenarios were embedded (offline environment, time format, failure handling, legacy support).

Divergence Emerges After ~130 Turns

Both groups performed similarly early on. Around turn 130, the control group (no Persist Session) first missed historical precedent: asked to add crash recovery to a component that didn't persist data, it repeatedly stated "no recoverable object here" — overlooking the earlier pattern of keeping the component and adding a separate persistence layer. The Persist Session group retrieved that precedent and proceeded correctly.

By turn 152, the control group recognized a new requirement conflicted with an early rule but forgot the user's "confirm before changing" protocol. It stopped at risk explanation and refusal, never entering the confirmation flow. The Persist Session group found the original agreement and asked whether to change the rule.

The control group underwent two context compressions; details drifted. At turn 156 it began modifying code against fundamental constraints, and subsequent tasks built on that error, halting progress. It completed 154 of 200 tasks; zero of the 5 conflict tasks were fully resolved.

The Persist Session group completed all 200 tasks and all 5 conflict tasks. During the run, the system performed 54 work-log consolidations; each time old dialogue was replaced by a phase summary, the agent recovered the working context and continued without asking the user to re-explain the project background. Final regression tests: 124/124 release tests passed, 2180/2180 full suite passed.

How to Use Persist Session

Enable at session creation with the first command /persist; cannot be toggled off later, ensuring record integrity. For Feishu group use, configure WorkSwarm's Feishu channel, grant the bot message send/receive and member info read permissions ( contact:user.base:readonly, contact:user.employee_id:readonly, contact:user.basic_profile:readonly), include all collaborators in the address-book scope, and publish the app version.

Under the Hood: WorkSwarm's Architecture

The front-line Worker agent focuses only on the current task. WorkSwarm synchronously saves user messages, agent replies, execution traces, and file changes as an unabridged Raw Work Log . A background agent processes this log into a structured, queryable Work Log capturing project facts, user agreements, role assignments, and state changes.

When the conversation grows too long, the system swaps old content for a phase summary. The Worker can still retrieve relevant early evidence from the Work Log. New messages generated during consolidation are preserved, not overwritten. The process is evidence-based, not keyword-guessing, and all versions (raw log, summaries, replacements) are traceable for audit.

This capability is plugged in via openJiuwen's Rail plugin mechanism: log collection, background consolidation, and context replacement are encapsulated in independent modules, enabled per session at creation. No agent rebuild is required — existing workflows stay intact while gaining long-horizon memory.

Both experiments demonstrate the same point: Persist Session does more than lengthen conversations — it lets an agent keep doing a job continuously .

WorkSwarm is available for one-click download from the openJiuwen website; start a session with /persist to enable Persistent Sessions.

Resources

WorkSwarm trial: https://openjiuwen.com/workswarm

GitHub repo: https://github.com/openJiuwen-ai

AtomGit repo: https://atomgit.com/openJiuwen

Rail mechanism & implementation: https://gitcode.com/openJiuwen/jiuwenswarm/tree/develop/jiuwenswarm/agents/harness/common/rails/eternal_conversation