# Context Is Not Permission

> How context, ownership, and authority became part of the workflow around an AI agent.

Canonical: https://vdigital.design/thoughts/context-is-not-permission
Published: 2026-09-02T00:00:00.000Z

![](https://assets.basehub.com/42eacfbf/342d7d92635649283b2a0e09b79025d7/context-is-not-permission-onishchenko.png)

For a while, my AI-assisted workflow worked because I was the integration layer. I knew which document was current, which decision was provisional, and which approved plan was not yet authorized for implementation.

Documentation, code, and product decisions already existed. What did not exist was a system that connected them without relying on my memory. As the product grew, that coordination stopped fitting in my head.

I worked this out while building a solo vocabulary-learning product. The details are specific; the failure mode is not. There was plenty of context. What was missing was a reliable way to tell which context was current, who owned it, what state it described, and what it authorized.

When the foundation stops holding, my response is usually the same: make the system explicit. With an AI agent in the delivery loop, that meant making context, ownership, lifecycle, and authority explicit too. The problem had shifted from prompting the agent to designing the environment around it.

## A workflow cannot depend on one person’s memory

![](https://assets.basehub.com/42eacfbf/8a5d6045fb6a239d5b3d55340a2c9c40/context-is-not-permission-visual-01.svg)

The early setup worked because I could translate between design intent, documentation, and implementation myself. When AI proposed a change, I could usually see the missing assumption because most of the product model still lived in my head.

The first crack appeared in a simple learner status. One vocabulary record was carrying identity, a specific meaning, participation, progression, scheduling, and evidence. The product could mark a whole word as “learned” even when the learner knew only one meaning, and it could not distinguish prior knowledge from learning verified after a delay.

That was not a prompt problem. The domain itself was underspecified.

As changes began crossing the interface, learning logic, authentication, content, data, and analytics, “implement this correctly” stopped meaning anything without explicit ownership and dependency boundaries. I added those boundaries to the codebase so I was no longer the only layer that knew what could depend on what. The workflow needed the same treatment.

## More context became a second problem

![](https://assets.basehub.com/42eacfbf/de03174d95e9641d77404d9e048c64fa/context-is-not-permission-visual-02.svg)

My first response to growing complexity was more documentation. That was the right response, until it was not.

`docs/project-setup.md` eventually reached **2,854 lines**. It was meant to be the one place an agent could open and understand the whole project. Instead, it moved the ambiguity. The question was no longer “where is the information?” It became “which part is current, who owns it, and does it describe shipped behavior, historical reasoning, or a future plan?”

I replaced the monolith with a short index, focused setup contracts, and separate history.

The design-system document followed the same arc. It reached **1,842 lines** after absorbing motion, PWA behavior, interaction rules, Practice patterns, and implementation guidance. It still contained useful knowledge, but it was no longer one contract that a human or an agent could review properly.

I split it by ownership: foundations, motion and feedback, reusable components, product patterns, and separate implementation owners for the runtime-specific behavior. Living contracts received line budgets, not because line 401 is dangerous, but because document growth is a useful signal that one owner may be absorbing facts that belong elsewhere.

The documentation system then gained explicit lifecycles:

* living contracts describe the current state;

* approved specs freeze instead of growing indefinitely;

* history remains history;

* status records preserve what a particular delivery slice actually shipped;

* approved-but-unimplemented architecture stays visibly separate from current behavior.

That structure did not come from a best-practice checklist. It came from contradictions.

In one case, two reviewers gave opposite but reasonable advice about the same roadmap text: preserve Completed as historical evidence, or correct it as stale current documentation. The document had no declared lifecycle.

A more revealing case appeared during a design-system cleanup. The sentence motion should feel interruptible sounded like a strong principle and nearly moved into the canonical motion contract, but the shipped interaction deliberately held a transition lock until the spatial movement finished. The code and the existing owning contracts agreed; the elegant sentence did not. A good rule had become the wrong product.

That changed how I thought about documentation. A document does not become true because it is well written, stored in the repository, or reviewed by a model. It still has to agree with its owner, the runtime, and its lifecycle.

More context had helped. Then the amount of context became part of the problem. What the project needed was knowledge architecture.

That first restructuring fixed the largest document monoliths, but the root agent context was still acting like a policy warehouse. An earlier governance reset had cut `AGENTS.md` to **347 lines**; a few later edits brought it to **350** by the time I revisited the root agent context. I removed duplicated design context, turned project setup into a link-only index, gave documentation governance one owner, and reduced the root file to **91 lines**.

The smaller file was not the point by itself. I tested six representative tasks from fresh contexts. The agent reached the correct owner every time: no missing or incorrect routes, and no more than one hop from root. The root had stopped being a compressed knowledge base and become a router.

That architecture has a cost too: more owners, more routing, more links, and more maintenance. One fact, one owner does not remove the work. It makes the work visible.

Splitting the documents raised a further question: which system should hold what. Product reasoning, research, and decisions change through discussion and rarely have one correct answer at the moment they are written. Current behavior changes through code and is verifiable at any commit. Keeping both in the same store meant a decision and a shipped behavior looked equally authoritative to an agent reading either one.\
\
So I separated them:

* [Superhuman Docs](https://superhuman.com/docs) (formerly Coda) holds product intent, reasoning, and decisions;

* [GitHub](https://github.com/) holds current executable truth. When the two disagree, that disagreement is drift to be named rather than a signal to quietly pick the better-written version.

## A correct document is not permission

![](https://assets.basehub.com/42eacfbf/a9d55ef192185273a721fd1f770ba9ce/context-is-not-permission-visual-03.svg)

That ownership model looked much clearer, but it was still incomplete.

The repository contains an approved target architecture for a future domain rebuild. It is current, canonical, and owned. It can guide planning and decomposition.

It explicitly does not authorize changes to application code, the database schema, or migrations; implementation requires a separately authorized slice.

The document was correct, current, and canonical, and it still was not permission.

This matters more when the reader is an agent. A human may infer “approved direction, not yet scheduled”. An agent sees a detailed implementation-ready specification unless the authority boundary is explicit.

Adding more context does not solve that problem. The missing thing is not knowledge. It is permission.

I started separating four layers:

1. **Product intent** — what should change and why.

2. **Current executable truth** — how the system works now.

3. **Approved target** — where the system is meant to go.

4. **Implementation authority** — what this delivery slice is allowed to change.

That distinction became a decision-alignment preflight. Before substantial domain, data, target-architecture, or roadmap work, the agent has to compare the product decision source with the current repository, name conflicts, anchor the review to the relevant main commit, and identify the authorization state separately.

The first version was too strict. A conflict blocked even the documentation work needed to resolve the conflict. The guardrail had created a deadlock.

I did not solve it with another prompt exception. I redesigned the boundary. A fresh-main, documentation-only resolution pull request can align the owners. Implementation remains blocked until the preflight is run again and the slice receives explicit authorization.

Making those boundaries explicit did not reduce the agent’s room to work. It gave the agent more room to execute without silently turning an approved direction into permission.

A source of truth answers **what should be treated as correct**; a source of authority answers **what action is allowed now**. An agent needs both.

![](https://assets.basehub.com/42eacfbf/82808774d2357305d0707a7c3190b768/context-is-not-permission-visual-04.svg)

I developed this model in a solo project, where ownership is easier to change and authority ultimately sits with one person. In a team, the same distinction would need shared owners, explicit change rights, and language simple enough for people other than the author to use. This is evidence of how I work, not a universal operating standard.

**Context can explain the work. It cannot grant permission to do it.**