Evaluate alternatives for SDLC agentic architecture on Claude Code

[nightjarrr]

Evaluate architectural approaches for implementing the agentic SDLC workflow given Claude Code capabilities and limitations discovered during issue #131.

Options to consider:

1. Subagents + relay protocol — Current approach. PM dispatches AA/Coder as Agent-tool subagents, relays communication via SendMessage. PRO: works now, minimal new infrastructure. CON: fire-and-forget lifecycle, noisy background task notifications, no AskUserQuestion in subagents, ping-pong relay bottleneck for discovery-heavy phases.

2. Agent Teams — Use Claude Code Agent Teams (experimental, CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1). Teammates are persistent full sessions, PO talks directly. PRO: direct interaction, structured gates possible. CON: experimental, higher token cost, no /resume support for in-process teammates, coordination overhead.

3. Shift center of gravity from agents to skills — PM and AA merge into a single primary agent with skill-extended behavior per phase. Coder stays as subagent but loses interactive capability (fire-and-forget implementation only). PRO: simpler architecture, no relay needed for PM/AA work. CON: loses AA specialization, Coder cannot iterate with PO.

[nightjarrr]

Relay Protocol — Session Findings

Session date: 2026-05-14
Issue: #131 — Refine aa-spec skill
Context: First live relay session with AA under the PM relay protocol. Three distinct problems surfaced, one of which is an architectural constraint.

---

Summary table

#	Finding	Severity	Type
1	PM fabricated option label in AskUserQuestion relay	High	PM execution failure
2	SendMessage used agent name instead of agent ID	High	Missing protocol instruction
3	Background-resumed agents auto-deny all permission prompts	Critical	Architectural constraint
4	CLAUDE.md has no structured question example	Low	Documentation gap

---

Finding 1 — PM fabricated content in AskUserQuestion relay

What happened: PO selected "Other" in an AskUserQuestion and typed a question. PM incorrectly relayed #PO: 1. Yes, that direction — <typed text> to AA, prepending a fabricated option label that PO never selected.

Root cause: PM misread the AskUserQuestion result format. When "Other" is selected, the answer value IS the typed text — there is no label prefix. PM hallucinated a label from the available options list and combined it with the typed text as if it were a note.

Impact: AA received fabricated content attributed to PO. This is a content integrity failure — the subagent acted on words PO never said. In this session, AA was resilient enough to detect the answer was invalid and re-ask, but that is not guaranteed behavior.

Protocol status: No documentation gap. CLAUDE.md already states: "the selected option label (if any)" and "if PO selected 'Other' and typed free text, relay that text exactly as written." The rule is correct; PM did not apply it.

Severity: High — content fabrication in relay, even if caught by AA resilience this time.

Recommendation: No CLAUDE.md change needed. The parsing rule is already documented. Potential reinforcement: add an explicit note distinguishing the two cases — "if the answer value matches one of the option labels exactly, it is a selection; otherwise it is free text from 'Other'."

---

Finding 2 — SendMessage used agent name instead of agent ID

What happened: After AA's first Agent tool call returned, PM sent the relay via SendMessage with to: "associate-architect" (the agent name). This call silently returned {"success":true} but did not resume AA's session. AA was paused, waiting for a resume — it received nothing.

Root cause: The relay protocol in CLAUDE.md describes using SendMessage to relay PO responses but never specifies that the agent ID (returned by the Agent tool) must be used as the to value. PM defaulted to the agent name, which is ambiguous and does not identify a session.

How it was discovered: PO noticed AA was not visible in the agents dialog. Investigation confirmed name-based SendMessage routes to a generic inbox, not a specific session. Sending with the agent ID (a946836d39b04ab18) immediately resumed AA from transcript.

Impact: One full relay exchange was dropped. AA never received PO's answer. The session was recoverable because AA remained paused, but any relay using the name is silently lost — PM has no way to detect the failure from the success:true response.

Severity: High — silent message loss with no error signal. Easy to miss entirely.

Recommendation: Add to CLAUDE.md immediately after the SendMessage availability check:

Capture the agent ID. When the Agent tool returns, extract the agentId from the result and retain it for the session. All subsequent SendMessage calls to that subagent must use the agent ID as the to value — not the agent name. The agent name is not a session handle; two parallel agents of the same type share a name but have different IDs. Using the name silently succeeds at transport but does not resume the correct session.

