← Writing

Kuzushi Labs · Applied research and engineering

Building a solo company with AI agents

Experimental · Work in progress · Internal R&D

An experimental operating platform for one founder: coordinate enquiries, sales, delivery, support and finance through shared records, controlled actions and an approval inbox.

Arunank Sharan · September 2026 · 40 articles · 47,386 words

Original internal R&D at Kuzushi Labs, commissioned for my own work. The series walks through 11 core loops and three sub-loops, with concrete state transitions, connector contracts and the custom harness being developed above them. Local implementations, simulated integrations and the next engineering steps are identified throughout.

Start with the architecture, follow the 14 business workflows, then build the execution layer: durable workers, real connector contracts, security, cloud deployment and evaluation. The final chapters compare Polsia and related research, map three business blueprints and walk through the runnable company lab. The reading kit includes 47 diagrams, 62 reference tests and the original 18-check lab.

Parts 1–5

Foundations

The shared records, action boundary and harness that hold the company together.

  1. PART 01 · 8 min read

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

    Why a solo founder needs connected commitments, records and decisions; a map of 11 core modules and 14 business walkthroughs.

  2. PART 02 · 8 min read

    The company needs a memory that can answer “what changed?”

    Typed business objects, state transitions, provenance and historical versions: the memory that holds the company together.

  3. PART 03 · 7 min read

    An agent may propose a decision; an action decides whether it can happen

    How a proposed action moves through validation, policy and approval, with stale-version checks and replay-safe effects.

  4. PART 04 · 8 min read

    The harness coordinates the work; it does not become the company

    A custom harness for bounded episodes, scoped tools, context assembly and cross-loop handoffs, built above the existing runtime interface.

  5. PART 05 · 10 min read

    Connectors translate the outside world into facts and receipts

    Email, forms, CRM, advertising and outbound messaging: existing simulations, live adapter contracts, receipts and reconciliation.

Parts 6–10

Demand and revenue

Find customers, prepare commitments, collect payments and retain the relationship.

  1. PART 06 · 7 min read

    Market to lead: turn an enquiry into a decision worth making

    Capture an enquiry, resolve identity, qualify fit and route an opportunity using the prototype’s concrete thresholds and handoffs.

  2. PART 07 · 7 min read

    Campaigns and outbound: keep the send button separate from the draft

    Prepare outreach, check permission and sender readiness, retain approval and measure useful demand without hiding the send decision.

  3. PART 08 · 7 min read

    Lead to cash: make the commercial commitment explicit

    Turn a qualified lead into explicit scope, a reviewed quote and an accepted commitment that delivery can act on.

  4. PART 09 · 7 min read

    Invoice to cash: a payment is a fact, not a reassuring message

    Move from a commercial commitment to invoicing, partial payment, duplicate receipt handling and an explainable outstanding balance.

  5. PART 10 · 7 min read

    Retention and renewal: connect the support history to the next promise

    Connect support, delivery and payment history to a renewal decision without inventing customer health from sentiment alone.

Parts 11–19

Delivery and management

Keep the promise, acquire capacity, understand the business and improve the system.

  1. PART 11 · 7 min read

    Order to delivery: complete the promise, not just the task list

    Coordinate work orders, jobs, deadlines and proof of delivery so completion means the customer’s promise was fulfilled.

  2. PART 12 · 7 min read

    Issue to resolution: make “resolved” mean the customer can move on

    Triage a complaint, gather evidence, resolve or escalate it, and control goodwill decisions with an explicit limit.

  3. PART 13 · 7 min read

    Procure to pay: an approved need is not an approved payment

    Separate an approved need, purchase order, receipt, invoice match and payment instruction; walk through the local purchasing workflow.

  4. PART 14 · 7 min read

    Hire to productivity: treat capacity as more than a headcount

    Turn a capacity gap into a hiring decision, structured assessment and onboarding readiness while retaining human judgement.

  5. PART 15 · 7 min read

    Record to report: make the operating picture explainable

    Connect operational events to balanced postings and period review, with explicit reversal and duplicate-obligation handling.

  6. PART 16 · 7 min read

    Risk to control: the same rule must apply in every loop

    Apply shared controls across loops, separate requesting and approving actors, and test the limits of the current policy boundary.

  7. PART 17 · 7 min read

    Concept to launch: help the founder decide what deserves building

    Turn an idea into a testable hypothesis, a build decision and a launch record without mistaking generated documents for demand.

  8. PART 18 · 7 min read

    Plan to performance: a dashboard should lead to a recorded decision

    Connect goals, forecasts, variances and reforecasting so the plan changes through a recorded decision.

  9. PART 19 · 7 min read

    Operate to improve: an agent should not grant itself more authority

    Evaluate an agent change, separate its proposer from its approver, and distinguish release-state simulation from real canary traffic.

