Governing AI delivery
AI-assisted development has made it easier to move from an idea to working code. That puts more weight on deciding what should be built and how we will know it is ready.
I approach that work much as I would any other commissioned delivery: make the brief explicit, define the boundaries and agree what constitutes an acceptable result.
There are three distinct parts to that approach.
The brief directs the work
The brief should explain the purpose, constraints, permitted scope and acceptance criteria. Existing decisions belong alongside it so the agent does not need to rediscover them.
A structured specification can make those expectations easier to reuse across tasks. It is still an instruction. It does not guarantee that the agent understands or follows every requirement.
That is why the next layer matters.
Controls constrain the actions
Some decisions can be enforced outside the model: filesystem boundaries, tool permissions, schema validation, dependency rules and release gates.
Others require judgement. A check can show that a required artefact exists; it cannot necessarily establish that the artefact is useful. A passing test demonstrates the behaviour it covers, not every behaviour the system may have.
For each requirement, ask what actually enforces it and what happens when the check cannot run. A prompt, a warning, an approval request and a blocking control are different mechanisms.
The distinction also applies to workflow hooks. A notification after a transition is useful evidence. It is not a control that prevents the transition.
Evidence supports acceptance
At delivery, I want the relevant diff, checks, unresolved findings and decisions in a form another person can inspect.
Evidence should identify what was evaluated and which version it relates to. A signed record can help establish that the record has not been altered. It does not make an incomplete or incorrect assessment true.
Missing evidence should remain visible. It should not quietly turn into a pass.
Keep human decisions deliberate
An agent can prepare a release without being authorised to publish it. The workflow should make that boundary explicit.
The person accepting the result needs enough information to make a decision: what changed, what was checked, what remains uncertain and how the change can be recovered if needed.
More agents do not remove this responsibility. They can create useful parallel work, but also coordination and integration work. Start with the simplest arrangement that serves the task.
My interest is in making expectations, transitions and evidence easier to understand.
The aim is useful delivery that someone can stand behind.
Further reading
This research discusses coordination problems and uncertainty in multi-agent settings. It is context, not validation of the projects described here.