The Construction Site No One Is Watching
Picture a construction site.
The architect is delayed.
The scaffolding crew arrives on schedule.
They have materials. They have tools. They have a general sense of what needs to be done.
So they start laying foundations.
Not out of malice.
Out of efficiency.
When the architect finally arrives, the footprint is wrong.
The materials are embedded.
Undoing it costs more than starting again.
Nobody blamed the scaffolding crew.
They did what they were capable of doing, in the absence of a boundary that said: this decision is not yours to make.
This is happening inside your enterprise right now.
Not on a construction site.
In production.
The Gap Nobody Has Named
Organisations are having the right debate about AI agents.
But they are having it at the wrong altitude.
The boardroom asks: How much autonomy should agents have?
The compliance team asks: What data can agents access?
The security team asks: What actions can agents execute?
All important questions.
But none of them address the structural problem.
Because while those conversations continue, agents in production are already making decisions that belong to architects.
They are choosing:
- Integration patterns
- Data structure shapes
- Retry and fallback logic
- Dependency chains between services
- Caching strategies
These are not workflow decisions.
These are architecture decisions.
And they are being made at runtime.
Without a record.
Without a review.
Without an owner.
What Is an Architecture Decision?
Before defining the boundary, the term needs to be precise.
An architecture decision is any choice that:
- Affects system structure beyond a single component
- Is difficult or costly to reverse after implementation
- Creates a dependency that outlasts the current task
- Shapes how future decisions can be made
By this definition, an agent that selects a retry pattern across three services has made an architecture decision.
An agent that resolves an ambiguous schema by choosing one data shape over another has made an architecture decision.
An agent that routes a message through a new integration path because the primary path timed out has made an architecture decision.
None of these appear in an ADR.
None were reviewed by a board.
None were approved by an architect.
They accumulated silently.
And the system quietly became something nobody designed.
The Agent Decision Perimeter (ADP)
The structural fix is not a policy document.
It is a boundary model.
Introducing the Agent Decision Perimeter (ADP): a three-zone framework that defines — precisely — what an agent may decide alone, what it must propose, and what it cannot initiate.
%% caption: The ADP zones: structural impact and reversibility decide whether an agent acts, proposes or hands off to a human
graph TD
A[Agent Action] --> B{Does the action affect system structure?}
B -- No --> C[Zone A: Autonomous]
B -- Yes --> D{Is the structure reversible within one sprint?}
D -- Yes --> E[Zone B: Propose + Confirm]
D -- No --> F[Zone C: Human Only]
C --> C1["Agent acts freely\nNo approval needed\nLogged automatically"]
E --> E1["Agent proposes\nArchitect reviews\nDecision recorded in ADR"]
F --> F1["Human initiates\nAgent cannot begin\nBoard review required"]
Zone A — Autonomous (Green)
The agent acts freely.
No approval is needed.
Actions in this zone are:
- Contained within a single component
- Fully reversible
- Structurally invisible to other systems
- Logged automatically for audit
Examples:
- Selecting a sorting algorithm for an internal list
- Retrying a failed internal function call
- Formatting an output payload
- Choosing between two equivalent internal methods
The agent is doing what it was designed to do.
Nobody needs to watch.
Zone B — Propose + Confirm (Amber)
The agent proposes.
A human architect confirms.
The decision is recorded in an ADR before the agent proceeds.
Actions in this zone are:
- Structurally visible to one or more other systems
- Reversible but costly within a sprint
- Creating a new dependency or modifying an existing one
- Affecting a shared interface, schema, or contract
Examples:
- Selecting a message format for a shared event topic
- Choosing a new fallback route that affects downstream consumers
- Modifying a data structure used across modules
- Introducing a new external call pattern
The agent does not proceed until the confirmation is recorded.
The ADR is the gate.
Zone C — Human Only (Red)
The human initiates.
The agent cannot begin.
Actions in this zone are:
- Structurally irreversible without significant rework
- Affecting multiple systems, teams, or deployment units
- Creating dependencies that outlast the current feature cycle
- Requiring board or governance review
Examples:
- Establishing a new integration pattern between bounded contexts
- Introducing a new shared infrastructure dependency
- Defining a new event schema that becomes a published contract
- Choosing an authentication pattern across services
No agent proposal. No agent action.
Human decision. Human record.
The ADP Zone Map
| Dimension | Zone A (Autonomous) | Zone B (Propose + Confirm) | Zone C (Human Only) |
|---|---|---|---|
| Structural Impact | Single component | One or more systems | Multiple systems or teams |
| Reversibility | Immediate | Within a sprint | Requires rework cycle |
| Dependency Created | None | Limited, known | Broad or long-lived |
| ADR Required | No | Yes — before proceed | Yes — before initiation |
| Governance Review | None | Architect | Board or Architecture Lead |
| Audit Trail | Auto-log | ADR record | Formal decision record |
How Drift Accumulates Without ADP
Without a defined perimeter, the boundary between zones collapses.
Agents occupy all three zones simultaneously.
The result is architecture drift — a condition where the system's actual structure diverges from the structure anybody designed, approved, or can explain.
%% caption: Without ADP, agent changes drift from the design unrecorded; with ADP, each zone has its own record and review
flowchart LR
subgraph Without_ADP["Without ADP"]
direction TB
A1[Agent Acts] --> B1[Structural change made]
B1 --> C1[No ADR created]
C1 --> D1[No architect review]
D1 --> E1[Drift accumulates silently]
E1 --> F1[System no longer matches design]
end
subgraph With_ADP["With ADP"]
direction TB
A2[Agent Acts] --> B2{Zone classification?}
B2 --> C2[Zone A: Log only]
B2 --> D2[Zone B: ADR created, architect confirms]
B2 --> E2[Zone C: Human initiates, board reviews]
C2 --> F2[System matches design]
D2 --> F2
E2 --> F2
end
Architecture drift is not a security problem.
It is not a compliance problem.
It is a governance problem.
And governance problems have structural solutions.
When ADP Is Absent: What Breaks
When zone boundaries are undefined:
- Agents make structural choices that cannot be traced to a decision owner
- ADRs record human decisions but miss an entire class of runtime decisions
- Architecture reviews approve designs that agents have already modified in production
- Debugging distributed failures becomes impossible because the structural cause was never documented
- Engineering teams inherit systems that behave differently from their architecture diagrams
When ADP is respected:
- Every structural change has a zone classification, an owner, and a record
- ADRs capture the complete decision set — human and agent
- Architecture reviews operate on an accurate picture of the live system
- Drift is detected at the proposal stage, not during an incident
- New engineers inherit a system they can understand and trust
The difference is not intelligence.
It is boundaries.
Implementation Guide (30–60 Days)
Introducing ADP requires three sequential phases.
The goal is not to slow agents down.
It is to make their structural impact visible.
Phase 1: Decision Archaeology (Weeks 1–2)
Objective: Find the decisions agents are already making.
Activities:
- Audit agent action logs for structural choices
- Identify all integration points agents currently control
- Classify each observed decision against ADP zone criteria
- Produce an inventory: what is my agent deciding that nobody approved?
Success Metric:
- Complete decision inventory for every active agent in production
Phase 2: Boundary Definition (Weeks 3–4)
Objective: Draw the perimeter.
Activities:
- Apply Zone A / B / C classification to every action type in the inventory
- Define entry criteria for each zone (using the ADP Zone Map)
- Update agent configuration to enforce zone-level behaviour
- Create ADR templates for Zone B decisions
Success Metric:
- Every agent action type is classified
- Zone B actions have an ADR workflow attached
Phase 3: Governance Integration (Weeks 5–8)
Objective: Embed ADP into the architecture lifecycle.
Activities:
- Add ADP zone classification to architecture review checklists
- Include agent decision logs in sprint retrospectives
- Require Zone C sign-off as part of the standard governance gate
- Train architecture leads on reviewing Zone B ADRs
Success Metric:
- No Zone C action executes without a recorded human decision
- Zone B ADRs appear in the architecture decision register alongside human ADRs
Evidence from Practice
A FinTech I worked with had agents running in production that were making structural choices — selecting integration patterns, defining retry logic, choosing data shapes — without any record that these decisions were being made. The architecture team's ADR register captured every human decision. It captured none of the agent decisions.
We introduced the Agent Decision Perimeter (ADP) model — a three-zone framework that classified every agent action as autonomous (Zone A), propose-and-confirm (Zone B), or human-only (Zone C). The classification revealed that three agent actions assumed to be Zone A were actually operating in Zone B territory — making structural decisions that no human had authorised. Within a month, every agent action had a zone classification, Zone B actions had ADR workflows attached, and Zone C actions required human initiation.
The agent governance model was part of a broader AI strategy engagement: From 15 AI Pilots to 6 Prioritized Initiatives
Action Plan
This Week
Ask three questions about every agent currently in production:
- What structural decisions is this agent making that I have not explicitly authorised?
- If this agent's choices were extracted into ADRs, would my architecture review board approve them?
- Do I have a record of every integration pattern this agent has introduced or modified?
If the answers are unclear, structural drift is already in progress.
Next 30 Days
Apply the Agent Decision Perimeter model:
- Classify every agent action type into Zone A, B, or C
- Attach Zone B ADR workflows to agents operating in that zone
- Enforce Zone C as a human-only initiation gate
3–6 Months
Extend ADP across the agent portfolio:
- Include ADP zone classification in every new agent design
- Integrate agent ADRs into the central architecture decision register
- Audit zone boundaries quarterly as agent capabilities evolve
Final Thought
The scaffolding crew was not wrong to show up.
They were wrong to lay foundations without a boundary that said: this is not your decision to make.
Your agents are the scaffolding crew.
They are capable.
They are efficient.
They are already working.
The question is not whether to trust them.
The question is whether you have drawn the line that tells them — and your architects — exactly where their authority ends.
Without that line, the footprint is already shifting.
And undoing it will cost more than drawing the boundary now.
Define the Boundary Before the Foundation Shifts
If your agents are operating in production without zone classification…
if your ADR register captures human decisions but not agent decisions…
or if your architecture diagrams no longer match your live system —
the Agent Decision Perimeter may be the structural gap you have not yet named.
In a focused 30-minute Architecture Governance Diagnostic, we will:
- Identify what structural decisions your agents are currently making without authorisation
- Classify your agent action inventory against ADP zone criteria
- Define the minimum governance model needed to prevent structural drift
- Establish a review cycle that keeps agent behaviour aligned with architectural intent
No over-engineered frameworks.
No restrictions that slow delivery.
Just boundaries that make intelligent systems governable.
→ Book an Agent Governance Session
or
The most capable agents are the ones that know exactly where to stop.
