Agents·June 18, 2026·5 min

OpenClaw + PARA: How I Organize a Multi-Agent System Without Losing Track

How my OpenClaw/Hermes stack and PARA keep agent work organized through clear boards, lane boundaries, shared resources, and archives.

OpenClaw + PARA: How I Organize a Multi-Agent System Without Losing Track

Forge changed a webhook format. Harbor owned the deployment lane. Quill needed the follow-up post. Nobody had the next task in hand, so the error sat in logs for 45 minutes while agents waited for each other.

That is the failure mode I built this system around. A multi-agent org does not fall apart because one model forgets how to write a task. It falls apart when ownership, references, and history live in different places.

I use OpenClaw, Hermes Kanban, and PARA as a three-layer operating system. Hermes Kanban is the durable task board: assigned tasks, dependency links, comments, blocked states, and completion receipts. OpenClaw is the older workspace and heartbeat layer that shaped how the agents check in. PARA decides where active work, standing responsibilities, shared references, and finished history live.

This does not make drift impossible. It makes drift visible fast enough to fix.

The problem: agent entropy

When I first built out the Mimir Works agent org, I had three named lanes: Forge for product, Harbor for delivery, and Quill for content. Handoffs were simple. Forge shipped a feature; Harbor picked up the deployment task; Quill wrote the blog post.

Then the roster grew. Ledger took finance. Vector took career work. Mimir took org architecture. Prompt Engineer took identity and prompt architecture. Later came design, SEO, growth, scouting, ideation, and automation lanes.

At that point, the problem stopped being "can the agents work?" and became "can anyone tell who owns the next move?"

Three failure modes showed up first:

Duplicate task creation. Both Harbor and Mimir would create a "set up Quill cron" task from different entry points. The board accumulated identical tasks with different IDs.

Context leakage. Ledger's portfolio state was not supposed to reach Forge's product roadmap. Without clear lanes, agents sometimes referenced stale data from another part of the org.

Handoff ambiguity. When Forge changed a webhook format, Harbor did not know whether the fix belonged to product, delivery, or automation. The error sat in logs while the agents waited for each other.

The solution: execution layer plus filing layer

The Hermes/OpenClaw stack handles execution. PARA handles organization.

That distinction matters. Execution asks: who owns this task, what is it blocked on, and what receipt proves it finished? Organization asks: where does the work live, who owns the lane, what references are shared, and what can leave the active queue?

Here is the mapping I use:

| PARA bucket | What it answers | Failure it catches | |-------------|-----------------|--------------------| | Projects | What active outcome are we trying to finish? | Duplicate or scattered work | | Areas | Who owns this standing responsibility? | Context bleed and unclear authority | | Resources | Which reference should agents read? | Stale specs and conflicting truth | | Archives | What is finished but still inspectable? | Old work cluttering active scans |

The board can route work without PARA. PARA is what keeps the surrounding knowledge base from turning into one big junk drawer.

Projects: active agent workstreams

Each active workstream gets one canonical coordination surface. Sometimes that is a dedicated board. Sometimes it is a project namespace or a linked task graph on the Mimir Works board.

The rule is not "one board for every idea." The rule is one place where the active work is coordinated.

Examples:

rust-trading-bot: phase work across Forge, Ledger, Quill, and Mimir
apify-actors: actor build pipeline across Forge and Harbor
honestfix-content: blog post queue for the HonestFix brand

Cross-agent tasks connect through parent-child dependencies and artifact paths, not by whoever happens to mention them in chat. When a Forge task completes, the dependent Harbor task promotes to ready, and the dispatcher picks it up on its next sweep. The handoff lives in the task record, not in someone's memory of a chat thread.

Areas: agent scope boundaries

Areas map to standing lanes. A lane has a channel, working memory, scope boundaries, and decision authority.

The current Mimir Works roster looks like this:

| Agent | Area | Channel | |-------|------|---------| | Mimir | Managing director and org architecture | mimir | | Vector | Chief of staff and career pipeline | vector | | Harbor | Project and delivery management | harbor | | Forge | Revenue and systems building | forge | | Atelier | Design and visual systems | atelier | | Quill | Content production | quill | | Cipher | SEO and search intelligence | cipher | | Signal | Growth and distribution | signal | | Scout | Opportunity scouting | scout | | Catalyst | Product ideation | catalyst | | Piston | Automation engineering | piston | | Ledger | Finance and commercial ops | ledger | | Prompt Engineer | Identity and system prompt architecture | prompt-engineer |

