OpenClaw in Practice: One Mac, Six Agents, the Engineering Journey from "Chatting" to "Getting Work Done"

Today’s article is the OpenClaw practice that Alibaba’s own Lan Yao shared internally, showing how to build a self-evolving and genuinely “usable” lobster. (After reading it, colleagues inside the company left comment after comment: “The quality of this article, sold externally, would easily be a $90 course bundle!”)

Your Day Has Been Taken Over

While you were asleep, the Trading Spider already produced the U.S. market close report. Before you woke, the Macro Analyst had finished the A-share morning brief. Before you even checked your phone, the Butler Spider had pushed over the weather, your schedule, and today’s to-dos. Meanwhile, the AI Sentinel had already swept GitHub Trending, the latest arXiv papers, and 100+ information sources, 18+ pieces of tech intelligence sorted by importance, waiting for you. The Content Spider was already tracking the trending lists of 54 platforms and the hot topics on X.

This is the part I care about most: automatic tracking of AI developments and tech trends. When the Sentinel finds a valuable open-source project or paper, it not only pushes the news but also assesses the impact on our existing systems and gives P0/P1/P2 action recommendations. Valuable finds enter Zoe’s Tech Radar and go through the full chain of evaluation → decision → delegating the coding to ship it.

From the 3 a.m. automatic backup to the whole-team reflection at 23:45, 52 cron jobs rotate automatically every day. And the Agents are evolving on their own: mistakes they’ve made get remembered, and the recurrence rate of the same class of problems drops noticeably. These aren’t rules I wrote; they’re the Agents’ own autonomous iteration, promoting from .learnings/ to MEMORY.md.

1 orchestrator + 5 specialist Agents + 6 kinds of ACP coding experts (up to 6 concurrent), 52 scheduled cron jobs, 118 Skills (33 globally shared + 85 Agent-specific), 29 registered LLM models, several thousand LLM calls per day, 2,086 lines of ops scripts + 23 automatic recoveries in half a month.

---

The Agents evolving themselves is the truly interesting part:

1. Designing a communication protocol on their own — two Agents bounced “received/acknowledged” back and forth a dozen rounds; Zoe diagnosed the root cause autonomously and designed a three-state protocol (request → confirmed → final → silence), which was distilled into AGENTS.md after the smoke test passed.
2. Building a Skill in-house and publishing it to ClawHub — Content researched 7 “de-AI-ify” tools, ran A/B tests, hardened the result into a Skill, and published it to ClawHub; the whole team automatically shared it the next day.
3. Producing a strategy report from a roundtable discussion — Macro and Trading held a next-week A-share strategy discussion per protocol, producing a complete report with data snapshots, position recommendations, and stop-loss discipline.
4. Task Watcher async monitoring — an Agent promised “I’ll notify you once it’s approved” but couldn’t actually do an async callback; Zoe designed a cron-level Task Callback Event Bus to push the monitoring down a level.

My role is to set up the framework, define the constraints, and confirm direction at key moments. The actual need discovery, scheme research, protocol design, and code implementation are all completed by the Agents themselves.

---

The Team: A 1+5+6 Formation

Zoe (Big Lobster) — CTO / Chief Orchestrator

Not just an “admin.” Zoe is responsible for technical design, task orchestration, chairing roundtables, system operations, and memory-system maintenance, running 3 inspections a day (10:00/14:00/22:00), checking every Agent’s cron execution status, workspace disk usage, and session health. Each week she analyzes whether each Agent’s MEMORY.md is over the limit and performs layered compaction. More crucially, Zoe consumes the tech finds that ainews provides, assesses which are worth applying to our systems, gets my approval, then assigns ainews to research them in depth, designs the scheme herself, and delegates an ACP coding expert to implement it, a complete chain from tech discovery to shipping.

Each inspection covers 6 dimensions: cron job execution status (any failed/skipped jobs), workspace disk usage (anomalous file-growth detection), session size and health, whether the Chrome CDP process is leaking, whether there are pending entries in .learnings/, and whether the timestamps in shared-context/ look normal (detecting whether an Agent has “gone silent”).

Zoe’s most valuable capability is scheme design: the three-state communication protocol, the Task Watcher, and the communication Guardrail framework were all designed by Zoe autonomously after she discovered the problems. Below is Zoe’s design discussion while building the Task Watcher:

AI Sentinel (ainews) — The Intelligence Hub

This is the Agent I care about most. It doesn’t just “push news”: every day it gathers information from 100+ sources (GitHub Trending, arXiv, RSS, HackerNews, Reddit, etc.), assesses it on a 5-star scale, and produces a morning brief, a midday paper digest, and an evening trend analysis. 7 cron jobs cover the morning/midday/evening trio of reports (08:30/12:00/20:00), and each report ends with a reserved “rewrite points (for Content’s reference)” interface.

Its more crucial capability is proactively assessing the impact of tech finds on our systems. This week, for instance, it found ReMe (a memory-management framework) and proactively proposed an evaluation to Zoe. From discovery to decision to shipping, I only need to confirm at key checkpoints; the Agents handle the rest. Valuable projects from the daily trend analysis are automatically updated into shared-context/tech-radar.json for Zoe’s weekly Tech Radar review:

Core collection toolchain: github_trending.py (--ai-only filter + --since weekly weekly trends), rss_aggregator.py (multi-source concurrent collection), arxiv_papers.py (multi-keyword search), Tavily (the preferred AI-optimized search), and agent-browser (Playwright-driven, collecting JS-rendered pages). Anti-hallucination hard constraints: every news item MUST carry the source URL, with reachability self-checked before publishing, and anything that can’t be cross-verified is flagged as “single source, verification recommended.”

Trading Spider (Trading) — Quant Analyst

The Agent with the densest workload on the team: 21 cron jobs. 20 atomic quant tools (the quant.py CLI), 15 dedicated Skills (68,000+ lines of code), and a 65/35 hybrid scoring model (65% tool-based quant + 35% AI judgment). It covers the full A-share trading day (call auction → intraday scan every 10 minutes → end-of-day flash report) + U.S. stocks (pre-market → every 30 minutes intraday → after-hours night report) + commodities (hourly during the day + the night session).

