m2ai-portfolio Agent Standup — Multi-Agent War Room Status Check
A structured standup command that queries every active agent in your team, surfaces blockers and cross-agent dependencies, and writes a shared log entry. The war room pattern: agents don't just run in parallel — they report to a shared surface so the operator can see the whole picture at once.
When to Invoke
- You want to know the status of all active agents at once
- You suspect blockers or dependency conflicts between agents
- Beginning or end of a work session ("what happened while I was away?")
- Before dispatching a new mission (check for capacity/conflict)
Phase 1: Roster Discovery
Identify all active agents:
- Read available agent configuration files (
agent.config.json,AGENT.md,ecosystem.config.cjs, or equivalent in the project root). - If no config is present, ask the user to list their active agents by name and role.
- For each agent, note: name, role/specialty, last known status (from logs, task queue, or prior standup log if one exists).
Active agents discovered:
- {agent-name}: {role} — last known: {idle / working on X / blocked}
- ...
Phase 2: Per-Agent Status Query
For each agent in the roster, collect the three standup fields:
Done — what did this agent complete since the last standup (or since session start)?
- Source: task completion logs, git commits in the agent's worktree, or output files with recent timestamps
Blocked — is anything preventing this agent from making progress?
- Source: error logs, stalled task states, failed tool calls, missing dependencies
Next — what is the agent's next planned action?
- Source: queued tasks, pending subtask in the dependency DAG, or agent's stated intent if interactive
If an agent's state cannot be determined automatically, mark it as UNKNOWN and flag for manual check.
Phase 3: Cross-Agent Dependency Check
After collecting individual reports, scan for:
- Dependency conflicts: Agent A is waiting on output from Agent B, but Agent B is blocked or idle.
- Resource contention: Two agents working in the same file, worktree, or database table simultaneously.
- Orphaned tasks: Tasks queued but no agent assigned or capable of handling them.
Cross-agent issues:
- DEPENDENCY: {agent-A} waiting on {agent-B} → {agent-B status}
- CONTENTION: {agent-A} and {agent-B} both modifying {resource}
- ORPHAN: Task "{task}" has no assigned agent
Phase 4: Standup Log Entry
Write the standup log to stdout (and optionally append to a local standup log file):
## Standup — {YYYY-MM-DD HH:MM}
| Agent | Done | Blocked | Next |
|-------|------|---------|------|
| {name} | {summary} | {blocker or "none"} | {next action} |
| ... | ... | ... | ... |
### Escalations
{Any BLOCKER or DEPENDENCY issues that require operator action — if none, write "None."}
### Suggested actions
{1–3 concrete operator actions, if any — e.g., "Unblock {agent}: {what's needed}", "Reassign orphaned task X to {agent}"}
Phase 5: Operator Decision Gate
Present the standup log and stop. Do not automatically reassign tasks or modify agent state.
The operator decides:
- Approve — standup noted, agents continue as-is
- Reassign — move a task from one agent to another
- Unblock — provide input or resource that unblocks a blocked agent
- Pause — suspend an agent's next action pending review
- Dispatch — add a new mission or task to the queue
Configuration
| Parameter | Default | Description |
|---|---|---|
log_to_file |
false | Append standup to a local standup.log file |
log_path |
./standup.log |
Path for the log file if enabled |
include_unknowns |
true | Include agents with unknown status in the report |
escalate_blockers |
true | Surface blocked agents as escalations |
Verification
- Every agent in the roster has a row in the standup table
- No agent row was silently skipped (UNKNOWN is a valid status)
- Cross-agent dependency check ran (not just per-agent reports)
- Escalation section is present (even if "None")
- Operator decision gate was reached — no automatic reassignments made
Source
Mark Kashef — "This Claude Code Setup Runs My Entire Business" (2026-05-03) https://www.youtube.com/watch?v=7aQbN543Mec
Core extraction: the War Room + /standup command pattern (timestamp 02:27). The shared war room surface provides a single log where every agent in the team reports status, blockers, and next actions simultaneously — analogous to a human team standup but queryable on demand. Transcript unavailable (HTTP 429); extraction based on video description and chapter timestamps.