---

Finding 3 — Background-resumed agents auto-deny all permission prompts

What happened: AA completed its discovery conversation and attempted to write the refined SKILL.md. Both Write and Edit were silently denied. No permission prompt appeared for PO. AA escalated with the full draft in its final message.

Root cause: This is documented platform behavior, not a misconfiguration. From the Claude Code docs (source):

"Background subagents run concurrently while you continue working. They run with the permissions already granted in the session and auto-deny any tool call that would otherwise prompt."

Every SendMessage resume runs in the background — the tool response explicitly confirms this: "resumed from transcript in the background." Therefore, any AA action requiring a permission prompt (Write, Edit, destructive Bash) will always be auto-denied during a SendMessage resume cycle. This is a hard platform constraint.

Impact: AA can never write files while operating in the relay loop. The entire write stage — which is the primary deliverable of an AA docs session — is blocked. This affects every AA session that follows the current relay architecture.

Severity: Critical — the relay loop as currently designed cannot complete an AA docs task end-to-end.

Recommended course of action:

The docs offer the canonical path: "start a new foreground subagent with the same task to retry with interactive prompts" — i.e., a fresh Agent tool call.

Two viable patterns for the relay protocol:

Option A — Split dispatch: discovery in relay loop, write in fresh foreground dispatch.
AA operates normally through the relay loop for all discovery and drafting decisions. When AA signals it is ready to write (e.g., a structured "ready to write" terminal message), PM terminates the relay session and spawns a fresh foreground Agent dispatch with the agreed content and a narrow write-only task. The foreground dispatch surfaces permission prompts normally.

Option B — PM applies the write directly.
AA outputs the final content in its terminal message (as it did in this session). PM — which runs in the foreground — applies the write to the file on AA's behalf and handles the permission prompt. AA's role ends at producing the content; PM owns the commit step.

Option B is simpler and already demonstrated to work in this session (AA did produce the full content). Option A preserves AA's authorship of the write but adds a dispatch round-trip. Option B is the recommended starting point.

---

Finding 4 — CLAUDE.md has no structured question example

What happened: No actual problem occurred — PM handled the structured question correctly on the mechanical level. But CLAUDE.md describes the --QUESTION--/--OPTIONS--/--ENDQUESTION-- format without showing a concrete example, while subagent-relay-comms/SKILL.md already has one (with numeric labels).

Severity: Low — documentation asymmetry, no operational impact.

Recommendation: Add a matching example to the CLAUDE.md "Structured questions handling" section for symmetry. Low priority.

---

What worked correctly

Behavior	Notes
#PO: prefix stripping on every outbound message	Consistent throughout
🟢 header applied to all AA→PO relay	Correct format every time
Structured question detected and transformed into AskUserQuestion	Correct
Free-form AA response relayed without unnecessary AskUserQuestion	Correct judgment call
Split routing on #AA: / #PM: markers	Both parts routed independently
Ping response not relayed to PO	Correctly treated as noise
Session recovered after name-based SendMessage failure	Correct diagnosis and recovery
AA terminal response presented verbatim	Correct

---

Priority order for CLAUDE.md updates

1. Agent ID capture and use (Finding 2) — straightforward instruction addition, high impact
2. Write step architecture (Finding 3) — requires protocol design decision before documenting
3. Structured question example (Finding 4) — low priority, polish only

[nightjarrr]

Discovery finding: multi-issue complexity and the necessity of PM as coordinator

During the architectural exploration for this issue, a case study of #71's history surfaced an important insight about the nature of the SDLC workload.

The history of #71 shows how real development work does not arrive as a clean sequential issue queue:

• Associate Architect agent definition #71 started as a single implementation ticket, then its scope revealed sub-issues were needed (per-phase AA skills)
• Refine aa-spec skill #131 (first skill: aa-spec) was spun off and began work
• During Refine aa-spec skill #131's work, the relay communication problem was identified → Define and implement relay communication protocol between PO, PM, and subagents #135 (relay protocol) was created as a dependency
• The architectural findings from Define and implement relay communication protocol between PO, PM, and subagents #135's first live use → Evaluate alternatives for SDLC agentic architecture on Claude Code #136 (this issue, architectural evaluation) was opened
• At peak: four simultaneously open, active issues with hierarchical and dependency relationships: Associate Architect agent definition #71 (umbrella, can't close until skills are done), Refine aa-spec skill #131 (first skill, blocked on relay), Define and implement relay communication protocol between PO, PM, and subagents #135 (relay protocol, dependency for Refine aa-spec skill #131), Evaluate alternatives for SDLC agentic architecture on Claude Code #136 (long-term architectural track)