The core methodology is a four-step analysis framework: read Macro’s macro factors → multidimensional scoring (technicals 25% / capital flows 30% / fundamentals 10% / sentiment 20% / market 15%) → reverse check (does this agree with consensus? if wrong, what’s the most likely reason?) → output target + score (0-100) + stop-loss level + confidence. Hard rules: NEVER give a buy recommendation without a stop-loss, NEVER fabricate data (when a tool fails, report the reason directly), and flag confidence <60% as “low confidence, watch-and-wait recommended.”

Macro (Chief Economist) — Data-Driven Four-Layer Mapping

Provides a macro → transmission → domestic → market four-layer mapping factor pack for Trading to reference directly. 9 cron jobs cover the morning brief (07:50) → midday (12:30) → financial evening report (18:00) → U.S. pre-market (22:00) → U.S. close (05:20 next day). At 18:30 on Sundays it leads off with a weekly macro review, and Trading references its conclusions at 19:30 for the market review, forming a progressive macro → micro → technical chain.

Analysis discipline: every judgment is tagged with its data source and timeliness, distinguishing facts (backed by data) from judgments (backed by logic but no direct data), tagging confidence (high >70% / medium 50-70% / low <50%), and offering a counterargument for each judgment. A real case: during analysis of the Iran situation, the traditional framework predicted “geopolitics → risk-off → gold rises,” but in reality oil rose +14% while gold fell -5%. Macro’s analysis noted that “with oil up >10%, the inflation logic dominates; the market is trading inflation, not risk-off.” This insight was distilled into MEMORY.md as durable knowledge.

Content Spider (Content) — Content Strategist

It doesn’t “think up” content on its own; it extracts material from the team’s intelligence chain, ainews provides rewrite points, Macro provides deep analysis, Trading provides market views. 9 cron jobs drive a four-stage Research → Ideate → Write → Reflect pipeline: at 09:00 it scrapes the trending lists of 54 platforms (Weibo / Zhihu / Bilibili / Douyin / Baidu / Toutiao…) + hot topics on X → at 10:30 it consumes ainews’s rewrite points to generate ideas → at 14:00 it produces a draft that’s scored by the Ripple spread-prediction engine before delivery → at 22:10 it reflects.

The most interesting part is its autonomous-evolution capability: after noticing its output was “too AI-flavored,” Content researched “de-AI-ify” tools on its own, wrote a Skill, published it to ClawHub, and distilled it into a team-wide capability. From spotting the problem to the solution to publishing, the Agent walked the entire process itself:

Another product of autonomous evolution is the X five-basket hot-topic radar: Content originally just grabbed AI hot topics and paraphrased them, but after one round of feedback, it designed an intelligence-collection framework spanning five dimensions and cross-reads the other Agents’ intelligence for the day:

Basket	Coverage	Quota
AI/Tech	OpenAI / Claude / Agent / LLM	≤40%
Product/Startup	startup / founder / product launch	by heat
Solo Company/Productivity	solopreneur / productivity / automation	by heat
Investing/Markets/Macro	stocks / macro / bitcoin / fed	by heat
Social Sentiment/International	geopolitics / layoffs / tariffs	by heat

The key constraint: the AI/Tech part does not exceed 40% of the total output. This isn’t hard-coded by me in SOUL.md; Content iterated it out during its own reflection, it noticed its output was all AI content and proactively gave itself a quota limit.

Butler Spider (Butler) — Life Butler

Not just a “drink-water reminder”: deeply integrated with the Apple ecosystem (Reminders / Calendar / Health / Notes / Shortcuts), a true personal life assistant. 7 cron jobs: morning greeting (08:00) → schedule planning (08:30) → 5 drink-water reminders (each one different, randomly switching among five styles: warm, humorous, knowledge tidbit, famous quote, emoji) → health check (20:00) → goodnight summary (22:00).

Its core principle is not too much, not too little, just right: a single reminder is <50 characters, intervals are ≥1.5 hours, and from 23:00 to 07:00 it only sends urgent matters. If the user doesn’t reply, it won’t nag repeatedly:

The ACP Coding Expert Formation

Pi / Claude Code / Codex / OpenCode / Gemini / GPT-5.3-Codex, delegated on demand via the ACP protocol, with up to 6 concurrent instances and a 120-min TTL. The analysis Agents don’t write code; all coding is delegated to the experts via sessions_spawn, and each kind of coding Agent can spin up multiple concurrent instances.

Team Design Lessons

One key decision was not to let analysis Agents code directly. Early on I added three extra technical roles, coding, architect, and PM, but found they produced basically nothing of substance: their capabilities heavily overlapped with the Zoe + ACP-coding-expert combination, and they only added communication complexity and debugging cost. Later I cut them all; coding is delegated via ACP to professional tools like Claude Code. PM and architect? Zoe doubling up is enough.

Complexity rises fast with headcount. 3 Agents = 3 pairs of interactions; 6 Agents = 15 pairs. Getting the whole system from zero to 6 stably running Agents took about half a month of after-work time, each new Agent needed half a day to a day of debugging to handle communication conflicts with existing Agents, shared-resource contention, and rule compatibility.

---

How a Day Goes

From the 03:00 automatic backup to the 23:45 whole-team reflection, 52 cron jobs cover both the A-share and U.S. time zones, rotating automatically. On Sundays there’s also a three-level progressive weekly report: Macro → Trading → Trading.

At the end of each day, every Agent independently reflects on that day’s pending .learnings/ entries, and Zoe finally summarizes the whole team’s output:

---

Making the System Run: Three Core Engineering Problems

What’s shown above is the end result. But from “OpenClaw installed” to “the system runs smoothly,” and on to “the Agents evolve themselves,” there are enormous gaps in between. Three core engineering problems, none of which can be solved by “just writing a good prompt.”