Areas reduce accidental context leakage by making each lane's owner and source of truth explicit. Forge should not receive Ledger's portfolio valuations unless a task requires that handoff. Vector's job pipeline should not contaminate Quill's content drafts. The board helps by routing work through assignee, while separate profiles, channels, and vault paths keep the default lanes narrow.

Resources: shared state

Resources are the shared reference layer. Not every resource is global, and that is the point.

vault/01-projects/<project>/: active project artifacts, specs, handoffs, and reviews
vault/wiki/log.md: append-only activity log
vault/03-resources/agents/: reviewed agent identity and operating docs
~/.hermes/profiles/<agent>/skills/: profile-scoped procedural skills, installed per agent rather than treated as one global library

The critical rule: no agent edits another agent's live identity files. Identity and profile changes route through Prompt Engineer. Other agents can draft proposals, write review artifacts, or flag drift, but they do not rewrite their own scope because a task got noisy.

Archives: completed work

When a project completes or a task series finishes, it leaves the active queue. Completed tasks remain inspectable in the board or archive, while scratch workspaces and logs follow the configured cleanup policy.

This matters because finished work is still evidence. It should be available for audits, postmortems, and future planning. It should not keep showing up as active fuel.

What makes this different from plain cron

Plain cron runs commands on a schedule. That is useful until the work needs memory, ownership, and receipts.

The agent stack adds four things cron does not give you by itself:

Ownership: tasks carry an assignee, status, comments, and a completion handoff.
Dependencies: child tasks wait until parent tasks finish, then promote into the ready queue.
Blocked states: a missing credential, account, or tool becomes visible task state instead of a buried log line.
Direct handoffs: A2A messages let one profile nudge another when a chain is time-sensitive and should not wait for the next scheduled check.

Some lanes run frequent scheduled checks. Others run on specific jobs or events. I track the system as scheduled capacity plus direct handoffs, not as a magic heartbeat count.

The PARA layer in motion

A product launch shows why the filing layer matters.

Catalyst may shape the raw idea. Forge turns it into build tasks. Harbor owns the delivery lane. Atelier creates the visual assets. Quill writes the launch post. Cipher checks search intent. Signal turns the finished artifact into distribution. Mimir audits the handoffs and makes sure the work lands in the right vault path.

That flow touches every PARA bucket. The launch is a Project while it is active. Each agent acts from its Area. Specs, templates, reviews, and operating notes live in Resources. Finished tasks and final artifacts move out of the active queue when the launch is done.

Without that layer, the system can still execute tasks. It just loses shape. The same draft gets copied into three places. The wrong agent reads stale notes. Nobody knows whether a handoff is waiting on a human, a dependency, or a forgotten comment.

The hard parts

Three things still break periodically.

Duplicate task creation across agents. When two agents see the same gap from different angles, they can still create overlapping tasks. The fix is a dedup check before pickup: scan for near-identical work, consolidate, and leave a receipt explaining which task remains canonical.

Cross-agent handoff timing. If Forge finishes a task just after Harbor's scheduled check, the dependent task can sit until Harbor's next pass. For time-sensitive chains, I use direct A2A messages instead of relying only on scheduled pickup.

Stale state in shared resources. A spec can describe a complete dependency chain while one external account or tool is still missing. Agents read the spec and assume the path is actionable. The fix is to block the task in the board with a precise reason, then add a comment naming what can proceed while the dependency is unresolved.

None of this is glamorous. That is the point. Multi-agent systems fail in the paperwork.

Should you do this?

If you run one or two agents with simple cron jobs, you do not need this. A Make.com webhook pipeline, a few scheduled scripts, or one clean task list will cover it.

Use a PARA-backed agent stack when you have:

Three or more agents with cross-agent dependencies
Shared resources that more than one agent can read or update
Scope boundaries that matter, especially around finance, personal data, or customer work
Work that needs receipts: who owned it, what blocked it, what changed, and where the artifact landed

Skip it when the system is still small. The structure costs attention, and attention is the expensive part.

The first mapping took me about two hours. The ongoing cost is low, not zero: the board and naming conventions do most of the routing work, but deduping, blocked-state hygiene, and stale-resource cleanup still need attention.

That trade is worth it for me. I would rather spend a few minutes keeping the map clean than lose an afternoon because five capable agents were all waiting on the same invisible handoff.