Explore director agents for repo-local coordination

[eloylp]

Context

As the fleet grows, we are starting to see a need for agents that are not pure implementers or reviewers. A future pattern is a director agent: an agent with strong local knowledge about one repo or one bounded agentic world, responsible for deciding what work should happen and which specialist agents should be asked for help.

This is intentionally more advanced than today's dispatch model. Today, dispatch is mostly a direct agent-to-agent request: an agent sees an expert roster and can request one of the allowed targets. A director would be closer to a coordinator with repo-local judgement.

Core idea

A director agent would:

• Keep and curate local knowledge about a repo: architecture, conventions, risky areas, release cadence, recurring problems, ownership boundaries, and current priorities.
• Receive broad requests from humans or other agents and translate them into concrete work.
• Decide which specialist agents should be involved: coder, refactorer, pr-reviewer, security reviewer, docs writer, scout, etc.
• Reduce duplicate or conflicting work by tracking intent before dispatching specialists.
• Act as a high-signal routing layer rather than making every worker agent independently rediscover repo context.

Why this matters

The current model works well when a trigger points at a concrete issue/PR/comment. It is weaker when the work is broad, for example:

• “Improve this repo.”
• “Find useful refactors.”
• “Prepare the next release.”
• “Check whether any current PRs need specialist review.”
• “Choose what coder should work on next.”

Without a director, multiple agents can inspect the same repo and independently choose similar work. That creates noise and duplicated PRs.

Possible future primitives

This issue is not prescribing an implementation yet, but these concepts may be needed:

• Director role/prompt pattern: a standard prompt contract for coordinator agents.
• Curated memory: director memory may need stricter hygiene than normal worker memory, because it becomes an operational knowledge base.
• Work intent records: a way to represent “agent X is currently working on issue/PR/task Y”.
• Dispatch intent types: e.g. select_work, review_plan, implement_task, review_output, investigate.
• Namespaces/worlds: advanced isolation where related agents and repos belong to the same coordination boundary.
• Conflict avoidance: directors should avoid dispatching duplicate implementation work when a semaphore/label/work record already exists.

Open questions

• Should directors be normal agents with conventions, or a first-class daemon concept?
• Should director memory be manually editable/approved, or fully agent-maintained?
• Should directors dispatch across repos, or only within a repo/namespace?
• How should a director know that work is already in progress?
• Should the daemon provide work-intent storage, or should the first version rely on GitHub labels/comments?
• Should user-triggered broad repo runs go through a director by default?

Out of scope for now

• Changing dispatch validation semantics.
• Implementing namespaces.
• Replacing the current direct dispatch model.
• Solving manual run deduplication. That should be handled separately.

Proposed next step

Keep this as a design discussion until the fleet has more operational data. A small first experiment could be a manually configured director agent prompt that uses repo labels as semaphores and dispatches only to explicitly allowed specialists.