agent-fungibility-philosophy
Made by JeffFungible agent architecture for multi-agent coding. Use when scaling agent swarms, designing multi-agent workflows, recovering from agent failures, or choosing specialized vs. interchangeable agent patterns.
Works With
Quality and Utility come from canonical skill metadata. Community ratings appear separately as stars when subscriber reviews exist.
Subscribe to download
Public previews are available, but downloads, CLI sync, and premium content require an active subscription.
Sign In to Subscribe- Full skill content with deterministic versioning
- CLI sync + local search index
- Access to Jeffrey’s premium library
Save to your account
Saved skills live in your cloud list. Run jsm sync on each machine to pull them locally.
What's New with this Skill
2Updates, enhancements, and release notes for this skill.
Enhanced: agent-fungibility-philosophy, recovery commands use real pane selectors
The rate-limit recovery page addressed panes as PROJECT:cc_3, a form NTM rejects outright since session names cannot contain a colon. The recipes now use the real selector grammar: ntm kill PROJECT --pane=3,4 -f to shed panes and ntm send PROJECT --pane=1 to pause a specific agent.
- Colon-form pane addressing replaced with --pane=N selectors (N, W.P, or %N) verified against the live binary
- kill --pane carries -f so an automated recovery is not silently aborted by the confirmation prompt
New: Agent Fungibility Philosophy, interchangeable generalists beat specialized roles
Specialized agents ("frontend agent", "testing agent") create bottlenecks: when the testing agent dies, the work stops. Fungible agents are identical generalists pulling beads from a shared queue. The skill is the architecture argument and the bootstrap prompt that makes every agent (Claude Code, Codex, Gemini) start from the same context and the same rules: read AGENTS.md and README.md fully, investigate the codebase, register with Agent Mail, then start pulling beads.
- The bootstrap prompt is identical for every agent and every model (Claude Code, Codex, Gemini): read AGENTS.md and README.md, investigate the code, register with Agent Mail, then pick the next bead with bv. It also warns against "communication purgatory"
- Failure resilience comes from the swarm shape: a dead agent is replaced by a fresh agent with the same init prompt, and its in-progress bead can be resumed by anyone
- Linear scaling: 3 → 10 → 30 agents requires no rebalancing of ownership; the shared queue does the work
- No critical-path specialists blocking the pipeline. "Only Alice can do auth" is the failure mode this skill exists to prevent
- Model mix still matters even though agents are fungible: 3 Claude + 2 Codex + 1 Gemini for general development, starting with 3-6 agents via ntm spawn
- Composes with ntm (spawning and managing identical agents), agent-mail (coordination without a central dispatcher), and br/bv (the shared bead pool and decentralized prioritization)
The philosophy: "fungibility bestows a LOT of really good properties automatically in a computer system." The goal is to build the machine once, set it running, and move on. Front-load the human input in planning so the swarm runs unattended. Every agent reads AGENTS.md and README.md from scratch, investigates the codebase, registers with MCP Agent Mail, and starts pulling beads from the shared queue using bv. There is no role replacement because there are no roles.