Building a 26-Subagent Marketplace in One Session
A single conversation that spawned 26 subagents to build an entire community marketplace feature -- backend API, frontend pages, dynamic OG images, ChromaDB search, and semantic categorization -- across a full-stack monorepo.
It started with a routing bug on /marketplace/[id] — the page was 404ing because the dynamic route wasn’t being generated. That was a two-minute fix. But while investigating it, I noticed the entire marketplace feature was missing substantial functionality. One conversation later, twenty-six subagents had built it.
Scope of the feature
The full scope only became clear once the orchestrator mapped the existing codebase. The backend needed CRUD endpoints for marketplace listings, a clone/fork endpoint with ownership transfer and version bumping, publish/unpublish endpoints with validation that prevented publishing integrations with missing required fields, rate limiting middleware to prevent spam listings, and soft delete with cascade — when an integration was unpublished, any active workflows referencing it needed a warning banner injected. Beyond the basic data layer, the system needed ChromaDB semantic search so listings could be discovered with natural language queries rather than just keyword filtering, and LLM-powered automatic categorization so new listings were tagged without requiring manual category selection.
The frontend scope matched the backend: a grid page with category filtering, sort controls, and a search bar that hit the ChromaDB endpoint; a detail page with documentation, screenshots, and a configuration guide; a publish modal with preview that let integration authors see exactly what their listing would look like before making it public; category sidebar navigation; Open Graph image generation so each listing had a distinct social preview with its icon and description; and a full clone/install flow for users to add marketplace integrations to their own accounts.
Dispatch pattern
The orchestrator started with four explorer subagents before any implementation began. One mapped the existing marketplace create flow. One audited the codebase structure — where FastAPI routes lived, how Next.js pages were organized, existing patterns for API calls. One looked at existing community marketplace patterns in the codebase for anything reusable. One documented the integration data model in detail to ensure every subagent used consistent field names.
With that map, implementation ran in three waves. Eight backend subagents built in parallel, each with a scoped task and clear ownership: CRUD operations, clone/fork logic, ChromaDB indexing, LLM categorization, publish validation, version management, rate limiting, and soft delete handling. Eight frontend subagents handled their parallel slice: grid page, detail page, publish modal, search UI, category navigation, OG route, card component, install flow. Six subagents then handled testing and verification: API tests, component tests, end-to-end flows, visual verification of the grid layout, search relevance testing with example queries, and a security audit of the publish endpoint specifically.
The orchestrator resolved three file conflicts during the implementation wave — places where the backend CRUD subagent and the clone/fork subagent had both modified the same integration service file. In each case it identified the conflict, merged the changes manually, and updated both subagents’ context before their downstream tests ran. The final feature — a full community marketplace spanning FastAPI, Next.js, ChromaDB, LLM inference, and dynamic image generation — shipped from a single conversation in four hours.