This rejects an early assumption in this exploration: that the SDLC for a single-developer project would be largely sequential (one issue at a time), which would make PM's coordination role largely overhead.

The reality is the opposite: issues spawn sub-issues, platform constraints spawn infrastructure work, and findings during implementation spawn parallel evaluation tracks. Four active issues with complex dependencies is a normal product of real work, not a deviation from the expected case.

Implication for architecture: PM's value is not within-issue orchestration (that framing makes it look like overhead). Its value is cross-issue coordination: tracking state across multiple active issues, understanding dependency relationships, deciding what to advance and when, managing phase transitions that span tracks. That coordination work is genuine and scales with the complexity of the product. It does not go away as the SDLC matures — it increases.

This doesn't close the question of how to implement PM's coordination role (relay, Agent Teams, or merged model) — but it establishes that PM as a distinct role with real ongoing responsibilities is a design requirement, not a nice-to-have.

[nightjarrr]

Options evaluation: criteria and scoring (Options 1 and 3)

SDLC needs

#	Need	Description
N1	AA ↔ PO interactive design	Discovery conversations, iterative drafting, structured gates
N2	AA file authoring	Write, commit, push artifacts to feature branch
N3	Coder implementation	Execute impl-plan, push code
N4	Communication integrity	PO's intent reaches the right agent without distortion
N5	GitHub state management	Phase labels, issue comments, PR creation
N6	Within-issue phase transitions	PM decides when to advance phase, dispatch correct agent
N7	Cross-issue coordination	Track multiple active issues, dependency relationships, priority decisions — reconstructed from GitHub state each session (no persistent session assumed by SDLC design)
N8	Context window usage	Keeping context pressure manageable across roles and phases
N9	Token usage	Cost of message exchange and instruction overhead
N10	Design scalability	Adding new roles (code reviewer, critic, QA); fan-out of parallel agents

Note: session continuity (persistent session carrying context phase-to-phase) is not a design requirement. Git/GitHub is the persistence layer; context is carried in documents and issue threads. Any session reconstructs context from durable artifacts.

---

Option 1 — Subagents + relay

Need	Status	Notes
N1 AA ↔ PO interactive	⚠️ Brittle	Works via relay — structurally unstable; PM fights its own instincts on every exchange; 5 patches required in a single live session
N2 AA file authoring	❌ Blocked	Background-resumed agents auto-deny permission prompts — hard platform constraint, unresolvable by instruction
N3 Coder implementation	⚠️ Conditional	Works only if Coder is strictly fire-and-forget; any relay communication (a question mid-run) triggers the same background auto-deny as N2
N4 Communication integrity	⚠️ Unreliable	Content fabrication, wrong SendMessage target, relay interception — all occurred in first live session
N5 GitHub state mgmt	✅ Works	PM handles directly, no relay needed
N6 Within-issue transitions	✅ Works	PM tracks phase, dispatches next subagent
N7 Cross-issue coordination	✅ Works	PM reconstructs from GitHub at session start; within-session working memory is a pragmatic benefit
N8 Context window	✅ Isolated	Separate context per session; AA gets a clean, phase-scoped context per dispatch
N9 Token usage	⚠️ Relay overhead	Every exchange is doubled: PM processes and re-formats each message in both directions; relay instructions add weight; costly for discovery-heavy phases
N10 Design scalability	⚠️ Constraints multiply	Adding one-shot roles scales fine. Every new interactive role inherits relay brittleness + background permissions constraint. Fan-out: relay protocol assumes one active subagent at a time — parallel roles require major redesign on top of existing structural problems

Summary: N2 is a hard blocker. N1 and N4 are structurally unstable — not fixable by better instructions, they reflect a fundamental mismatch between what relay requires (transparent message pipe) and what PM naturally does (analyze, interpret, be helpful). The background permissions constraint is not AA-specific: it affects any subagent that communicates via relay. N10 scales poorly as interactive roles are added.

