The Organisation as Code

Co-authored by Chris Barlow & Claude

Any organisation can be run the way good software is built. You write the work down, you have a program check it, you keep every change and you let AI help build the rest, and you do it one workflow at a time.

The work is in people's heads

Try this in a large organisation. Ask someone how a solution design gets approved, or how a new hire gets from "we need someone" to "they start Monday". You'll get an answer, and if you ask a couple more people you'll get a couple more answers that don't quite agree with each other. What you won't get, when you ask where it's written down, is a process. In my experience you get a template and a folder of old examples, and someone tells you the name of the person who really knows.

That's how most organisations run. The work gets done, and quite often it gets done well, but the knowledge of how it gets done is in people's heads. What's actually written down is the output, a Word document or a slide deck or an email thread with "approved" somewhere near the bottom, and the process that produced it never gets written down at all.

The cost shows up in a few places. Nobody can tell you how long a design takes to approve, or which step is the slow one, because the start and the end were never recorded as events anywhere. You'll find two people running the same process differently and neither of them is wrong, because there's nothing for them to be wrong against. When one of them leaves, their version of the process goes out the door with them. And when the organisation decides it wants to "use AI", it discovers there's nothing for the AI to get hold of. The data is sitting inside Word documents, and the rules and steps were never written down.

Over the past few months I've built three tools with AI to test a different way of running things. Iris maps an organisation. Gantry runs a document workflow (solution designs, in my case). Unsorry is the odd one out. It let a swarm of agents loose on mathematical proofs with nobody in charge, and it went from four proofs to five hundred in ten days. This essay is what the three of them taught me, including where they fall short.

I'm not claiming any of the ideas are new. People who do process mapping have been saying most of this for years. What's changed is that an agent can now pick the work up the moment it's written down, so writing it down pays off straight away, where it used to pay off slowly if at all.

I do think this applies to any organisation, since it doesn't really depend on the sector so much as on the shape of the work, and the shape I have in mind is work that produces documents, gets repeated, and needs somebody's sign-off. I've ended up with seven principles. The first three make the work checkable, the next two make it governable and measurable, and the last two are about scaling it and keeping it alive. The passages marked "In practice" are for the engineers, though the first principle has nothing to do with software at all.

Principle one: make the work explicit

Before you can automate a piece of work, or measure it, or hand it to anyone else, somebody has to write it down, and by that I don't mean the documents the work produces but the work itself. What are the steps, what does each step need before it can start and what does it produce, who decides that it's done, and what depends on what.

Business process mapping and value stream mapping have been doing this for decades. If you've ever run a mapping workshop you'll know the moment when a room full of people realises they've been describing four different processes under the same name. That map is worth having even if you never automate anything, because more often than not it's the first time the organisation has actually looked at its own work.

It's also the first job I'd give an AI partner. A model makes a patient facilitator, since it will ask the questions, put up a straw man and reconcile the contradictions, and it doesn't get bored the way a person running their fourth workshop does. I'd happily let it do the drawing, as long as it's understood that the people who do the work are the ones who own the map.

The maps I've found most useful also show the relationships, so you can see which systems support which capabilities, which team owns a given process, and which processes would break if a system changed.

In practice. Iris is the tool I built to hold this kind of map. It models systems, capabilities, processes, actors and the relationships between them in ArchiMate (a standard notation for how those things fit together), and every diagram is a view of the underlying data. I built it because I was tired of "what depends on this system" being a question that needed a meeting to answer, and now you put the question to the model and get a list back. Everything else in this essay is built on top of that map.

Principle two: separate structure from content

Now look at what each step produces. Almost always it's a document, and almost always that document mixes two different things: the structure of what has to be said, and the content of what's being said this time.

Take a solution design. It has a section for the business driver, one for the affected domains, one for the security controls, and so on, and while the structure of that is the same every time, the content is different every time. The trouble is that both live in the same Word file, so the structure isn't really data. If you want to know which designs have no security controls filled in, you have to open each one and look.

