The Org Chart Is Code

Pull up the org chart at most companies. It's a slide.

Boxes and lines. Someone made it for the last board meeting. By now, two people on it have left, three people who should be on it aren't, and the reporting line in the middle is wrong because that team got reorganized in February. The CEO doesn't know the slide is wrong because nobody updates it. Nobody updates it because the slide isn't connected to anything that does work. It's a picture of how the company is supposed to be structured. The actual structure lives in heads, in Slack threads, in tribal knowledge that takes new hires six months to absorb.

The org that runs SpeyAI doesn't have a slide. It has a file.

The org chart is code. A file the system reads on every task. Change the file, change the company. Same morning.

Everything in this paper hangs off that trade, slide for file. The rest of it walks through what the file says, what each part of it does, and why a structure can hold more weight when it lives in a place that runs instead of a place that gets ignored.

Quick grounding before we start. SpeyAI runs its own company on the agent org it sells. The file described here isn't a diagram of an aspiration. It's the thing the company reads every time it routes a task, approves a change, or blocks a release. "Change the file, change the company" is meant the way you mean "change the thermostat, change the temperature."

Some roles see the whole company. Some see one workspace.

The first thing the file says about any role is what it can see.

Most roles see the whole org. They build the product. They review code. They run audits. They watch security. If you picture the corporate functions at any normal company, this is most of them.

A smaller set of roles is different. Each one runs inside a single customer workspace. It cannot see across workspaces. Even if a developer drops into a debug shell and asks one of those roles to read another workspace's data, the file says no, and the system enforces the no at the application layer and again at the database layer. Two walls, one rule.

The closest human analogy is a consultant on retainer who only ever sees one client's files. Corporate has access to everything; the retainer consultant has access to one folder. The difference here is that the boundary isn't a clause in an onboarding doc that someone might forget under deadline pressure. The boundary is the file. The role has no path to the other side of the wall, and no amount of asking nicely creates one.

That boundary gets its own paper in this library, The Wall Is Not a Sign, because "we take isolation seriously" and "the role has no path across" are two different claims, and only one of them survives an audit.

Teams own surfaces end to end

Underneath the visibility rule, the file groups the see-everything roles into teams, and each team owns one product surface end to end.

Own means own. If a customer experiences a problem with a surface, one team is accountable. Not a committee. Not a matrixed working group with a shared OKR and a rotating scribe. One team, one surface, one line in the file that says so.

This part isn't new. Spotify wrote the pattern down in 2014: squads own product areas vertically, while chapters and guilds carry disciplines horizontally across them (Spotify Engineering Culture, 2014). Half the tech industry copied the vocabulary and skipped the discipline. The agent org keeps the shape and changes the substrate. Spotify encoded the model in culture, which means it lived exactly as long as the people who believed in it. This file encodes it in code, which means it lives as long as the file, and the file is in version control.

So far, a fairly normal company. Teams, ownership, accountability. The unusual part comes next.

The reviewers who check instead of write

Most companies have a team that owns a surface. Most companies do not have a standing reviewer whose entire job is to audit every change to that surface and block the ones that open a hole.

The agent org has a bench of them. Senior reviewers who cut horizontally across every team. They don't write the work. They check it. Each one covers a discipline (security, architecture, testing, performance, and so on down the list you'd expect) and watches every team's output through that single lens.

The file gives each reviewer one of three levels of authority.

Some reviewers can stop a release outright. Full stop. If one of them flags a problem, the release does not ship, and there is no path around them.

Some can stop a release under specific, named conditions. A latency budget broken on a critical path. Test coverage dropped on a sensitive part of the codebase. Each grant is narrow on purpose. The reviewer isn't a gatekeeper for everything. They're the authority on one thing, written down.

The rest publish findings but can't block. They flag, they recommend, they document. What they produce is an audit trail, which makes ignoring them a recorded decision instead of a quiet one.

Every finding from every reviewer lands in a queryable list. So when a pattern shows up (security flagging the same class of issue across three teams, performance pushing back on the same team week after week), the pattern arrives as a number, not as a feeling somebody has at the offsite.

Why the writers and the checkers are different roles at all is the subject of No One Audits Themselves. The short version: the incentive to ship and the incentive to catch are different incentives, and the file refuses to house them in the same role.

Work routes through a classified path

The file also describes how work moves from "we should do this" to "it's live."

Three paths exist. A change to a customer-facing surface takes the full path: a spec gets written, the relevant reviewers read it, a builder implements, the reviewers check the result, a pull request opens, and the required checks have to pass before anything ships.

A lower-impact change takes a shorter path. Same skeleton, fewer reviewer stops, based on what the change actually touches.

The smallest changes (bug fixes, copy edits, documentation) take the shortest path. The checks still run. Then it ships.