---

Option 3 — Merged PM/AA (skills-based)

Need	Status	Notes
N1 AA ↔ PO interactive	✅ Works	Direct PO interaction — demonstrated in the current session
N2 AA file authoring	✅ Works	Foreground session, full permissions
N3 Coder implementation	✅ Works	Fire-and-forget by design; no relay communication needed
N4 Communication integrity	✅ Works	No relay, no distortion
N5 GitHub state mgmt	✅ Works	Requires github:write in role definition — design choice, not a hard constraint
N6 Within-issue transitions	✅ Works	Same session handles full issue lifecycle
N7 Cross-issue coordination	⚠️ Design gap	PM-mode coordination logic (issue reading, dependency reasoning, priority decisions) needs to be explicitly designed into the merged session. Not a hard constraint — GitHub is the persistence layer — but requires intentional work
N8 Context window	⚠️ Pressure	PM instructions + AA instructions + phase skill + prior artifacts + discovery conversation all in one window. Manageable with phase-scoped sessions (fresh session per phase, context reconstructed from GitHub); risk grows if a session spans multiple phases
N9 Token usage	✅ Efficient	No relay doubling. Larger initial instruction context, but no per-exchange overhead. More efficient overall for multi-exchange sessions
N10 Design scalability	⚠️ Hard ceiling on parallelism	Sequential roles add cleanly as skills. Single-session model is a structural ceiling: fan-out (parallel reviewer agents) is architecturally impossible. Non-interactive parallel subagents (fire-and-forget, same pattern as Coder) remain possible but PM tracking of parallel outputs needs explicit design

Summary: N1–N6 all work or are straightforwardly solvable. N7 is a design gap (not a platform constraint) that requires intentional work on PM-mode capabilities. N8 is manageable with session discipline. N10 hits a hard parallelism ceiling — sequential role extension is clean, but fan-out doesn't fit the single-session model.

---

Option 2 (Agent Teams) evaluation pending — expected to score differently on N1, N8, N9, and N10 in particular.

[nightjarrr]

Broad brainstorm: unexplored directions

⚠️ These are unvetted "crazy ideas" — no feasibility or applicability check has been done. Captured here to map the exploration field, not as serious candidates. We'll criticize later.

---

Communication channel alternatives (replace the relay)

MCP server as message broker
AA calls mcp_ask_po(question, options) → MCP server holds it → surfaces to PO → PO answers → AA polls mcp_get_answer(). PM is completely out of the content path — only knows "AA is waiting." The channel is a dumb API, not a thinking agent. No interpretation risk by design.

File-based mailbox
AA writes /tmp/aa-to-po.json, polls for /tmp/po-to-aa.json. A watch script or PM triggers a notification. Dead simple, fully decoupled from PM's language model. Could even be a markdown file PO edits directly in the editor.

Named pipe / local socket
./scripts/channel.sh send "message" / ./scripts/channel.sh recv. Low-level IPC, zero intelligence in the channel. AA blocks on read, PM/PO writes to it. Reliable because there's no agent interpreting it.

Tiny local web server in the container
Express/Flask server already running in the dev container. AA calls POST /message, PO sees it in a browser tab or terminal, responds via POST /reply. Minimal UI possible.

Dedicated AskUserQuestion MCP tool for subagents
Custom MCP tool that wraps AskUserQuestion and makes it callable directly by subagents. AA calls ask_user(question, options) as a proper tool call instead of emitting the --QUESTION-- text format that PM has to detect and transform. PM is bypassed entirely for question/answer exchange. No transformation step, no interpretation risk.

---

Fixing background permissions (attack the constraint directly)

permissionMode: bypassPermissions in AA frontmatter
If the root problem is "permission prompts are auto-denied in background," eliminate the prompts by pre-approving them. AA already has a bash allowlist hook constraining shell commands. File write/edit are safe for AA by design. Setting bypassPermissions removes prompts → removes auto-deny. Potentially the simplest fix — worth testing.

Pre-warm permissions in foreground
Before the first SendMessage, have AA perform a Write to a temp file in the foreground portion of the session. Write gets added to the session's approved set. When AA is later resumed in background, Write is already approved — no new prompt, no auto-deny. Hacky but zero-infrastructure.