So the second principle is to pull the two apart. The structure becomes a definition: which fields exist, which are required at which stage, and what guidance the author gets. The content becomes plain text written against that definition. The document people are used to reading gets rendered from the two whenever someone wants it.

That's what makes everything else in this essay possible, and the nice thing is that the people doing the work don't have to change what they produce. They still get their Word document, it's just that underneath it the data can now be addressed. AI is good at the extraction as well. Give it a pile of past designs and the reviewers' comments on them and it will draft you the definition.

For the structure I use YAML, which is a plain-text format for labelled fields, and for the content I use markdown. Both go under version control, so every change is a saved, named step.

In practice. Gantry does this for the solution design process at MSD, New Zealand's Ministry of Social Development. It began in August 2026 with the ministry's actual Word templates and a set of approved designs. The AI partner and I went through them heading by heading, and the first-cut definition, four stages and fourteen sections, was committed the next day.

Four weeks and some 450 commits later it was a working engine with over 1,000 tests. In Gantry's README I describe the document as a view and the data as the thing, and that's how it's built: a definition in YAML declares the stages, gates, sections and documents, an instance is a folder of markdown files with one per section, and the rendered documents come out of a template on demand.

Solution design is the only workflow I've codified so far, but recruitment, procurement business cases, privacy and security assessments, policy changes, post-incident reviews and board papers are all the same shape, so I don't expect them to be very different.

Principle three: gate deterministically

Once the structure and the content are separate, the definition can say what "done" means for each stage and a program can check it, whether the required fields are filled in, whether the content parses, and so on. Those are yes or no questions, and I'd much rather a program answered them than rely on a reviewer's eye.

I should define "as code" here, since I lean on it from now on. For me something is as code when it's written down as explicit text, when its changes are versioned and reviewed, and when a program can check it. Where it's stored is secondary, so a rule in a YAML file counts and so does a rule in a database table, and the thing I'm ruling out is a rule that only exists in somebody's judgement.

I want to be clear about one thing here because I come back to it later. Whatever else changes, the gate itself must never be a language model. It needs to be an ordinary program that checks the same things in the same way every single time.

A deterministic gate checks what it was written to check and nothing more. The first version of Gantry's gate checks that required fields are non-empty, so if someone types "TBD" into a required field the gate is perfectly happy. I know that's a hole, and I don't have a clever answer to it other than that the gate is only ever as good as its rules, and tightening them as we go is part of the work.

In practice. Gantry runs its gate before a stage can advance. Unsorry, which I'll come to, works in Lean, a language for writing mathematical proofs so that a small trusted program called the kernel can check every step. A proof either gets past the kernel or it doesn't, and there's no partial credit.

Principle four: govern through versioned change and review

Now that the structure is data and the content is text, every change to either one is a diff, a line-by-line record of what changed.

Every change is a commit, that is a saved and named step, and every sign-off is a review of a proposed change, recorded against the exact content being approved, which gets invalidated if that content changes afterwards. So the history of who changed what, when, and who approved it can't be edited later without leaving a trace.

I've been calling this minimum viable governance. You get a history, you get a review and you get a gate, and that's about it, and the reason it's trustworthy is that nobody can quietly alter the record afterwards. What it does for the reviewer is take the box-ticking off their plate so they can spend their time on the part that actually needs a person, which is whether this is a good design, or a fair decision, or the right candidate. I've no problem with AI reading it first and flagging things for them. I do have a problem with it doing the approving.

We do this with pull requests. A pull request bundles up what changed, the conversation about it and the decision, and every mature code-hosting platform gives you them for nothing. There's one thing I'd warn you about from experience, which is that if the content can still change after you've approved it and your tick is left standing, then you haven't really approved anything at all. Gantry had to enforce this itself because the hosting platform didn't.

