Monitoring tells you a workflow ran. It doesn’t tell you who answers for it.
That’s the gap I kept hitting once I had more than a handful of workflows in my company. The questions stopped being “did it run” and became “who owns this one”, “what breaks if it fails”, and “should this be able to act irreversibly without asking anyone”.
So I built Fleet and open-sourced it. MIT, self-hosted, one container and a volume.
It syncs over the MCP server or the public API (a read-only key is enough), then gives you:
- An ownership roster. Import your instance’s users, assign who’s accountable, and every change lands in a decision ledger
- Risk as a visible rule set instead of a score. Each flag shows which rule fired
- Blast radius from the sub-workflow call graph. Click a node, see what breaks
- Autonomy graded by whether an action can be undone, not by how much you trust the model
It never edits your workflows. Every fix hands off to the editor or to an agent you run. The gap list is in the README: no built-in auth yet, change requests are recorded but not delivered, autonomy is displayed but not settable, sync is manual.
I think it’s useful. But I’ve been testing my own thinking against my own setup, so I’d rather ask:
- Is ownership the right thing to track, or is approval routing the actual need?
- Would you want Fleet to enforce autonomy policy, or just tell you when something has drifted from it?
- If you run more than one instance, would a single view across them be what makes this worth deploying?
pnpm dev with no config loads a seeded demo estate if you want a look before wiring anything up.
The most useful thing anyone could do is point it at your own instances and tell me where it’s got the reversibility grading wrong. There’s an issue template in the repo!