Phase 8: Multi-Agent Systems & Platform Architecture · 50 min · Claude Code · MCP · Python
Scaling Your Product to a Platform
Six layers, one document: what's shared, what's product-specific, and why — written down before Orbit 3 has to build on top of the answer.
Hiring signal: A real platform architecture document — not just a working product — is the artifact that lets you talk about scaling a system to support multiple products in an interview, not just describe the one you built.
What you will learn
- Decide which of your product's capabilities belong in shared platform layers versus staying product-specific
- Document multi-agent orchestration, memory architecture, and long-running task support as explicit platform decisions
- Apply the same specificity bar from earlier specs and harness documents to a platform architecture document
- Produce a platform architecture document that becomes the foundation for your Orbit 3 project
Introduction
Scaling Your Product to a Platform
Marcus is building the social-clip generator alongside his podcast show-notes tool, and this time he starts by writing down the platform architecture, not by building the second product's infrastructure from scratch. Interaction layer: each product gets its own — a chat interface for show-notes, a simpler batch API for clips. Everything else is shared: context assembly (the same rules and skills apply to both, since both process the same transcripts), model behavior (the same model-task router serves both), tool/agent execution (the same dependency-aware scheduler from this phase's second lesson runs both products' multi-step pipelines), observability (one tracer, one drift detector, watching both products), and governance (one approval-gate system, one quality gate, protecting both). Writing this down before building the second product is what turns "we happen to have two products" into "we have a platform," in exactly the sense this phase's first lesson defined it.
What belongs in the platform document
A platform architecture document names, for each of the six layers, what's shared infrastructure and what's product-specific, using this phase's actual decisions rather than generic statements. For the tool/agent-execution layer, that means naming which of your product's tasks use the dependency-aware scheduler from c12-08-2, and whether any use single-agent architecture instead (per c12-05-3's "when one agent is enough" reasoning). For memory, it means specifying which tier (short-term, working, long-term) holds which categories of information, and which long-term entries are meant to be shared across every product on the platform versus scoped to one. For long-running task support, it means stating explicitly which tasks can idle for extended periods, what state needs to survive that idle time, and what the loud/attributable/boring failure design looks like for this specific product's idle-time failure modes.
The same specificity bar as every other document in this course
"We use multi-agent orchestration where appropriate" says nothing checkable, the same way "the agent uses appropriate tools" said nothing in c12-04-2's harness spec. "Batch document processing across the clip-generation queue uses the dependency-aware scheduler from c12-08-2, with each document as an independent parallel unit; single-episode chapter detection uses a single agent, since no specialist role has a demonstrated benefit for that task" is specific enough that a reader could verify it against the actual system.
A learner's platform architecture document states, for the tool/agent-execution layer: 'we use agents as needed for various tasks across the platform.' Does this satisfy the documentation standard this course has applied consistently since the harness spec lesson?
This sentence could describe literally any platform with any architecture — it names no specific task, no specific scheduling pattern, and nothing a reader could check against the real system. This is the identical failure mode c12-04-2 named for harness specs, applied here: specificity, not just word count, is what makes a platform document a real artifact instead of a placeholder.
Unlock the full lesson
You've read the first 2 sections. The rest of this lesson covers Deciding what's shared versus product-specific, Why this document, specifically, feeds Orbit 3, Writing it before the second product, not after, Build It — plus a hands-on lab, quiz, and project artifact.
Create a free account to unlock Phase 0 and Phase 1 of every course — no credit card.
Browse all courses · View pricing · DeVenture Academy