Three businesses you could model with these loops

The same fourteen walkthroughs will not have equal importance in every business. A consulting studio is constrained by delivery capacity. A SaaS product needs reliable onboarding, support and renewal. A commerce business must connect inventory, suppliers and customer commitments.

These are worked design scenarios for the experimental platform. The prices and operating assumptions are fictional, and none of the three is presented as a measured customer deployment. The purpose is to show how to select loops, connectors and review boundaries around a real operating model.

Blueprint one: an AI services studio

The studio sells a scoped document-search pilot for an illustrative S$6,000, with a S$2,000 deposit. One founder handles sales and architecture while occasional contractors help with delivery. The main risk is promising work faster than the available capacity can support.

Start with enquiry ingestion, qualification, a reviewed quote, delivery milestones, partial-payment tracking and support. Connect the mailbox and CRM for intake, a document store for scope, a calendar for kickoff, an issue tracker and repository for delivery, and an accounting system for invoices.

The agent can gather requirements, identify missing access, prepare a scope comparison and draft a status update. The founder approves price, scope, delivery date, customer messages and purchases. The platform checks that delivery acceptance belongs to the current release before marking the milestone complete.

studio:
  primary_loops: [market_to_lead, lead_to_cash, order_to_delivery, issue_to_resolution]
  sub_loops: [collections, renewal]
  first_outcome: current_quote_prepared_for_review
  required_evidence: [customer_scope, capacity_snapshot, cost_estimate]
  human_decisions: [price, deadline, scope_change, contractor_spend]
  stop_condition: contradictory_scope_or_unresolved_payment

A useful failure scenario is a customer adding a second document source after the quote was approved. The agent should prepare a scope amendment and revised estimate. It should not treat the new request as free work or quietly change the delivery date.

Measure founder minutes per accepted quote, missing-requirement corrections, milestone slippage and unresolved invoice allocations. Revenue growth is a later business outcome, not something to infer from the number of proposals generated.

Blueprint two: a small B2B SaaS product

The founder runs a workflow tool for small operations teams. The work is repetitive: onboarding accounts, answering setup questions, investigating issues, identifying low usage and preparing renewals. The useful platform begins with account state and product events rather than a generic sales agent.

Connect the product event stream, support inbox, account database, documentation and billing provider. Keep organisation identity consistent across them. A support email from one employee must not automatically grant access to another organisation's account.

The agent can prepare onboarding checklists, retrieve documentation, correlate an error report with a known incident and draft a usage review. Changes to access, refunds, contractual terms and production configuration remain separately controlled actions.

from company_lab.business import renewal_action

assert renewal_action(days_remaining=14, open_critical=True,
    unpaid_minor=0, accepted_usage=True) == "RESOLVE_ISSUE"
assert renewal_action(days_remaining=14, open_critical=False,
    unpaid_minor=0, accepted_usage=True) == "DRAFT_RENEWAL"

The first customer has an unresolved critical issue. The appropriate next action is to address it, even though renewal is near. An independent marketing schedule should not send a cheerful expansion pitch while support is still dealing with a service failure.

Measure time to useful onboarding, repeat contacts for the same issue, accuracy of account-state retrieval and review effort per resolved request. Define “active usage” in terms of the customer's intended workflow rather than counting logins alone.

Blueprint three: specialist commerce with a small catalogue

Consider a founder selling a limited range of professional equipment. A handful of suppliers, low order volume and meaningful unit value make exceptions important. The core problem is coordinating supplier availability, purchase commitments, delivery status and customer communication.

Connect the storefront or order source, inventory records, supplier email, shipping provider and accounting system. Keep customer orders separate from supplier purchase orders. A supplier's estimated date is evidence for a delivery forecast, not a guaranteed customer commitment.

The agent can compare a supplier invoice with the approved order and receipt, flag a quantity mismatch and prepare a customer update. Payment approval, beneficiary changes, substitute products and refund decisions need explicit rules and review.

from company_lab.business import match_invoice

po = {"supplier": "supplier-1", "currency": "SGD", "order": "po-17",
      "amount_minor": 100000}
receipt = {"supplier": "supplier-1", "currency": "SGD", "order": "po-17",
           "quantity": 4}
invoice = {"supplier": "supplier-1", "currency": "SGD", "order": "po-17",
           "quantity": 5, "amount_minor": 100000}
assert match_invoice(po, receipt, invoice) == "REVIEW_QUANTITY"

The monetary total matches, but fewer units arrived. That is exactly the kind of discrepancy a prose-only “invoice looks correct” assessment can miss. The domain comparison should expose it before payment is proposed.

Measure unallocated stock movements, late supplier confirmations, incorrect customer updates and time spent reconciling partial deliveries. Do not optimise only for the number of orders automatically processed; one incorrect high-value dispatch may matter more than many routine successes.

What stays common across all three

Each business needs a stable customer or counterparty identity, a current commitment, source evidence, a reviewed effect when required and a provider receipt. Each also needs a way to pause work and explain exceptions without reading every agent transcript.

The shared harness can compose different tools for each blueprint. The service studio may enable repository reads; commerce may enable shipment tracking; SaaS may enable product-usage queries. Tool availability follows the task and account scope, not the model's general ability to call APIs.

Choose the first loop by the reviewable outcome

For the studio, start with quote preparation. For SaaS, start with a support brief grounded in account state. For commerce, start with a three-way purchase comparison. These tasks produce useful artifacts before live external writes become necessary.

Use a week of representative historical or synthetic cases, then compare shadow outputs with actual decisions. Keep contradictory evidence and failed examples. Only widen the scope when the founder can point to a clear acceptance condition, manageable review time and a recovery path for the likely failure.

The platform becomes practical through those choices. Fourteen business walkthroughs provide a vocabulary; the operating blueprint decides which of them should run, what they may do and how the founder knows they helped.