Agentic Architectures and Orchestration

This chapter treats agents as architectural components with explicit boundaries, not as a new kind of software that escapes the usual disciplines. It distinguishes a workflow from an agent, shows how tool use and the Model Context Protocol (MCP) connect a model to the enterprise, and bounds autonomy with permission manifests, approval gates, and audit trails in version control, before turning to the failure modes we see most often and their controls.

Figure 11.1: Workflow patterns (prompt chaining, routing, parallelisation) keep control flow in code; orchestrated patterns (orchestrator with workers, evaluator with optimiser) share it; the autonomous agent loop (model selects a tool, tool executes, observation returns) hands it to the model.

Workflows and agents are different components

Chapter 10 described the foundation model as a probabilistic component behind a well-defined interface. Once that component may call tools and choose what to call next, we have changed the architecture, not merely the prompt. The distinction that matters is who owns the control flow.

In a workflow, the control flow is written in code: the sequence of model calls, the branching conditions, and the tools invoked at each step are fixed by the developer, and the model fills in content. Anthropic's practitioner guidance draws exactly this line, recommends the simplest solution that works and adding complexity only when it demonstrably improves outcomes, and notes that workflows offer predictability and consistency for well-defined tasks, whereas agentic systems often trade latency and cost for better task performance (64, Anthropic, 2024). In an agent, the control flow is delegated to the model, which receives a goal, selects a tool, observes the result, and selects the next tool until the goal is met or a limit is reached. The ReAct pattern, which interleaves reasoning traces with actions and observations, is the canonical description of that loop (57, Yao et al., 2023). Toolformer showed that models can learn when to invoke external functions from relatively little supervision, which is why tool use has become a general capability rather than a bespoke integration (58, Schick et al., 2023).

A workflow therefore has a finite set of paths that we can test, whereas an agent has an open set that we can only bound. Zaharia and colleagues observe that state-of-the-art results are increasingly obtained by compound AI systems, in which models are one component among retrievers, tools, and control logic, and that leading results can come from clever engineering, not just from scaling up training (63, Zaharia et al., 2024). Agents are the most demanding of these.

Choosing the least autonomy that works

My default advice is to pick the pattern with the least autonomy that meets the requirement, and to document that choice in an AI Decision Record of the kind described in Chapter 5. Figure 11.1 orders the common patterns along that axis.

Pattern	Control flow owner	Typical use	Primary risk
Prompt chaining	Code	Document drafting in fixed stages	Error propagation between steps
Routing	Code, with a model as classifier	Triage of citizen enquiries	Misclassification at the entry point
Parallelisation	Code	Independent checks, voting	Cost multiplication
Orchestrator–worker	Shared	Multi-step tasks with variable decomposition	Orchestrator drift from the goal
Evaluator–optimiser	Shared	Refinement against explicit criteria	Convergence on the evaluator's blind spots
Autonomous agent	Model	Open-ended tasks in an instrumented environment	Loops, privilege escalation, cost run-away

If a competent analyst could write down the steps in advance, build a workflow; if the steps depend on what the first tool returns, an agent is justified, provided the environment is bounded.

Tool use and the Model Context Protocol

Tool use is the mechanism by which a model invokes external functions. The model emits a structured request naming a tool and its arguments; the runtime executes the function and returns the result as an observation. The model never executes anything itself, so every tool call passes through code we control, the natural place for policy enforcement.

The Model Context Protocol is an open protocol that standardises how a model host connects to tools and data sources (36, Anthropic, 2024). An MCP server exposes tools, resources, and prompts over a defined transport; a host connects one or more servers and presents their tools to the model. For a large organisation the attraction is separation: a single MCP server in front of the case-management system can serve every agent that needs it, carry one security review, and be versioned and monitored like any other integration component.

Treat an MCP server as an integration adapter with the obligations of an API: an owner, a contract, a threat model, and a place in the architecture repository. Chapter 12 covers the gateway and identity patterns that apply to it; Chapter 16 covers prompt injection through tool results, which Greshake and colleagues demonstrated as a realistic attack path when tools return attacker-controlled content (51, Greshake et al., 2023).

Worked example: registering an MCP server

Illustrative example. Hansa Mutual, the multinational insurance group introduced in Chapter 1, fronts its core claims system with one MCP server that several agents share. Before any agent may connect, the server is registered in the architecture repository, and the agent pipeline refuses a manifest that names a server or tool absent from the registration.