Parts 20–24

Operate the first loop

Connect the handoffs, measure complete task cost and put decisions in the founder’s hands.

  1. PART 20 · 8 min read

    One customer journey across the loops

    Trace an enquiry through scope, delivery, billing and support with durable event identities, an outbox and explicit recovery.

  2. PART 21 · 7 min read

    What does it cost to delegate a business task?

    Measure cost per accepted task, include supervision and recovery time, and calculate acquisition payback without counting margin twice.

  3. PART 22 · 7 min read

    Evaluate the business state, not just the answer

    Test business states and irreversible effects as well as model answers; build replay scenarios for approval, isolation and recovery.

  4. PART 23 · 7 min read

    The founder’s cockpit and the deployment behind it

    Design the founder’s approval inbox and a compact deployment with authenticated access, durable records and operating limits.

  5. PART 24 · 8 min read

    Build one complete operating loop, then widen it

    A staged implementation roadmap, connector sequence and an offline Python lab for approvals, replay and partial settlement.

Parts 25–30

Durability and integrations

Workers, evidence, mailbox and CRM, documents, calendars, code, payments and MCP.

  1. PART 25 · 5 min read

    Durable workers: the company must survive a process restart

    Leases, fencing tokens, outboxes, delayed work and recovery when the worker disappears halfway through a business action.

  2. PART 26 · 5 min read

    Memory that supports a decision without rewriting the company

    Versioned facts, evidence selection, retrieval boundaries and compact context for business agents.

  3. PART 27 · 5 min read

    Connect the mailbox and CRM without losing ownership of the facts

    Incremental mailbox ingestion, contact identity, field ownership, draft review and uncertain sends.

  4. PART 28 · 5 min read

    Documents, calendars and code: connectors for delivering the promise

    Versioned deliverables, scheduling intent, issue trackers and release evidence across an operating workflow.

  5. PART 29 · 5 min read

    Payment events, accounting entries and the meaning of “paid”

    Provider signatures, business deduplication, partial settlement, ledger posting and reconciliation.

  6. PART 30 · 5 min read

    A capability registry for tools the agent may actually use

    MCP discovery, typed contracts, role intersection, connection aliases and controlled composition.

Parts 31–35

Concurrency and reliability

Shared budgets, hostile inputs, incident recovery, AWS/GCP deployment and business benchmarks.

  1. PART 31 · 5 min read

    Parallel agents without conflicting commitments

    Structured concurrency, shared budgets, queue fairness and one owner for each business write.

  2. PART 32 · 5 min read

    When the customer document tries to become the system prompt

    Prompt injection, tool authority, sandbox boundaries and adversarial tests for a business harness.

  3. PART 33 · 5 min read

    Trace the business task, then debug the agent

    Correlated runs, redacted evidence, useful service objectives and an incident walkthrough for uncertain external effects.

  4. PART 34 · 5 min read

    A small deployment that can grow into a dependable platform

    A proposed AWS and GCP architecture with durable storage, scoped identities, background work and recovery drills.

  5. PART 35 · 5 min read

    Build a benchmark around the company’s promises

    Scenario manifests, reproducible fixtures, repeated reliability, failure severity and release gates.

Parts 36–40

Comparison and adoption

Polsia, research papers, three business blueprints, the local lab and a supervised pilot.

  1. PART 36 · 5 min read

    Polsia and the systems around the autonomous-company idea

    What comparable products and frameworks contribute, and how I would evaluate them for a solo operating platform.

  2. PART 37 · 5 min read

    What agent research changes in this business platform

    From ReAct and Reflexion to TheAgentCompany, τ-bench, Vending-Bench and adversarial tool use: concrete design consequences.

  3. PART 38 · 5 min read

    Three businesses you could model with these loops

    Concrete operating blueprints for an AI services studio, a small B2B SaaS product and a specialist commerce business.

  4. PART 39 · 5 min read

    Run the company lab: a quote, a lost receipt and a partial payment

    A complete local walkthrough of the downloadable Python package, its failure cases and its implementation limits.

  5. PART 40 · 5 min read

    From shadow mode to a supervised operating loop

    A staged adoption plan with measurable gates, operator review, stop controls and a current implementation inventory.