The other caveat is that a review only governs what actually flows through it. Gantry's pull request sign-off exists in only one of its three storage modes, so work saved through the other two doesn't pass through it, and that means the process is really only as governed as the least governed way through it. My advice would be to give the work a single path and close the others.

In practice. In Gantry's git-backed mode, each stage of a design lives on its own branch, a working copy that can change without touching the approved version. Saving is a commit. When the gate passes, Gantry opens a pull request, reads the reviewers' votes and merges on approval. Iris versions its model in the database instead, with a hash-chained audit log where any alteration breaks the chain, though who may alter it is not yet enforced. Both count as code by my definition, but it's only the git-backed one that gets a pull request without any extra work.

Principle five: measure from the history

Once the work is running through versioned change and review, the measurement falls out of the history without anyone having to collect it. Cycle time is the gap between the first commit on a stage and the merge, review latency is how long a pull request sat open before someone approved it, rework is how many times the gate failed before it passed, and if you want to know which reviewer everything is waiting on, that's in there as well.

I like these metrics because nobody had to fill in a timesheet to produce them. They come from events that had to happen anyway for the work to go ahead, so they're hard to fudge. Somebody still has to look at the numbers and decide what to do about them, but that's a much better use of a manager's time than gathering them in the first place.

In practice. Unsorry already does this, at the level of the swarm. Every run records its claim attempts, collisions, merge rate and gate failures against a written schema, and the leaderboard is regenerated from the repository's history on every merge. Gantry and Iris measure themselves but not yet the process they run. The history is all there, the queries just haven't been written, and that's an afternoon's work with an agent.

AI as a partner, and where it stops

Before the last two principles, it's worth saying where AI sits in all this. "AI-native" gets used loosely, so I'll say what I mean by it for these three tools, and there are three parts to it.

The first is simply that AI built them, and I don't mean that I dictated and it typed. It was involved in the domain mapping, it pushed back on design choices, it wrote the code and the tests, and it drafted the decision records and then reviewed the changes. Iris ended up with more than 200 architecture decision records in four and a half months, most of them written in conversation with the model that then went on to implement them.

The second is that the tools were designed from the first commit to be driven by agents. Gantry keeps everything in markdown, YAML and git, which are the formats an agent reads and writes best, and every command returns structured output. Every section of a definition carries its purpose, fields and guidance in machine-readable form, so an agent pointed at an instance already knows what it's supposed to write, and in effect the specification does the job of the prompt. Each section is its own file, so several agents can work on one design at once, and each section carries a status (draft, review or agreed) so the gate can tell what an agent drafted from what a person has accepted.

Iris is further along. Every capability is exposed in the web application, on the command line and to agents through a Model Context Protocol server (the standard doorway agents use to reach a tool), and an automated check fails the build if the three drift apart. An agent can describe a diagram in prose and have Iris materialise it deterministically, and the prompts it uses are data in the model, editable like any other field.

The third thing is that none of what the AI builds or drives is checked by AI. The gate, the validation, the render, the merge rules and the audit chain are all ordinary programs, so the model is involved in pretty much everything except the check itself, and anything it produces is treated as a proposal until a program has confirmed it. Gantry's engine has no language model in it at all, which is why I'm comfortable letting a model drive it. Unsorry's contract puts it as "the judge is nobody", meaning nothing a model says is trusted until the kernel has checked it.

So all three follow the same shape, where a person kicks it off, the agent does the work in the middle, and whatever comes out has to get past a check that a person chose, which is a reviewer's vote in Gantry and the kernel in Unsorry.

In practice. A colleague had a design that needed to get through the architecture committee within days, and nothing had been written against the definition yet. I asked him to collate everything that existed on it, which came to eleven documents, into a folder beside a new instance of the design definition.

Then we fired up an agent with a copy of Gantry, pointed it at the folder, and asked it to draft the first two stages and put anything it couldn't settle in the open questions section. Fifteen minutes later the solution outline and the high-level design were rendered out to Word documents in the committee's format. The collating had actually taken longer than the drafting did, which is worth noting, because collating is the principle one work and the model can't do that part for you.

