# Three policies for an agent: what changed in v1.1.0, sgit.ai

> The changes to the article "Three policies for an agent" in v1.1.0, paragraph by paragraph.

*Source: <https://newsroom.sgit.ai/articles/versions/three-policies-for-an-agent/v1.1.0.html> · sgit.ai v0.7.87 · this file is generated from the same content as the page, so the two cannot drift. Every page on this site has a `.md` twin; internal links below point at them.*

---

[Home](../../../index.md) / [Articles](../../index.md) / [Three policies for an agent](../../three-policies-for-an-agent.md) / [Versions](../three-policies-for-an-agent.md) / v1.1.0

# Three policies for an agent: what changed in v1.1.0

From v1.0.0 (2026-10-17, `4c750bd9b`) to v1.1.0 (2026-10-18, `bb2978831`), paragraph by paragraph.

3 paragraphs added, 2 removed, 4 changed in place, 46 unchanged. About 169 words added and 115 removed. Insertions are marked like this, deletions like this; unchanged runs are folded to one line; figures appear as their file names.

[all versions](../three-policies-for-an-agent.md)

1 unchanged paragraph

Summary: When something goes wrong with an agent, the question people ask is how it made that decision. A behaviour policy cannot answer it on its own, because it says what an agent may do, not who chooses at a branch point or why. This is the first of four articles on what I think the answer looks like. There are three policies, not one. The Agent Behaviour Policy, the ABP we already publish, says what an agent may do and where. An Agent Decision Policy says, at a branch point, who chooses, on what evidence, within what limits, and who to call when it is out of bounds. An Agent Workflow Policy says which steps run in what order. They meet at fixed points: a workflow transition is gated by a decision, and the decision's outcome is carried out by behaviours the ABP permits. We have been putting light decisions into behaviour policies all along, and that is fine at low zoom: the ABP's approval cell is a small decision. Zoom into one cell and it becomes a decision policy and a workflow policy of its own. Every element of all three can be defined before it can be enforced: what gets enforced, and where, depends on what is wired up, so each element carries fourfive states, defined, implemented, enforcedenforced, observed and observed.verified. The word "decision" matters because it is the one the business and the risk team already use.

8 unchanged paragraphs, under In short {#in-short}

• **Defined is not enforced.** Each element is defined, implemented, enforcedenforced, observed and observed,verified, separately. The map can be complete before the wiring is.

21 unchanged paragraphs, under The question people ask {#question}, Three policies {#three}, Zoom into one cell {#zoom}…

The aim is to map all of it. Whether a given element can be enforced is a separate question, and the answer depends on what is wired up: the technology, the platform, whether there is a hook, a gateway or a test, and whether anyone can see what happened. So I would give every element four states, kept separately:

| State | The question | |---|---| | **Defined** | Is it written down, with an owner? | | **Implemented** | Does something exist that could carry it out? | | **Enforced** | Does something outside the agent stop it when it is broken? | | **Observed** | Would we know, afterwards, whether it held? |

The aim is to map all of it. Whether a given element can be enforced is a separate question, and the answer depends on what is wired up: the technology, the platform, whether there is a hook, a gateway or a test, and whether anyone can see what happened. So I would give every element five states, kept separately:

| State | The question | |---|---| | **Defined** | Is it written down, with an owner? | | **Implemented** | Does something exist that could carry it out? | | **Enforced** | Does something outside the agent stop it when it is broken? | | **Observed** | Can we reconstruct, afterwards, what happened? | | **Verified** | Can we prove, against records the agent did not write, that the outcome was right? |

Observed and verified are different, and the difference is the subject of Ashish Rajan's Northstar example, which [allowed is not right](../../allowed-is-not-right.md) answers: a complete log of a wrong refund is observed and not verified.

9 unchanged paragraphs, under Why "decision" {#why-decision}, What comes next {#next}

1. **Three policies for an agent.** This one. 2. **[Approve at altitude](../../approve-at-altitude.md).** How it scales: decisions at every altitude, from strategy to one agent's step, each level allowed to narrow the one above and never to widen it. 3. **[Case law for agents](../../case-law-for-agents.md).** The business will never predict every case. How English law handles that, with statutes, precedent and distinguishing, and what the same would look like for agents. 4. **[Three decisions, mapped](../../three-decisions-mapped.md).** An agent's memory, this newsroom's release and a customer refund, through all three policies, with each element's fourfive states.

3 unchanged paragraphs, under What this does not claim {#limits}

• **The fourfive states are a suggestion.** They are how I would map it; other cuts are possible.

4 unchanged paragraphs, under Where this comes from {#sources}

[all versions](../three-policies-for-an-agent.md)


---

*[Site index for agents](../../../llms.txt) · [HTML version](https://newsroom.sgit.ai/articles/versions/three-policies-for-an-agent/v1.1.0.html)*