PostToolUse / PreToolUse hook to pre-approve
Hooks run synchronously in the agent's context. A hook that pre-approves specific tools when AA starts its session (before any SendMessage) might carry those approvals into the background resume. Speculative — depends on whether the approval set persists across resume boundaries.

Foreground-only relay via fresh dispatch
Never use SendMessage to resume. Instead: AA writes its question + full context snapshot to a handoff file and terminates. PM spawns a fresh foreground AA dispatch with the handoff file. Every "exchange" is a cold-start foreground session. Background resume never happens → constraint never triggered. Cost: latency + cold-start per exchange. Benefit: full permissions always.

---

Alternative coordination patterns

Multiple Claude Code instances in tmux
PM in pane 1, AA in pane 2, Coder in pane 3. Each is a full foreground session. Communication via shared filesystem. No relay — PO switches panes to talk to whoever is active. Already have multi-pane tmux in the container. Essentially "manual Agent Teams" without the experimental flag.

PM as a script / state machine (not an AI)
Replace PM's coordination role with a deterministic script: issue state → label → next agent to dispatch. No LLM in the coordinator = no interpretation risk. PM's judgment becomes explicit rules. Loses ability to handle edge cases, gains reliability for the happy path. AI judgment reserved for roles that actually need it (AA, Coder).

GitHub Actions as PM
AA completes Phase 2, commits, pushes. A GitHub Action detects the committed artifact, updates the label to phase: tech-design, fires a notification. Phase transitions are automated CI/CD. Loses judgment, gains determinism and zero relay.

Event log + reactive PM
Agents emit structured events to a shared log file on disk. PM is a reactive loop that reads the log and dispatches based on events. Completely decoupled: AA doesn't know PM exists, just emits events. PM is never in the communication content path.

---

Weird / lateral ideas

AA as a GitHub bot
AA is not a Claude Code agent at all — it's a standalone Claude API call triggered by a GitHub webhook. PO comments on an issue → webhook fires → Claude API call with AA prompt → response posted as issue comment. Completely serverless, no session management, no background resume. Interaction is entirely in the GitHub issue thread. Loses real-time back-and-forth, gains reliability and no dependency on Claude Code internals.

Structured artifacts as the protocol (async discovery)
AA never talks to PO in real time during a phase. PM writes a fully-specified brief capturing all requirements, decisions, and constraints, then dispatches AA fire-and-forget. If AA has a question, it writes it to an "open questions" section and terminates. PM surfaces the questions to PO, next dispatch AA gets the answers in the brief. Discovery is asynchronous — multi-turn but each turn is a fresh dispatch. No real-time channel needed.

PM is not Claude
PM doesn't need to be a Claude Code session. It could be GPT-4o, a simple script, or a Slack bot. PM's core tasks (read GitHub state, make routing decisions, dispatch agents) are low-complexity — they don't require a frontier model. Using a different tool or a lighter model for coordination eliminates the "PM interprets content it should relay" problem by construction.

[nightjarrr]

Full options comparison: 12 criteria across 3 options

SDLC needs (complete list)

#	Need	Description
N1	AA ↔ PO interactive design	Discovery conversations, iterative drafting, structured gates
N2	AA file authoring	Write, commit, push artifacts to feature branch
N3	Coder implementation	Execute impl-plan, push code
N4	Communication integrity	PO's intent reaches the right agent without distortion
N5	GitHub state management	Phase labels, issue comments, PR creation
N6	Within-issue phase transitions	PM decides when to advance phase, dispatch correct agent
N7	Cross-issue coordination	Track multiple active issues, dependency relationships, priority decisions — reconstructed from GitHub state each session (no persistent session assumed)
N8	Context window usage	Keeping context pressure manageable across roles and phases
N9	Token usage	Cost of message exchange and instruction overhead
N10	Design scalability	Adding new roles; fan-out of parallel agents
N11	Conceptual alignment	How well the approach maps onto the SDLC's role model and workflow shape
N12	Stability	Whether the approach relies on GA or experimental/preview features

---

Option 1 — Subagents + relay

