When a coding agent can draft a specification in two minutes, it is natural to ask what the product owner is for. When it can propose three architecture options before lunch, the same question lands on the architect. And when it writes tests as fast as code, people start wondering about QA.
The answer is that the work changes and the accountability does not. An agent can draft a requirement, an architecture, a test or a release note. It cannot accept organisational risk. If Kestrel Mutual’s recovery feature lets a fraudster take over a policyholder’s account, no regulator, customer or board will accept “the agent approved it” as an answer. Human roles remain accountable for product value, architecture integrity, security, legal obligations, production changes and customer outcomes.
We are following one fictional organisation through this series. Kestrel Mutual is fictional, and all figures are illustrative. Kestrel is a South African insurer building assisted account recovery (SPEC-017): a way for customers who have lost their registered mobile number to regain portal access, designed so SIM-swap fraud does not get easier. The team is a product owner for digital channels, a fraud and identity operations lead, a solution architect, a tech lead, five engineers, a QA engineer, information security and the privacy office, supported by a shared platform team.
The decisions still exist, even in a small team
Start with the human roles and, more importantly, the decision each one cannot hand to a machine.
| Role | Owns | Must not delegate blindly |
|---|---|---|
| Product owner | Outcome, priority, scope and acceptance | Whether the feature is valuable |
| Domain expert | Rules, language and exceptions | The meaning of a policy or regulation |
| Solution architect | Boundaries, quality trade-offs and ADRs | System-wide consequences |
| Tech lead | Implementation strategy and code health | Merge readiness and maintainability |
| Engineers | Code, tests, refactoring and operational detail | Technical judgement |
| QA or test engineer | Risk-based test strategy and evidence | Whether acceptance coverage is adequate |
| Security and privacy | Threat, control and privacy assurance | Acceptance of residual risk |
| Platform or SRE | Harness, environments, observability and reliability | Production readiness |
SRE stands for site reliability engineering: the discipline of running services reliably, usually with explicit reliability targets. An ADR is an architecture decision record.
At Kestrel, the fraud and identity operations lead is the domain expert, and the “must not delegate” column is not abstract. An agent can summarise the fraud team’s procedures into draft rules. Only that lead can say whether “three failed checks lock the flow for 24 hours” is the right rule, because only that lead knows how fraudsters actually probe the contact centre.
One person may hold several of these roles in a small team. In a five-person startup the founder may be product owner and domain expert, and the most senior engineer may be architect and tech lead. That is fine. The roles can merge; the decisions still exist. Someone still has to decide whether the feature is valuable and whether the residual risk is acceptable, and it helps to know who.
Agents as bounded functions, not employees
It is tempting to model agents as a virtual team: an “AI product manager”, an “AI architect”, an “AI QA lead”. The personas can be useful prompts. They become harmful when the organisation starts treating them as colleagues who own outcomes.
A more reliable way is to define agent functions: a bounded responsibility with a clear input, a clear output and a named gate where a human or an automated check decides whether the output is accepted.
| Agent function | Input | Output | Gate |
|---|---|---|---|
| Discovery assistant | Notes, sources and brief | Questions, conflicts and draft scope | Product and domain review |
| Spec author | Approved context | Draft behaviours and acceptance | Product approval |
| Architecture analyst | Spec and repository | Options, impacts and ADR draft | Architect approval |
| Planner | Approved spec and design | Dependency-ordered tasks | Tech-lead review |
| Implementer | One bounded task | Code, tests and change note | Automated checks |
| Reviewer | Spec, diff and standards | Findings and traceability | Human merge owner |
| Test agent | Acceptance criteria and interfaces | Test cases and evidence | QA and risk gate |
| Documentation agent | Approved change | Updated durable documentation | Owner review |
Read the “Gate” column carefully. Only one of the eight gates is purely automated: the implementer’s output goes through the harness described in Part 5 before any human sees it. Every other gate is a person with the authority to say no.
Two gates deserve special protection. Product approval of the spec is where a wrong goal is cheapest to catch. The human merge owner is where a wrong change is last caught before it becomes production behaviour. At Kestrel, every pull request declares whether it changes behaviour, and any change to a recovery code path also needs approval from the owners of the SPEC-017 folder.
Also notice what the reviewer agent does not do: it produces findings, not approvals. An agent reviewing another agent’s work is useful for catching inconsistencies with the spec. It is not a control on its own, especially when both use the same model and the same context, which tend to share the same blind spots. Our article on expert judgement in the AI era goes deeper into why the governing role stays human.
The flow for a material feature
Put together, the flow for SPEC-017 runs like this. The product owner and the fraud and identity lead shape intent. Spec authoring, with an agent drafting and people deciding, produces SPEC-017. The architect and information security review it, and ADR-024 is written. Planning breaks the work into tasks. Two implementers, each an engineer with an agent, work on separate tasks. Everything goes through the shared verification harness. An independent reviewer checks the result against SPEC-017. The outcome goes back to the product owner, who accepts it or sends it round again.
The loop back to the product owner is the part teams tend to skip. A feature can pass every check and still not do what the business needed. The person who owns the outcome closes the loop.
Three team shapes
The same responsibilities show up differently depending on the size and shape of the organisation.
Small team (two to five people)
- The product owner or domain lead owns intent.
- A senior engineer holds architecture and implementation leadership.
- Engineers use one shared spec template.
- Tests, CI and review together form the harness. CI, continuous integration, is the automated pipeline that builds and tests every change.
- Security or specialist review is called in when the risk justifies it.
The main danger here is over-structure. Avoid creating eight agent personas for a two-day feature. Separate perspectives only where they produce a distinct decision or verification step. If the same person approves the spec, the architecture and the merge, three agent personas feeding that person is ceremony, not control.
Product squad
One cross-functional team, like Kestrel’s recovery squad:
- product and design shape the outcome and scenarios;
- the architect or tech lead maintains boundaries and ADRs;
- engineers and agents implement tasks;
- QA turns risk into executable acceptance tests;
- the platform team supplies reusable harness capabilities;
- a service owner accepts operational readiness.
The feature spec belongs to the squad. Enterprise principles and shared contracts belong to their named owners. Kestrel’s squad owns SPEC-017, but it does not own the RecoveryDecision contract alone, because the portal team and the fraud case system depend on it too.
Platform plus squads
For several teams, a central layer appears. Enterprise policy and architecture set the rules. A platform team turns those rules into a paved road: templates, policy checks, CI patterns, sandboxes, observability and approved integrations. Domain ownership supplies the vocabulary and boundaries for each business area. Squads build on both, and their evidence flows into shared governance.
The trap for the platform team is becoming the author of every product spec. It should make good specs easy to write and verify. It should not write them. A platform team that owns everyone’s specs has quietly become a requirements bottleneck with a CI pipeline.
Regulated teams
Kestrel is an insurer, supervised by the Prudential Authority and the Financial Sector Conduct Authority, and processing personal information under POPIA. That adds explicit approvers: data and privacy, information security, legal and compliance, model risk where a scoring model is involved (the risk engine behind recovery decisions is one), and production release.
The discipline that keeps this workable is to make approval focus on named risks and evidence, not a generic sign-off meeting. The privacy office does not need to approve the colour of the recovery screen. It needs to see the retention rule for selfie images and the evidence that they are deleted on time.
A RACI for a material feature
A RACI chart names, for each activity, who is Responsible (does the work), Accountable (owns the outcome and has the final say), Consulted (gives input before the decision) and Informed (told afterwards). Here is a starting point for a feature like assisted recovery.
| Activity | Product | Domain | Architect | Engineering | QA | Security | Operations |
|---|---|---|---|---|---|---|---|
| Outcome and scope | A/R | C | C | C | C | C | C |
| Rules and examples | A | R | C | C | C | C | I |
| Architecture and design | C | C | A/R | R | C | C | C |
| Implementation | I | C | C | A/R | C | I | I |
| Acceptance evidence | A | C | C | R | R | C | C |
| Security risk | I | C | C | C | C | A/R | C |
| Production readiness | I | I | C | R | C | C | A/R |
Two rules make a RACI useful. First, accountability must be singular for each decision: one A per row. Two accountable people means nobody is. Second, agents never appear in the A column, and rarely in R without a named human behind them. The table is a starting point, not a universal answer; Kestrel’s version adds the privacy office as consulted on rules and accountable for retention decisions.
Parallel agents without chaos
Agents make parallel work cheap, which makes it tempting to run several at once. At Kestrel, one engineer’s agent takes TASK-017-03, the adapter for the external verification provider, while another takes TASK-017-04, the case-creation adapter. Both depend on the RecoveryDecision contract.
If both agents start immediately, each will make reasonable local assumptions about that contract. One adds a reasonCode field. The other expects reason. Both pass their own tests. The conflict appears at integration, after two sets of work have been built on incompatible foundations.
Parallel work needs:
- tasks that do not overlap, or an explicit sequence where they do;
- separate branches or worktrees;
- stable interfaces agreed first;
- file and component ownership;
- a shared integration test;
- one merge coordinator;
- limits on automatic retries and cost;
- a policy for conflicting changes;
- independent review against the original spec.
The single most important rule is the shortest: do not parallelise ambiguity. Resolve shared design first. Kestrel’s tech lead now settles and versions the contract before splitting tasks that depend on it. It costs an hour. It saves the week that two agents would otherwise spend confidently building on different assumptions. Cost limits matter too: our piece on subagents and cost isolation shows how parallel agent work can multiply spend when nobody sets a ceiling.
What to take from this part
Agents take on work, not accountability. Every material decision still has a named human owner.
Model agents as bounded functions with gates. Define the input, the output and who decides whether the output is accepted.
Roles can merge in a small team; decisions cannot disappear. Someone still owns value, risk and merge readiness.
Keep one accountable person per decision. Never put an agent in the A column of a RACI.
Do not parallelise ambiguity. Agree shared contracts before splitting work across agents.
Next in the series: Four worked examples: greenfield, brownfield, a small defect and an AI feature.
How CloudNala can help
We help delivery leaders redesign roles and gates for AI-assisted work: mapping which decisions each role owns, defining agent functions with clear inputs, outputs and approval points, and writing a RACI that fits the team’s real size and regulatory context. We also help tech leads set up parallel agent work so shared contracts are settled before tasks split.
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 SDD Pilot or write to us at consult@cloudnala.co.za