Re-platform default agents as harness-driven configs, not scaffold-embedded artifacts

[ralphbean]

What happens

Fullsend's six default agents (triage, code, review, fix, prioritize, retro) are delivered through a different mechanism than custom agents:

• Their workflow files, harness configs, agent definitions, skills, scripts, and policies are embedded in the fullsend binary via internal/scaffold/fullsend-repo/
• They are layered at runtime via ADR 0035 (upstream defaults overlaid with customized/ overrides)
• Their roles are hardcoded in ValidRoles() and DefaultAgentRoles()
• Each has a dedicated workflow file with a # fullsend-stage: marker and a dedicated reusable workflow (reusable-triage.yml, reusable-code.yml, etc.)

This means default agents and custom agents use fundamentally different delivery and configuration paths. An org admin looking at their .fullsend repo sees no trace of the default agents in their config — they're invisible infrastructure that "just exists."

What should happen

Default agents should be configured using the same mechanism as custom agents. When an org admin looks at their config.yaml, they should see entries for triage, code, review, etc. that look exactly like an entry for a third-party agent — harness references pointing to fullsend-ai/fullsend (or fullsend-ai/library) with the same URL+SHA256 format.

This means:

• An admin can remove a default agent by deleting its config entry, not by understanding the scaffold layering model
• An admin can add a default agent the same way they'd add any other agent
• The scaffold for a fresh install produces a config.yaml with explicit harness references for each default agent, not an implicit "you get all six"
• Installing with no agents and enabling one at a time becomes the natural default path

Context

Depends on #1985 (harness-driven dispatch routing) being implemented first.

This is the "eat your own dogfood" step: if the custom agent installation path is good enough for third parties, it should be good enough for fullsend's own agents.

Related:

• ADR 0035 — Layered content resolution
• ADR 0038 — Universal harness access via URLs
• Investigate plugin repository approach for community/custom agents #631 — Investigate plugin repository approach for community/custom agents
• Publish scaffold skills and sub-agent definitions as a standalone Claude Code plugin #1901 — Publish scaffold skills as standalone Claude Code plugin

[ralphbean]

This one matters for redhat-developer too — and really for anyone adopting fullsend. Custom agents shouldn't feel like they're grafted onto the side of the system while default agents get special treatment. If we re-platform our own agents to use the same harness-driven config path, then adding a third-party agent and adding a default agent are the same operation. Level playing field. That's the experience we want.

/fs-prioritize

[fullsend-ai-triage]

Triage Summary

This issue proposes re-platforming the six default agents (triage, code, review, fix, prioritize, retro) from scaffold-embedded artifacts to harness-driven config entries — making default and custom agents use the same delivery mechanism.

Status: Blocked

This issue explicitly depends on #1985 (harness-driven dispatch routing), which is still open. The harness-driven dispatch mechanism must exist before default agents can be re-platformed to use it. Once #1985 lands, this issue can proceed.

The scope is well-defined: replace the implicit scaffold layering with explicit config.yaml entries that reference harness URLs, update ValidRoles()/DefaultAgentRoles() to be config-driven, and ensure fresh installs produce a config with explicit agent entries rather than invisible defaults.

Related issues for context: #631 (plugin repository approach), #1901 (standalone scaffold skills).

---

Labels: Adding component/dispatch since this involves changing how default agents are dispatched, and priority/medium as a planned architectural improvement with no production impact.

[ralphbean]

/fs-prioritize

[fullsend-ai-prioritize]

RICE Priority Score: 0.8

Score breakdown

Dimension	Score	Reasoning
Reach	2	This affects all fullsend users since every org uses the six default agents. The comment from ralphbean explicitly calls out redhat-developer and 'anyone adopting fullsend' as beneficiaries. Every org admin who configures agents will interact with this change, so scoring as most active users across orgs.
Impact	1	This is an architectural consistency improvement — default agents work fine today via scaffold embedding. The benefit is a unified mental model for admins (add/remove any agent the same way) and a level playing field for custom agents. It's a noticeable improvement to the configuration workflow but not blocking anyone currently.
Confidence	0.8	High confidence — the issue is exceptionally well-described with clear scope (re-platform 6 agents, update ValidRoles/DefaultAgentRoles, change scaffold output), explicit dependencies (#1985), and supporting ADRs. The triage agent confirmed the scope. The only gap is that it's blocked, so timeline is uncertain.
Effort	2	Complex — requires re-platforming all six default agents from scaffold-embedded artifacts to harness-driven config entries, updating hardcoded role functions to be config-driven, changing the scaffold for fresh installs, updating reusable workflows, and ensuring backward compatibility. Multiple components (dispatch, harness, install) are involved per the labels.

Formula: (2 x 1 x 0.8) / 2 = 0.8