What I'd show anyone is the open questions section. There were twenty-eight of them, each with the role that has to answer it and the point by which it has to be answered, and what pleased me was that where the agent couldn't settle something it raised it as a question for whoever was accountable, instead of guessing and moving on.

Principle six: distribute the work

Once the work is explicit, structured, gated and versioned you can hand it out, and it doesn't much matter whether a person or an agent picks it up. We use the repository for this, the same versioned folder the work already lives in, so a work package is just a file, you claim it by committing, you deliver it by opening a pull request, and the gate decides whether it's accepted, with the history keeping a record of who did what along the way.

Ten days in June

Unsorry began on 10 June 2026 with one question put to a newly released model. What's the hardest problem that would benefit humanity, can be worked on asynchronously, verifies itself, compounds, and needs almost no infrastructure? The answer was formal mathematics in Lean. The instruction was "build version one, don't stop until it ships", and it shipped about seven hours later.

It's a swarm of autonomous agents that turn unproven statements, marked sorry, into proofs the kernel accepts. The repository doubles as the work queue: each unproven goal is a file, an agent claims one by committing to a shared branch, the proof comes back as a pull request, and two deterministic gates decide whether it merges.

By day ten the repository had 1,322 merged pull requests and over 3,000 commits on its main line. By the time the June burst ended it held around 17,000 commits, roughly 6,000 merged pull requests and 4,755 kernel-verified proofs. Nearly two thirds of those commits were made by the repository's own automation, refreshing boards, recomputing the leaderboard and retiring archives, which is housekeeping the swarm did for itself. None of the nine contributors were onboarded or trained in any formal sense. They were given access to the repository and they started an agent.

The number I care about is the merged pull requests, because each one of those is a piece of knowledge work that was put up, picked up, finished, checked and logged without anybody managing it. There was no project manager and there were no status meetings. Most of the proofs were actually closed by a deterministic solver rather than a language model, whose runs succeeded less than one time in ten, and that was the design, since the kernel checks every proof the same way whoever or whatever wrote it.

Why a repository scales

A repository has no central bottleneck. Every worker holds a full copy, so a hundred agents aren't queuing behind one server, and because contributions land as independent pull requests, each checked by its own gate on its own machine, throughput grows with the number of machines you've got rather than with how patient your reviewer is. To join you clone it, and access control, history and review all come from the hosting platform, where a free account will do to start with.

Compare that with how it's usually done, where you have a ticketing system, a manager handing out items, a status meeting and a review queue that gets longer as the team grows, and every one of those is somewhere you're paying for scale in coordination. The repository doesn't get rid of the coordination, but most of it happens as a side effect of doing the work, and that's as true for people as it is for agents. A contractor or a partner organisation joins the same way Unsorry's ninth contributor did.

There are two things I should be upfront about. The June run was a burst of ten days and I wouldn't read it as a steady state, and scale has an operational tail to it. By day ten there were two thousand branches, and the project's own decision records say plainly that git was never designed to hand out thousands of short-lived claims a minute.

Unsorry also works in the one domain with a perfect verifier, and the fair challenge is how much of this survives when the verifier is a field-completeness check. My feeling is that more of it carries over than you'd expect, as long as you're honest about what the gate does and doesn't check.

What do humans do now?

Unsorry ran for weeks without a person anywhere in the correctness path, so it's a fair question. My answer is that there are three things I wouldn't hand to an agent, and then a longer list of things people carry on doing inside that.

The three are intent, approval and accountability. None of these systems starts itself, so somebody has to decide that a design is needed, or that a theorem is worth going after, or that a map should exist. Approval has to be built into the tools rather than laid over the top of them, which is why Gantry won't advance a stage until a named reviewer has voted on the exact content, and records that vote against the commit, why Unsorry names a human owner for its gates and automation in the repository, and why Iris writes every change to the model against a user, in a chain that shows if anything has been altered since. And a person stays answerable, in their own name, for every decision and every stage gate. Agents can draft, suggest and raise flags as much as you like, but the sign-off belongs to a person.

