On a Monday morning at Langkloof Financial Cooperative, a fictional regional financial-services cooperative, the design authority opened its agenda and found the work already done. Overnight, an AI assistant had refreshed the application inventory, noticed that the new mobile onboarding service was calling the legacy member-records system directly, flagged that this broke the integration standard, and drafted an impact view showing the four systems affected. The diagram was tidy. The evidence links worked.
What the assistant could not do was answer the question that mattered. The direct call existed because branches in the Langkloof and the Klein Karoo often lose connectivity for hours, and the onboarding team had built an offline capture path that synchronised straight into member records when the link came back. Was that an acceptable exception, a temporary workaround with an expiry date, or a design that had to change before the next region went live? That decision involved member experience, operational risk, cost and who would carry the consequences. It took Nomvula, the lead architect, forty minutes with the onboarding product owner and the head of risk.
That is the shape of the change this series is about. AI does not remove architecture work. It removes a large part of the artefact production that used to hide the real work, and it exposes how much of the architect's value was always in context, judgement and decision rights.
What actually moved
The useful framing comes from software delivery. Addy Osmani's essay Human judgment doesn't leave the software factory. It relocates. (21 August 2026) argues that as agents take over more of the writing and checking of code, human judgement moves upstream, to intent, system shape and the quality bar, and stays at the point where someone decides what ships. His earlier post, Own the outer loop (15 July 2026), separates the agent's inner loop of investigate, implement and verify from the human-owned outer loop of constraints, sampling, audit evidence and ownership of the production boundary.
Architecture has the same two loops at a different scale. The inner loop is keeping the picture current: what exists, what connects to what, which standards are met, what a proposed change would touch. AI is increasingly good at that, provided it reads from trustworthy sources. The outer loop is deciding what the organisation should do about the picture: which constraints are real, which exceptions are acceptable, which investments come first, and who carries the risk. That loop does not automate, because it is where the organisation's intent and accountability live.
We made a related argument for engineering roles in Experts govern. This article applies it to the enterprise and solution architecture function, where the artefacts are inventories, standards, roadmaps and review packs rather than code.
The shift, row by row
| Traditional emphasis | AI-augmented emphasis | What stays with a person |
|---|---|---|
| Periodic architecture documents | Evidence refreshed on every change or every night | Deciding what is accurate enough, in scope and material |
| Manual repository reconciliation | Automated ingestion, classification and conflict detection | Naming the authoritative source and resolving conflicts |
| Annual portfolio analysis | Continuous signals on duplication, debt, cost and risk | Investment, retirement and sequencing decisions |
| Standards written as prose | Selected standards expressed as tests and pipeline gates | Intent, proportionality and the exception path |
| Review boards that inspect everything | Conformance evidence with targeted human review | Approving high-impact change and accepting risk |
| Artefact volume as visible output | Quality of context, trade-offs and decisions | Accountability for enterprise outcomes |
Read the right-hand column as a job description. None of it is new, but in most architecture teams it was squeezed into whatever time was left after the documents were produced. When AI takes over the drafting, that column becomes the work.
Langkloof's onboarding programme
Langkloof is modernising member onboarding across three channels: branch counters, a mobile app and assisted onboarding by field agents in areas with weak connectivity. Everything about the cooperative, its systems and its people is invented for this series. The pattern is common.
The architecture team split the work deliberately.
What the AI assistant does. It ingests the configuration management database, the cloud resource inventory, the integration platform's route definitions and the repositories, all read-only. It maintains a draft application inventory, detects dependencies that contradict the recorded architecture, flags services that do not meet the integration and data-classification standards, and drafts impact views for proposed changes. Every finding links back to the source record that produced it.
What it may not do. It may not change an authoritative record. A discovered dependency that contradicts the repository becomes a finding, not an edit. Generated from reality explains why discovered architecture should be reconciled by identity rather than trusted by eye; Langkloof applies that rule to the whole inventory.
What the architects do. They validate business meaning ("is this really the same member record, or a copy with different retention rules?"), resolve conflicting constraints, define what the assistant and delivery agents are allowed to decide, and take material exceptions to the design authority with alternatives and consequences attached.
What the design authority does. It decides. The offline capture exception was approved for six months, with a condition: the onboarding team would replace the direct call with a queued synchronisation through the integration platform before the next region went live. The decision, its owner, its conditions and its expiry date went into the architecture repository as a record, not a meeting note.
Eight moves, in order
The order matters more than the tooling. Teams that start with the assistant and add governance later usually end up with a faster way to produce untrusted documents.
- Establish the authoritative repository and its provenance model first. Decide which source wins for each kind of fact: the service catalogue or CMDB for who owns an application, the cloud inventory for what is deployed, the repository for intended design. The architecture repository is a management system sets out what that repository needs.
- Convert a few principles into testable rules. Pick standards that are already agreed and checkable, such as "no direct database access across domain boundaries", and express them as tests. Keep the prose intent and an exception path beside each rule.
- Connect sources read-only. Repositories, pipelines, cloud inventories and operational signals feed the assistant. Nothing flows back automatically.
- Use AI to find, not to fix. Drift, missing evidence, conflicting records and probable impacts become findings with links. Living architecture documentation sets out the pipeline-maintained drift report; here the question is who decides what to do with it.
- Route material exceptions to named owners. Each exception reaches a person who has authority over it, with the evidence, the options and the consequences of each.
- Record decisions with supersession and expiry. A decision without an expiry date becomes a permanent exception by default.
- Measure decisions, not diagrams. See the measures below.
- Expand autonomy only on evidence. If six months of the assistant's dependency findings were accurate and useful, perhaps it may auto-close stale low-risk findings. Not before.
Failure modes to design against
Treating the generated inventory as truth. An AI-maintained inventory is a hypothesis until it has been reconciled with authoritative sources. Letting AI agents draw the architecture covers the gates that catch invented components in diagrams; the same discipline applies to inventories and dependency maps.
Silent correction. An assistant that "fixes" a record because it saw something different in production destroys the evidence that the two disagreed. The disagreement is often the most important fact in the repository.
Automating the board out of existence. Continuous conformance evidence can make most reviews unnecessary. It cannot replace the forum where accountable people accept risk. For a cooperative that answers to members and to its regulator, the record of who accepted what, and why, is part of the control environment.
Delegating without an accountability chain. When the assistant drafts, a delivery agent implements and a pipeline checks, each step needs an owner. Delegation does not remove accountability sets out what each handoff must carry.
Keeping the old measures. If the architecture function still reports the number of views produced or reviews held, it will be rewarded for the part of the work AI has made cheap.
What to measure instead
| Measure | What it tells you | Langkloof's first target |
|---|---|---|
| Decision latency | Time from a material finding to a recorded decision | Under ten working days |
| Exception age | How long approved exceptions stay open past their expiry | None past expiry without re-approval |
| Repository freshness | Share of records confirmed against an authoritative source in the last 90 days | 80 per cent for production systems |
| Finding precision | Share of AI findings that architects confirm as real | Tracked monthly; no target until a baseline exists |
| Preventable rework | Delivery work redone because a known constraint was missed | Recorded per release |
The targets are illustrative, and Langkloof set them after a three-month baseline. The point is the kind of measure. Each one is about whether decisions are being made well and on time, which is the work that remains.
A scorecard for your own architecture function
Ask these questions of your team before buying or building an architecture assistant.
- Can we name the authoritative source for each kind of architecture fact?
- Do we have at least five standards that could be tested automatically today?
- Does every material exception have a named owner, a condition and an expiry date?
- Could we show a regulator or auditor who accepted a specific architecture risk, and when?
- Do our architects spend more time producing artefacts than deciding with them?
- Would we notice if an AI-generated finding was wrong?
If most answers are no, the assistant will make the gaps more visible rather than closing them. That is still useful, but plan for the repository and decision work first.
This change also reaches beyond architecture. Delivery teams are giving agents overnight work, and the same rule applies there: the useful product is evidence and a decision-ready proposal. Let the agents take the night shift shows that pattern in a software team.
Key points
- AI is taking over the inner loop of architecture work: inventories, drift detection and impact drafts. The outer loop of intent, constraints, exceptions and accepted risk stays with people.
- Build the authoritative repository and its provenance model before asking AI to maintain it.
- AI findings should become routed decisions with owners, conditions and expiry dates, never silent corrections.
- Generated inventories and dependency maps are hypotheses until reconciled with authoritative sources.
- Measure decision latency, exception age, repository freshness and preventable rework, not the number of diagrams.
- Expand an assistant's autonomy only when months of evidence show its findings are accurate and governable.
Next: Part 2, Choose the orchestration pattern before the framework. All parts are on the series page.
How CloudNala can help
CloudNala reviews architecture practices that want to use AI without losing control of their decisions. We assess your repository and its sources of truth, identify which standards can become tests, design the exception route and decision records, and set the measures that show whether the function is deciding better, so that an architecture assistant strengthens the practice rather than producing more documents nobody trusts.
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.
Book an Architecture Practice Review or write to us at consult@cloudnala.co.za