design: agent execution model — document current reality and define target architecture #371
Description
Current reality (as of Keiko 11)
One monolithic agent per bet. Sensei dispatches via Agent tool with isolation:worktree. That agent handles all stages (research, plan, build, review) sequentially and creates a PR.
Why per-stage sub-agents don't exist: Claude Code agents cannot use the Agent tool themselves — only the sensei session can spawn sub-agents. The teammate-spawns-subagents model is architecturally impossible.
What is possible (but not yet done)
Sensei as meta-orchestrator can dispatch multiple agents per stage:
- Parallel research agents attacking different angles, sensei synthesizes
- Specialized build agent vs review agent per bet
- Cross-bet analysis agent after all bets complete
This would require sensei to actively manage stage transitions, not just fire-and-forget one agent per bet.
Design questions (needs-human)
- Is the current 'one agent per bet' model good enough for most bets? Or do we want per-stage dispatch?
- If per-stage: should sensei explicitly dispatch a research agent, wait, then dispatch a build agent — or should agents signal readiness and sensei decides?
- How do we handle bets that need parallel research (two agents exploring different approaches)?
- What is the right granularity — per-stage, per-flavor, or per-bet as now?
Related gap
Because each bet is one agent session, there is no mechanism for sensei to observe mid-stage and course-correct before the agent moves to build. The only intervention point is PR review.