Build one complete operating loop, then widen it

The platform has enough structure to explore a solo company's work in detail. The next challenge is to turn that breadth into a small dependable operating slice. I would not begin by enabling every loop and connecting every account. I would begin with one business promise whose inputs, decisions and completion evidence are clear.

This article is the current R&D roadmap. It separates the local prototype from the next experiments and explains how to use the reading kit without assuming the full internal monorepo is a public product.

Start with an enquiry-to-reviewed-quote slice

Choose one inbound channel and one offering. Capture the source interaction, prepare the lead brief, collect missing scope and draft a quote for the founder. Keep external sends manual initially. The completion condition is a reviewable quote with linked evidence and an unambiguous version.

A useful first experiment has a fixed set of historical or synthetic enquiries. Include duplicates, ambiguous identities, unsupported requests and an explicit opt-out. The platform should make the right records, expose missing information and avoid producing commercial commitments on its own.

The stages of the next implementation

There is deliberately no blanket deadline attached to this table. Progress depends on the chosen connector, the quality of input records and the failures found during review. Each stage has an inspectable exit condition.

Consolidate the two execution surfaces

The current code contains both a gateway-oriented action harness and the ontology-oriented dispatcher used by the business loops. I want one operational lifecycle with consistent action identifiers, approval binding, idempotency, cost attribution and audit events.

The AgentRuntime port provides a place to plug in a custom reasoning harness. Context assembly, per-run tool selection, bounded iteration and recovery can grow behind that interface. Business effects should continue through the governed dispatcher rather than a parallel raw-tool path.

This is an architectural consolidation task, not a reason to replace every working loop. Keep the deterministic adapters as regression references while adding the new runtime.

The connector sequence

For the studio example, I would connect an inbox and document store first, then an internal task system. These provide useful context and a low-impact write surface. Calendar and customer messaging can follow once identities and approval receipts are stable. Accounting and payment integrations require their own reconciliation and recovery work.

CRM coexistence needs an explicit field-ownership policy. The platform can project records to an incumbent system while operating in shadow mode; it should not silently become authoritative simply because it has a new user interface.

Each connector gets a replay fixture, external-ID strategy, credential scope, rate-limit handling and a known-outcome reconciliation path. Those are part of the integration, not optional work after the demo.

Use the public reading kit

The downloadable kit contains these articles, the diagrams and a small standard-library Python lab. It uses fictional records and simulated effects. It needs no model key and sends no messages or payments.

python3 examples/operating_lab.py

The lab checks idempotent replay, conflicting operation reuse, stale approval versions, approval actor separation, tenant boundaries, partial settlement and a simple cost calculation. It is a teaching reference for the contracts discussed here, not a distribution of the full platform or a ready-made autonomous company.

The article snippets that import platform packages describe existing internal interfaces. The standalone lab is the directly runnable public artifact. This keeps the walkthrough useful without pretending every internal dependency is included in a zip file.

Keep a failure notebook

For each trial, record the input, relevant record versions, selected actions, expected outcome, observed result, review time and recovery work. When a fix is proposed, add the failing case to the replay set before changing the implementation.

The project overview and implementation-status matrix will evolve with those results. The current local suite passed 303 tests, with two skipped, during this review. The next evidence I want is a restricted real workflow completed repeatedly with correct effects and an acceptable supervision burden.

What “solo” means in this project

Solo means the founder can coordinate more of the company's work without becoming the integration layer between every tool. It does not mean the founder disappears, that specialist judgement is unnecessary, or that every decision becomes an agent vote.

The useful end state is concrete: the platform knows what the company promised, gathers the evidence required for the next step, handles permitted routine actions and brings the unresolved decisions back with enough context to act. That is the experiment I am building, one complete loop at a time.

A first complete slice: enquiry to a reviewed quote

Start with a small service business selling a scoped document-search pilot. An enquiry enters through a form. The platform creates a customer record, checks whether the enquiry is in scope, prepares a brief and drafts a quote. The founder reviews the price and delivery assumptions before any message leaves the system.

This slice exercises memory, evidence, agent composition, approval and a connector without requiring every business loop to be autonomous. A successful local demonstration ends with a confirmed provider receipt and a traceable customer record. It does not end when a model prints a persuasive proposal.

Incoming enquiry
  → identity resolution and source receipt
  → qualification evidence
  → bounded read-only agent episode
  → proposed quote at a specific revision
  → founder decision
  → outbox and connector receipt

The next slice adds accepted scope, a work order, an invoice and a partial payment. Add one failure at a time: duplicate event, stale review, provider timeout, process restart and late payment allocation. You can then explain exactly which contract each new component protects.

Run the public implementation without credentials

The expanded reading kit includes a separate Python package with a SQLite store, connector simulator, bounded harness, evidence selector and business-rule functions. It is small enough to inspect before running it.

cd examples
python3 -m company_lab.demo
python3 -m unittest discover -s tests -v
python3 operating_lab.py

The demo creates a lead, pauses a write proposal for approval, simulates a provider accepting a message but losing its acknowledgement, reopens the local database and reconciles the receipt. It also applies a duplicated deposit event only once. There are no network calls or API keys.

The newer package has 62 tests; the original single-file lab retains its 18 checks. These are public reference implementations of the contracts discussed in the series. The internal platform has a broader set of domain objects and workflows; installing this reading kit does not install that application.

Use the remaining chapters as an implementation sequence

Parts 25–30 address the plumbing that makes a loop useful outside a demo: durable work, evidence retrieval, mailbox and CRM integration, documents and calendars, payment events and capability discovery. Parts 31–35 deal with concurrent execution, hostile inputs, operations, deployment and repeatable evaluation.

Parts 36–37 compare this design with products and research. Parts 38–40 turn the components into three business blueprints, a complete local walkthrough and a staged adoption plan. You do not need to finish all forty chapters before trying the first slice; the later chapters answer questions that appear when a prototype starts touching real work.

Keep an implementation ledger

For each proposed capability, record its current state: implemented locally, simulated, documented design, or validated with a live provider. Link the relevant test or run artifact. This prevents a connector interface from being mistaken for a working integration and a local benchmark from being mistaken for a customer result.

A useful first-week ledger might contain working version checks, simulated email receipts, a proposed Gmail OAuth adapter and a manually reviewed quote workflow. That is a coherent experiment. Marking every box “AI powered” would provide less information.

The founder owns the rollout decision. The platform's job is to make that decision easier by presenting evidence of what works, where it fails and how much supervision it consumes. The target is a business that can reliably keep more promises with the same small team.