Pattern matrix/White paper/Governance
ADPS Agent Design Pattern White Paper · Module overview
Governance Module: Making Agent Autonomy Manageable
Authorization, accountability, containment, cross-cutting controls, lifecycle, and control plane.
When an agent only recommends, governance often looks like content review. Once it invokes tools, changes business state, and delegates to other agents, governance becomes a runtime discipline: whom the agent represents, why an action is authorized, where failure stops, and whether responsibility and outcome can be reconstructed.
Locally compliant steps can still drift away from a long-running goal. Governance therefore evaluates both the current action and its relation to the original goal and real outcome.
Governance objectives
| Objective | Question | Engineering objects |
|---|---|---|
| Authorization | Who represents whom, and which action may affect which resource? | Identity, delegation, policy, tool, arguments, resource |
| Accountability | Who did what under which versions and policies, and what happened? | Run, trace, approval, versions, state delta, external receipt |
| Containment | If a control fails, where does the maximum impact stop? | Sandbox, tenant boundary, quota, budget, breaker, compensation |
G1 admits one intent. G2 bounds the damage if an admitted action is wrong. G3 changes the authority of a capability over time. X1 supplies their evidence, and G5 provides deterministic enforcement points.
The v0.5 structure
Dual-axis matrix
Cognitive function × execution topology remains the primary ADPS structure. Seven functions and six topologies are unchanged. The matrix now contains 27 cell-bound core patterns; the Governance row retains G1 Approval Gate, G2 Blast-Radius Control, and G3 Progressive Commitment.
Cross-cutting engineering planes
| Plane | Scope | Outputs |
|---|---|---|
| X1 Observability | Every pattern and lifecycle stage | Events, causality, versions, state deltas, receipts |
| X2 Evaluation & Validation | Artifacts, trajectories, business outcomes | Regression, graders, deterministic tests, acceptance |
| X3 Security & Identity | Principal, delegation, authority, and resource boundaries | Allow, deny, ask, limits, execution conditions |
The planes do not belong to the Governance row and do not occupy matrix cells. X1 supplies runtime facts, X2 supplies validation judgements, and X3 supplies identity and authority. Governance patterns consume that evidence to approve, contain, expand, or withdraw authority.
Lifecycle
ReAct is the perception-reasoning-action micro-loop inside controlled operation. Evals recur during offline validation, canary release, operation, and revalidation. Neither requires another matrix coordinate.
Running example: a payroll batch across the lifecycle
This example explains the composition and is not an attributed enterprise case.
| Stage | Engineering action | Evidence |
|---|---|---|
| Register and own | Record the agent, owner, purpose, production environment, two capabilities, and retirement conditions | Agent ID, owner, capability list, credential references |
| Design and version | Pin model, prompt, payroll rules, payment tool, approval policy, and data dependencies | Workload digest and dependency manifest |
| Offline eval | Cover routine batches, new hires, cross-region tax, duplicate requests, and hostile arguments | Regression results, failure classes, cost, boundary tests |
| Shadow and canary | Compare with the manual process before enabling a small recommendation slice | Human differences, adoption, long-tail distribution |
| Controlled operation | G1 freezes and routes intent; G2 limits tenant, amount, and batch; G5 revalidates before commit | Intent, Approval, quota, hook verdicts |
| Observe and attribute | X1 links source ledger, arguments, payment receipt, state delta, and reconciliation | Cross-system trace, receipt, business outcome |
| Change and revalidate | A payment-API upgrade freezes old grants and reruns affected evaluation and shadow work | Version diff, revalidation, change approval |
| Authority disposition | Validation may reach bounded execution; submission remains reviewed; an ended pilot is retired | Capability grant, demotion, or retirement record |
Governance control plane
A local middleware can guard one agent. Multiple agents, domains, and delegations need shared registry, policy, enforcement, and evidence services. A central platform can own identity, policy formats, telemetry, and cross-domain audit; domain teams still own risk, acceptance, approvers, and incident response.
Governance contract
intent_id: int_01K3...
principal: user://finance/108
agent: agent://payroll/prod-v7
run_id: run_8842
tool:
name: create_payment_batch
digest: sha256:4ef...
resource_scope:
tenant: tenant_42
max_records: 20
policy:
version: payroll-policy-v12
decision: ask
preconditions:
source_ledger_version: 417
approval:
expires_at: 2026-08-19T09:30:00Z
max_uses: 1
execution:
idempotency_key: payrun-2026-08-batch-17
A tool name is not enough for a governance decision. Immutable tool version, canonical arguments, resources, delegation, environment, aggregate budget, and business preconditions all affect risk.
Governance patterns and cross-cutting dependencies
| Specification | Control object | Boundary |
|---|---|---|
| G1 Approval Gate | Current high-risk intent | Revalidate intent and preconditions on resume; consume approval once |
| G2 Blast-Radius Control | Maximum action, run, and fleet impact | Agent judgment and historical success cannot alter hard limits |
| G3 Progressive Commitment | Capability- and scenario-specific autonomy | Promote, hold, demote, freeze, and retire |
| X1 Observability | Cross-cutting evidence chain | Keep observed facts separate from evaluation judgements |
| X2 Evaluation & Validation | Capability and regression evidence | Keep graders independent from the candidate system |
| X3 Security & Identity | Principal, delegation, and credentials | Propagate identity and narrow authority by resource |
| G4 Observability · legacy entry → X1 | Retains the old identifier and route | The current specification is X1 and no longer occupies a Governance cell |
| G5 Hooks Pipeline | Deterministic enforcement points | A hook is not the policy source or domain judge |
Public engineering material
DeerFlow Guardrail and two-layer authorization follows five public pull requests through pre-call interception, principal propagation, RunJournal, an RBAC provider, and assembly-time plus runtime authorization.
First Governance Module Workshop preserves concrete questions about sandboxing, approval resume, agent registry, evidence attribution, capability-level authority, and offline evaluation. That material led to the v0.5 engineering planes and lifecycle structure.
Mechanisms under further study
- Delegated identity chain across user, agent, workload, run, and downstream tool.
- Durable intent and the business changes that invalidate an approval during a wait.
- Agent registration and retirement for pilots, credentials, versions, queues, and ownership.
- Federated governance between central controls and domain accountability.
Suggested citation:ADPS, Governance Module: Making Agent Autonomy Manageable, Agent Design Pattern White Paper v0.5, 20 August 2026.
Pattern catalog · Governance workshop · CC BY 4.0
Scope:Public review draft. Definitions and classifications are open for discussion and citation; running examples explain mechanisms, while attributed practice appears in the case library.
Chronicle
- Recorded source
- First Governance Module Workshop (18 August 2026); DeerFlow Guardrail architecture evolution
- Source date
- First published on ADPS