Tools · Whitepaper

Chapter 19 · Agents and Autonomy

Observer, Stop Path and Evaluation Tools

Key insights from Chapter 19 of "Tools"

Author Conceived and directed by Gunnar Nordqvist; text written by AI agents under his direction.
Published 11 November 2026
Build number 2026.11
tools templates methods architecture-as-code ai-governance
Figure 19.1: The observer principle as a set of tools. The agent and its platform sit in one failure domain, the observer manifest declares probes and a heartbeat in another, the stop path runs in a third, and seeded faults, stop-path tests and evaluations produce the dated evidence behind an independence statement.
Figure 19.1: The observer principle as a set of tools. The agent and its platform sit in one failure domain, the observer manifest declares probes and a heartbeat in another, the stop path runs in a third, and seeded faults, stop-path tests and evaluations produce the dated evidence behind an independence statement.

This chapter serves one activity: showing, by evidence that an agent cannot write, that what an agent did worked, that the agent can be stopped, and that the level of delegation it holds is still earned. The tools come from four earlier volumes. AI Red Team (4, Nordqvist, 2026) contributes the golden-dataset evaluation. The Transformed Security Architect (6, Nordqvist, 2026) contributes the timed stop drill and the seeded-error drill. AI Purple (9, Nordqvist, 2026) contributes the independence principle and its artefacts. AI Operations (10, Nordqvist, 2026) contributes the observer manifest, the seeded-fault record and the promotion policy, with a few tools from AI Governance (2, Nordqvist, 2026), AI Platform and Security (3, Nordqvist, 2026), AI Threat (5, Nordqvist, 2026), AI Boss (7, Nordqvist, 2026) and AI Blue (8, Nordqvist, 2026). Three of the four kinds of tool in this book appear here: artefacts (manifests, records and policies), methods (drills, seeded exercises, reviews) and, in small number, third-party tools (benchmarks and a progressive-delivery controller). The chapter has no own tool in the sense of Chapter 1; the series ships no observer software, and an observer is built from the organisation's own probes and receivers.

Two questions organise it, and the answer to each is a design rule that the earlier volumes state and this chapter does not restate beyond what a reader needs. The first is what must be independent of what it verifies. The second is where the stop path runs. AI Operations, Chapter 17, answers them with the observer principle, which has three tests: what verifies an action must be independent of what performed it, the observer must not depend on the system observed, and the stop path must work when the platform does not (10, Nordqvist, 2026). AI Purple, Chapters 4 and 15, gives the same idea for a loop that tests defences: a check counts as verification only when the ways in which it can fail are not the ways in which the checked thing can fail (9, Nordqvist, 2026). Chapter 18 treated the tools that grant and bound an agent's authority; this chapter treats the tools that test whether the bounds hold and whether the agent deserves the level it has. Chapter 20 treats the tools that defend the agent itself.

The slice for this chapter holds 50 inventory entries. Most are artefacts and methods that belong together as a toolset, and a few are carried by the inventory into this chapter although another activity serves them better; the closing paragraph of the chapter says which. The chapter proceeds in four families: observers and independence, seeded faults and their relatives, stop paths and drills, and the evaluation and promotion of agents.

Primary topics explored

  1. Observers and independence
  2. Seeded faults, gaps, errors and incidents
  3. Stop paths and drills
  4. Evaluation and promotion of agents
  5. Across the degrees of delegation
  6. Summary

About Tools

Tools is a companion to The Transformed Architecture. It collects the tools that Books 1 to 10 describe in one reference, organised by what the practitioner is doing: artefacts (templates, manifests, records), own tools, third-party tools and standards, and methods. Each entry says what a tool is for, when to use it, what it needs and produces, and where the book that defines it explains the reasoning. The book covers choosing, adopting and retiring tools, architecture and delivery, governing AI, securing and testing, operating, agents and autonomy, and people, organisation and society, for European enterprises and public authorities. It comes with a template library, an inventory, three web tools and the Toolbox Maturity Method.

It builds on the conclusions of Architecture as Code, AI Governance, AI Platform and Security, AI Red Team, AI Threat, The Transformed Security Architect, AI Boss, AI Blue, AI Purple and AI Operations.

Who should read this

Architects and security architects, CIOs and CISOs, platform and operations leads, heads of governance, risk, compliance and third-party risk, AI governance and AI platform teams, red, blue and purple team leads, boards and management bodies, procurement and vendor managers, supervisors and auditors, works councils and unions, data protection officers, and public-sector leaders.

Portrait of Gunnar Nordqvist

Gunnar Nordqvist

Conceived, directed and published the books of The Transformed Architecture.

Continue with the full chapter

Read the full chapter online

Chapter 19: Observer, Stop Path and Evaluation Tools in Tools gives the detailed explanations, practical examples and implementation patterns behind this summary.

This whitepaper belongs to “Agents and Autonomy” and is one of 29 drawn from the manuscript.