The Constitution
Constitution of Roxabi
Not a manifesto. A description of how the system actually works — and the principles we won't trade away.
There are things a ten-person engineering team can build that one person can't. Not because of skill — because of time. The team had someone on the orchestration layer. Someone who owned state. You didn't.
Roxabi exists to remove that structural disadvantage. The foundations every agentic system needs — routing, state, orchestration, recovery — are the same for everyone. So they should be shared, owned, and forkable. This document records the principles that follow from that choice.
The Foundation
Art. 0The operating layer
Roxabi is the part of the stack that doesn't change between projects. You don't rebuild an operating system to write a program; you build on it. Roxabi is that layer for agentic systems — and the interesting work starts on top of it, on day one.
Art. 1Primitives, not a framework
Roxabi ships primitives — routing, state, orchestration, harnesses, connectors. Each works standalone. None imposes an opinion about your architecture. A framework tells you how to build; a primitive hands you a part and gets out of the way.
Art. 2Compounding is structural
Each module is built to extend cleanly. Add a harness and it wires into the routing already there. Modules build on modules; the dependency graph grows, and its value grows with it. This is compounding in the sense of compound interest — a property of the architecture, not a slogan.
Open by Architecture
Art. 3Open by design, not by badge
Open source as a license is a legal fact. Open by architecture is a design choice: every layer is inspectable, every component replaceable, and nothing depends on Roxabi staying in the picture. AGPL-3.0. Full source. No "community edition" with the useful parts removed.
Art. 4Nothing calls home
No telemetry by default. No vendor API routing your agents through our servers. The model layer is a pluggable interface — no specific AI vendor is required or mentioned. What you run is what you can read.
Art. 5No hidden layers
No feature gates between you and the thing that actually works. No enterprise tier. No asterisk. If a capability exists, it's in the source you cloned.
Sovereignty
Art. 6The stack is yours
The moment you run git clone, the stack is yours: forkable, self-hostable on any infrastructure you control. It doesn't require our permission, our servers, or our continued existence to keep working.
Art. 7The escape hatch is the default
Every closed dependency is a future tax — a pricing email that wrecks a month, a shutdown notice with thirty days to migrate. Roxabi is the opposite by construction: there is nothing to be locked out of, because there is nothing locked.
Built for Builders
Art. 8For the one who ships
Roxabi is for the solo developer and the small team that moves fast — the person who builds because they have to, and would rather fork and extend than buy a seat and wait for a feature request.
Art. 9Honest about scope
It is not for enterprises with dedicated platform teams, and we won't pretend otherwise. A tool that's for everyone is for no one. The builder who actually needs this should recognise themselves in it.
The Commons
Art. 10Built on what came before
The foundations are published because shared infrastructure compounds. You benefit from what came before you; others benefit from what you add. Contribution is a building method here, not an ideology.
Art. 11Roxabi extends open source
"Roxabi extends open source. Open source extends Roxabi." That is a description of how the dependency graph actually works — not a slogan. When a contributor adds to the commons, the next builder starts from a position the contributor didn't have.
Seven things we won't trade away
- The license is AGPL-3.0 and stays copyleft. No relicensing the useful parts away.
- No telemetry without explicit, opt-in consent.
- Every layer remains inspectable and replaceable.
- The model layer stays vendor-neutral and pluggable.
- A claim ships with its mechanism or its proof, never alone.
- Primitives stay standalone — usable without adopting the whole stack.
- The README is the onboarding. No sales call required.
Unfinished by design
This document is open to amendment, and the git history is its memory. The foundations grow with the people who use them. If you find something here that the code contradicts, the code is the truth — open an issue, and this text gets corrected.