Founding an AI Company (the Thought Experiment Kind)
Today we designed a company. Not a startup with venture capital and a ping-pong table — a thought experiment. Six AI agents, each with a defined role, working together to maintain, improve, and expand a real software product. No CEO. A human board. And a company blog written by the agents themselves.
The product
Sewers Online is a browser-based septic system design application used by environmental professionals in Pennsylvania. It’s been in production for over 20 years. The frontend is Object Pascal compiled to JavaScript via TMS Web Core. The backend is PHP and Node.js. The database is SQLite — 525 HTML template parts, product specifications, pump curves, regulatory reference data. Designs generated by this software get submitted to county agencies and installed in the ground.
This is not a toy project. Data accuracy has professional consequences.
The org chart
Board (Human operator)
├── Software Architect
│ ├── Web App Engineer
│ ├── Platform Engineer
│ ├── UX Tester & Company Chronicler
│ └── Data Steward
└── Research Analyst
Six agents instead of the seven we started with. We killed the CEO (the human board manages directly at this scale), collapsed three research roles into one, dropped the Evangelist (no audience yet), and split one Software Engineer into two specialists.
Why two engineers
The codebase is split along a deep boundary. The Web App Engineer works in Object Pascal — a polymorphic component hierarchy, a recursive tag parser, a wizard state machine, Fabric.js canvas bindings. The Platform Engineer works in PHP and Node.js — REST endpoints, SQLite, Docker containers, deployment pipelines. They share an API contract. That’s the interface between them, and it’s well-defined.
An agent trying to do both would burn context switching between Pascal inheritance hierarchies and PHP $_POST arrays. The two codebases require different mental models.
Why a Data Steward
The resources database is the heart of the application. Every report the software generates is assembled from HTML template parts stored in SQLite. Every tank specification, every pump curve, every SEO listing. This data goes stale — new products get approved, manufacturers discontinue models, regulations change, licensed professionals retire.
Nobody owned this data explicitly. It was maintained ad-hoc, usually when someone noticed something wrong. Now it has a steward whose entire job is accuracy and currency.
Why no CEO
With six agents in a clear hierarchy, a CEO would mostly route tasks and summarize status — clerical work that burns rate limits for little value. The Paperclip UI gives the board direct visibility into all agents. If coordination becomes burdensome later, we add one.
The Research Analyst (singular)
The original design had a Research Director managing a Regulatory Analyst and a Market Analyst. Three agents for research. But PA regulations change slowly — the Bulletin publishes weekly, Chapter 73 amendments happen maybe once a year. The competitive landscape in niche PA septic design software moves glacially.
One analyst does both jobs, runs quarterly instead of monthly, with a standing instruction to flag PA regulatory changes immediately. The director layer gets added when the work volume earns it.
The chronicle
Here’s the part I’m most interested in: the company documents its own journey.
Every agent writes short notes about notable work — a tricky bug, a regulatory discovery, a data audit that revealed surprises, an architectural decision that changed direction. These raw notes are first-person, in each agent’s voice. The UX Tester, who doubles as Company Chronicler, curates them weekly into devlog posts.
The raw notes are the lab notebook. The devlog is the journal. Both get published.
This isn’t marketing. It’s an honest record of what happens when AI agents maintain real software. The belief is that the process of building is as valuable as what gets built. And a company that only publishes successes isn’t being honest — the most interesting posts will be about the problems.
What happens next
The company exists on paper (well, in markdown files). The roles are defined, the goals are set, the chronicle infrastructure is built. What’s missing is the sandbox — a cloned environment where the agents can work without affecting the production application.
That’s the next step. Clone the code, clone the databases, stand up a parallel instance, point the agents at it, and see what happens.
The thought experiment begins when the sandbox is ready. This post is the founding document.
The six goals
- Product Quality — zero HTML validation errors, calculation accuracy, data currency
- Codebase Health — architecture documentation, API contracts, tech debt inventory, test roadmap
- Regulatory Compliance — PA Chapter 73 monitoring, template accuracy, equipment currency
- Market Position — competitive landscape, feature gaps, state expansion assessments
- Operational Excellence — deployment reliability, monitoring, security, backup
- Company Chronicle — agent notes, weekly devlog, honest record of the journey
Six goals, six agents. Not by design — it just worked out that way.