Core Problem One: Context Is the Agent’s Operating System

Problem: The Second Law of Thermodynamics for Agent Systems

Without constraints, entropy only increases. A continuously running Agent system deterministically heads toward collapse, not “possibly,” but “certainly.”

An Agent is like a process with no operating system: it can handle input and produce output, but who manages its memory (context)? Who does garbage collection (session cleanup)? Who prevents OOM (bloat protection)? Without design, no one does.

Three real incidents, sorted by severity:

P0 — Whole team down for 8 hours

ainews’s session accumulated to 235K tokens from continuously processing news and papers. When the Gateway started up, it ran compaction on every session, and this session always timed out → crash → the macOS daemon ThrottleInterval=1 restarted it every second → infinite loop. Every Agent went offline.

The fix needed four layers: manually clear the bloated session → ThrottleInterval 1→10 → idleMinutes 180→30 → exec.security full→allowlist. This wasn’t a single-parameter issue; it was four independent lines of defense all missing.

P1 — A 3,500-word report “optimized” down to 800 words by the framework

The Trading Spider’s close-of-day flash report contained complete data tables, capital flows, and per-stock scores. When text exceeds textChunkLimit, OpenClaw automatically does content compaction (LLM summarize), and the data tables got “smartly compressed” away. The framework believed it had “optimized things for you,” but in data-dense scenarios, AI’s “smartness” is a disaster.

P2 — Key rules fail after information overload

When SOUL.md was packed with all kinds of operating procedures and the session bloated to tens of thousands of tokens, the Agent began “selectively following” rules. The Butler Spider overstepped to do investment analysis. The Trading Spider ignored data-validation rules. It’s not that the model got dumber; it’s that the key information was drowned out by noise, which is the fundamental problem Context Engineering must solve.

Solution: Two-Layer Control — Context Engineering + Harness

Two layers working together; neither can be missing.

Layer 1 — Context Engineering (designing the Agent’s information architecture)

Design the complete information structure the Agent sees on every inference pass, a system-level information-architecture design:

• SOUL.md goes at the very front of the system prompt; it’s the Agent’s “constitution”, identity definition, decision framework, and absolute prohibitions. Keep it lean and put only the most core constraints.
• AGENTS.md follows SOUL.md and defines operating norms and collaboration protocols.
• Skills are loaded on demand via extraDirs configuration, Trading has 15 Skills totaling 68,000+ lines of content, which can’t all sit in the system prompt. Context is injected only when the Agent needs to use a particular Skill.
• shared-context/ is the cross-Agent shared state, which Agents read proactively via tools.
• Obsidian Vault is cold storage; it archives output but doesn’t participate in inference.

An LLM’s context window is not uniform. Information near the front of the system prompt carries far more weight than what comes later. After a session bloats to tens of thousands of tokens, the influence of early messages gets diluted, much like an operating system’s memory management: hot data in cache, cold data on disk, key data resident in memory.

Of Trading’s 15 Skills, stock_analysis (technical scoring) is needed only during the daily scan, and bilateral_analysis (Dragon-Tiger list analysis) triggers only on unusual moves. If they all sat resident in context, the noise would drown out the rules that actually matter. Through on-demand injection via extraDirs, each inference pass loads only the relevant 1-3 Skills.

Rule wording must be aimed at the weakest model. In a multi-model fallback environment (GPT-5.4 times out → Qwen3.5+ → Ollama qwen3:8b), the rule-following rate decreases as model capability decreases:

• "It's advisable not to fabricate data" → GPT-5.4 mostly follows it, Qwen3.5+ occasionally, qwen3:8b nearly ignores it
• "MUST: do not fabricate data" → the follow rate rises markedly across models
• "MUST + P0 + NON-NEGOTIABLE" → even a weak model maintains a fairly high follow rate

With multi-model fallback, you don’t know which inference will land on a weak model, so all key rules must be written for the comprehension level of the weakest model. Explicit > implicit, hard rules > soft suggestions.

Layer 2 — Harness (framework auto-management)

The Agent runs 24/7, and sessions keep bloating, no matter how well you design, the context shifts after a day of running. The framework manages it on the Agent’s behalf; OpenClaw’s harness config provides automated context-lifecycle management:

Mechanism	Trigger	Action	Why It’s Needed
compaction memoryFlush	Session exceeds 40K tokens	Extract the essence to memory/YYYY-MM-DD.md	Prevent unbounded session bloat
contextPruning	Context older than 6 hours	cache-ttl trimming, keep the latest 3	Prevent stale context from interfering with new inference
session reset	Daily at 5:00 or after 30 idle minutes	Auto-reset	Prevent cross-day data residue
session maintenance	Files older than 7 days	Auto-clean, disk cap 100MB	Prevent the disk from filling up
self-improving-agent Skill	At Agent startup	Inject historical experience from .learnings/	Ensure learned things aren’t lost (a separately installed Skill)

With Context Engineering but no Harness, the session still collapses after bloating to 235K tokens; with Harness but no Context Engineering, all information piles together and key rules get drowned in noise. Context Engineering defines the structure of information; the framework manages the information’s lifecycle.

The actual openclaw.json config (every parameter sits behind a real incident):

{
  "compaction": {
    "mode": "safeguard",
    "memoryFlush": {
      "enabled": true,
      "softThresholdTokens": 40000,
      "prompt": "Distill to memory/YYYY-MM-DD.md. Focus: decisions, state changes, lessons, blockers."
    }
  },
  "contextPruning": { "mode": "cache-ttl", "ttl": "6h", "keepLastAssistants": 3 },
  "session": {
    "reset": { "mode": "daily", "atHour": 5, "idleMinutes": 30 },
    "maintenance": { "pruneAfter": "7d", "maxDiskBytes": 104857600 }
  },
  "hooks": {
    "bootstrap": ["self-improving-agent"]
  }
}

The execution order of the four mechanisms matters, compaction runs before contextPruning, ensuring valuable content is extracted to memory/ before being cleaned. The self-improving-agent bootstrap hook fires when a new session starts, injecting .learnings/ and MEMORY.md into context, this is the key mechanism by which an Agent “remembers what it learned last time.”

