## 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](how-it-works.html), 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](briefs.html).

**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](https://nhi.sgit.ai/hope/)
   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.*