Need	Status	Notes
N1 AA ↔ PO interactive	⚠️ Brittle	Structurally unstable; PM fights its own instincts; 5 patches required in first live session
N2 AA file authoring	❌ Blocked	Background-resumed agents auto-deny permission prompts — hard platform constraint, unresolvable by instruction
N3 Coder implementation	⚠️ Conditional	Works only if Coder is strictly fire-and-forget; any relay communication triggers same background auto-deny as N2
N4 Communication integrity	⚠️ Unreliable	Content fabrication, wrong SendMessage target, relay interception — all occurred in first live session
N5 GitHub state mgmt	✅	PM handles directly
N6 Within-issue transitions	✅	PM tracks phase, dispatches next subagent
N7 Cross-issue coordination	✅	PM reconstructs from GitHub at session start
N8 Context window	✅ Isolated	Separate context per session; clean phase-scoped AA context per dispatch
N9 Token usage	⚠️	Every exchange doubled by relay; relay instructions add weight; costly for discovery-heavy phases
N10 Design scalability	⚠️	One-shot roles scale fine; every interactive role added inherits all relay constraints; fan-out requires major relay redesign on top of existing structural problems
N11 Conceptual alignment	❌ Poor	Repurposes fire-and-forget subagents for interactive work — fights the tool's design intent at every turn
N12 Stability	⚠️ Experimental	Requires CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 for SendMessage — same flag as Agent Teams

Summary: N2 is a hard blocker. N1 and N4 are structurally unstable — not fixable by better instructions. N11 and N12 compound the picture: experimental and conceptually misaligned. No remaining advantage over the other options.

---

Option 3 — Merged PM/AA (skills-based)

Need	Status	Notes
N1 AA ↔ PO interactive	✅	Direct PO interaction — demonstrated in the current session
N2 AA file authoring	✅	Foreground session, full permissions
N3 Coder implementation	✅	Fire-and-forget by design; no relay needed
N4 Communication integrity	✅	No relay, no distortion
N5 GitHub state mgmt	✅	Requires github:write in role definition — design choice, not hard constraint
N6 Within-issue transitions	✅	Same session handles full issue lifecycle
N7 Cross-issue coordination	⚠️	PM-mode coordination logic needs explicit design in merged session; not a hard constraint — GitHub is the persistence layer
N8 Context window	⚠️	All instructions + skill + artifacts + conversation in one window; manageable with phase-scoped sessions (fresh session per phase)
N9 Token usage	✅	No relay doubling; larger initial context but no per-exchange overhead; more efficient for multi-exchange sessions
N10 Design scalability	⚠️	Sequential roles add cleanly as skills; fan-out architecturally impossible in single-session model — hard ceiling on parallelism
N11 Conceptual alignment	⚠️ Partial	Collapses PM and AA role boundaries that the SDLC design intentionally separates; works well for current sequential workflow; departs from the long-term role separation intent
N12 Stability	✅ GA	No experimental features required

Summary: N1–N6 all work or are straightforwardly solvable. N7 is a design gap, not a platform constraint. N10 has a hard parallelism ceiling. The only GA option — stability is a genuine advantage. Conceptual alignment is a compromise: captures the intent in practice, sacrifices the role model in design.

---

Agent Teams

Need	Status	Notes
N1 AA ↔ PO interactive	✅	PO attaches directly to AA teammate via Shift+Down; PM not in content path
N2 AA file authoring	✅	Full session permissions; prompts surface as "needs input" or pre-approve via bypassPermissions
N3 Coder implementation	✅	Teammate or fire-and-forget subagent; both work
N4 Communication integrity	✅	No relay; PO ↔ AA direct
N5 GitHub state mgmt	✅	Lead (PM) handles directly
N6 Within-issue transitions	✅	Lead manages phase transitions
N7 Cross-issue coordination	⚠️	Lead reconstructs from GitHub; "one team at a time" limits true parallel-issue management
N8 Context window	✅ Isolated	Each teammate has own context window; in-process mode (Shift+Down) — no split panes in current dev container setup
N9 Token usage	⚠️	"Significantly more tokens" — each teammate is a full independent Claude instance
N10 Design scalability	✅	Native fan-out; shared task list with dependency tracking; quality gate hooks (TeammateIdle, TaskCompleted); designed for parallel roles
N11 Conceptual alignment	⚠️ Misaligned use case	Designed for parallel independent workers with minimal human intervention; our SDLC is sequential, high human involvement — framework is over-engineered for the workflow shape, but technically capable
N12 Stability	⚠️ Experimental	Requires same CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 flag as Option 1

