The engine underneath
onMain Agency adds the clients who see the work; it does not change the engine that does it. Your agents plan, decide and build through one MCP, under one written Standard — the same process layer onMain itself is built with. This page is the overview; each part links to onmain.dev, where it is covered in full.
The agency edition is the team edition, plus the people who read it
Everything on this page is the product your developers would run on their own. onMain Agency wraps it in a client layer — a portal scoped to each client, the contracts and invoices their managers hold — but underneath, the engine is the same one, record for record. Nothing here is built twice for agencies.
An MCP built for the agents doing the work
Your coding agents do not drive a dashboard and call an API on the side. In onMain the MCP is the interface — the same set of tools for a person and for an agent. Claiming a card, reading its plan, recording a pull request, drafting the status report a client will read: each is one call, not a screen someone fills in.
A process the agent reads before it builds
How work moves through onMain is written down once, published in versions, and read by the agent before it plans anything — not kept in a wiki nobody opens. A stream is shaped into a brief; a claimed card becomes a plan that has to survive an adversarial pass before anyone builds it; each phase is built test-first. The Standard is the same on both editions.
How onMain ships its own work
onMain is built by onMain. When several agents finish within minutes of each other, merging one branch makes every other one stale — so the pull requests that are ready are gathered, tested together in one run, and landed in a single move. The team edition’s own train page carries the real figures: how many landed, and how many were held back.
Coming: when the train ejects a branch for a conflict, a resolver tries a plain rebase onto the new main and, if it is clean, marks the branch ready again itself. That much runs on Liquidsoft’s own repository today; it has not yet carried a pull request all the way to landing.
Records that stay linked to the work
The decisions, requirements and architecture are not a document set that rots beside the code. They are written by the work that changes them and read before the next change is planned: a plan cites the decisions it rests on, a card hangs off a stream, an invoice points back at the milestone it bills. That chain is what a client reads — and what your next agent reads too.
Questions
Is the agency edition a different product from the team edition?
No. It is the team edition with a client layer on top — the same MCP, the same Standard, the same records. A client sees a scoped view of the same work; nothing underneath is rebuilt for agencies.
Where is each part covered in full?
On onmain.dev, the team edition’s own site. Each section above links to its page — the MCP, the Standard and its loops, the train, and the records.