Cites or escalates: designing a compliance-grade policy agent.

Why "ISO buddy" is the wrong brief

The tempting brief is a friendly chatbot that "knows our policies." That brief fails, predictably, in the same three places every time: it answers from general knowledge when your documents are silent, it phrases policy with a confidence the policy doesn't have, and it leaves no trail an auditor could inspect. In a GTM context, a wrong agent answer costs an opportunity. In compliance, a wrong answer creates a liability — and a single screenshot of an agent saying "that should be fine" is how the whole program gets switched off.

So the design target isn't a buddy. It's an agent under contract — what we call a policy brain. The contract has four clauses, and everything else in this article is the machinery that enforces them:

In AUX terms: the citations are Confidence Cues made structural, and the escalation path is a permanent Escape Hatch. The agent doesn't ask you to trust it — it shows its sources and keeps the door to a human open in every single turn. That is what makes it deployable in an organization that is, rightly, suspicious of agents.

The shape of the system

The architecture is the House of Agents pattern: a governed foundation at the bottom, deterministic answering brains above it, a router with hard gates, and — only later, only if earned — drafting machines. Everything lives in one version-controlled repository. (It's the same separation of concerns behind agent process design: declare the work, gate the actions, keep a named human who owns the outcome.)

Note what's dashed: in phase one, the machines layer ships empty. A read-only answering layer is a complete product — and for risk-averse organizations it's the right first agent precisely because it cannot act. Its telemetry becomes the evidence base for everything you build after it.

Convert the policies into a governed repo

Your policies were written for the certification audit, not for daily use. The first move is restructuring them into nine version-controlled markdown files — question-first headings, stable anchors for citation, YAML frontmatter declaring owner, version, review date, and the ISO clauses each file implements.

Two design notes that punch above their weight. First, exceptions.md is the file almost nobody has, and it does the most adoption work: every exception gets a requester, an approver, a risk note, and a mandatory expiry. A wall creates shadow IT; a door creates a register. Second, the repo itself satisfies clause 7.5 (document control) natively — every change is a reviewed PR, every version has an owner, and the changelog is git log. Your document control upgrades before any AI answers anything.

The conversion is agent labor — research agents draft the nine files from your existing documents and flag every contradiction they find. The approval is not: the compliance owner reviews every line before it enters main. The foundation is the one place where 100% AI output is never acceptable.

Write the risk gates before any brain ships

Some question classes never get a machine answer on the merits — regardless of what any brain could technically say. These gates are reviewed with legal and HR before launch, enforced by the router and mirrored by mechanical hooks:

A gated question still gets a useful response: the gate reason, the named human, and the SLA. The gate event is logged like any answer. Nobody hits a wall; everybody hits a door.

Build the brains as skills under contract

Each brain is a Claude skill: a SKILL.md declaring its allowed sources, its tasks, and its refusal behavior, plus a YAML manifest for governance. Eight brains map one-to-one(ish) onto the foundation files — Acceptable Use, Access, Data Handling, Incident, Third-Party, Exception, SoA/Audit, Scope. The contract core, from the highest-traffic brain:

You are a deterministic policy brain. You answer ONLY from:
- foundation/acceptable-use.md
- foundation/data-handling.md
- foundation/exceptions.md

You MUST:
1. Cite file#anchor (+ Annex A control where mapped) on every claim.
2. Check exceptions.md#active before any FORBIDDEN verdict — an
   active waiver changes the answer, and its ID must be cited.
3. On FORBIDDEN, always include the legitimate path.
4. If not answerable from sources, reply exactly:
   NOT COVERED → ask security@ (SLA: 4 business hours).
   Gap flagged for policy review.
5. NEVER assess risk, grant permission, or predict what the CISO
   "would probably say." You state policy; humans make exceptions.

The full question flow, end to end:

An employee leaves every interaction with one of exactly two things: a cited answer, or a named human and a deadline. Nothing else is acceptable output — and the eval suite enforces it.

Test it like software, with fixtures from real questions

"Deterministic" and "compliant" are claims. Test them. Fixtures aren't invented — they're drawn from the ticket history, so the suite measures readiness for the actual question distribution. This is where agent enablement earns its keep: the eval harness is the thing that turns "it seemed fine in the demo" into evidence. Four checks run in CI on every foundation change:

Open one front door, and measure

Adoption lives where questions already happen: a Slack DM bot (private by default — "is this an incident?" is a question people avoid asking publicly, which is exactly why incidents get reported late) and a public #ask-security channel whose answers compound into a searchable, cited FAQ. The Slack tool, like the repo host and ticketing, connects over MCP. Launch read-only, to one department, and watch four numbers:

The query log quietly becomes a compliance asset of its own: evidence of an operating awareness mechanism (clause 7.3), data-driven input for management review (9.3), and a continual-improvement loop with receipts (10.2). The surveillance audit gets shorter, not scarier.

Add drafting machines only if the telemetry earns them

After weeks of watching the brains cite, refuse, and escalate correctly, the organization is ready to climb one rung: stochastic drafting machines, bounded by the same brains, checked by a Critic, staged for human approval. Build from the log, not the catalog — if 30% of escalations are exception requests, the Exception Request Machine pays for itself first: it turns a blocked employee's situation into a complete waiver draft that the requester owns and submits. The machine never files anything. Drafting is agent labor; requesting is a human act.

This sequencing is the four-stage trust architecture in miniature: the read-only layer earns functional trust, the telemetry builds contextual trust, and only then do drafting machines ask for judgment trust — with the approval rate on their staged drafts as the north-star metric for whether they're earning it.

What to take away

Designing a compliance agent is not a retrieval problem; it's a contract problem. Closed world, citation, escalating refusal, no authority — enforced by architecture and hooks, tested like software, logged end to end. Start with the repo (your document control upgrades for free), gate the dangerous questions with legal and HR in the room, ship the read-only layer to one department, and let the telemetry tell you what to build next. It's the same lesson that runs through everything we publish: a safe agent isn't a trusted one — trust is earned, structurally, one cited answer at a time.

And one question to ask any vendor — including us: can your system pass our own vendor intake? Policy OS registers in your vendor register and SoA like any supplier. If an agent can't survive the process it answers questions about, it has no business answering them.

“Isn’t this just our service desk with extra steps?”

Fair questions we get from CISOs and IT leads. Direct answers.