Cultivate

Local MVP for a software factory

Cultivate, with evidence and limits.

Cultivate explains the move from one coding assistant to a Gas City software factory, then maps the capabilities needed for autonomous product organisations that operate under human authority.

How the workflow has evolved.
  1. AssistantA model helps plan and write code.
  2. Agent teamIssues, branches and PRs let several agents work safely.
  3. Software factoryGas City keeps persistent work, formulas and sessions.
  4. Product organisationAgents test hypotheses before commissioning code.
  5. Institutional researchOrganisations and governance become research subjects.

Three parallel pillars

Engineering

Can agents build and deliver software reliably?

The ability to plan, implement, review and ship software through issues, branches, worktrees, tests and recoverable orchestration.

Product

Can agents discover what is worth building?

The ability to define outcomes, gather evidence, compare hypotheses, run experiments and decide when not to build.

Organisation

Can agents organise themselves to achieve outcomes?

The ability to hold roles, delegated authority, budgets, review duties and governance boundaries across teams and institutions.

Current state

What is working

The engineering workflow has issue claims, isolated worktrees, pull requests, automated checks and a running Mayor in Gas City. Slop Filter is the main verified example.

What is being tested next

The next product milestone is a bounded experiment comparing classification and exception approaches before commissioning more Slop Filter work.

Current frontier

The factory can deliver approved software. It has not yet proved that agents can decide which software is worth building. That is the shift from engineering automation to product organisation.

Next

Browser verification is required before delivery claims

The process distinguishes synthetic checks, temporary Chromium release checks and installed signed-in Brave checks.

See this milestone
Next

Outcome and baseline are written down

The first product experiment needs agreed outcome measures, representative-enough examples and a held-out evaluation set.

See this milestone
Next

Authority boundaries are explicit

Agents can recommend work, but new spending, public deployment, sensitive data collection and external actions require human approval.

See this milestone

Capability epics

E1

Coordinated coding agents

Agents can take approved engineering tasks, work in isolated branches and expose their progress through issues and pull requests.

Open epic

E2

Persistent software factory

A configured Mayor and Gas City runtime can keep work, dependencies and sessions alive across interruptions.

Open epic

E3

Verified continuous delivery

Software changes are not treated as delivered until the right automated and browser checks have run and their limits are stated.

Open epic

E4

Economic and self-improving factory

The factory can reason about cost, capacity, quality and its own improvement opportunities.

Open epic

P1

Outcome measurement and evaluation

The product layer defines useful outcomes and tests changes against evidence that can falsify weak ideas.

Open epic

P2

Competing hypotheses and experiments

Several teams can propose different approaches to the same outcome, and an evaluator can compare them before build work starts.

Open epic