# tool-registry/claims-core-mcp.yaml - Hansa Mutual (illustrative)
apiVersion: ai-architecture.example.org/v1
kind: ToolServerRegistration
metadata:
  name: claims-core-mcp
  version: 1.4.2
  owner: claims-integration-team
  securityReview: {date: 2026-08-19, reference: SR-2026-077, nextDue: 2027-02-19}
  threatModel: threat-models/claims-core-mcp.md
spec:
  endpoint: https://claims-core-mcp.internal.hansa.example/mcp
  network: internal-only, mutual TLS
  authentication:
    method: oauth2-token-exchange
    requiresActingUser: true
  dataClassification: personal-ordinary
  tools:
    - {name: policy.lookup, effect: read}
    - {name: claim.get, effect: read}
    - {name: claim.create_draft, effect: reversible-write}
    - {name: document_request.draft, effect: reversible-write}
    - {name: claim.suggest_queue, effect: reversible-write}
    - {name: document_request.send, effect: irreversible}
    - {name: reserve.set, effect: irreversible, agentUse: prohibited}
  outputHandling: {markAsUntrusted: true, maxResponseTokens: 4000}
  allowedConsumers: [claims-triage-agent, claims-assistant]
  logging: {traces: otel://collector.internal, arguments: logged, retentionDays: 3650}

The effect classification is the field the rest of the design depends on. It lets the pipeline check that every irreversible tool in a manifest carries an approval requirement, and it prohibits agent use of reserve.set outright, so that no manifest can grant it. Because of requiresActingUser, the server rejects any call that does not carry the identity of the claims handler on whose behalf the agent acts, the delegated-authority pattern of Chapter 12.

Worked example: an agent skill

Illustrative example. An agent skill is a packaged set of instructions, and optionally scripts and reference files, that an agent loads when a task calls for it. The Agent Skills specification defines the package as a directory containing a SKILL.md file with YAML front matter, of which name and description are required, followed by Markdown instructions (208, Agent Skills Contributors, n.d.). Hansa Mutual's claims-triage agent uses the skill below for motor claims; a reference file with the required fields per claim type sits beside it and is loaded only at step 2.

---
name: motor-fnol-checklist
description: Check a first notification of loss for a motor claim for completeness and prepare a claim draft. Use when a new motor claim arrives from the web form or the contact centre.
metadata:
  owner: motor-claims-team
  version: "1.2.0"
  decision-record: AIDR-0024
---
# Motor first notification of loss: completeness check

## Steps
1. Look up the policy with `policy.lookup`. Stop and hand over if no active
   policy covers the date of loss.
2. Check the form against references/motor-required-fields.md.
3. List missing items. Do not infer missing facts from photos or free text.
4. Create a claim draft with `claim.create_draft`. Mark missing items.
5. If items are missing, prepare a request with `document_request.draft`.
   Sending it needs a handler's approval.

## Never
- State or imply whether the claim is covered.
- Estimate repair costs or set reserves.
- Contact a third party directly.

A skill changes what the agent is told, never what it is permitted to do: its prohibitions repeat boundaries that the registry and the policy decision point already enforce, and it is versioned and reviewed like a prompt. A pipeline check that every tool a skill mentions is granted in the manifest catches the common error of a skill that instructs an agent to use a tool it cannot reach. Chapter 8 describes how skills are catalogued and promoted as governed shared assets.

Multi-agent patterns that survive contact with production

Multi-agent systems are compositions of the patterns above. Frameworks such as AutoGen popularised the idea of several model-driven participants conversing to solve a task (59, Wu et al., 2023). The production experience, however, is more sobering than the research results, and three patterns have proved reliable in the organisations I work with.

Orchestrator–worker. An orchestrator decomposes a task, dispatches each sub-task to a narrow worker, which may be a workflow, and synthesises the results. Because the orchestrator alone sees the whole task, it is where the step budget, the cost budget, and the goal check belong, while workers receive the minimum context and permissions their sub-task requires. In a manufacturing maintenance scenario, workers query sensor history, retrieve the manual, and draft a work order that a technician approves; no worker can create one on its own.

Evaluator–optimiser. One component produces a candidate, a second scores it against explicit criteria, and the first revises. This works when the criteria are clear, as for format compliance and citation presence. Its weakness is that the evaluator's blind spots become the system's, so the criteria belong in version control and in the evaluation suite of Chapter 20.

Routing. A classifier directs each request to a specialised flow, so that a small, cheap model handles most traffic and larger models are reserved for the hard cases, which Chapter 22 develops into a cost policy. In a public authority, routing also enforces scope: an enquiry the chatbot may not handle goes to a human queue.

Unstructured group conversations with no owner of the goal, and recursive delegation without a depth limit, have not survived well, because both produce loops and cost run-away.

Bounded autonomy as an architectural property

Bounded autonomy is a principle of AI Architecture that AI Governance, Chapter 4 sets out: a system's freedom of action is declared in advance, limited to what its purpose needs, and enforced by controls outside the model. Autonomy is bounded when four things are true: the agent can only reach explicitly granted tools; each tool call executes under a least-privilege identity; actions above a defined risk threshold require approval; and steps and spend are capped. Figure 11.2 shows how those controls fit together at runtime. They must hold even when the agent works around them in pursuit of its task, without any attacker involved; Chapter 19 examines that behaviour and the containment that does not depend on the agent's intentions.

Figure 11.2: A policy decision point mediates every tool call against a versioned permission manifest, routes risky actions through an approval gate, and writes every decision to the audit log.

The permission manifest

The permission manifest is the agent's declared intent, in the sense of the principle, also from AI Governance, Chapter 4, that a system's purpose and boundaries are stated in a versioned artefact before it runs. It states what the agent is for, which tools it may call with which arguments, under which identity, and which actions require a human. It is reviewed through a pull request and loaded by the runtime at start-up, and nothing the model emits can extend it.

apiVersion: ai-architecture.example.org/v1
kind: AgentPermissionManifest
metadata:
  name: maintenance-diagnostic-agent
  owner: plant-reliability-team
  decision_record: ADR-0142
spec:
  purpose: Propose maintenance actions for rotating equipment based on sensor history and manuals
  prohibited_uses:
    - Issuing work orders without technician approval
    - Accessing personnel or payroll data
  identity: {service_account: svc-maint-agent, token_lifetime_minutes: 15}
  budgets: {max_steps_per_task: 25, max_cost_eur_per_task: 0.80, max_wall_clock_seconds: 300}
  tools:
    - name: sensor_history.query
      allow: true
      argument_constraints:
        asset_id: "^PLANT-[A-Z]{2}-[0-9]{4}$"
        lookback_days: { max: 90 }
    - name: manuals.search
      allow: true
    - name: work_orders.create
      allow: true
      requires_approval: true
      approver_role: certified-technician
    - name: work_orders.close
      allow: false
  audit: {log_destination: otel://collector.internal, retain_days: 365}

The prohibited_uses list is the agent-level counterpart of the intended-purpose statement that the AI Act requires providers to document for high-risk systems. The budgets block is the first defence against loops and cost run-away. The argument_constraints block prevents injected text from steering the model to request a broader query than the task needs, requires_approval implements the approval gate, and allow: false documents a tool that exists on the server but that this agent may never call.

Worked example: a deny-by-default manifest for an IT-operations agent

Illustrative example. An agent with write access to production systems is where bounded autonomy matters most. Hansa Mutual's IT-operations agent, accepted in AIDR-0027 (Chapter 5), diagnoses alerts and may perform a short list of remediations. Its manifest denies everything by default and grants each action explicitly, with conditions.

# agents/itops/manifest.yaml - Hansa Mutual (illustrative)
apiVersion: ai-architecture.example.org/v1
kind: AgentPermissionManifest
metadata:
  name: itops-remediation-agent
  owner: site-reliability-team
  decision_record: AIDR-0027
spec:
  default: deny
  purpose: Diagnose production alerts and apply pre-approved remediations
  identity: {service_account: svc-itops-agent, token_lifetime_minutes: 5, standing_privileges: none}
  environments: {allowed: [production-eu], denied: ["*"]}
  grants:
    - {tool: observability.query, effect: read}
    - {tool: runbook.read, effect: read}
    - tool: kubernetes.restart_deployment
      effect: reversible-write
      conditions: {namespaces: [claims-web, claims-api, document-service], max_per_hour: 3}
    - tool: kubernetes.scale_deployment
      effect: reversible-write
      conditions: {namespaces: [claims-web, claims-api], replicas: {min: 2, max: 12}}
    - tool: feature_flag.disable
      effect: reversible-write
      conditions: {flags_tagged: [agent-may-disable]}
  approval_required:
    - {tool: kubernetes.rollback_deployment, approver_role: on-call-engineer, expires_minutes: 10}
  never:
    - database writes, schema changes or data deletion
    - changes to identity, network policy, secrets or the agent's own manifest
  budgets: {max_steps_per_incident: 30, max_write_actions_per_incident: 4, max_wall_clock_minutes: 20}
  stop: {kill_switch: agents.itops.enabled, on_stop: hand over to on-call engineer with full trace}
  audit: {trace: otel://collector.internal, log_arguments: true, retain_days: 1825}

Every write the agent may perform is reversible, rate-limited, and confined to named targets; rollback it may only propose, and standing_privileges: none means that each action is authorised by a five-minute token issued for that call. Under Article 9 of DORA these remediations are ICT changes, and the manifest is the documented control that makes them auditable (3, European Union, 2022).

The tool allow-list and the policy decision point

A policy decision point between the model and the tool servers evaluates every tool request against the manifest before execution. Organisations that already use Open Policy Agent can express the manifest as Rego, OPA's declarative policy language, and reuse the same engine (35, Open Policy Agent, n.d.); Architecture as Code (Chapter 10) describes that pattern for infrastructure (72, Nordqvist, 2025). What matters is that deterministic code outside the model makes the decision against a versioned artefact.

An agent should never run under a human user's full credentials. It runs under a service identity with a short-lived token scoped to the tools in the manifest, and where it acts on behalf of a user, delegated authority is propagated explicitly so that the system of record sees both the agent and the person, a pattern Chapter 12 develops.

Worked example: a complete agent configuration

Illustrative example. The manifest says what an agent may do; the agent configuration assembles everything the runtime needs to run it, including how it stops. Hansa Mutual configures its claims-triage agent, which uses the skill and MCP server above, as follows.

# agents/claims-triage/agent.yaml - Hansa Mutual (illustrative)
apiVersion: ai-architecture.example.org/v1
kind: AgentConfiguration
metadata:
  name: claims-triage-agent
  owner: motor-claims-team
  decisionRecord: AIDR-0024
  riskClassification: limited-risk
spec:
  model: {gatewayRoute: routes/claims-triage, pinnedVersion: registry://gpai-large-eu/2026-04}
  instructions:
    systemPrompt: prompts/claims-triage/system@v2
    skills: [skills/motor-fnol-checklist@1.2.0]
  identity: {serviceAccount: svc-claims-triage, tokenLifetimeMinutes: 10, actingUser: required}
  tools:
    - {server: claims-core-mcp, name: policy.lookup}
    - {server: claims-core-mcp, name: claim.get, scope: "claims assigned to acting user"}
    - {server: claims-core-mcp, name: claim.create_draft}
    - {server: claims-core-mcp, name: document_request.send, approval: approvals/claims-agents.yaml}
  budgets: {maxStepsPerTask: 20, maxCostEurPerTask: 0.50, maxWallClockSeconds: 240}
  stop:
    killSwitch:
      flag: agents.claims-triage.enabled
      operatedBy: [claims-duty-manager, ai-platform-on-call]
    stopConditions:
      - any budget exhausted
      - 3 policy denials in one task
      - same tool called with same arguments 3 times
      - tool output flagged by injection classifier
    onStop:
      safeState: claim draft marked "agent stopped - manual review"
      handover: queue://motor-claims/manual-intake
  audit: {trace: otel://collector.internal, logArguments: true, retentionDays: 3650}

The stop block is the part teams most often omit. The kill switch is a feature flag that named roles can set without a deployment, the stop conditions turn the failure modes described later into concrete triggers, and the safe state guarantees that a stopped task leaves a reviewable draft rather than a half-finished change. The ten-year audit retention follows Hansa Mutual's claims-file retention, not a platform default.

An evaluation gate decides whether a new version may run at all. Any change to the model, prompt, skill, or tool list produces a new agent version, which loads only after 260 recorded notifications have been replayed against tool stubs and the thresholds met, with zero irreversible calls without approval. An adversarial set of notifications with embedded instructions checks the outcome that matters, namely that no tool call fell outside the manifest and no embedded instruction was acted on, rather than enumerating attack strings.

Approval gates and human oversight

Approval gates are the architectural form of human oversight for agents. Article 14 of Regulation (EU) 2024/1689, the AI Act, requires that high-risk AI systems be designed so that natural persons can oversee them, including the ability to intervene or interrupt, and Article 26 places the duty to assign competent oversight on the deployer (1, European Union, 2024). For an agent, oversight is therefore an interruption path, a queue of pending actions, a role that may approve them, and a log of who did so.

Three design decisions determine whether a gate works. The gate presents the proposed action with enough context to judge it; approvals are bound to the specific action and expire, so that approving one work order does not authorise the next ten; and a timeout results in a safe stop, never in silent approval. A gate that approves by default under time pressure is worse than no gate, because it produces evidence of oversight that did not occur.

Worked example: a human-approval policy

Illustrative example. Hansa Mutual writes these decisions into one policy that every claims agent references.

# approvals/claims-agents.yaml - Hansa Mutual (illustrative)
apiVersion: ai-architecture.example.org/v1
kind: ApprovalPolicy
metadata: {name: claims-agents, owner: head-of-claims, version: 2.0.1}
defaults:
  bindTo: action-hash        # approval covers one tool call with exact arguments
  batchApproval: false
  onTimeout: reject-and-stop # never approve by default
rules:
  - {actionClass: read, approval: none}
  - actionClass: customer-communication
    tools: [document_request.send]
    approval: required
    approverRole: claims-handler
    expiresMinutes: 30
  - actionClass: financial
    tools: [reserve.set, payment.release]
    approval: not-available   # agents may not request these actions
monitoring:
  flagApprovalsFasterThanSeconds: 4
  reviewIf: approval rate above 98 per cent for a team over 4 weeks

Binding approval to the hash of the exact tool call means the handler approves the request they were shown, not whichever request the agent sends next. The monitoring block looks for rubber-stamping: an approval given in under four seconds, or an approval rate that never falls below 98 per cent, suggests the appearance of oversight rather than oversight, the outcome Article 14 of the AI Act is designed to avoid for high-risk systems and which Hansa Mutual guards against for every agent (1, European Union, 2024). The thresholds are starting values for Hansa Mutual's risk appetite, not universal constants.

Public authorities face a stricter version of this requirement. Where an agent's action would constitute or materially shape an administrative decision about a person, Article 22 of the GDPR restricts decisions based solely on automated processing, and national administrative law typically requires that a reasoned decision be attributable to an official (2, European Union, 2016). Architecturally, the agent may prepare but a person must decide, and the record must show the person's decision as distinct from the agent's proposal. AI Governance, Chapter 17 returns to this point.

Auditability of agent actions

Every tool call, policy decision, approval, and refusal must be logged so that it can be reconstructed later. For a high-risk system the log is also the record-keeping that Article 12 of the AI Act requires, and the evidence that AI Governance, Chapter 11 turns into assurance. Use the OpenTelemetry semantic conventions for generative AI so that agent traces correlate with the ordinary traces of the systems the agent touches (34, OpenTelemetry, n.d.); a single trace should show the user request, model calls, tool calls with their arguments, policy decisions, and approvals. Log the arguments, because that is where the risk is, and keep the audit log append-only with its own retention, separate from application logs.

Failure modes and their controls

The failure modes of agents are predictable and can therefore be designed against.

Loops. The model alternates between tools or retries a failing call. Controls: step budgets, a progress check, and a wall-clock limit, after which the agent stops and escalates with its trace.

Escalation of privilege. The agent obtains, through injected content or an over-permissive tool, access it was not meant to have. Controls: the allow-list with argument constraints, short-lived scoped tokens, tool servers that enforce their own authorisation, and treating all tool output as untrusted input.

Cost run-away. A loop or over-eager decomposition produces thousands of model calls. Controls: the per-task budget, a per-agent daily budget at the AI gateway, and alerting on spend rate rather than totals; Chapter 22 provides the cost policy.

Goal drift. In long tasks the orchestrator substitutes an easier goal. Controls: restate the goal in every orchestrator turn and check it explicitly before completion.

Confident wrong actions. The agent executes an irreversible action on the basis of a hallucinated fact, which Chapter 10 defined as fabricated output presented as true. Controls: classify tools as reversible or irreversible, require approval for the irreversible class, and prefer designs in which the agent drafts and a system or person commits.

Sculley and colleagues warned that machine learning systems accumulate hidden technical debt through entanglement and undeclared consumers (43, Sculley et al., 2015). Agents add undeclared capabilities, which no one listed and therefore no one assessed. The manifest is the remedy, because it turns an implicit capability set into a declared, reviewed, and testable one.

Codifying agent architecture in the repository

Manifests, allow-lists, approval roles, and budgets are architecture and belong in the same repository and pipeline as the rest of the estate. A pipeline stage validates the manifest against its schema, checks that every tool exists on a registered MCP server, confirms that every irreversible tool requires approval, and rejects budgets above the limits in the AI policy. The same stage can generate the agent's entry in the AI inventory that AI Governance, Chapter 9 describes, so that the register is derived from the artefact. This is the Architecture as Code conviction applied to agents: the boundary is executable, versioned, and tested, and the evidence of its enforcement is produced automatically.

Agents also work on the architecture repository itself. Nordvik Region's architects, for example, use one skill that drafts AI Decision Records in the format of Chapter 5, marking the classification as proposed and leaving thresholds "TO BE AGREED" rather than inventing them, and another that reviews AI-related pull requests against the region's policy rules. The second skill's allowed-tools field, an experimental part of the specification, limits it to reading files, so a review cannot alter the change it reviews (208, Agent Skills Contributors, n.d.).

Worked example: a repository configuration for coding agents

Illustrative example. Coding agents now work in many repositories, including those that hold AI systems. AGENTS.md is an open format used across many coding agents: a Markdown file at the root of a repository that gives coding agents the context and instructions they need, much as a README does for people (209, AGENTS.md Contributors, n.d.). Hansa Mutual places the file below in the claims assistant's repository.

# AGENTS.md - claims-assistant repository (Hansa Mutual, illustrative)

## What this repository is
The claims assistant: a retrieval-augmented system for claims handlers.
Decision record: decisions/AIDR-0021. Risk class: limited-risk.

## Checks
Run before proposing any change: `make lint test eval-smoke`

## Rules for changes
- Work on a branch and open a pull request; never push to `main`.
- Do not edit files under `decisions/` that have `status: Accepted`.
- Changes to `prompts/`, `rag/` or `gateway/` must add or adjust
  evaluation items in `eval/`.
- Never put customer data, credentials or internal hostnames in code,
  tests, prompts or commit messages.

## Off limits
- `.github/workflows/`, `policies/` and `CODEOWNERS`: human changes only.

## When unsure
Stop and ask in the pull request. Do not guess at policy or thresholds.

AGENTS.md carries instructions, not enforcement. Hansa Mutual therefore pairs it with controls the agent cannot override: branch protection on main, CODEOWNERS approval by the model-risk team for prompts/ and eval/, and a runner policy that gives the agent a repository-scoped token and denies network access by default. The instructions file says what is expected; the platform makes what is forbidden impossible.

Across the usage modes

Agents appear in several usage modes of Chapter 2 (usage-mode matrix), with very different degrees of organisational control. Mode 0 involves no agent the organisation configures.

Mode	Agent pattern	Boundary enforced by
Mode 1 – Conversational assistants	None, or provider-run tool use such as web search	The provider
Mode 2 – Embedded workplace assistants	Suite agents acting with the user's permissions	Tenant settings and the user's own permissions
Mode 3 – Agentic work tools	Agents on workstations, repositories or sandboxes	Tool permissions, sandboxing and repository protection; AGENTS.md guides but does not enforce
Mode 4 – Built AI applications	Workflows, with agents only where steps cannot be written down	Permission manifest and policy decision point
Mode 5 – Autonomous production agents	Agents acting on business systems	Manifest, policy decision point, approval policy, kill switch and evaluation gate

Most of this chapter's controls are written for Mode 5, and the coding-agent configuration shows how far they reach into Mode 3. The governance of skills and agents as shared assets is the subject of Chapter 8.

Nordvik Region and Hansa Mutual

Nordvik Region uses this chapter mainly for its architects' assistants. It runs no autonomous production agents, because an agent acting on residents' cases would raise questions of administrative law, such as who took the decision and on what grounds, that it is not ready to answer.

Hansa Mutual runs agents with real authority: the claims-triage agent of AIDR-0024 on the core claims system and the IT-operations agent of AIDR-0027 with write access to production. Bounded autonomy is therefore its central control, and manifests, the approval policy, and the kill switch are its daily instruments. Its agents also act across jurisdictions, because the claims-triage agent works through the Polish service centre on claims from several markets. Hansa therefore binds every tool call to the market of the claim, lets the policy decision point apply that market's overlay, and blocks actions for markets the decision record does not cover. Where Nordvik limits agency by not granting it, Hansa limits it by making the jurisdiction part of every permission.

Summary

Agents differ from workflows because the control flow lives partly inside a probabilistic component. We therefore choose the least autonomy that meets the requirement and reserve agents for tasks whose steps depend on what the environment returns. Tool use and the Model Context Protocol give a standard seam at which to enforce policy, and the orchestrator–worker, evaluator–optimiser, and routing patterns have proved dependable where unstructured multi-agent conversation has not.

Bounded autonomy is an architectural property, realised through a version-controlled permission manifest, a policy decision point outside the model, least-privilege identities, approval gates that implement the human oversight of Articles 14 and 26 of the AI Act, and an audit log of every action. Each common failure mode maps to a specific control in that design.

Chapter 12 turns from the agent to the landscape of existing systems that it, and every other AI service, must connect to.

Sources

1. Anthropic. Building effective agents. Anthropic research blog, 19 December 2024. (64, Anthropic, 2024)
2. Yao, S., Zhao, J., Yu, D., Du, N., Shafran, I., Narasimhan, K. & Cao, Y. (2023). ReAct: Synergizing Reasoning and Acting in Language Models. International Conference on Learning Representations (ICLR 2023). (57, Yao et al., 2023)
3. Schick, T., Dwivedi-Yu, J., Dessì, R., Raileanu, R., Lomeli, M., Hambro, E., Zettlemoyer, L., Cancedda, N. & Scialom, T. (2023). Toolformer: Language Models Can Teach Themselves to Use Tools. Advances in Neural Information Processing Systems 36 (NeurIPS 2023). (58, Schick et al., 2023)
4. Zaharia, M., Khattab, O., Chen, L., Davis, J. Q., Miller, H., Potts, C., Zou, J., Carbin, M., Frankle, J., Rao, N. & Ghodsi, A. (2024). The Shift from Models to Compound AI Systems. Berkeley Artificial Intelligence Research blog, 18 February 2024. (63, Zaharia et al., 2024)
5. Anthropic. Model Context Protocol Specification. November 2024, revised 2025. (36, Anthropic, 2024)
6. Greshake, K., Abdelnabi, S., Mishra, S., Endres, C., Holz, T. & Fritz, M. (2023). Not what you've signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection. Proceedings of the 16th ACM Workshop on Artificial Intelligence and Security (AISec '23). (51, Greshake et al., 2023)
7. Agent Skills Contributors. Agent Skills Specification.. (208, Agent Skills Contributors, n.d.)
8. Wu, Q., Bansal, G., Zhang, J., Wu, Y., Li, B., Zhu, E., Jiang, L., Zhang, X., Zhang, S., Liu, J., Awadallah, A. H., White, R. W., Burger, D. & Wang, C. (2023). AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation.. (59, Wu et al., 2023)
9. European Parliament and Council of the European Union. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). Official Journal of the European Union, 27 December 2022. (3, European Union, 2022)
10. Nordqvist, G. (2025). Architecture as Code. The Transformed Architecture, Book 1, published at aac.geon.se. (72, Nordqvist, 2025)
11. European Parliament and Council of the European Union. Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). Official Journal of the European Union, 12 July 2024. (1, European Union, 2024)
12. European Parliament and Council of the European Union. Regulation (EU) 2016/679 on the protection of natural persons with regard to the processing of personal data (General Data Protection Regulation). Official Journal of the European Union, 4 May 2016. (2, European Union, 2016)
13. OpenTelemetry Authors. OpenTelemetry Documentation, including the Semantic Conventions for Generative AI systems. Cloud Native Computing Foundation. (34, OpenTelemetry, n.d.)
14. Sculley, D., Holt, G., Golovin, D., Davydov, E., Phillips, T., Ebner, D., Chaudhary, V., Young, M., Crespo, J.-F. & Dennison, D. (2015). Hidden Technical Debt in Machine Learning Systems. Advances in Neural Information Processing Systems 28 (NeurIPS 2015). (43, Sculley et al., 2015)
15. AGENTS.md Contributors. AGENTS.md: a simple, open format for guiding coding agents.. (209, AGENTS.md Contributors, n.d.)
16. Open Policy Agent Contributors. Open Policy Agent Documentation. Cloud Native Computing Foundation. (35, Open Policy Agent, n.d.)