D5 — the shape of permission

The first agent architecture conversation is usually too technical.

Someone opens with the orchestration layer. Someone else asks whether the model should be swapped. A security architect asks about tool permissions. The product owner asks whether it can ship before quarter end. All reasonable questions. None of them is the first one.

The first question is quieter.

What is this agent allowed to do before a human notices?

D5 — Agent Architecture and Autonomy in the framework is the first dimension in the Responsible & Agentic AI Governance pillar. The Strategy pillar asked whether the organisation is choosing the right work, with enough evidence and data confidence. D5 asks what happens once the work starts acting back.

The central claim is simple: an agent estate is governable only when each agent’s scope of action and escalation path are explicit before deployment. Not in a policy aspiration. Not in a slide saying “human oversight”. In the architecture itself: what the agent can sense, decide, write, execute, spend, communicate, and trigger.

That is D5.1, per-agent autonomy classification and blast-radius design. I think it is the load-bearing idea in the agentic governance thesis. The question is not whether an agent is autonomous in the abstract. It is whether the organisation can draw the edge of the agent’s world before the agent crosses it.

A summarisation agent working over internal, non-sensitive material is one design problem. A procurement agent that can issue purchase orders is another. A claims agent that can change a customer outcome is another again. A service-management agent that can trigger production remediation is not made safe because it has the same chatbot shell as a meeting-note assistant. The interface hides the difference. The operating model has to recover it.

Autonomy therefore has to be paired with containment. The label is not the control. It should drive sandboxing, transaction limits, approval checkpoints, rate limits, rollback patterns, deployment gates, and recovery paths. If an agent can change a record, communicate externally, or call tools, the organisation needs to know whether the action is advisory, preparatory, binding, and reversible.

The mature version is not a beautiful taxonomy. It is a set of decisions that arrive before release: autonomy level, D2.3 criticality, material-impact tier for D6, reversibility class, escalation path, and evidence that rollback or containment has been tested.

This is why agent architecture cannot be left as an engineering pattern alone. The operating model has to make the permission shape visible enough for executives, risk owners, product owners, and platform teams to make the same decision. Otherwise every agent becomes a local exception with a confident sponsor.

An agent boundary is not just a system boundary. It is a scope of action. Which data can the agent retrieve? Which tools can it call? Which records can it write? Which messages can it send? Which workflows can it pause, escalate, or complete? Which human does it act for, and when does that delegation end?

These sound like security questions, and eventually they are. D9 should enforce identity, access, perimeter controls, and deny-by-default tool authorisation. But D5 has to define the requirements first. If the architecture has not distinguished the agent, the human delegate, the service principal, the environment, and the tools, downstream audit becomes storytelling.

That is the narrow point in D5.7. Agent identity is a design requirement, not a plea for a particular IAM technology. Shared bot accounts, opaque keys, and generic service identities may be convenient in pilots; they collapse accountability in material workflows. Specialist IAM and security engineers should determine binding models and token mechanics. The operating-model obligation is to require attribution to survive agentic execution.

Multi-agent workflows sound futuristic until you look at enterprise work now. A retrieval step finds policy. A classification step sets a risk tier. A drafting step prepares a response. A workflow agent routes the case. A SaaS agent updates the record. A human sees a narrow approval screen and clicks yes because the queue is long.

D5.5 is about making that distinction visible. Human review is meaningful only when the person has enough context, time, authority, interface support, and training to change the outcome, risk tier, customer communication, or escalation path. A click is not a control if the human cannot challenge the system, see the evidence, reverse the workflow, or route the case to authority.

This is where the forward links matter. D6 will deal with decision rights: who can approve, pause, override, and accept residual risk. D11 will return to human-in-the-loop capability: whether people have the skill, confidence, and institutional permission to intervene. D5 sits before both. It designs the breakpoints.

Those breakpoints need names: approval, challenge, pause, reversal, escalation, timeout, conflict resolution, and evidence capture. If a chain of agents hands work from one step to another, the architecture must say where authority transfers and what happens when one agent fails, disagrees, loops, or stalls.

Most organisations will not have one neat agent platform. They will have model providers, orchestration frameworks, SaaS agents, embedded assistants, internal agents, and employee-initiated tools arriving through browsers, extensions, scripts, and expense lines. The 5-to-500 transition will feel like entropy. This is where D5.3 matters as estate visibility: agent identifiers, owners, version history, tool history, and retirement evidence are the register signals that stop permission boundaries disappearing into local projects. The D2.3 register cannot be decorative, or unmanaged agents quietly become the estate.

D5.2 adds the multi-vendor version. Portability by itself is no longer the interesting claim. Protocols and orchestration options are moving quickly. The harder question is whether governance survives a provider change. If a material agent moves between providers or SaaS hosts, do the controls, audit trails, tool scopes, evaluation criteria, rollback paths, and retention expectations survive?

Specialist platform, security, privacy, and legal counsel should determine which artefacts must be preserved. The operating-model test is whether a migration or provider-failure drill proves the governance posture stayed intact. A functional migration that silently loses audit continuity is not maturity. It is a more impressive form of drift.

The regulatory intersections are real, but they should be handled with discipline. Section 180 of the Corporations Act anchors directors’ duty of care and diligence; corporate counsel determines whether a specific AI decision engages director duties. APRA’s CPS 230 matters where a prudentially regulated entity’s agent failure can affect material services or critical operations; specialist regulatory counsel determines applicability. The Privacy Act and the Australian Privacy Principles matter where personal information is used, disclosed, routed offshore, or inadequately protected; privacy counsel owns the pathway. AICD’s AI governance guidance is useful board-facing guidance, not law.

The framework’s job is to force the evidence trail to exist before the specialist judgement is needed.

Evaluation and runtime monitoring still matter, but in D5 they are supporting evidence for permission design, not the spine. Pre-release tests (D5.4) should prove the agent stays inside its autonomy class; production signals (D5.6) should show when it tries to cross that line — unexpected tool calls, prompt-injection response, spend or rate breaches, anomalous chaining, unmanaged agent use. Methodology by agent class is specialist evaluation and data-science work. D10 owns the monitoring response; D9 owns enforcement.

At full maturity, the test should resist theatre. Pick an agent class at random from the D2.3 register at the start of the review. Ask for same-quarter evidence from the register, orchestration platform, SaaS admin console, cloud or identity logs, and procurement or expense data. Ask for a rollback, revocation, provider-swap, emergency-disable, or HITL escalation drill. Ask what failed, how long recovery took, and whether remediation closed.

It moves the conversation away from whether the organisation has an agent strategy and towards whether the agent estate can be governed under pressure.

The next post, D6, takes the architecture into decision rights: who is allowed to approve, pause, override, and carry consequence. But D6 only works if D5 has drawn the lines first. You cannot assign decision rights over a foggy system. You can only assign them over a known scope of action.

The agent architecture work begins there.

Not with the model. With the permission.