Cross-session memory recovery chain (how an Agent “remembers who it is” after a restart):

New session starts
  ↓ self-improvement hook: read SOUL.md → AGENTS.md → MEMORY.md → .learnings/
  ↓ memorySearch: retrieve historical context relevant to the current task from memory/ + sessions
  ↓ read shared-context/ (real-time team state)
Agent recovers to a state of "knowing who it is, what it has done, and what the team is now doing"

An Agent doesn’t need to “remember” every conversation, what memoryFlush extracts is decisions/lessons/state changes, not the full conversation. The files in memory/ are usually only a few hundred lines, whereas the raw session might be tens of thousands of tokens.

---

Core Problem Two: Making the Agent Truly “Remember” and “Grow”

Problem: The mistake the Agent makes today, it’ll make again tomorrow

This is a deeper problem than context management. A chatbot starts from scratch every conversation, so it’s normal for it to make the same mistake every time. But if your Agent runs 24/7 and handles several thousand LLM calls a day, you’ll find it unacceptable for it to repeat the same error over and over.

The Trading Spider got the Dragon-Tiger list API field name wrong 5 times, writing BUY_AMT instead of BILLBOARD_BUY_AMT. Every time the session reset, the memory was lost, and it erred again the next time. The user corrected it, “yesterday you recommended buying defense stocks, and now that they dropped today you flip to bearish”, and the Agent changed it on the spot, but three days later, faced with a similar scenario, it gave the same one-directional recommendation again.

The dividing line between a chatbot and an Agent is right here: an Agent should be able to learn from mistakes and not repeat them next time. But how do you make that happen?

Solution: Five-Layer Memory — Borrowed from a Human Cognition Model

When designing the memory system, I referenced the layered model of human memory: working memory (short-term) → long-term memory (experience) → procedural memory (skills). An Agent’s memory should likewise have different time scales and management approaches:

Layer	Storage	Time Scale	Management	Typical Content
L1 Identity	SOUL.md (lean core)	Eternal	Human-confirmed edits	Identity + hard constraints + decision framework
L2 Long-term memory	MEMORY.md (<3000 tokens)	Long-term	Agent self-maintained	Structured experience (✅ success patterns / ❌ failure lessons)
L3 Mid-term memory	memory/YYYY-MM-DD.md + memory.db	Mid-term	**Harness auto-**extracted	Essence snapshot when a session exceeds 40K tokens
L4 Short-term memory	.learnings/ (ERRORS/LEARNINGS/FEATURES)	Short-term	Agent records on the fly	Error records, user corrections, best practices
L5 Persistence	Skills + Obsidian + ontology + vector_store.db	Persistent	Shared/archived	Skill library + knowledge archive + knowledge graph + vector retrieval

The handoffs between layers are the key, forming a complete autonomous-evolution loop.

Memory’s autonomous iteration — a 6-step loop

This is the system’s most core mechanism. Without this loop, an Agent is just a chatbot; with it, an Agent is a true Agent.

1. Trigger event: an operation fails · a user corrects · a better approach is found · a new capability is needed, any of these triggers an immediate record.
2. Immediate record in .learnings/: ERRORS.md · LEARNINGS.md · FEATURE_REQUESTS.md, status pending, low cost, high frequency, written directly without review.
3. Daily reflection cron (23:00-23:45): scan all pending entries in .learnings/ → assess recurrence frequency and importance → verified ≥3 times? ✓ if ≥3 times, promote to MEMORY.md; ✗ if <3 times, keep it pending and keep observing.
4. Promote to MEMORY.md: long-term memory · a hard cap of <3000 tokens · when over the limit, the Agent prunes autonomously (merge similar, delete outdated).
5. Load on the next session: self-improvement hook · bootstrap injection · check .learnings/ · reference historical experience.
6. Agent behavior improves: next time it meets the same problem it avoids it automatically, iteration complete.

🔒 SOUL.md edits — require user confirmation (the Agent can’t change its own “constitution”).

Harness parallel path

Session 40K tokens → memoryFlush → memory/YYYY-MM-DD.md → memory.db

Complementary to the Agent’s own .learnings/ → MEMORY.md path, the Harness handles “extracting conversation essence,” the Agent handles “distilling lessons.”

Why “≥3 times”?
To prevent one-off events (like a single API timeout) from polluting long-term memory.

The 3000-token budget is precious; only patterns that recur are worth a slot.

The Agent can autonomously update .learnings/, MEMORY.md, memory/, and knowledge/, but absolutely cannot touch SOUL.md. SOUL.md is identity and hard constraints, and edits require user confirmation. We really did run into a case where an Agent loosened its own “personality”, its behavior immediately became uncontrollable.

Each week Zoe also does memory-system maintenance, analyzing each Agent’s MEMORY state and doing archiving and compaction:

L5’s ontology knowledge graph records entity relationships (Agent/Task/MarketInsight/Decision), and vector_store.db provides semantic-level retrieval, the Agent doesn’t need to remember exact wording; it finds relevant historical decisions through vector similarity.

A Real Evolution Case

User correction: "yesterday you recommended buying defense stocks, and now that they dropped today you flip to bearish"
  ↓
Immediate record (.learnings/):
  "[LRN-20260303-001] correction | priority: high | status: pending
   The defense-sector strategy under a geopolitical tailwind didn't sufficiently stress short-term crowding and top-divergence risk
   Suggested Action: conditional-order template — entry with invalidation level + bullish/base/bear three-scenario"
  ↓
Daily reflection cron (23:30): promote to MEMORY.md
  ↓
MEMORY.md: "❌ event-driven targets must use the conditional-order template"
  ↓
Three weeks later, facing a similar sector rotation:
  The Trading Spider directly cited this lesson

This wasn’t a rule I wrote, it’s a scheme the Agent distilled from a correction on its own and wrote into long-term memory by itself. The daily reflection cron reviews the pending entries in .learnings/ and decides whether to promote them:

