Coding agents are now good at reporting completion. They summarise what they changed, list the tests they ran, note the checks that passed and declare the task done. The report is usually accurate about what the agent did. It is silent on the question that matters to the business: should this change be accepted?
Those are different questions, and many teams have started to blur them. A change merges because the agent said it was done and the pipeline was green. A reviewer approves a large diff because nothing in it looked wrong. Nobody in particular decided that the behaviour was right, or that the residual risk was acceptable. The decision happened by default.
Our position: execution can be delegated to agents; acceptance authority cannot. For every material change, a named person, or a policy that a named person approved, decides whether the result is accepted. The agent's speed is welcome on the execution side. It has no bearing on who holds the authority.
Seapoint Payments is fictional, and its systems and figures are illustrative. We continue with Seapoint's merchant onboarding squad, which by now has a living specification (Part 3) and a harness that catches most routine defects (Part 4).
Two lanes that meet at three points
It helps to picture agentic development as two lanes. In the execution lane, agents read the specification, change code, run checks, repair failures and propose a result. That lane can loop as many times as the harness allows. In the authority lane, people take a small number of decisions.
Before execution: is this the right work? Someone accountable for the outcome confirms the intent and the specification section the agent will work from. At Seapoint that is the product owner, and for any change touching a risk control, the risk lead as well.
During execution: is this exception accepted? Agents meet situations the specification did not anticipate. A well-harnessed agent stops and asks rather than guessing. The answer is a decision, and it should be recorded against the specification, not buried in a chat thread.
After execution: may this reach customers? Evidence is reviewed against acceptance criteria, and a named person or approved policy says yes, no, or yes with conditions.
Merging code and accepting a change are not the same event. Seapoint used to treat a merge as acceptance. It now treats a merge as "eligible for acceptance", and a separate, recorded decision as the release gate for anything above low risk.
Authority scales with risk
Not every change needs a committee. The work of governance is to decide, in advance, who accepts what.
For low-risk changes, such as copy on a help page, the authority can be a policy: if every check passes, the change may merge and release automatically. That policy is itself a decision, made once by someone accountable and reviewed periodically. For moderate changes, an engineer in the squad reviews and accepts. For high-risk changes, such as anything affecting when payouts are held or released, the product owner and the risk lead both accept, against evidence per acceptance criterion. For critical changes, such as replacing the bank-verification provider, a change board accepts and a rollback has been rehearsed.
The agent's speed is the same in every row. The difference is entirely in who must be satisfied and with what evidence.
What the acceptance authority needs
A person can only accept responsibly what they can understand. For agent-built work that means changing what arrives at the acceptance step.
| Instead of | Provide |
|---|---|
| A large diff | Small changes, each tied to specification sections |
| "All tests pass" | Results per acceptance criterion, including which tests were written by whom |
| The agent's summary | Evidence the agent cannot have produced alone: independent tests, check output, production-like trial results |
| A verbal assurance | A recorded decision: who accepted, on which version, with which conditions |
| Silent exceptions | A list of every point where the agent stopped and someone decided |
The middle row deserves emphasis. If the agent wrote the code and also wrote every test that proves the code works, the tests show internal consistency, not correctness against intent. At Seapoint, acceptance tests for high-risk rules are written by the tester from the specification before the agent starts, and the agent may not change them. The agent can add its own tests. It cannot mark its own homework on the criteria that matter.
Common ways authority leaks
Approval by fatigue. A reviewer facing hundreds of lines approves because nothing looks wrong, which is different from confirming that it is right. The fix is smaller changes and evidence organised by criterion.
Approval by proxy. "The AI review passed" is treated as approval. Part 6 covers why that is a filter, not a decision.
Approval by pipeline. The pipeline was designed for human-written code at human speed. Its automatic promotion rules may now apply to far more change than anyone intended.
Approval nobody recorded. The release went out, but nobody can say who decided that the partial-match behaviour was right. When something goes wrong, that gap becomes a governance finding.
Authority held by the wrong person. The engineer who ran the agent accepts a change to a risk control because nobody defined who should. Risk decisions belong with people accountable for risk.
Policy as an acceptance authority
Automated acceptance is legitimate when it is deliberate. Seapoint auto-merges low-risk changes because a named person approved a written policy: which paths count as low risk, which checks must pass, what is logged, and how often the policy is reviewed. That is acceptance authority exercised once, in advance, and it is far better than the same automation arriving by accident because the pipeline happened to allow it.
The test for any automated acceptance rule is whether you can answer three questions about it: who approved this policy, what does it cover, and when was it last reviewed?
Connection to the wider governance picture
This separation is not unique to software. Our series AI Before the Rulebook makes the same argument for AI-assisted decisions about people: AI may assist the decision, but it must not inherit authority. The Release on Evidence series goes deeper into the evidence chain from requirement to release decision. And the experts govern article argues that this is where engineering judgement becomes more valuable, not less.
A practical starting point
- Write down your acceptance matrix: risk tiers, examples, who accepts, what evidence they need.
- Separate "merged" from "accepted" for anything above low risk, and record the acceptance decision.
- Make acceptance tests for high-risk rules independent of the agent that does the work.
- Turn every automated acceptance rule into an approved, reviewed policy.
- Require agents to stop and ask at specification gaps, and record each answer.
Next: Part 6, AI code review is a filter, not a sign-off. All parts are on the series page.
How CloudNala can help
We help teams define acceptance authority for agent-built work: an acceptance matrix by risk tier, the evidence each tier needs, the separation of merge from acceptance, and written policies for automated acceptance where it is appropriate. We work with delivery, risk and product leads together, because acceptance authority is a governance decision, not just an engineering setting.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Plan an AI Delivery Pilot or write to us at consult@cloudnala.co.za