Story
From coding agents to product organisations
The path starts with a person asking a model for help. It now includes GitHub issues, isolated worktrees, T3 Code, Tailscale and a Gas City Mayor coordinating persistent work.
- AssistantA model helps plan and write code.
- Agent teamIssues, branches and PRs let several agents work safely.
- Software factoryGas City keeps persistent work, formulas and sessions.
- Product organisationAgents test hypotheses before commissioning code.
- Institutional researchOrganisations and governance become research subjects.
The example is a better LinkedIn feed
LinkedIn Slop Filter aims to keep worthwhile posts visible while reducing engagement bait, empty advice and low-value content. The extension classifies posts that LinkedIn already shows. It can hide, label or highlight posts, but it does not discover posts LinkedIn failed to recommend.
That distinction matters. A better classifier may reduce false hides. Better exceptions may help recover useful posts. A different follow list or a positive-selection interface might work better than another classifier change. Those are competing product hypotheses, not just engineering tasks.
- Outcome or approved issue
- Claim with run ID
- Branch and worktree
- Implementation
- Draft PR
- Tests and review
- Merge or stop
- Evidence record
How agents work today
The current engineering workflow uses a shared record. A planning model can define a change, but approved work lives in a GitHub issue. An implementation agent claims the issue with a run ID, branch, worktree path and intended files. It opens a pull request, runs checks and records what remains unverified.
A worktree is a separate working folder for a branch. It lets two agents work from the same repository without switching the same checkout under each other. It does not remove logical conflicts. Agents still need to coordinate when they touch the same behaviour.
What Gas City changes
Gas City adds persistent tasks, formulas and session management. The Mayor can register project rigs, create beads, route work and track dependencies. T3 Code on Android is the reported control surface. Tailscale is the reported private network path to the Mac.
This is evidence of a software factory, not proof of an autonomous organisation. The factory can deliver authorised work. It does not automatically decide whether the work improves the product outcome.
- PR #116Usage counter resetMerged 11 October 2026
- PR #118Mandatory isolated worktreesMerged 11 October 2026
- PR #122Selected correction examplesIncorporated through PR #121
- PR #124Local category rewritesIncorporated through PR #121
- PR #121Feedback personalisation stackMerged 11 October 2026
The recent Slop Filter delivery shows the integration boundary
PR #116 added an explicit usage reset. PR #118 made isolated worktrees mandatory. PR #121 integrated durable keep-visible exceptions, selected correction examples and local Ollama-assisted category wording. PRs #122 and #124 were incorporated through the integrated stack rather than both merging separately.
The automated tests passed for that integrated work. The PR record also says the newer feedback features had not been checked in the installed signed-in Brave extension. This site preserves that boundary instead of turning synthetic success into a live-product claim.
Where the story goes next
The next step is not another scheduler. It is a bounded product experiment. Two teams can propose different ways to reduce useful posts being hidden, while an independent evaluator checks them against a protected baseline. The organisation must be able to decide not to build anything.
Open the roadmap