Inside that frame, people are still the ones deciding what the work is, because the map comes out of their heads and only they can tell you whether it's right, and the same goes for every definition.

They are also the ones picking things up wherever the gate stops. The kernel can't tell you whether a formal statement faithfully captures its English source, so in Unsorry two agents translate it independently and a person only looks at the mismatches. In my colleague's design the twenty-eight open questions went to a business owner, a lead architect, a security officer and a privacy team, each named against the question that was theirs, and I don't see how you'd produce that table without people.

They review the changes that are too consequential to merge unseen, which in these tools means the gates, the automation and the toolchain, since a mistake there would compromise the machine's ability to check itself. That's the difference between minimum viable governance and none at all.

They do the work the machines aren't allowed or able to do. Unsorry's roadmap gives two examples, writing the explanations the mathematics library requires and putting their name to the submission, which the library reserves for a person, and every organisation will have its own version of those.

And somebody has to keep an eye on the whole thing. A system like this keeps running on its own, but it doesn't point itself anywhere, so someone has to keep asking whether it still serves its purpose and redirect it when it doesn't, which is where the last principle comes in.

Principle seven: evolve and prune

An organisation run this way accumulates a codebase of definitions, gates, renderers and the tools themselves, and the last principle is that this codebase should only grow from what's actually needed and should lose what falls out of use.

The growing side is mostly a discipline about scope, which is to say build the workflow you've mapped rather than the platform you can imagine, and record every decision so the reason for a piece of code is as easy to find as the code. All three tools grew this way, under a stated rule that every change carries a decision record or a changelog entry. In Gantry that rule is a test that fails the build, whereas in the other two it's an instruction the agents follow, so a convention rather than a gate. Unsorry alone accumulated 118 recorded decisions and 43 automated jobs.

The losing side is pruning on disuse, so if a workflow definition hasn't been instantiated in a year you archive it, and if a field never gets filled in you ask whether it should be there.

In practice. I have to be honest that the only automated pruning in any of the three tools happened because a measured cost forced it. Unsorry's active library got archived hourly because builds had grown to minutes, and a housekeeping job was written because stale branches had piled up. None of the tools collects usage data, so what I'm arguing for is pruning on disuse and what has actually happened so far is pruning on cost. Principle five is what joins the two up, because once you're measuring the history, disuse turns into a number, and a scheduled job can act on a number.

What this looks like as a whole

Let me follow one solution design through all seven principles.

An architect is asked for a design for a change to a payments system. Because the map already knows which capabilities that system supports, the request arrives with the affected domains named, and an agent drafts the routine sections from the map and from past designs, which the architect corrects before writing the substance.

The first time the stage tries to advance the gate refuses it, because the security controls section is empty, and it passes the next day. A pull request opens, one reviewer asks for a change, so the approval is invalidated and given again, and the design merges. The cycle time, the gate failure and the round of rework are all sitting in the log before anyone thinks to ask for them, and a year later a field that no design has ever filled in gets retired through a reviewed pull request against the definition.

All the way through, it was the architect who asked for it, the agent drafted against what they asked for, and every gate was passed on a named person's approval.

None of the building blocks are exotic:

The art of the possible

Everything up to this point I've held to what the three tools can actually evidence. This section is where I get to speculate, so take it as a set of invitations.

The thing I'd most like to see is an organisation that can answer questions about itself. Today if you ask which of our capabilities depend on a system we're about to retire, you get six weeks of consultancy. Once the map is in a queryable model and the workflows are sitting in a versioned history, that's a query, and not a difficult one.

A few other things follow from the same setup. Work could arrive partly done, because when the map knows what a change touches and the workflow knows what a design has to contain, an agent can open the design with the affected domains already filled in, which has already happened once. Workflows could get better on their own, because every gate failure and every field that gets filled in last is recorded, so an agent reading that history could propose changes to the definition as a pull request for the people who own the process to review.

