How it works, in the order it happens

A peer asked in a chat, what does this do? and then how does it technically work? The first has a one-line answer — we map the gap between what you want an agent to do and what it can actually do, so you can find ways to contain it. The second had a page called How it works↗, and the page did not answer it. It described an architecture from before the Agent Behaviour Policy existed: twins, a RiskGraph, engines, plug profiles, board briefings, an API. None of that is what is sold, and one line of it — twins instead of integrations — said the opposite of what the lead's memo of the same day says. Registered as D12↗.

Rebuilt in the memo's order, with the status of each step on the step. The technical insight is kept word for word, because it is still the best thing on the page: authorisation is whatever the agent can already do, so the work is shrinking it. Then six steps:

1. Start with a prompt — running, free. Thirteen prompts against the assistant you already run. First because being surprised by the reach is the shift, and the list is longer than the tile that sold it.
2. Notice that a prompt is hope — running, in every policy. Once somebody asks how to reduce it, asking the agent to behave is not a control; nhi.sgit.ai ↗ says it in four words, quoted and dated. Hence the four barriers, of which only the fourth bounds anything.
3. Fit the policy to the controls you actually have — per engagement, levels 3 and 4. What bounds an agent depends on the proxy, the egress rules, which accounts can be created, what corporate tooling prevents. And who holds each barrier: you, or a vendor who can move it in a release.
4. Integrate with whatever you have — sixteen shapes today, connectors per engagement. We read, never enforce. Connectors to a customer's own control planes are built per engagement and productised as they mature; none is a product yet and the page says so.
5. Connect it to the graph — standards running, the rest in design. Behaviours as nodes, edges to the EU AI Act, GDPR and ATT&CK nodes every vault already carries, and the same mechanism going upward to risks and the board and sideways to internal policies.
6. Keep it in a vault, because the vault is the provenance — running; execution logs in design. Every version, the record, the sign-off, and what voids it. Where this goes: the logs and the evidence beside the policy, in the same vault or yours.

What was removed and why. The architecture diagram naming things that do not exist, the no integration treadmill claim, and telemetry tests the map, which described a capability nobody has built. A page called How it works that names five products which do not exist is not an aspiration; it is the one page a technical reader would use to decide we are not serious.

The word rung does not appear on the rebuilt page. It still appears on forty-one others.

These notes were written before the release was cut and the release script replaced them with its stub; the stub shipped in the first commit of v1.32.0 and this text followed in the next.