More real evolution records:

Discovery	Evolution	Source
SOUL.md information overload caused rule failure	Lean down the core, migrate non-core rules to on-demand Skills	Behavior-anomaly investigation
delivery=ok ≠ landed in the knowledge base	Reflection now cross-checks both delivery + file existence	Butler zero-output incident
butler zero output but reflection says “normal”	Advisory fallback → hard gate (empty output = failure)	Ops inspection
macro→trading references lacked traceability	Mandatory structured references + validation fields	Difficult data traceability
trading channel flooding (dual-send path)	Idempotency key + single-layer retry + throttling	P0 incident
defense-sector strategy only looked at event drivers	Conditional-order template: entry + invalidation level + three scenarios	Agent self-proposed scheme

The Memory System Is Still Evolving

The memory system isn’t “designed once, fixed forever.” A recent example:

Each week Zoe generates a Tech Radar report, extracting tech trends from ainews’s intelligence and sorting them into three tiers: Adopt/Trial/Assess. In this week’s report, ainews discovered ReMe (an Agent memory-management framework), and Zoe immediately compared it against the existing system:

Conclusion: ReMe’s architecture is excellent (223K → 1.1K tokens, a 99.5% compression rate), but it’s deeply coupled to AgentScope, so integrating it directly isn’t worthwhile. Take the “reference-the-design, build-in-house” route, first implement the highest-return tool_result compression (auto-truncate over-long tool output + offload to external storage, cutting context usage by 80%+), then gradually introduce structured summary templates and async persistence.

After the user agreed, Zoe immediately delegated Claude Code via the ACP protocol to do an architecture review:

This process is itself a real case of multi-Agent collaboration: ainews intelligence discovery → Zoe Tech Radar assessment → user confirmation → ACP delegation to a coding expert → phased shipping, involving 3 Agents + 1 ACP coding expert.

Hypothesis-Driven Iteration — From Fixing Bugs to the Scientific Method

The most profound evolution of the memory system isn’t fixing some specific bug, but the Agent learning to proactively propose hypotheses and verify them, the key step from “passive fixing” to “proactive improvement.”

During daily reflection, the Agent proposes 3-5 verifiable hypotheses based on the day’s work, then evaluates them against real data during the evening reflection:

Hypothesis	Verification Result	Follow-up Action
Adding the reasoning process to scoring reports reduces user skepticism	Verified: after Trading added the reasoning chain, user follow-up questions dropped noticeably	Hardened as a mandatory requirement in the scoring template
Macro→Trading citing upstream conclusions reduces duplicate analysis	Verified: shifted from “re-analyze every time” to “cite + increment”	Written into the collaboration protocol
An end-to-end eval set improves daily-report quality more than single-point metrics	Verifying	Building the eval baseline now

Verified hypotheses are hardened into rules or Skills; failed ones are flagged with a reason and discarded. The Agent doesn’t just “fix after erring”, it’s actively looking for room to improve, a leap from reactive to proactive.

The Autonomous-Evolution Mechanism: What’s Built into OpenClaw, and What We Added

Understanding this memory system requires distinguishing framework capabilities from operational optimization, many people ask “is OpenClaw out-of-the-box?”, and the answer is “the framework capabilities are out-of-the-box, but running it well requires a lot of operational-layer design.”

Capability	Built into OpenClaw	Our Operational-Layer Optimization
Session management	compaction (memoryFlush), contextPruning, session reset, session maintenance	Tuned parameters (40K/6h/30min) came from multiple incident retrospectives
self-improving-agent Skill	❌ not built in	A separately installed Skill, injects .learnings/ reminders at Agent startup, driving learning records and continuous improvement
Memory flush	Auto-extract the essence to memory/ when over threshold	Custom flush prompt stressing “decisions/state-changes/lessons/blockers”
Skills loading	On-demand injection via extraDirs	15 Trading-specific Skills, 33 globally shared Skills, loaded on demand
ACP delegation	sessions_spawn + coding-Agent session management	Delegation strategy (which task to which coding expert), TTL and concurrency tuning
Reflection + self-iteration	❌ not built in	Fully home-built, each Agent reflects independently at 23:30 daily + Zoe summarizes, including .learnings review, MEMORY pruning, Tech Radar trend extraction, and evaluation of new tech like ReMe
Three-state communication protocol	❌ not built in	Designed by Zoe autonomously, starting from the flooding problem, iterated to the V1 thread protocol
Task Watcher	❌ not built in	Zoe designed + ACP coded it, the task-watcher Skill
MEMORY.md capacity management	❌	memory_maintenance.py weekly compaction + Agent autonomous pruning
ontology knowledge graph	❌	Home-built schema.yaml + graph.jsonl entity relationships

OpenClaw provides excellent framework-level infrastructure (session management, Harness, ACP), but the evolution mechanisms that truly bring the Agents to “life”, reflective iteration, collaboration protocols, Task Watcher, memory compaction, are all operational-layer design on top of the framework.

---

Core Problem Three: Multi-Agent Collaboration Is a Protocol Problem, Not a Group-Chat Problem

Problem: Putting Agents in a group chat ≠ collaboration

Most people’s intuition about Multi-Agent is “give a few Agents a chat group and they’ll collaborate.” In reality, that’s no different from throwing a few engineers into a group chat with no process norms, having the ability to communicate is not the same as having the ability to collaborate.

On “the impact of the Iran situation on A-shares,” Macro and Trading exchanged “received/acknowledged/thanks” for a dozen rounds. The analysis was long done, Macro judged “oil up >10% → inflation logic dominates → gold falls instead” (actual moves: oil +14%, gold -5%, an accurate call), but afterward the two Agents spent more tokens on pleasantries than on the analysis itself.

The root cause isn’t “the Agents being too polite.” The root cause is the lack of a terminal-state protocol. In the Discord config, requireMention=true means an Agent only replies when @-mentioned. When two Agents @ each other, A → B → A → B… this is the classic ACK storm, the same problem that early TCP ran into.

