All work

Multi-agent coordination · Open-core · Go

Flowlio

A shared backlog for AI coding agents, so your sessions stop using you as a message bus. When one repo answers another, the asking agent wakes up and reads the reply on its own — the session can die in between, and the loop still closes with no human in the middle.

01 · The problem

You are the message bus, and it leaks

You work on acme-api and acme-web. The frontend agent notices the backend changed a contract. Today you copy the question into a file, switch windows, paste it into the other session, wait, then copy the answer back. Context leaks at every hop, and you are the transport layer.

Flowlio models this directly: one project per repo, tasks inside it, and issues between repos — read and answered over MCP. The agent that asked wakes up on the reply by itself, even if its session died in between.

02 · The architecture

Open-core, and the boundary is a decision

Three repositories with a boundary that's deliberate, not accidental. flowlio-agents is the open-source engine — CLI and MCP, no accounts, deterministic, with no LLM inside so the coordination layer itself can't hallucinate. flowlio-core is the hosted layer — accounts, billing, OAuth — and it's a client of the engine's admin API, never a fork. Accounts and Stripe must never leak into the open-source repo.

The hosted engine is co-deployed inside a single Render service, driven by a plainly stated constraint: the product earns nothing yet, and a second paid instance isn't affordable — so co-deployment answers it without touching the code. One service, one bill, two databases.

03 · The license

AGPL, chosen — not defaulted

AGPL-3.0 isn't cargo-cult here. It's a network-copyleft moat: anyone can use and self-host the engine, but anyone who modifies it and serves it over a network has to open their changes.

That's what stops a competitor from taking the engine closed and offering a rival hosted service without contributing back. MIT would let them; AGPL doesn't.

04 · Honest about the debt

Debt you can see is debt you can pay down

The biggest architectural gap is written down, not hidden: there's no store layer yet, services hold the query object directly, and that's exactly why auth and billing are hard to test.

A guard refuses new violations while baselining the existing ones. A baselined file is tolerated, never blessed, and the list is built to only shrink — every rewrite has to leave it shorter than it found it.

05 · What it honestly is

A niche tool, built well

Flowlio started as a learning project — an open-source, Linear-style UI I added the logic to — and grew through real friction: a Go rewrite, then an MCP so my own agents could read a board, then flowlio-agents so they could coordinate across repos without me.

I dogfood it: my other projects use it for their cross-repo questions. It's a niche tool built well, open-sourced, with managed hosting like n8n — not a startup pitch. The engineering is the point.

Method

How this gets made

My part is the direction and the rules; the AI writes the code inside them, and I read what it writes. That is how I can name the debt exactly — no store layer yet, services holding the query object, which is what makes auth and billing hard to test — and keep a guard behind a baseline that only ever shrinks. Knowing the code well enough to see where it is slipping is the same thing that lets me pull a build back before it drifts.

Available · remote

Want the same, shipped and run?

Three lines about your idea is enough. Reply within 24 hours.