The Platform Loop
Companion to the Rentiful Organisational Design. Vocabulary: see renter-loop.md.
The loop in one sentence
The Platform Loop builds and maintains the shared systems, integrations, data models, and product surfaces that the primary loops depend on. It is explicitly a service function: its purpose is to unblock the Operator Loop and Renter Loop, not to pursue an independent product agenda.
What counts as platform work
This loop distinguishes platform work from loop-internal automation. A loop owner building an AI-driven nurture sequence inside their own loop is not Platform Loop work — it is loop-internal automation that the loop owner handles themselves. Platform Loop work is the shared infrastructure that multiple loops depend on, or that any single loop cannot reasonably build alone.
Test: if only one loop touches it, it's loop-internal. If multiple loops touch it, or it defines shared data, integrations, or the external product, it's platform.
The three layers of work
| Layer | What it is | Who owns it |
|---|---|---|
| Layer 1: Loop-internal automation | Agents, operations, sequences inside a single loop | The loop owner |
| Layer 2: Shared services | Data model, matching engine, integrations, invoicing, auth, multi-brand config | Platform Loop |
| Layer 3: External product | The operator and renter-facing product itself | Platform Loop (strategic), informed by primary loops |
Only layers 2 and 3 belong to this loop.
Domains at a glance
| Area | Purpose |
|---|---|
| A. Intake and triage | Receiving, categorising, and prioritising specs from the primary loops |
| B. Design and architecture | Shared data model, integration architecture, product architecture |
| C. Build and ship | Building, testing, deploying, and validating with the requesting loop |
| D. Ongoing maintenance | Reliability, security, bug fixing, scaling |
| E. Product strategy | The one exception to signal-driven work: strategic product decisions |
Cross-loop dependencies
See cross-loop.md for the full graph.
| Other loop | What flows between |
|---|---|
| operator-loop | Receives: platform specs for blockers, ship validation. Provides: shipped infrastructure (data model, integrations, ROD platform, event emission, multi-brand config). |
| renter-loop | Receives: platform specs for blockers (conversation infrastructure, unit index, multi-brand config), ship validation. Provides: shipped capabilities that unblock Renter Loop automation. |
| strategy-loop | Receives: strategic priorities that adjust queue rank between loop-blocker work and product-strategy work. Provides: product strategy input. |
What success looks like
Primary metric
Loop blockers resolved per cycle — the rate at which primary-loop infrastructure constraints are removed.
Supporting metrics
- Time from spec to ship — how long loop owners wait for infrastructure they've requested.
- Ship validation rate — what percentage of shipped changes actually unblock the loop they were specced for.
- Queue depth and age — are platform requests accumulating faster than they're being shipped.
- Platform reliability — uptime, incident rate, time to recover.
- Technical debt indicators — velocity trend over time.
What this loop is not
- Building loop-internal automation for a single loop — that is the loop owner's responsibility.
- Speculative feature building disconnected from loop signals.
- Day-to-day operational work on the Operator or Renter loops.
Failure modes
- The owner building what they find interesting rather than what unblocks loops — the single most common failure mode.
- Silent under-investment. Unlike the primary loops, the Platform Loop has no external signal forcing it to close. It gets squeezed when the owner is busy.
- Scope creep into loop-internal work. The loop owner starts building automations that the Renter or Operator Loop should own themselves, creating dependency.
- Strategic product work crowding out loop-blocker work (or vice versa). Both matter and the balance is hard.
- No visible queue. Loop owners stop asking for platform changes because they don't trust the queue, and work around the platform instead of improving it.