A solo company is a set of promises that must be kept

A customer emails asking for a quote. I answer, agree a scope, schedule the work, deliver it, send an invoice and follow up on payment. Later, the same customer reports a problem. Running the company means keeping all of those promises connected. A very good answer in a chat window completes only a small part of that work.

This is the question behind an internal R&D project I commissioned for myself at Kuzushi Labs: how much of that coordination can a solo founder delegate to AI agents while retaining a clear view of commitments, money and exceptions? I am building an experimental operating platform around that question. It is work in progress; there is no claim here that a business is already running unattended.

Start with the work, before choosing an agent framework

Imagine a small software studio offering a fixed-scope document-search pilot. I use this fictional studio throughout the series. A customer asks whether it can search a collection of manuals. That enquiry should become a lead, then an opportunity, then an agreed deliverable. The delivery record should explain when billing is justified. A payment must be supported by a receipt from the payment system. A support complaint should retain the link to the original promise.

The founder's repetitive work is moving information between these steps: copying context, checking prerequisites, requesting a decision and remembering what is still open. The proposed platform takes on that work. The founder still chooses what to sell, negotiates unusual commitments, reviews consequential actions and handles relationships.

A loop has five ingredients: a trigger, current facts, a permitted action, evidence of its outcome, and feedback that changes the next attempt. An agent that drafts a quote but never discovers whether it was accepted has not closed the sales loop.

The 14 walkthroughs, and what the code actually groups together

The current contract defines 11 top-level loop modules. For this series I separate campaign operations, cash collection and renewals into three additional walkthroughs, because a solo founder operates them as distinct jobs. They remain sub-loops of their owning modules; they are not three extra implemented services.

A small executable core, rather than 14 separate assistants

The prototype uses Python, Pydantic and a shared object runtime. Loop definitions describe business objects, states, actions, events and agent roles. The same dispatcher checks proposed changes. SQLite and in-memory stores support local experimentation; the application also contains a model gateway, evaluation components and a cost/value ledger.

The essential unit is a business operation, not an LLM call:

{
  "operation_id": "quote-pilot-017-v2",
  "tenant_id": "studio-demo",
  "subject": "opportunity-017",
  "requested_action": "prepare_quote",
  "evidence": ["enquiry-017", "scope-017-v2"],
  "expected_result": "quote awaiting founder review",
  "external_effect": false
}

This is the sort of record I want to follow through the system. Producing it twice must not send two quotes. Updating the scope should invalidate an approval for the previous version. An accepted quote should retain the evidence needed by delivery, even if the conversation that produced it was long.

How to read the implementation status

I use three distinctions. Prototype means a local implementation or deterministic workflow exists. Simulated connector means an external service is represented by an in-memory adapter. Next implementation means the design is specific, but the capability is still to be built or hardened.

The current lead pipeline, for example, can ingest an email-shaped payload, resolve identity, qualify the lead and create an opportunity. That is different from maintaining a live Gmail OAuth connection. Likewise, moving a payment record to Paid in a fixture does not transfer funds.

Most loop agents are deterministic adapters today. There is a Pydantic AI adapter demonstrating a governed lead-creation tool; it is not a general autonomous operator across every module. Keeping the shared interface small lets me improve the reasoning later without letting a new model bypass the business rules.

What would make this useful to one founder?

My first useful milestone is modest: one real enquiry can reach a reviewed quote without duplicate records or hidden changes, and I can see the outstanding decision in one inbox. The next milestone connects delivery evidence and payment reconciliation. Only then does it make sense to widen the number of loops.

The measure is the time required to complete and supervise a business task. I will also track missed commitments, incorrect actions, recovery work and unresolved exceptions. More agent runs are not inherently progress. A day with fewer runs and every customer promise accounted for can be the better day.

The next four articles explain the shared records, action controls, agent harness and connectors. After that we can walk through the actual business loops without repeatedly rebuilding their foundations.

Make the first business promise executable

Let us put a harder edge on the studio example. The customer wants a search pilot for 5,000 maintenance manuals, two named reviewers and a handover in three weeks. The accepted scope excludes a production support rota. The founder needs a S$2,000 deposit against a S$6,000 fixed fee before reserving delivery capacity. These are scenario assumptions, not historical client results.

I would create a commitment record before asking an agent to plan work. It carries the document limit, acceptance method, commercial terms and the evidence that the customer accepted them. The agent's plan points to that record. If it invents a weekend support obligation, there is a concrete source against which to reject the addition.

from company_lab.store import Store

store = Store()
store.create("studio", "commitment-017", "commitment", {
    "scope_version": 3,
    "document_limit": 5000,
    "reviewers_required": 2,
    "fee_minor": 600000,
    "deposit_minor": 200000,
    "currency": "SGD",
    "state": "AWAITING_DEPOSIT",
    "acceptance_ref": "customer-email-017",
})
record = store.get("studio", "commitment-017")
assert record["version"] == 1
assert record["body"]["state"] == "AWAITING_DEPOSIT"

This runs from the downloadable kit's examples directory. It is the new public reference implementation, with its own SQLite store. The internal platform has a richer typed ontology; the small lab exposes the coordination contract without requiring that monorepo.

The next event is not automatically “start delivery.” It may be “deposit evidence received,” “access missing” or “scope changed.” Each produces a different next task. That is where the practical value of the loop model appears: one customer can have sales complete, finance pending and delivery blocked at the same time.

Decide who owns each change

The shared store does not imply shared permission to edit everything. A delivery agent may discover a scope mismatch, but the mismatch should open a commercial review. It should not rewrite the agreement until the task appears complete. Similarly, a finance agent can prepare a reminder, but it must see the current dispute state before sending it.

A first acceptance exercise

Start with five copies of the same enquiry: the original, a provider retry, a customer follow-up, a changed requirement and an unrelated person with the same name. The expected outcomes are one buying process, two genuinely new interactions, one scope review and no identity merge based on the name alone. Record what the system creates, not just its reply.

Then follow the original opportunity through a missed deposit. The founder should see “capacity not reserved; deposit unconfirmed,” with a link to the agreement and latest receipt search. The system should not claim delivery has started because an agent generated a plan. This is a useful first test even before an LLM is involved.

Relate the experiment to real products

Polsia's public product description covers planning, coding, advertising, customer replies and sales. That makes it a relevant comparison for the ambition here. Its public description does not establish how it implements state transitions or recovery, so I use it as a product reference, not as evidence that this platform has equivalent capabilities. Polsia.

For this project, the first meaningful demonstration is narrower: an accepted commitment remains consistent across the loops, including when a connector fails. Once that works, increasing the number of decisions the agents can handle becomes an engineering experiment with observable outcomes.