In the last field note I argued that before a company can become AI-native, it has to become legible. This piece names the parts.

A legible organization is not a documented organization. The two are easy to confuse, and the confusion is expensive.

You can tell the difference by what happens when you ask a simple question. Who owns the renewal process for accounts under fifty seats? In a documented company, three people point you to three different Notion pages, two of which are nine months out of date and one of which describes a workflow that was abandoned after the last reorg. In a legible company, someone says: Priya owns it. Here's the mandate. Here's the policy and where the carve-outs live. Here's the last decision we made about it and why.

Both companies have answers. Only one of them has an answer an agent can use.

Documentation is not legibility

Some documentation is genuinely legible. Engineering runbooks that get executed weekly. API docs that have tests behind them. SOC 2 controls an auditor will check. The thing they share is that something — automation, customers, or regulators — keeps the document honest.

The documentation that goes stale is the documentation about how the company actually operates: how a renewal gets handled, who signs off on a refund, what the onboarding flow really looks like once the customer is large enough to negotiate. That documentation drifts the moment it's written, because nothing in the daily life of the company forces it to stay true. The wiki page exists. It describes a 2022 version of the process. The current team has a Slack channel where the real decisions get made, a Google Doc where the real real decisions get made, and an unwritten rule that you check with Marco before doing anything cross-functional, because Marco knows where the bodies are buried.

Marco is not a problem. Marco is the adaptive layer that has kept the company functioning while the documentation rotted. He is also the reason an agent, or a competent new hire, cannot work here without his help.

Put an agent in this environment and ask it to handle a renewal. It will read the wiki, follow the documented process, and produce something confident and wrong. Then someone will say agents aren't ready yet. The agent's failure here is not really an agent failure — it's the company quietly billing the agent for a cost it has been paying Marco to absorb for years.

What an actor actually needs

To act inside a company without asking around, any actor — human or agent — needs at least six things to be legible. These are the spine of the piece, and they show up in this order:

These are the smallest set that has to be readable before independent action is possible. Anything missing routes the actor back to a human, every time.

This is the schema I keep coming back to whenever I look at an organization through the question of what would have to be true for an agent to work here. It is also, not coincidentally, what would have to be true for a strong new hire to do their job in week two instead of month six.

Workflows

Workflows are the first part and the one most companies get most wrong. Not because they don't talk about how work gets done, but because they talk about it through the wrong vocabulary. Org charts describe roles. Job descriptions describe responsibilities. Quarterly plans describe initiatives. None of these describe the workflow itself — the actual end-to-end sequence the company performs to turn an input into a result, with named steps, triggers, owners, and outputs.

The illegible version sounds like: We have a Customer Success team that owns the post-sale relationship and drives expansion. That is a description of an organizational unit and its goal. It is not a workflow. The legible version names the workflow with its triggers and steps: When a customer crosses 80% of their seat allocation, we do X. When a contract enters its renewal window, we do Y. When a champion leaves the account, we do Z.

Naming a workflow this way is harder than it sounds, and the difficulty is rarely about clarity. It's about politics. A named workflow has a named owner, named steps, and named outputs — which means ownership someone is currently enjoying tacitly is suddenly subject to revision. That's the real reason most companies don't do it.

Mandates

In the previous note I called a mandate the atomic unit of accountability. It is smaller than a role and larger than a task. The point of that definition is that you can't make a role legible by writing a better job description. A role is a bundle, and the bundle is what has to be unpacked.

Inside the bundle, each mandate is a specific piece of work the organization will hold someone — or something — accountable for, with the authority and context that piece of work actually requires. Maintain the company canon. Choose article angles. Approve refunds under a threshold. Those are mandates. Head of Growth is a label glued to a stack of them.

In illegible companies, mandates and titles collapse into each other. Someone is "Head of Growth" and the rest is implied. In practice this means every Head of Growth in the company's history has done the job slightly differently, and the current one is rediscovering, by trial and error, where their authority actually ends. When something falls between two mandates, there is a quiet meeting to decide who picks it up, and the answer is recorded nowhere.

The legible version of a mandate reads as a few sentences about outcomes and edges: this role owns the metric, escalates above a threshold, does not own the channel even though the channel is upstream of the metric. Specific enough that two people in the role would do it the same way. And also specific enough that an agent assigned to a slice of it would know when to stop.

Smaller companies will resist this as bureaucracy creep. The point isn't to write JD-style essays for every role. It's to be able to answer, in three sentences, what each role is on the hook for without using its title. If you can't, the title is doing the work the mandate should do, and the title is doing it badly.

Canon

Canon is one of several types of artifact a company produces, and the most load-bearing one. Working drafts come and go. Reference material gets updated as the world changes. Records describe what happened on a given day. Canon describes what the company has decided is true and is not going to re-decide on a whim.

Voice. Customer. Approved claims and forbidden ones. Pricing posture. Competitors it positions against and the ones it ignores. The product names that changed last quarter. The legal carve-outs that govern what the company can promise. Canon governs far more than content. Engineers make canonical claims in error messages, sales reps make them in pricing conversations, and recruiters make them in offer letters. Every output the company produces is sitting on top of this layer whether it knows it or not.

Canon is the most common silent failure in modern companies, because it lives almost entirely in the heads of the founders and the first ten employees. It gets transmitted by osmosis to the next ten, garbled to the next fifty, and by employee two hundred there are functionally three different companies operating under one name, each with its own folk version of the canon.

The illegible version of canon is "we just know." The legible version is a small set of artifacts. This can be a voice guide that has actual examples in it, a written ICP, a list of things this company doesn't do that any new actor can read and align to without booking time on the founder's calendar. The test is whether someone could write a piece of customer-facing copy on day three and have it be recognizable as the company's. In most companies the honest answer is no, and the workaround is that nothing customer-facing ships without going through the same two people, forever.