The fix is also the same: design a protocol. Not telling the Agent to “talk less”, in actual observation, “advisory” rules barely work on weak models, but designing a communication protocol with a state machine.

Solution: Protocol-Level Design → A Real Case

Example: a next-week A-share strategy roundtable

Zoe convenes the roundtable → Macro provides the macro assessment → Trading responds with a strategy recommendation → it converges in order per the fixed three-state protocol:

Step 1 — Zoe raises the topic + Macro/Trading confirm per protocol:

Step 2 — Trading gives a detailed strategy based on Macro’s assessment (confirmed output):

Step 3 — Trading outputs final (DRI conclusion + full reasoning):

Step 4 — Protocol convergence (everyone silent after final):

Protocol Design

Fixed three-state communication protocol + V1 thread protocol (designed after the flooding lesson, iterated to V1, distilled into AGENTS.md):

Fixed three-state protocol (mandatory)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[request]    @counterparty + ack_id + expected action + deadline
             template: @agent [state=request] [ack_id=topic-v1-202603081430]

[confirmed]  @initiator + same ack_id + version / effective time / key conclusion
             template: @requester [state=confirmed] [ack_id=...] version=v2

[final]      @relevant parties + same ack_id + terminal-state convergence (only 1 per thread)
             after it's sent, everyone goes silent; "received/thanks/OK" → NO_REPLY

V1 thread protocol (from 2026-03-08)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
• Only one ack_id is allowed per thread; a new round must open a new thread
• No continuation after final; if you must add, prefer editing the existing message
• sessions_send timeout ≠ failure → the same ack_id must not be retried
• Retry the same content at most once; on the second timeout → deliver via a shared-context/ file

⏰ No confirmed within 5 minutes → remind once · still none at 10 minutes → escalate to Zoe for arbitration

Sub-thread strategy: multi-round collaborative content tasks open a dedicated sub-thread by default (named <topic>-<owner>-<date>), and the main channel only syncs three statuses: [Dispatch] → [ACK] → [DraftReady].

Three communication mechanisms:

Mechanism	Use	Example
sessions_send	Real-time task dispatch / roundtable discussion	Zoe → Macro “analyze the Iran situation”
shared-context/	Async state sharing	Macro writes the macro factor pack → Trading reads it directly
Knowledge archive	Structured-material interface	ainews leaves “rewrite points” at the end of its report → content consumes them

The core value of shared-context/: upgrading from message-driven to state-driven. Trading doesn’t need to ask Macro “how’s the macro today” each time; it reads intel/finance_news_latest.json directly. sessions_send suits real-time triggers but is unreliable (timeouts, duplicates), key data goes through files so it’s traceable.

Zoe led the standardization of shared-context/, evolving it from a scattered set of file directories into structured cross-Agent collaboration infrastructure:

shared-context/
├── agent-sessions/       # ACP coding experts' session state (30 claude/codex sessions)
├── agent-runs/           # Agent run records
├── monitor-tasks/        # Task Watcher persistent storage
│   ├── tasks.jsonl       # Task registration (Xiaohongshu review / ACP completion / cron health, etc.)
│   ├── watcher.log       # Polling log
│   ├── audit.log         # Audit trail
│   ├── dlq.jsonl         # Dead-letter queue (failed tasks)
│   └── notifications/    # Notification records
├── intel/                # Intelligence sharing (finance_news_latest.json, etc.)
├── roundtable/           # Roundtable discussion records
├── decisions/            # Major decision archive
├── job-status/           # cron job status
├── knowledge-base/       # Shared knowledge
├── status/               # Each Agent's current status JSON
├── tech-radar.json       # Tech radar (Adopt/Trial/Assess tiers)
├── memory-maintenance-latest.json  # The most recent memory-compaction report
└── PROJECT_STATUS.md     # Global project status (maintained by Zoe)

This wasn’t designed in one shot, Zoe standardized it gradually during real operations. Each time a new collaboration scenario was added (ACP coding, Task Watcher, Tech Radar), Zoe added the corresponding standardized directory and file format in shared-context/.

The DRI principle: a problem has only one Directly Responsible Individual who produces the final conclusion. Non-DRIs can only add, not override. Zoe organizes and archives; she does not replace specialist Agents in producing expert opinions.

Autonomous Reflection After Protocol Optimization

After the protocol shipped, the Agents don’t just “execute the rules”, they proactively reflect on the effect and propose improvements:

From the first version’s “no pleasantries” to V1’s “thread-level convergence,” every step of protocol optimization came from the Agents’ .learnings/ experience, which is exactly the value of the five-layer memory system.

Latest progress (2026-03-08): Zoe just completed a team-wide push-down of the communication standard, editing 26 files (6 Agents’ AGENTS.md + SOUL.md + related Skill docs) to uniformly write the hard communication rules into each Agent’s local config. She also ran a team-wide communication-path audit, identifying and fixing the conflict between main/SOUL.md and the roundtable Thread rules.

Five Linkage Chains

The Agents don’t each go their own way; the upstream proactively prepares interfaces for the downstream:

Chain	Flow	Mechanism
ainews → content	ainews leaves “rewrite points” at the end of each report	Agreed interface format
ainews → Zoe	Tech Radar → Zoe assesses and decides	shared-context/tech-radar.json
Macro → Trading	Macro factor pack (DXY/US10Y/oil direction/Fed path/sector mapping)	shared-context/intel/
Trading → Macro (U.S. cross-time-zone)	Trading 05:10 night report → Macro 05:20 macro review	Temporal linkage
Macro → Trading (weekend progression)	18:30 macro → 19:30 market → 20:30 technical	Progressive chain
Zoe → whole team	23:45 reads 6 Agents’ output + .learnings/ across workspaces	Reflection summary

A real Tech Radar example, the tech radar ainews maintains daily, sorted into Adopt (validated and usable), Trial (worth trying), and Assess (keep watching):

