Investigate plugin repository approach for community/custom agents

[ascerra]

Summary

Investigate whether a dedicated plugin repository (e.g., fullsend-ai/fullsend-community-agents) is the right model for distributing non-first-class agents, and define the mechanics for how org admins would discover, install, and maintain them.

Context

The team has identified three tiers of agent distribution:

1. First-class agents — shipped with the scaffold, installed by default or opt-in (code, review, triage, etc.)
2. Custom/user agents — written by org admins directly in their fullsend repo (e.g., classify)
3. Community/plugin agents — shared in a separate repository, installable but not verified by the core team

The first two tiers have a clear model. The third does not. Concerns include:

• Maintenance burden: A community repo could grow to 100+ agents. Who tests them? Who reviews PRs? Past ecosystems (e.g., Ansible Galaxy) have dealt with this by introducing "community tested" vs "community untested" tiers — do we want that complexity?
• Discovery UX: How does an admin find and evaluate a community agent before installing it?
• Installation mechanics: fullsend admin install-agent <repo>/<agent>? Git submodules? Copy-paste from a template?
• Version compatibility: How do community agents stay compatible as the harness, scaffold, and credential model evolve?
• Security review: Community agents run with agent-level permissions. What guardrails prevent malicious or poorly-written agents from causing harm?

What this investigation should produce

1. A decision on whether to pursue a plugin repo at all (vs. relying on docs + "bring your own agent" patterns)
2. If yes: proposed directory structure, contribution guidelines, testing expectations, and installation CLI support
3. If no: documented reasoning for the decision

Related

• Skills loading policy: explicit harness list vs. org+repo union with scanning #237 — Skills loading policy (parallel question for skills vs. agents)
• docs: add automated regression test for the adding-custom-agents guide #554 — Regression test for the adding-custom-agents guide
• Make scribe agent a first-class fullsend agent #222 — Scribe agent promotion (example of the first-class graduation path)
• docs/guides/admin/adding-custom-agents.md

[fullsend-ai-triage]

RICE Priority Score: 0.12

Score breakdown

Dimension	Score	Reasoning
Reach	0.5	This is a forward-looking investigation into community/plugin agent distribution — a third tier that no current users or strategic customers (konflux-ci, openkaiden, guacsec) have requested. All three strategic customers are still in early onboarding with first-class and custom agents, so the audience for a plugin repo is speculative future community contributors, not today's users.
Impact	0.5	Even if completed, this investigation produces a decision document and possibly a design proposal — it does not directly unblock any workflow or resolve a pain point for current users. The first two agent tiers (first-class and custom) already have clear models, so this gap is not causing friction today.
Confidence	0.5	The issue is well-written with clear scope and deliverables, which helps with effort estimation. However, confidence is lowered because there is no signal from actual users or strategic customers that this is needed — reach and impact are speculative. The project just passed MVP and is still onboarding its first customers, making the timing for a community ecosystem uncertain.
Effort	1	This is an investigation issue, not an implementation task. It requires researching prior art (Ansible Galaxy, etc.), evaluating security and compatibility concerns, and producing a written recommendation. Medium effort — it touches multiple concerns (CLI, security, versioning, UX) but the deliverable is a decision document, not code.

Formula: (0.5 × 0.5 × 0.5) / 1 = 0.12

Previous run

RICE Priority Score: 0.12

Score breakdown

Dimension	Score	Reasoning
Reach	0.5	This is a forward-looking investigation into community/plugin agent distribution — a third tier that no current users or strategic customers (konflux-ci, openkaiden, guacsec) have requested. All three strategic customers are still in early onboarding with first-class and custom agents. The audience for a plugin repo is speculative future community contributors, not today's users.
Impact	0.5	Even if completed, this investigation produces a decision document and possibly a design proposal — it does not directly unblock any workflow or resolve a pain point for current users. The first two agent tiers (first-class and custom) already have clear models, so this gap is not causing friction today.
Confidence	0.5	The issue itself is well-written with clear scope and deliverables, which raises confidence in the effort estimate. However, confidence is lowered because there is no signal from actual users that this is needed — reach and impact are largely speculative. The project is post-MVP and still onboarding its first customers, making the timing for a community ecosystem uncertain.
Effort	1	This is an investigation issue, not an implementation task. It requires researching prior art (Ansible Galaxy, etc.), evaluating security and compatibility concerns, and producing a written recommendation. Medium effort — it touches multiple concerns (CLI, security, versioning, UX) but the deliverable is a decision document, not code.

Formula: (0.5 × 0.5 × 0.5) / 1 = 0.12

[ggallen]

I think this is related and possibly addressed in #722.