Why we govern our own build
Agents write changes faster than people can review them. A tool reporting success doesn't mean the job is finished. So three questions go unanswered: who asked for this, who approved it, and was it checked against what we wanted? A platform that sells governance for agents would be hard to believe if its own agents worked on trust. So we run our build under the rules we build.
Five obligations
Five obligations define what accountable agent work means, in our own development and in a customer's production system alike.
- 01
Explicit purpose
Each piece of work traces to a request with a stated objective and a named person accountable for it.
- 02
Delegated authority
An agent may do only what the person who asked could delegate to it, and a check at the moment of action enforces that limit.
- 03
Traceable evidence
The path from request to plan to change to approval can be reconstructed afterwards.
- 04
Honest uncertainty
An agent reports what it observed, what it inferred and what it does not know, and material doubt blocks a claim of success.
- 05
Conditional completion
An agent can propose that work is done; whether the objective is met is judged against agreed acceptance conditions, with evidence.
How a change moves
This is the path each change is designed to follow.
- 01A request states what is wanted and who is accountable for it.
- 02The request becomes a plan, and the plan is reviewed.
- 03A person approves the exact list of tasks, and only then are the tasks created.
- 04Agents carry out the tasks, each change linked to its task and its purpose.
- 05Each change is checked against its purpose and its acceptance conditions, and what the checks find is recorded and followed up.
- 06A person decides whether to accept the change.
Each step is designed to leave a record, so the path from request to accepted change can be reconstructed.
Dashed steps are decisions a person makes.
What works today
Planning and task creation work this way now. A request becomes a reviewed plan, a person approves the exact list of tasks, and only then are the tasks created, which covers the first three steps. The rest is being built step by step: linking each change to its task and purpose, the checks that compare it with that purpose, the evidence trail from request to accepted change, and the follow-up on what the checks find. Throughout, agents work under human direction and a person approves and merges the work. We make no certification claim for this process, so read the five obligations as the target and the weekly counts in the Engineering Room (/engineering-room) as a record of activity.
The same rules as the platform
These obligations line up with four of the platform's own principles: Principle 1 (Bounded autonomy), Principle 4 (Governance before execution), Principle 6 (Humans stay above the automation layer) and Principle 7 (Explainability and audit by design). Building Synedrix OS under them shows us where they are too loose or too heavy, which is better learned on our own work than on a customer's. The full set is on the principles page (/principles).
Synedrix OS is in active development. The architecture is complete and the platform is being built, and the lifecycle described here is part of that build.