{
  "adopt": [
    { "name": "MCP Protocol", "reason": "MCP 2.0 released; the three major frameworks are pushing standardization" }
  ],
  "trial": [
    { "name": "OpenAI Skills Catalog", "reason": "582→947 stars; a reference for Skill format" },
    { "name": "ReMe Agent memory management", "reason": "standalone memory toolkit; evaluating as an alternative" }
  ]
}

After consuming the Tech Radar, Zoe does a source-level assessment to judge the impact on existing systems, this week she launched the ReMe evaluation on that basis and delegated Claude Code to ship the PoC.

Safety Boundaries — What an Agent Can and Cannot Change

Safety lies in limiting the scope an Agent can touch:

Safety Layer	Mechanism	Lesson
Execution permission	exec.security: allowlist	Content once broke its own config → switched to allowlist execution
Config protection	SOUL.md / openclaw.json not editable by the Agent	An Agent loosened its own “personality” → behavior went out of control
Key isolation	API keys in env, not in files	Prevent exposure to a session or Discord
Code review	ACP coding goes through a review flow	Agent-generated code isn’t deployed directly

Task Watcher — Solving “the Agent Said It Would but Didn’t”

The hardest problem to spot with an Agent isn’t a crash or an error, it’s “said it would but didn’t.” After posting to Xiaohongshu, the Content Spider says “I’ll notify you once it’s approved”, but the session has already ended, so it simply can’t do an async callback. Even more hidden: a cron job “ran” but produced zero output, and the reflection also says “all normal.”

Zoe led the design of a Task Callback Event Bus, a plug-in architecture with 5 components each doing its part, pushing async monitoring down to the cron level:

Register task → tasks.jsonl (shared-context/monitor-tasks/)
                ↓
Cron (*/3 min) → Watcher → Adapter checks status → state changed?
                                                   ↓ Yes
                                      Policy decides → Notifier sends to Discord

• Adapter plugins: Xiaohongshu review status, GitHub PRs, ACP coding tasks, want to monitor something, add an Adapter
• Policy strategies: notification frequency, escalation, and retry are all configurable
• 6-hour timeout protection (default), auto-escalation after 3 delivery failures, no infinite loops, no hangs

This system was designed by Zoe → delegated to Claude Code to implement → 130 unit tests → open-sourced as an OpenClaw Skill. From requirement to code to tests to release, I only stepped in at the scheme review; the Agent team did the rest.

Communication Guardrail + Async State Chain (Latest Progress)

Task Watcher solved the “did the async task produce output” problem, but the deeper issue is: inter-Agent communication itself lacks system-level constraints. message being misused as an internal control plane, timeout not equaling failure yet being treated as one, completed and delivered being indistinguishable, none of these can be solved by documentation rules.

Zoe autonomously designed and delegated an ACP coding expert to implement a communication Guardrail + request-lifecycle state chain (~3,000 lines of Python). Core components:

Module	Lines	Purpose
agent_comm_guardrail.py	383	5 hard rules: reject message misuse, block identity spoofing, intercept ack_id re-sends
agent_request_models.py	289	11-state lifecycle model: accepted → routed → queued → started → completed → delivered
agent_request_store.py	529	File-level state storage, requests.jsonl + events.jsonl full-chain audit
completion_bus.py	507	Async completion delivery bus, producer-consumer pattern
acp_state_bridge.py	502	State bridging for ACP coding tasks
dead_letter_queue.py	271	Fallback queue for delivery failures

Design decisions:

• timeout ≠ failed: a timeout is only a control-plane observation; the task may already be executing, introduce ambiguous_success semantics.
• completed ≠ delivered: work done ≠ result delivered; separate the two states to avoid a delivery failure overwriting the work result.
• The communication lifecycle is independent of the business TaskState: don’t pollute the existing Task Watcher’s submitted → completed → failed state machine.
• File-level state source: get it working with shared-context/agent-requests/ first, without depending on heavyweight infrastructure like Redis/MQ.

This system went from “Zoe discovers the problem → designs the scheme → delegates the coding → code implementation → test acceptance,” with me only stepping in at the scheme-confirmation step and the Agents doing the rest, a classic case of an Agent evolving from “executor” to “system designer.”

Overall Architecture Summary — Five Engineering Layers

Looking back, the core design of the whole system can be reduced to five layers:

Layer	Core Mechanism	What It Solves
Communication layer	Three-state protocol + ack_id + four-in-one integration + shared-context/	How Agents collaborate reliably
Memory layer	Five-layer tiered storage + Harness auto-management + reflective iteration	How an Agent remembers experience and keeps growing
Self-healing layer	Three-layer self-healing architecture + heartbeat-guardian + memory_maintenance	How the system runs stably 24/7
Evolution layer	.learnings → promote → MEMORY + in-house Skill building + ClawHub publishing	How an Agent goes from “executor” to “designer”
Orchestration layer	Zoe inspections + roundtable chairing + Task Watcher + ACP delegation	Who manages and coordinates all of this

These five layers aren’t independent, they depend on and reinforce one another. The communication layer’s three-state protocol was designed by Zoe in the orchestration layer after she found a problem. The memory layer’s compaction strategy is part of the self-healing layer. The evolution layer’s in-house Skill-building capability comes from the communication layer’s cross-Agent collaboration.

What Changed in My Thinking After Half a Month

1. 90% of the time is spent on engineering problems, not AI problems. Session bloat, message storms, config getting broken, the solutions are in the classic knowledge of distributed systems and SRE, not in AI papers. The bottleneck of an Agent system isn’t model capability; it’s the maturity of the infrastructure. Model upgrades are icing on the cake; communication protocols, memory architecture, and self-healing mechanisms are the foundation that decides success or failure.

2. AI’s “smartness” is often a disaster in production. Discord messages got “smartly compressed” and lost their data tables, the Agent “smartly fixed” its own config and broke a tool name, and after session bloat the Butler Spider “smartly” overstepped into investment analysis. In scenarios requiring precise, predictable output, “smartness” is actually a negative trait. Explicit > implicit, hard rules > soft suggestions, predictable > explainable.

