hermes - 💡(How to fix) Fix feat(kanban): allow one Hermes profile to run multiple tasks concurrently

Feature Description

Add first-class support for running multiple Kanban tasks concurrently with the same Hermes profile / assignee, by treating a profile as an optional worker pool rather than always as a single serial lane.

Today, Hermes itself can handle multiple independent sessions concurrently (for example, one Telegram DM session and one group-chat session can both interact with the same Hermes profile). However, in Kanban-style software-team workflows, if several independent cards are assigned to the same capable Hermes profile, they are effectively treated as a queue / single lane. This limits throughput even when the tasks are independent and the runtime could safely spawn separate worker sessions.

Motivation

In an agent software-development-team setup, users often assign a large business module to one Hermes/OpenClaw profile because that profile has the right long-term memory, skills, repo conventions, and accumulated project knowledge.

Inside that module, many tasks are independent and could run in parallel, for example:

• backend implementation and test expansion;
• frontend implementation and documentation updates;
• static verification and code review;
• multiple independent research or code-inspection tasks.

If all of these cards are assigned to the same module-aware Hermes profile, they become a throughput bottleneck. Delegating to Codex or other stateless workers helps, but those workers often lack the module owner's long-term memory, project-specific pitfalls, and operational conventions unless the owner carefully compiles a task-context pack each time.

Allowing a single Hermes profile to run multiple Kanban worker sessions concurrently would significantly increase task throughput while preserving access to that profile's skills, memory, tool configuration, and repo-specific context.

Proposed Solution

Introduce configurable per-assignee/profile concurrency for Kanban workers.

Conceptually:

kanban:
  workers:
    messages-owner:
      profile: messages-hermes
      mode: lane
      max_concurrency: 1

    backend-hermes-pool:
      profile: backend-hermes
      mode: pool
      max_concurrency: 3
      workspace_policy: worktree-per-task

Possible behavior:

1. Keep the current safe default: max_concurrency: 1 per assignee/profile.
2. Allow users to opt into max_concurrency > 1 for selected profiles/assignees.
3. When multiple ready cards target that assignee, the dispatcher may spawn multiple independent Hermes sessions using the same profile, up to the configured concurrency limit.
4. Each task should get its own Kanban worker session and ideally its own isolated workspace, especially for code-changing tasks.
5. The dashboard/CLI should show active slots, e.g. backend-hermes 2/3 running.

This would let users choose whether an assignee represents:

• a serial responsibility lane (max_concurrency: 1), useful for owners, reviewers, deployment, integration; or
• a worker pool/template (max_concurrency: N), useful for implementation, testing, research, and inspection tasks.

Safety / Design Considerations

To keep this safe, the feature should probably include guardrails:

• Default to serial execution for backward compatibility.
• Require explicit opt-in for same-profile parallelism.
• Recommend or enforce isolated workspaces for code tasks, such as worktree-per-task.
• Avoid sharing a single conversation context between concurrent tasks; each task should run in a separate session.
• Consider memory-write policy for pooled workers. For example, concurrent workers may read profile memory but avoid writing durable memory directly; task summaries/metadata can be reviewed and later consolidated by an owner.
• Support per-profile concurrency limits so high-risk profiles such as deployment/release remain single-lane.
• Preserve dependency semantics: cards with unfinished parents must still wait, while independent cards can run concurrently.
• Provide clear recovery behavior for stuck/crashed slots: reclaim/reassign should operate per task/run, not globally per profile.

Example Workflow

A module owner receives a feature request and creates a task graph:

T0: define message-recall contract          -> messages-owner, max_concurrency=1
T1: implement backend API/repository        -> backend-hermes-pool, max_concurrency=3, parent=T0
T2: implement frontend UI                   -> frontend-hermes-pool, max_concurrency=2, parent=T0
T3: add tests/static verification           -> backend-hermes-pool, max_concurrency=3, parent=T0
T4: final integration review                -> messages-owner, max_concurrency=1, parents=T1,T2,T3

T1/T2/T3 can run in parallel, but architectural decisions and final integration remain serial and reviewable.

Alternatives Considered

1. Create many duplicated profiles manually

   • Example: backend-hermes-1, backend-hermes-2, backend-hermes-3.
   • Works, but creates profile-management overhead and memory/config drift.

2. Delegate to Codex or stateless subagents

   • Useful for many coding tasks, but those workers do not automatically have the same long-term memory, module-specific pitfalls, skills, or conventions as the Hermes owner.
   • Requires repeatedly compiling and passing detailed context packs.

3. Keep same-profile Kanban execution serial

   • Simpler and safer, but leaves a lot of potential throughput unused for independent tasks.

Expected Benefit

• Higher throughput for Kanban-based multi-agent development workflows.
• Better use of Hermes' existing ability to run multiple independent sessions.
• Less need to duplicate profiles only to achieve parallelism.
• Preserves module-specific Hermes memory and skills while allowing independent tasks to progress concurrently.

Open Questions

• Should concurrency be configured per profile, per Kanban assignee alias, or both?
• Should code-changing tasks require worktree-per-task when max_concurrency > 1?
• Should pooled workers be allowed to write durable memory, or should memory writes be restricted to owner/reviewer lanes?
• How should the UI expose running slots, queued cards, and stuck slots?
• Should the scheduler implement fairness across profiles/assignees when several pools have available capacity?