Summary: Solves all hard technical blockers (N1, N2, N4). Best N10 story of the three. Shares experimental status with Option 1 (same flag), but with far fewer structural problems. Main cost: token usage and conceptual mismatch — the framework is designed for a different workflow shape than the SDLC requires.

---

Cross-option pattern

	Option 1	Option 3	Agent Teams
Hard technical blockers	❌ N2 blocked, N4 unreliable	None	None
Stability	⚠️ Experimental	✅ GA	⚠️ Experimental
Conceptual alignment	❌ Poor	⚠️ Partial	⚠️ Misaligned use case
Scalability ceiling	Interactive roles break	Fan-out impossible	One team at a time

Option 1 is the worst combination — experimental and conceptually misaligned, with hard blockers that can't be resolved by instruction.

The real choice is between Option 3 (GA, simpler, works now, long-term role model compromised) and Agent Teams (experimental, more complex, preserves role separation, better scalability story — but designed for a different workflow shape).

[nightjarrr]

Option 3 vs Agent Teams: final comparison and AA recommendation

Final comparison

	Option 3 — Merged PM/AA	Agent Teams
Hard technical blockers	None	None
Stability	✅ GA	⚠️ Experimental (same flag as relay)
Near-term fan-out (read-only subagents)	✅ Works today	✅ Works
Long-term fan-out (interactive coordinating agents)	❌ Hard ceiling	✅ Native
Token cost	✅ Efficient	⚠️ Significantly higher
Session resumption	✅ Normal	⚠️ Teammates lost on /resume
Conceptual fit with SDLC workflow	⚠️ Collapses PM/AA boundaries	⚠️ Designed for different workflow shape
Migration path	→ Agent Teams when fan-out needed	Terminal — no further step

The decisive asymmetry: Option 3's ceiling (no Agent Teams-style fan-out) is in the long-term/uncertain bucket. Agent Teams' main risk (experimental stability) is immediate. We have direct evidence that experimental Claude Code features under real-world pressure produce significant instability — that was the relay experience. Option 3 keeps us on stable ground while the platform matures.

Subagent fan-out (read-only parallel workers — code reviewers, exploratory sub-agents) is already compatible with Option 3. The background permissions constraint only affects file-writing agents. Near-term fan-out needs are covered without Agent Teams.

---

Associate Architect's recommendation: Option 3

Note: this is AA's recommendation based on the exploration in this issue. PO has not endorsed it.

Adopt Option 3 (merged PM/AA, skills-based) as the architectural direction.

Reasoning:

1. Only GA option. Given the relay's instability under experimental conditions, building on stable platform primitives is the right risk posture.

2. Covers everything needed now and near-term. All current SDLC phases are sequential. Near-term fan-out (read-only subagent workers) works without modification.

3. The uncertainty cuts in its favor. The only thing Agent Teams does better is long-term coordinating fan-out — and we don't know if or when that's needed. Under that uncertainty, the stable option wins.

4. Migration path is defined. When the SDLC genuinely needs interactive coordinating agents, Option 3 → Agent Teams is a natural evolution: same AA/Coder definitions, PM re-separated, Agent Teams hopefully GA by then. Building on Option 3 now doesn't close that door.

5. This session is the proof of concept. AA running as a primary session, communicating directly with PO, writing files, doing deep discovery work — this is Option 3 in practice. It works.

What Option 3 requires to be implemented properly:

• PM-mode capabilities (github:write, cross-issue coordination logic) explicitly designed into the primary session
• Phase skills continue to define AA's behavior per phase
• Coder remains one-pass fire-and-forget subagent
• Issue thread + artifacts remain the persistence layer (no reliance on session continuity)

[nightjarrr]

Phase-primary design — architectural direction for the agentic SDLC Claude Code implementation. Core concept: one agent is the primary foreground session per phase (slideshow model), coordinated by a script called the conductor.

Draft:
https://github.com/nightjarrr/molim/blob/136-evaluate-alternatives-for-sdlc-agentic-architecture-on-claude-code/docs/claude-sdlc/phase-primary-design.md