The OwnCharter ecosystem
One governed model, two owners: run agents for clients with the blast radius bounded per client, or hold both roles and keep the whole model inside your own walls.
One model, two shapes
The ecosystem has two roles. The shop packages, signs, deploys, and maintains agents. The agent frontline does the work inside a business, through granted capabilities and nothing else. Over those roles sit two ownership shapes: an operator owns the shop and serves many clients, each a separate governed relationship, or a single business holds both roles and keeps everything in-house. The model does not change; only the ownership does. Whichever shape is yours, the rest of this page is about you.
The shop
A shop is a real business: it takes an order for capability, manufactures a governed pack, signs it under its own authority, deploys the agent, and stays accountable for what it shipped. That accountability is survivable because authority is bounded before anything runs: every pack verifies against a pinned root, the gate fails closed on anything unverified, and a deployed agent cannot widen what it was granted, so the blast radius of any one deployment is capped per client. When something goes wrong, the client calls the shop first. The shop can take that call, because the agent could never act outside what that client granted, and the record shows exactly what it did. The shop's whole book runs through the Control Information Center: every deployment visible, every action on the record.
The agent frontline
The deployed agent lives inside the business it serves, and its contract fits in one sentence: gate closed by default, it works its granted capabilities and nothing else, its authority flows only from the operator, and every action lands on the hash-chained permanent record. Privilege does not creep here. Capability arrives as a signed pack, verified before it runs, and a request to expand the agent's own authority is denied like anything else unverified: no self-grant, ever. Underneath, tools swap without touching intent; the frontline is bound to what should happen, not to any vendor's API.
Held together by governance
The rules that bind shops and agents do not live inside either of them. Builders never sign off on their own work, agents never grade their own homework, unverified means denied, and no role can widen its own authority: the gate is not writable by anything it gates, and the operator, a human, is always the final authority. That makes governance a property of the platform, not a project for your team. It does not loosen when a deadline slips, and it does not depend on anyone remembering to check. Proof sits under the rule: every action is authorized before it happens and recorded after, on a hash-chained, tamper-evident record that no role can edit, including the role being recorded. This site describes that system; it does not define it.
Find your place in it
The ecosystem role map
Five parts, four paths that flow, two that are refused. Select any of them; the caption is the rule that governs it, stated the way the gate enforces it.
Tap a role or a path to read its rule.
The roles
Paths that flow
Paths refused by construction
Choose your shape
Two shapes, one governed engine, and one question on the early-access form. OwnCharter is being built in the open, heading for early alpha: the shape you pick now is the shape you help finish.
Deploy and govern agents for clients
You own the shop and the recurring relationship that comes with keeping client agents governed and running. Every deployment is visible in your Control Information Center, every pack you ship carries a signature the client can verify, and the blast radius of any one agent is bounded per client. The practice scales; the liability does not.
Bring the whole model in-house
You hold both roles and keep everything inside your own walls: the shop, the frontline, and the record, on infrastructure you control. Governance arrives as a property of the platform, not a project for your team, and your data never has to leave. Because intent is separated from tools, leaving is a supported operation: adopting the model does not mean adopting a dependency.