[Epic]: Project Manager / Orchestrator long-running system with multi-agent team coordination (core v1.0.0 deliverable)

Major new stub Epic for v1.0.0 (introduced during Q&A refinement on scheduled/autonomous work).

The scheduled refactor/rearch (and broader autonomy) bespeaks the need for a "Project Manager" long-running script that orchestrates all of the project work. It serves the API for Q&A, and clients just speak directly to it. (This will also be a good future surface to serve a browser-based Q&A/Task/dashboard for PLATE projects. TUI and browser can read from the same endpoints.)

This Project Manager system polls the "What's Next?" endpoint and assigns work to sub-agents. Additionally, this deliverable requires a team of agents with pre-defined personas. Multiple developer agents with different personalities and approaches to problem solving, multiple designer agents with different aesthetics, third party agent integration, etc. The Orchestrator's job is to keep work within-budget while making continuous autonomous progress.

Perhaps this "Project Manager" system (with sub-agents and work coordination) is the core deliverable for v1.0.0.

Scope (initial, to be refined)

• Long-running orchestrator script/service
• Polls plate_what_next or equivalent, assigns to specialized sub-agents
• Serves Q&A API surface (for TUI, future browser dashboard)
• Team of agents: devs with varied personas/personalities, designers with aesthetics, third-party integrations
• Budget keeping, continuous progress
• Ties to multi-agent (#644), simulation, checkpoints, procedures, feed
• Relation to AutonomyEngine (#470, #657)

Detailed Architecture (added per Q&A refinement)

• Core Loop: The PM runs as a long-lived process (e.g. via gh plate autonomy run --loop or dedicated service). It periodically calls plate_what_next (or enhanced version) to get prioritized list of open Questions, Tasks, due procedures, health issues, etc.
• Work Assignment: Based on type (planning, coding, design, research, deploy), budget remaining, risk tolerance, and agent availability/skills, it delegates via plate_delegate_to_agent or direct MCP/tool calls to sub-agents. Maintains internal work queue/state (perhaps in .agentic/ or GitHub issues as source of truth).
• API Surface: Exposes endpoints or MCP tools for Q&A clients. TUI (ask_user_question) and future browser dashboard query the PM for current feed (open items, status, suggested actions). Clients don't call low-level tools directly; they speak to the PM which orchestrates and surfaces via native forms.
• Sub-Agent Coordination: PM acts as orchestrator. Sub-agents are specialized (see personas below). PM handles handoffs, context passing (narrow packets), conflict resolution, and aggregates results back to feed or artifacts. Supports third-party agent registration (via skills or extension model).
• Budget & Safety: Integrates with costs/budgets (#634, #653). Before delegation, estimates cost, may run simulation (#645). Surfaces checkpoints (#648) for high-risk or high-cost items. Enforces .plate risk_tolerance and token budgets.
• Observability: Updates feed (#631) with progress, usage reports, decisions. Logs to GitHub for audit. Polls health/epics/status.
• State Management: GitHub remains single source of truth (issues, procedures in .agentic/, .plate config). PM maintains ephemeral runtime state (queue, active delegations) but recovers from GitHub on restart.
• Future Browser Surface: The PM's API allows a web UI (e.g. served via GitHub Pages or separate surface) to display live feed, approve tasks, view dashboards, without agents needing direct GitHub access.

Integration with Existing PLATE Components (added per Q&A)

• plate_what_next & Contemplation: The PM's primary input loop is built on plate_what_next (enhanced for orchestration state). It consumes the same signals as the current autonomy engine but acts as a higher-level dispatcher that assigns to specialized sub-agents rather than executing directly. Contemplation results (answers) feed back into the PM's queue for follow-up actions.
• AutonomyEngine (#470) and .plate config: The PM builds on or extends the AutonomyEngine. It uses .plate autonomy section (risk_tolerance, token_budget, schedules_enabled) for decisions. The engine may evolve to be the backend for the PM's polling/decision logic, or the PM becomes the user-facing orchestrator while the engine handles low-level procedures. The PM enforces budgets across sub-agents and can throttle or pause based on .plate settings.
• MCP surfaces and plate-mcp: The PM exposes or wraps MCP tools. Clients (TUI, future browser) interact via MCP or a new orchestration MCP surface. Sub-agents use existing MCP tools (e.g. plate_delegate_to_agent, plate_plan_epic) under PM coordination. This allows the PM to be the "single API" for Q&A while delegating.
• GitHub as System of Record + Webhooks: GitHub issues, labels, comments, and webhooks are the core state. The orchestration engine subscribes to webhooks for real-time updates (PRs, issue changes, comments, labels, etc.). On webhook, it updates its task queue with specific next steps and may immediately delegate or surface to the feed.
• Labels for Driving Mode (new convention proposed): Introduce labels or a GitHub Project field to indicate ownership:
  • driver:agent / "Agent is driving this" (for Features/Bugs that can be autonomous)
  • driver:human / "Human is driving this"
  • driver:collaborative (default for Epics and Tasks; Epics always collaborative, Tasks always human-driven)
    These help the PM populate dashboards, decide delegation, and avoid conflicts. Features and Bugs can be any of the three.

Agent Personas / Sub-Agent Team (initial ideas)

• Developer Personas: "Cautious Implementer" (TDD-first, high test coverage, risk-averse), "Pragmatic Hacker" (fast MVP, focuses on working code), "Refactorer" (specializes in scheduled rearch, clean code).
• Designer Personas: "Minimalist" (clean, accessible UIs), "Creative Storyteller" (rich visuals, marketing assets, GIFs), "Interaction Specialist" (focus on flows, wireframes, usability).
• Other: Researcher (market/discussions), Release Engineer (cut/finalize, packaging), Deployer (marketing site, prod deploys), PM Orchestrator itself (coordination, budgeting).
• Third-party: Integration points for external agents (e.g. via MCP or skills) that can be assigned work if registered and within policy.

Full Epic Implement Orchestration Example (added per Q&A)

The PM coordinates full epic delivery: after planning, assigns sub-features to dev personas (e.g., one for core logic, one for tests), designer for visuals/GIFs, researcher if needed. Uses feed checkpoints at milestones (e.g., "Design approved? Budget 30% used."), simulation for risky parts, driver labels to show collaboration. Tracks overall epic budget, surfaces when complete for close ceremony.

Acceptance (stub)

• Orchestrator coordinates sub-agents for end-to-end work from feed/Q&A
• Pre-defined personas for sub-agents (dev, design, etc.)
• Unified API for Q&A clients (TUI/browser)
• Budget-aware assignment and progress
• Detailed architecture, stories, integration with existing surfaces
• Polling of What's Next + delegation logic
• Support for third-party agents and multi-persona teams
• Real-time webhook handling for queue updates
• Driving mode labels/fields for dashboard and assignment

PM-specific Risks, Non-Goals, Success Metrics (added per Q&A)

Risks:

• Coordination overhead: Too many sub-agents or personas leading to slow handoffs or context loss (mitigate: narrow packets, clear protocols).
• Persona bias: Agents favoring certain styles (e.g., over-refactoring) skewing output (mitigate: diverse personas, human checkpoints, A/B in sim).
• Label adoption rate: Low uptake of driver: labels leading to mis-orchestration (mitigate: default collaborative, auto-suggest in feed, training via Q&A).
• Third-party security: External agents leaking data or misbehaving (mitigate: sandbox, scoped auth, usage caps, audit logs).
• Over-automation fatigue: Users overwhelmed by feed or feeling loss of control (mitigate: tunable budgets, easy overrides, transparent logs).

Non-Goals:

• Replacing human judgment entirely (Epics always collaborative; high-risk always checkpointed).
• Building a full UI framework (browser is future client via API; core is orchestration).
• Vendor lock-in to specific sub-agents (open to third-party via extensions).

Success Metrics (for PM as core deliverable):

• Orchestration efficiency: % of work autonomously progressed vs. human intervention (target: >70% for low-risk Features/Bugs).
• Budget adherence: Average burn rate vs. planned across cycles; % cycles under budget.
• Label adoption: % of Features/Bugs with explicit driver labels post-adoption (target: >80% within 1 week).
• Third-party integration: % of ceremonies using at least one third-party agent (target: >20% in mature projects).
• User satisfaction: Feed engagement (answers/approvals per week); reduction in manual toil (e.g., via surveys or git activity analysis).
• Reliability: Uptime of PM loop; % webhook-driven updates processed in <1m; error rate <1%.
• Adoption impact: Time-to-first-Q&A and health green in <30m for new/existing (from #633 metrics).

Roadmap: #654 (new core deliverable)
Related: #644 (multi-agent), #657 (autonomy), #631 (feed), #654, #659 (scheduled)
Status: Stub. This may be the heart of making the 'endlessly feeds' vision real at scale with a team of agents.

Q&A note (2026-06-17): Captured from user vision expansion on scheduled work and orchestrator needs. Architecture details + integration + webhook + labels + epic example + risks/metrics added in this round. Guidance note: orchestration mapping largely in script; labels communicate state; GitHub is SOR; webhooks for real-time.

Start with the named entry points and integrations: plate_what_next, AutonomyEngine, .plate configuration, plate-mcp, and plate_delegate_to_agent. Trace how GitHub issues, webhooks, budgets, checkpoints, and driver labels would connect, then compare the design against the acceptance checklist; done requires an agreed implementation scope rather than the current stub architecture.