[FEATURE]: DB-backed agent team coordination (parallel sub-agents, messaging, memory) #19215

DB-backed state is the right call over file-based. we run 5+ parallel agents daily and file-based locking breaks down under real concurrency, race conditions everywhere. SQLite WAL mode handles concurrent reads well but you still need to be careful with writes.

the idle vs completed distinction is critical. we added that after realizing agents would finish their immediate task but the lead had no way to know they were available for follow-up work. one thing I'd add to the design: a heartbeat mechanism. agents that crash silently look identical to agents that are just thinking for a long time. we poll for a heartbeat timestamp and if it goes stale for 60 seconds, the orchestrator marks the agent as stuck and can reassign the task.

the delegate mode concept is interesting too. we found that leads without write restrictions tend to start doing the work themselves rather than delegating, which defeats the whole purpose of parallelism.

our parallel agent orchestration with session management, heartbeat monitoring, and completion tracking: https://github.com/m13v/tmux-background-agents/blob/main/SKILL.md

and the resource locking layer we use to prevent agents from fighting over shared resources: https://github.com/m13v/browser-lock/blob/main/playwright-lock.sh

I want to add a more specific use case here because it matches what I am looking for very closely.

The capability I want is not just parent -> child context inheritance.
It is shared task-scoped context across parallel sibling subagents.

More concretely:

• several subagents are spawned under one parent task
• they should be able to see shared findings, constraints, decisions, and intermediate artifacts from each other
• ideally without copying full transcript history into every child session
• the parent should not be the only relay point for all coordination

Why this matters:

• avoids duplicate exploration across parallel agents
• lets one agent's discovery immediately inform another agent's work
• improves reviewer / implementer / researcher coordination
• makes multi-agent execution feel like one collaborative task rather than isolated branches that only report back upward

A shared scratchpad / shared memory bus / task-level coordination layer would solve the actual problem for me.

So if design choices need to be prioritized, my strongest request is:
first-class sibling-to-sibling shared context for agents working on the same task, not only parent-child session linkage.

I have been thinking about a related problem: once agents can coordinate as a team, "agent memory" should probably be more than a per-agent blob. The useful unit is often an experience: under which task condition, which action or route worked, which route failed, and whether the lesson is reusable by other agents.

I built a small free and open-source tool called Khaos Brain for that reason. It is a local-first experience system for AI agents.

Khaos Brain stores experience as visible file-based cards instead of opaque memory. The cards are inspectable, searchable, reviewable, Git-versionable, and can be merged or rolled back. It also separates personal/local preferences from reusable team or organization knowledge.

For this DB-backed team coordination proposal, I think the interesting overlap is the agent_memory table. One possible design question is whether memory should only be "agent X remembers Y", or whether some memories should become reviewed team experience:

• task condition
• route/action taken
• result
• failed alternative
• better route
• skill dependency
• local-only vs team-shareable

Repo:
https://github.com/liuyingxuvka/Khaos-Brain

Feedback:
liuyingxuvka/Khaos-Brain#2

If useful, Khaos Brain may be a reference point for the memory/experience layer around team agents, even if your runtime state itself remains DB-backed.

To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.