The software factory · the build

Build a software factory you run from your phone

One person, one Telegram thread, a fleet of agents doing the work — open-source, model-agnostic, and cheap to run. Here's the actual architecture, layer by layer, and why each piece is what it is.

Most "software factory" writing stops at the concept. This is the build. The goal is a system you text from your phone — "ship the fix," "start a research project on X," "draft the landing page" — that gets it started without hand-holding, does the first real tranche of work, and comes back to you with output and the decisions only you can make. You are the only human in the loop, and your job is intent and review — never babysitting. Software is just the first and hardest vertical; the same machine builds documents, plans, and research, because the control plane doesn't care what the deliverable is. Click through the stack:

One human, for intent and review — not babysitting

The design goal isn't "no humans," it's "one human, spent well." Everything mechanical — noticing, planning, executing, testing, opening the change — is the machine's. What's left for you is the two things a machine can't own: deciding what to build and why, and deciding whether the result is actually good. That's why the control plane (Hermes) is deliberately task-agnostic: intake, memory, scheduling, escalation, and review flow the same whether the output is a pull request or a research memo. Keep the code-specific parts — the coding agent, the CI guardrail — at the edges, and the same factory bootstraps any kind of project from a single message.

Why open-source and model-agnostic

Two reasons, both practical. Cost: a factory runs a lot of tokens, and the only way that stays affordable is routing — mechanical work to a cheap or local model, frontier models only when a task earns it. That requires a stack that can point at any provider, including your own GPU. Control: the thing merges code and runs unattended on your data; you want it on hardware you own, with no vendor able to change the terms underneath you. Every box in the diagram is self-hostable and swappable — which is also why we're building it two ways (see the bake-off below) instead of betting the whole thing on one tool.

Controlled from your phone

The front door is Telegram, on purpose. Factory work is asynchronous — you fire a task and get pinged when it's done or needs you — and a chat app you already carry is the right shape for that, far better than a dashboard you have to go open. Text or voice note in (Telegram transcribes voice itself); results and escalations push back out. And crucially, the review is mobile too: when a change needs human eyes, the factory sends a twocents link and you pin exactly what's wrong on the rendered result from the same thread. Control plane and quality gate, both on your home screen. One caution that shapes the whole build: a bot that can merge code from a phone is powerful, so it's locked to your Telegram id alone — and that thinner-context approval is exactly why the auto-merge guardrails carry the weight.

What we're building, and how honestly

This page is the architecture; the depth lives in the guides for each layer, published as we actually stand the thing up. We're building it as a bake-off — the same factory on two coding executors (oh-my-pi and OpenCode under Hermes) — and documenting the real findings: cost per task, edit reliability, how much each one fights you. Nothing here gets asserted as fact until it's survived a real setup. Start with the concept if you're new to it, then follow the machine down: