Over the past few months I have been building a community agent that helps run a Discord server. Real permissions, real members, and for most of what it does, no human in the loop. I have written before about how that agent proposes changes to its own behaviour through pull requests.
While I was building it, a new term started doing the rounds: graph engineering. Designing AI workflows as explicit graphs, where the humans, the budgets and the rules are part of the graph rather than paragraphs in a policy document. When I read the definition I recognised my own build. I had arrived at the same shape independently, because I was trying to make one agent secure by default. Registries. Human gates. Kill switches. Nothing trusted just because the model seemed reliable.
That last part matters. The most common objection I hear to agentic systems is some version of "we cannot trust the model not to do something it shouldn't". It is a fair objection. I do not trust the model either. Trust is what you fall back on when the architecture does not decide the question for you. So I have turned the pattern into something an organisation can pick up and learn from: graph-engineering-for-organizations. It is a small governance layer that makes the rules machine-checkable. An agent fleet either matches its declared governance, or the build goes red.
The constraint is not model capability
Every organisation I talk to sizes its agent ambitions against how good the models are getting. That is the wrong denominator. The binding constraint on an agent fleet is human review capacity: how many decisions a real person can meaningfully look at in a week, before looking becomes clicking.
This reframes the design problem. If review is the scarce resource, then humans are not a safety feature bolted onto the outside of a workflow. They are nodes in it, with the same obligations any other node has: a defined input, a defined output, and a defined behaviour on timeout. A human gate that says "someone will look at this" is not a control. Give that gate a structured payload, an approve/reject/modify decision, a named owner, and an explicit rule for what happens when nobody responds in four hours, and it becomes one. Every part of it can now be checked.
Autonomy is earned from outside, or it is not earned
The rule I care most about is the one that governs when an agent gets to stop being watched.
The tempting path is to let a workflow graduate on its own numbers. It has run four hundred times, the error rate is under one percent, the dashboard is green, so let it off the leash. The problem is that every one of those numbers is produced by the system being measured. A workflow optimising against its own metrics will improve the metrics. That is not the same as improving the outcome, and the gap between the two is invisible from inside.
So autonomy scales with external anchors and nothing else: signals that come from outside the workflow and that it cannot reach. Did the cash actually land. Did the customer come back. Did someone outside the team find the incident first. A workflow with named external anchors can earn sampled oversight. A workflow whose only evidence is internal stays fully gated, no matter how good its own numbers look, and no matter how elegant its architecture is.
For that to mean anything, the measuring instrument has to be out of reach too. An agent that can write to the system that scores it does not have an anchor, it has a mirror. So instruments are registered and frozen, and a workflow that writes to a frozen instrument fails the build. That rule never bends. Two others never bend either: nobody approves their own work, and no governance role is ever held by an agent identity rather than a person. That includes the authority to pull a kill switch.
Governance that cannot go stale without someone noticing
Written-down governance decays. The document says every agent has an owner; three of them left the company. The policy says credentials are short-lived; one service account has had a standing token since March. Nothing announced the drift, because prose cannot fail.
The whole point of putting this in a repository is that files can be checked against each other. A validator runs on every pull request, and weekly as well, so decay surfaces even when nobody is committing. It fails the build on any of these:
- a workflow references an agent that is not registered, owned, and kill-switchable
- an active agent holds a standing credential instead of a just-in-time one
- two workflows write the same resource without an edge between them
- a gate has no timeout behaviour, or escalates to the person who was already reviewing it
- a workflow's owner is also its reviewer
- sampling is claimed without external anchors
- a workflow sails past its review date and becomes an orphan
Being out of compliance is allowed. Organisations are messy, and a rule with no escape hatch gets bypassed rather than followed. But an exception has to be a file: a named approver who is not the owner, a reason, and a hard expiry inside ninety days. The expiry is the part that matters. It converts "we will fix this later" from a sentiment into a date that fails CI when it passes.
It is a linter for your agent fleet's governance. That is the whole ambition. It does not build agents and does not want to. You bring LangGraph or Temporal or Step Functions or plain CI, and this sits above whatever you brought, as the contract and the enforcement.
What I owe you about its maturity
It has no outside adopters. Not few. None. The example teams in the repository are fictional, and they stay fictional until a real pilot's numbers replace them.
The run log has exactly one row, and it is an agent run. By the framework's own rule that proves very little. An agent run demonstrates nothing is broken and no command is wrong, but it does not count toward the target, because agents read faster than people and get lost in different places. The target is that a human clones the repository and reaches a green validator, including a workflow of their own, in under an hour. Until a human row lands, that target is an aspiration the log exists to test, not a claim I get to make.
I built it with my own domain expertise and a lot of agent commits. By its own standard, that is exactly the kind of internal evidence it refuses to accept as proof. I am aware of the recursion. It is the honest position: a framework asserting that self-generated metrics do not justify autonomy, tested so far only against self-generated metrics.
Two other limits worth stating plainly. This needs at least two people. Separation of duties is not something a solo operator can honestly perform, and I would rather say so than sell it to an audience of one. And the rules are only as strong as the platform underneath: without branch protection and a required check, every constraint here is advisory, which is to say decorative.
What would actually help
I cannot test this further on my own. Everything I would learn by running it against my own workflows, I have already learned. What it needs now is contact with somebody else's mess: a real team, real ownership boundaries, a real workflow that someone would be annoyed to see break.
So the useful thing is not a star. It is forking it and trying to break the rules on purpose. Register an agent with a standing credential. Make yourself the reviewer of your own workflow. Claim sampling with no anchors. Then tell me where the validator was wrong, unclear, or merely irritating. It is Apache-2.0, there is no runtime dependency on anything I control, and the first case-study slot is open.
This is the same argument I keep making from a different angle. I have written before about matching autonomy to blast radius and about governance as an enabler rather than a brake. Both of those describe a discipline. The gap I kept hitting was that a discipline lives in someone's head and degrades silently. This is an attempt to move it into files that fail loudly instead.