Permissions

Mandates describe what someone is supposed to do. Permissions describe what the systems will let them do. The gap between the two is where illegibility lives.

In a legible company, permissions are explicit, granular, and enforced where the work actually happens — in the CRM, in the billing system, in the deploy pipeline. In an illegible company, permissions are a pile of shared logins, generous defaults nobody has audited since onboarding, and a Slack channel called #approvals where senior people emoji-react to things.

Most companies underestimate how much of their daily operation runs on permissions that aren't, technically, permissions. They are habits. Refunds over five hundred dollars always go through Jess because Jess used to be in support and never lost the instinct. Nobody has written this down. Nobody has audited it. When Jess leaves, the refund queue quietly gets worse for six weeks and nobody can name why.

An agent does not have habits. It has access.

If you have not written down who is allowed to do what, you have a folk tradition, and the agent will not respect it.

Policies

Policies are the standing rules that back permissions and gate workflows. Refunds over five hundred dollars require manager approval. Customer data leaves the EU only through these two routes. Production deploys require a passing test suite and a second pair of eyes. Without policy, permissions are arbitrary and workflows are improvised. With it, the system has a backbone.

The part of policy most companies miss isn't the rule itself. It's the carve-outs. The rule gets written down. The exceptions do not. The exceptions live in the head of whoever is senior enough to grant them, and the rest of the org learns them by watching what happens when the rule is followed and somebody gets unhappy.

This is where agent work fails most expensively, because agents follow the rule. They do not know that the enterprise renewal process has a different path for the three accounts the CEO personally sold. They do not know that the refund policy is suspended in December. They do not know that the standard onboarding flow gets a custom variant for any customer over a certain ARR. The rule is in the wiki. The carve-outs are in someone's memory.

A legible policy names both: here is the rule, here are the conditions under which it does not apply, here is who is allowed to invoke an exception, here is where invocations are recorded. It is not glamorous. It is the difference between an agent that handles the renewal and an agent that has to be checked.

When this is in place, the work changes shape. The agent receives a renewal, reads the mandate that says it owns renewals under a threshold, checks the policy and finds the carve-out list, sees that this particular account is on it, routes the work to a human, logs the routing, and moves on. None of that requires a smarter model. All of it requires a company that has written down what it actually does.

Records

Most companies record outcomes — the slide that says we are going to do X. Few of them record the trail behind the slide: who decided, what alternatives were considered, what was rejected and why, what would cause us to revisit. Decision records are the most common missing records, but not the only one. Incident write-ups, post-mortems, vendor evaluations, customer escalations — all the same shape: a dated entry that explains how the present got to be the way it is.

The cost of not keeping this trail is that it gets reconstructed badly, in real time, by whoever asks the obvious question next. Six months later, someone joins, asks why a particular tool is in the stack, and the room either patiently re-explains the original reasoning or quietly re-opens the question. Both are expensive; the second is worse. A company without records is a company that re-decides its own past, and the cost shows up as meeting hours that look like work.

The legible version is unglamorous. A short record per non-trivial decision: what was decided, what was considered, what was rejected, what would change our mind. Boring. Cheap to do once, less cheap to maintain — which is the actual reason most companies skip it. But the maintenance cost is paid in minutes. The cost of skipping it is paid in meetings.

Records and canon are easy to confuse, and the distinction is worth making. Canon is what the company believes is true now. Records are how it got there. Canon is the destination; records are the road. An agent acting on canon needs to know what's settled. An agent reasoning about a tricky situation often needs the records to know whether something is settled because it was actually decided, or because no one has ever asked.

Why the failure mode is silent

The reason most companies are illegible without noticing is that humans route around illegibility for free. We use context, favors, memory, and the fact that we sit next to each other. The company runs. It runs on a layer of relationships and tribal knowledge that nobody costed because nobody had to.

Agents cannot use this layer. Neither can new hires, which is why onboarding takes the time it does and why people start being useful around the same month they stop being new. The cost of illegibility was always being paid; it was paid in onboarding time, in re-litigated decisions, in Marco's calendar, in the fraction of the company's brainpower permanently allocated to figuring out who to ask.

Agents make the bill visible because they bring the cost forward to day one and present it as a failure of the agent.

It is not a failure of the agent. It is a bill that was already due.

A diagnostic

Three questions a reader can ask their own company. These three are where the rot is densest.

  1. Pick a role on the team. Can you write its mandate in three sentences without using its title?

    If you can't, the mandate doesn't exist; the title is doing its job badly.

  2. Name a non-trivial decision your company made this quarter. Can you find the reasoning, the alternatives that were considered, and the conditions under which it would be revisited?

    If you can't, the record doesn't exist, and the decision will be re-opened — probably soon, probably by someone new.

  3. Pick a policy your company follows — a refund threshold, an approval rule, an onboarding standard. Now name the carve-outs. Who is allowed to invoke them. Where invocations are recorded.

    If the answer to any of those is "we just know," the policy is illegible and the carve-outs are a liability.

If you can only fix one of the six layers, fix Policies. Not because policies are more important than mandates or canon — they aren't. Because Policies is where the gap between what your company says and what your company does is most concentrated. The rule is written. The carve-outs aren't. That gap is the first one that breaks agent work, and closing it makes every other layer cheaper to legibilize.

Close

Bureaucracy is the company describing itself as it was supposed to be. Legibility is the company describing itself as it is. The first is for compliance. The second is for action.

You cannot automate work you have not named.