You've signed it. You haven't read it. Neither has anyone else. And somehow this counts as a control.
The acceptable use policy. The information security policy. The clean desk policy. The bring-your-own-device policy. Most organisations accumulate these the way attics accumulate boxes — one at a time, each for a reason that made sense at the time, until the sheer volume makes the contents unknowable. The library grows. The understanding doesn't.
A policy nobody reads isn't a policy. It's a liability with a signature on it.
The Volume Problem
Policy libraries got this large for a reason, and the reason wasn't incompetence.
Every policy in your library was written to solve something. A regulator asked for evidence of a control. An auditor flagged a gap. An incident happened and someone decided it needed a documented response. One by one, documents accumulated — each defensible in isolation, collectively unmanageable.
What nobody questioned was who the documents were actually for.
The answer, increasingly, was auditors. Not the people the policies were supposed to govern, but the people reviewing them once a year. And once you're writing for auditors rather than for employees, something shifts. Length starts to signal seriousness. Comprehensiveness starts to feel like rigour. Edge cases get documented because an auditor might ask about them, not because anyone expects them to arise. The policy stops being a tool for orienting behaviour and becomes a tool for demonstrating that someone thought about the problem.
The result is documents that are too long to be read, too abstract to be followed, and too disconnected from real work to be useful. Policies written for a hypothetical audit rather than an actual human trying to make a decision. The acknowledgment gets clicked. The understanding never arrives.
The part that doesn't get said aloud: most people inside these organisations know it. They know they couldn't explain their own information security policy. They know the clean desk procedure doesn't reflect how anyone actually works. They maintain the system because that's what compliance looks like, or so they've been told.
Two Kinds of Policy, Two Different Fates
Not all policies are the same problem, and the solution isn't the same for all of them.
Some policies govern systems and processes — how access requests are handled, how incidents are triaged, how new starters get provisioned. For these, the document was always a proxy for something else: a description of how the process actually works. And if an agent is now running that process, the proxy is redundant. The agent behaviour is the policy. Observable, queryable, always current. An auditor who wants to understand the joiner-mover-leaver process doesn't need a document describing it — they can watch it work, or ask the agent directly.
This is the principle from The Process vs. Trust Paradox: document the why, not the what. In an agent-driven architecture, even the why doesn't need to live in a separate document. It can be embedded in the process itself, surfaced on request, visible in the reasoning the agent applies. The procedural policy doesn't just get shorter — it disappears, replaced by something more honest and more useful.
The second kind is harder. Policies that govern people — their behaviour, their judgement, their decisions in situations no process can fully anticipate — can't be replaced by agent behaviour alone. You can't instrument human intent. People need a reference point before an incident tests them, not a document to consult after the fact.
But the same principle applies: document the why, not the what. What actually orients people isn't a ten-page policy. It's a clear statement of why this matters, what the organisation values here, and what good judgement looks like in this domain. The rest — the edge cases, the procedural detail, the exhaustive definitions — exists for the auditor, not for the person the policy is supposed to help.
Strip that away, and what you need is short. One page, at most. Specific enough to orient. Brief enough to be read.
That brief intent statement can then be fed directly to the relevant agent as context. The agent operationalises it — surfacing the relevant guidance when someone faces a real decision, applying the intent rather than just describing it. The document becomes a values brief. The agent becomes the policy in practice.
What's Left
After this compression, what remains is small. Not because corners have been cut, but because most of what existed was serving the wrong purpose.
For each domain where human judgement genuinely matters — data handling, acceptable use, risk appetite, incident escalation — you have a single short document. It answers three questions: why does this matter for us specifically, what does good judgement look like here, and what are the boundaries that aren't negotiable. Everything else is either embedded in agent behaviour or simply unnecessary.
This is the minimum viable policy set. The word "minimum" here isn't about doing less — it's about being honest about what a policy can actually accomplish. A document that's too long to read accomplishes nothing. A document that's short enough to internalise accomplishes everything a policy is supposed to.
The auditor relationship changes too. Instead of presenting a library of documents and hoping the relevant sections get read, you're presenting a small set of clear intent statements and a system whose behaviour can be queried directly. The question shifts from "can you demonstrate you have a policy?" to "can you demonstrate the policy is real?" One of these is a documentation exercise. The other is a conversation about how the organisation actually works.
Brevity in a policy isn't laziness — it's a signal of confidence. A long policy is often evidence that the author didn't trust the reader to exercise judgement. A short one is evidence that they did. The minimum viable policy set is, among other things, an expression of what kind of organisation you're trying to be.
We're still working this out — how brief is brief enough, which domains genuinely need a human-facing document and which don't, how intent statements evolve as the organisation changes. The architecture is clear. The details are still being lived.
But the direction is right. Most policy libraries are large because nobody ever asked what they were actually for. Ask the question, and the answer is much smaller than the library suggests.