The same goes for a change in legislation or policy rippling through the organisation. At the moment "what does this affect" is answered by people reading documents. With the relationships in the model and the documents as data it becomes a traversal, and the response could be a swarm raising a pull request against every affected definition and document, each one gated and each one reviewed by its owner, which would make an impact assessment a good deal smaller than the project it is today.

Audit could be continuous too, since an auditor of an organisation run this way could read the history instead of interviewing people and sampling documents, given that every decision, approval and gate result is already chained and complete. And scale stops being a hiring question, because ten times the volume of a codified workflow doesn't need ten times the coordinators, and the surge can be handed back when it's over.

How the tools might evolve

Iris could export its model to versioned text, so that a change to the organisation's map is itself a pull request reviewed by the people it affects.

Gantry's next step is the agent-facing interface, with the sign-off staying with a person. After that I'd like a library of definitions, each workflow a folder of YAML that other organisations can pick up and share.

Unsorry's own roadmap names the larger ambition, which is a generalised platform for distributed, verified research, and any domain with a cheap, exact check would qualify.

Use cases waiting to be codified

• Grant applications and their assessment.
• Consultation submissions, thousands at a time.
• Contract drafting against a clause library.
• Legislative drafting, where an amendment is as formal as any schema.
• Board papers, with the financial tables drawn from the ledger.
• Reproducible research, where the check is the rerun.

One workflow at a time

I've said any organisation can be run this way, but I wouldn't try to do it everywhere at once. Pick one workflow that's document-heavy, that the people who run it understand well, and that is painful enough that they actually want it fixed. Map it with them, separate the structure from the content, write the gate, put it under version control with review and measure it from the history, and then go and pick the next one. Solution design was that workflow for me, and recruitment could well be the next.

One workflow takes less than it sounds. You need an owner who wants it fixed and will sit in the mapping sessions, a code-hosting account the organisation already pays for, and an engineer with an AI partner for a few weeks. The expensive part is the mapping, and I don't think there was ever a way around that.

Unsorry got nine people to six thousand merged pull requests with nothing between them but a repository, and nobody managing the work. I'm not suggesting anyone's organisation should move at that pace, but I am suggesting it should be the same shape, because once the work is in that shape you can go as fast or as slow as suits you.

From the outside an organisation that does this won't look very different. The difference is that it will know how its work is done, will be able to prove it and measure it, and will be able to hand a piece of it to an agent when it wants to, with a person's intent at the start and a person's name on every approval. And when someone leaves, the process doesn't leave with them any more. Their judgement still does, of course, but that was never going to be written down anyway.

That's as far as I've got. If you got some value out of this, or think I've got it wrong somewhere, I'd love to hear about it, especially if you've tried something similar or have a workflow in mind that would be the one to start with.

Notes

Disclaimer

This essay is written in a personal capacity. The views are the author's own and are not endorsed by the Ministry of Social Development. Gantry is described from the author's work on it; nothing here should be read as a statement of Ministry policy or practice.

What remains to be built

Only solution design is codified. Gantry's pull request governance covers one of its three storage modes, and its gate checks presence, not quality. Iris keeps its live model in a database, not yet exported to text for review, and its role permissions are not enforced. Unsorry has run at scale for weeks, not years.

This essay as code

The essay was produced the way it says work should be. The brief, the research, the reviews and every draft are versioned in one repository. I worked with an AI partner on the research, the drafting and the criticism, and I decided what went in and what didn't.

The tools

• Iris, organisational relationship modelling: https://github.com/cgbarlow/iris
• Unsorry, git as a work substrate for a proof swarm: https://github.com/agenticsnz/unsorry
• Gantry, definition-driven document workflows: https://github.com/cgbarlow/gantry

Thanks to the Agentics NZ community and to the contributors on the Unsorry leaderboard, who made the ten-day story real.