Tai Durden // Sprinter

Operating design

Persistent companies.
Elastic execution.

The unit of scale is a well-defined company loop, not another permanent conversation. Every eligible venture keeps a place in the schedule.

Company

One venture identity, customer promise, permission scope, logical team and evidence trail.

Control

Amble at app.sprinter.ai owns venture theses, decisions, work, approvals and learning. Git owns code and releases. SprinterVault is reference-only.

Execution

ChatGPT Pro supplies strategic insights and PRs. Authorized OpenClaw, Hermes and other workers execute through Amble with tenant isolation, cost limits, claims and recovery.

Compounding

The Sprinter Platform extracts tested Amble/Praxium capabilities into reusable modules. Validated lessons transfer through compatible canaries—not untested fleet-wide changes.

Six loops, one evidence standard

Health and obligations are checked every six hours in the proposed policy. Value, product and distribution decisions are daily. Learning and proof preparation are weekly. Customer events interrupt the cadence. Every loop needs a due time, actual receipt and next action; a missing loop must remain visible.

A schedule and a passing policy test do not establish live execution. Runtime adoption and accepted customer outcomes remain separate acceptance gates.

40 → 100 → 1,000 → 10,000

This is the intended scale path. Increase measured worker pools and isolate failure domains while keeping shared components reusable. A synthetic 10,000-entry scheduling test is infrastructure evidence—not 10,000 operating businesses.

Design references: Inngest concurrency and OpenClaw multi-agent isolation. Neither source guarantees business outcomes.

Read the actual field notes →