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

[pamelia]

Feature hasn't been suggested before.

• I have verified this feature I'm about to request hasn't been suggested before.

Related: #12711 (file-based design by @ugoenyioha), #12661, #15035, #17994

Describe the enhancement you want to request

opencode's TaskTool only does synchronous sub-agent execution. No way to run agents in parallel, have them talk to each other, or coordinate on shared tasks.

#12711 proposes a file-based approach (JSON on disk, no DB changes). I built an alternative using DB-backed state, which fits how the rest of opencode works (sessions, messages, parts — all DB-backed with Bus events). Posting this to get design direction before opening PRs.

Key differences from #12711:

	#12711	This proposal
Storage	JSON files in .opencode/teams/	4 SQLite tables (team, team_member, team_task, agent_memory)
Concurrency	File locking	DB transactions + WAL mode
Recovery	Scan files, mark interrupted	reconcile() disbands stale teams on startup
Agent memory	Not included	Per-agent per-project persistent memory (100KB cap)

Why DB instead of files:

• Consistent with every other opencode subsystem (sessions, messages, parts, projects)
• Transactions give atomic team create (team + lead member in one tx)
• Bus events for real-time TUI updates work naturally via existing patterns
• No file locking needed — SQLite WAL handles concurrent agents

What's implemented (locally, ready to PR when approved):

• Team management with lead/member lifecycle, agent name auto-disambiguation
• Background agent execution with configurable concurrency limit (default 10)
• Cross-session message injection (synthetic user messages, race-safe Bus subscribe)
• Agent memory with 100KB cap
• Team task board
• TUI sidebar showing active teams/agents
• 30 tests across 3 test files

Features we'd add (from #12711 and beyond)

The current implementation covers the core primitives. These features from #12711 are worth adding and I'm ready to build them if the core team is interested:

Delegate mode — Lead gets restricted to coordination-only tools (no write/edit/bash). Forces clean separation between orchestration and execution. Prevents the lead from doing work it should delegate. Implementation: a delegate flag on team_create that applies a permission override denying write tools on the lead session.

Plan approval — Teammates start in read-only mode. They research, formulate a plan, send it to the lead for approval. Lead approves (write tools unlocked) or rejects (teammate revises). Prevents wasted token spend on wrong approaches. Implementation: planApproval status on team members and a team_approve_plan tool.

Broadcast messaging — Send a message to all teammates at once. Current send_message is point-to-point only. Useful for the lead to announce decisions, share context, or signal everyone to stop. Implementation: iterate members and inject into each session.

Atomic task claiming — Any member can claim a pending task from the shared board with an atomic DB transaction preventing two agents from grabbing the same task. Implementation: TeamTask.claim(taskID, agent) that sets owner + status in one transaction.

Idle member status — Distinguish between "finished current work, waiting for more" (idle) and "done forever" (completed). Lets the lead know which members are still available for follow-up work.

TUI enhancements — Header badge with team name + member count, prompt bar busy indicator ("3 teammates working"), spinner on busy teammate sessions in session list.

What is the use case?

• Parallel spec reviews (5+ specialist agents simultaneously)
• Iterative self-review loops (fresh reviewer each turn)
• Any skill where agents need to communicate findings to a lead
• Persistent agent memory across sessions
• Security audits across frontend/backend/infra with different models per teammate
• Multi-file refactors with coordinated plan approval before writes

[m13v]

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.

[m13v]

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

[Strelitzia-reginae]

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.