Explicit Agent Boundaries

About this paper

Here is the thing I keep noticing, repository after repository, and I want to say it plainly: we enforce standards on the code and we enforce nothing on the files that now drive the agents. You have coding standards, a linter, a CI gate, a review process, and a branch-protection rule that will not let an ungoverned change to your source merge. Then you add a README, a CONTRIBUTING, an AGENTS.md, a folder of skills, and a pile of prompts — and a coding agent reads those Markdown files and changes your code because of what they say. Those files steer behavior, and almost nobody governs them at all.

The reframe this paper is built on is one sentence: if a Markdown file can change what an agent does, it is executable configuration, and it deserves the same governance as code — an owner, a review gate, and an explicit boundary. The paper defines the five-clause boundary contract: may-change, may-not-change, requires-approval, behavioral limits, and who owns the contract itself. It sets out the minimum operational documentation an agent needs before it can succeed at a basic task. And it names the meta-move that makes it stick — putting the agent-driving Markdown under the same CI governance as your code, so a change to AGENTS.md triggers review, runs the boundary check, and is attributable. You get a provider self-assessment you can run against a repo in an afternoon and a reference agent-boundaries.yml to start from.

What's inside

1. The Markdown became executable — and nobody changed the rules
2. The boundary contract — may-change, may-not-change, requires-approval, behavioral limits, ownership
3. The minimum agent operational documentation floor
4. Governing the agent-driving docs themselves
5. Golden path, not a gate
6. Anti-patterns worth watching for
7. Provider self-assessment
8. Where this is going — the context layer is the control plane

What you get for $25.00