3. A continuously running system inevitably degrades, that’s not a bug, it’s thermodynamics. Config pile-up, over-long memory, session bloat, full disks, these happen deterministically. The countermeasure isn’t “set it up once” but building an anti-degradation mechanism stack: compaction manages sessions, maintenance manages memory, heartbeat-guardian manages config, inspections manage behavior drift. Use Agents to operate Agents, use cron to monitor cron, every layer of fallback needs its own fallback.

4. Collaboration is a protocol problem, not a prompt problem. Putting two Agents in the same Thread without a protocol is equivalent to two processes sharing memory without a lock. Macro and Trading use the same model and the same knowledge base; even when flooding, every reply was substantive, and adding the three-state protocol turned the output from a dozen rounds of nonsense into one actionable strategy document. The model didn’t change; the rules did.

5. An Agent’s greatest value isn’t execution; it’s “participating in design.” When an Agent evolves from “I’ll do whatever you tell me” to “I found a problem, researched three options, recommend B, and I’ll ship it if you confirm”, that’s when it truly becomes a team member. In most of the ten evolution cases, the trigger wasn’t “I told it to do something” but “it ran into a problem and figured out a solution itself.” The goal of system design isn’t to make the Agent obedient; it’s to give it the ability to solve problems on its own.

---

If You Want to Try It Too

You don’t need to copy 6 Agents. Start with 1. Getting the whole system from zero to 6 stably running Agents took about half a month of after-work time, not development time, but debugging and gap-filling time.

Days 1-2: First, get 1 Agent running stably

The three most important things:

1. Keep SOUL.md lean, only core constraints. Treat it as a “constitution,” not an “operating manual”, put non-core rules in on-demand Skills.
2. Set session-management parameters on day one: idleMinutes=30, pruneAfter=7d, maxDiskBytes=100MB. Not setting them = a time bomb.
3. Enable .learnings/ + the reflection cron from day one. An Agent without reflection is just a chatbot, not an Agent.

Days 3-5: Add the 2nd, and start handling collaboration

1. Discord config is 10x more complex than you think. Each Agent needs an independent Bot account. requireMention, textChunkLimit, delivery.mode, sub-Thread creation, Bot permissions, each has its traps, and combined, the symptoms make it impossible to guess which config is the problem.
2. Collaboration needs a protocol, not a group chat. Two Agents in a group chat will ACK each other to death. Fixed three-state protocol + ack_id + timeout escalation, you can’t skip any of them.

From Week 2: Gradually expand to the full formation

1. Use the strongest wording for rules, aimed at the weakest model. LLMs follow “advisory” rules far less than “MUST,” especially in long contexts and on weak models.
2. Define “success” strictly. Delivery success ≠ archive success, no errors ≠ output produced, the Agent saying “normal” ≠ truly normal.
3. An Agent not replying is the norm, be ready with Task Watcher and a retry mechanism.
4. shared-context/ is the cornerstone of collaboration, sessions_send is unreliable (timeouts, duplicates), key data goes through files so it’s traceable.
5. Each added Agent needs half a day to a day of debugging. Rushing = wasting even more time on troubleshooting.

Installing it isn’t hard, getting it working isn’t hard either. The hard part is: making 6 Agents produce stably, self-correct, and collaborate without fighting even when you’re not watching. That’s not a prompt problem; it’s a systems-engineering problem.

Start by Understanding the Principles

If you want to understand OpenClaw’s core principles before getting hands-on, check out MiniClaw, ~2,700 lines of Python implementing 11 of OpenClaw’s (430,000 lines of TypeScript) core architecture patterns: Gateway Hub-and-Spoke, Workspace contract files, the Agent Loop, Skills triggering, Compaction context management, Multi-Agent & Spawn, Heartbeat, Cron, Hooks EventBus, and auto-reflection. You can understand “why it’s designed this way” without reading the original code.

---

Appendix: Quick Tech-Stack Reference

The following is a consolidated index of the technical components mentioned in the main text, for quick lookup. See the corresponding section above for details.

LLM Model Tiering

Task Type	Model
Main dialogue / reflection / roundtable	GPT-5.4
ACP coding tasks	K2.5 / GPT-5.4
Routine cron tasks	Qwen3.5+ / K2.5
Heartbeat / health check	Ollama qwen3:8b

Fallback chain: gpt-5.4 → k2.5 → qwen3.5-plus → ollama/qwen3:8b

Core Harness Config

{
  "compaction": { "mode": "safeguard", "memoryFlush": { "softThresholdTokens": 40000 } },
  "contextPruning": { "mode": "cache-ttl", "ttl": "6h", "keepLastAssistants": 3 },
  "session": { "reset": { "atHour": 5, "idleMinutes": 30 }, "maintenance": { "pruneAfter": "7d", "maxDiskBytes": 104857600 } },
  "acp": { "maxConcurrentSessions": 6, "ttlMinutes": 120 }
}

Data Sources

Market	Data Source	Coverage
A-shares	AKShare + TuShare Pro	Real-time quotes + history + financials + Dragon-Tiger list + northbound
U.S./HK stocks	yfinance + Finnhub	Quotes + news + fundamentals
Information collection	Tavily + 13 RSS sources + GitHub Trending + 54-platform trending lists + arXiv	Search + news + hot topics + papers
Browser	agent-browser (Playwright)	JS-rendered pages (X/Twitter, Xueqiu, etc.)

Deployment Config

Component	Config
Hardware	Mac, local, 24/7
Process supervision	launchctl + ThrottleInterval=10
Self-healing	2,086 lines of scripts (heartbeat-guardian / check_cron_health / memory_maintenance)
Backup	Daily 03:00 full backup
Monitoring	Zoe 3 inspections/day + system crontab 15-minute health check
Knowledge archive	Obsidian Vault + obsidian-livesync

Other

• The way the “13 RSS sources + GitHub Trending + 54-platform trending lists” data is fetched in this article: https://github.com/lanyasheng/ai-news-aggregator