Here's the part that matters: the path is not a choice. A rule classifies the change at the spec stage and routes it. And certain kinds of changes get promoted to the highest review tier no matter what anyone prefers or what the deadline says. Touch the code that decides who a user is, touch the workspace boundary, touch a database migration, and the change auto-promotes. The author doesn't opt into scrutiny. The classification is read from the diff.

The checks at the bottom are the same on every path. The build succeeds. The tests pass. The types check. And a small registry of structurally protected files has to be untouched, or the change is dead on arrival. That registry gets a full paper of its own, The Code the Build Won't Let You Touch.

The constitution is in code too

One layer up from the org chart sits a short set of principles. Each one is brief. Each one is load-bearing.

Most companies have principles too. They live on a wall. They get read aloud at offsites. New hires meet them in onboarding and forget them by week three. They're aspirational, which is a polite word for optional.

These principles aren't on a wall. They're in version control, next to the rest of the code. Changing one is a commit. The commit goes through the same review path as every other commit, with reviewers who can block it. The principles get amended the way laws get amended: deliberately, on the record, with a trail that says when and why and who approved.

That's the difference between a wish and a rule. A wish lives on a wall. A rule lives in the file the system reads every time it decides what to do.

The short version of what the principles say: no role audits its own work. No role skips the pipeline. Certain files can't be touched. The wall between workspaces is absolute. Every agent spends inside a cap, and one switch stops all of it (that one gets its own treatment in When the Agent Spends Money). And the human at the top approves authority but doesn't operate the work.

What this isn't

Not a chatbot. Chatbots answer questions. The reviewers in this file block releases.

Not a copilot. Copilots suggest code to a person who decides. The teams in this file own surfaces, and the reviewers veto their work when a rule breaks.

Not a generic agent framework. Frameworks are wiring kits. Useful, and neutral about everything that matters. The file, the principles, the routing rules, the protected registry, the audit trail, the spend caps, the kill switch: none of those are workflow steps. Together they're a company.

And none of it depends on whose model sits underneath or whose cloud it runs in. The org described in the file runs in your infrastructure, against whatever model you bring. The structure is the product. The model is an employee.

The closest comparison in the existing world isn't a piece of software at all. It's an org chart that runs. Roles, authorities, principles above them, every layer that can be written down, written down, in a form that reads as machine instructions instead of inspiration.

What changes when the org chart runs

A new reviewer role gets added. Not by an email announcement. By a change to the file that adds the role, defines its authority, and slots it into the routing rules. The change goes through the same review path as everything else. Reviewers can block it. If they don't, it ships, and the next morning the new role is reviewing work.

The same is true in reverse. A role gets removed. An authority gets narrowed. A team picks up a different surface. None of these are slide updates. They're commits.

Change the file, change the company.

At most companies, the gap between "we changed the org chart" and "the company changed" is measured in months. The slide gets updated. The directory gets updated. Some teams adopt the new structure; others keep operating like the old one out of habit and muscle memory. The behavior catches up to the picture eventually, or it doesn't, and nobody can tell which from looking at the slide.

When the org chart is code, the gap doesn't exist. The behavior is the picture. Change one and the other changes by definition, because they are the same artifact.

A concrete example. A new class of attack on AI products starts showing up in the wild. At a normal company, security writes a doc about it. The doc gets reviewed. The policy gets circulated. An all-hands mentions it. Two months later, half the teams have absorbed the policy and half haven't, and the next release from the wrong half ships vulnerable, because nobody on that team remembered a memo on a Friday afternoon.

At an org chart in code, the security reviewer's file gets a new rule. The change rides the same review path as every change, ships overnight, and the next morning every release pipeline runs the new rule against every diff. A release that trips the rule stops by itself. No memo. No all-hands. No two-month gap between learning the rule and enforcing it.

The rule and the enforcement are the same artifact, read at the same moment.

That's the move, and it's the same move this whole library keeps making. Trust scales with structure, not culture (that argument opens the series, in Trust Scales with Structure). The structure here is a file the system reads on every task, with a constitution in version control above it. Tomorrow morning's behavior is whatever tonight's commit says it is.

Your org chart is a slide. This one is code. The difference shows up in everything that follows.

The takeaway: When the org chart is a file the system reads on every task, the gap between writing down a structure and behaving that way collapses to zero. Roles, visibilities, authorities, routing rules, principles: all of it in code, all of it amendable through review, all of it inspectable on demand. The picture and the behavior are the same thing, which is the entire meaning of architecture as governance.

References

1. SpeyAI agent org architecture. Live reference at speyai.com. Role registry with visibility scoping, horizontal reviewers at three authority levels, classified release paths with auto-promotion, and a constitution amended through version control.

2. Spotify Engineering. (2014). Spotify Engineering Culture. The "tribes, squads, chapters, guilds" model separating product ownership (vertical accountability) from disciplines (horizontal expertise). The structural ancestor of the agent org's shape, encoded in culture where the agent org encodes it in code.

This paper is part of Rise of the Agent Org, a series by Ed Hoehn, SpeyAI. The full library is at speyai.com/record.