Becoming an "Organization" Even Alone — Why We Split the Work into Nine Roles

We've covered the idea of separation of powers (here meaning: dividing execution, audit, and approval between separate agents) in earlier chapters — keeping these three functions apart, and the golden rules that support that structure. That's where the conceptual framework wraps up, for now.

From here, we move into how we actually built that framework in practice. The first topic: why we split the roles into nine.

When One Agent Did Everything

In the early days, we handed almost everything to a single AI agent (think of it as an AI partner you can assign a specific task to). It researched, wrote, edited, and decided whether something was ready to publish. Routing everything through one point of contact kept things simple and fast.

After running it for a while, though, we saw the problem: when the same agent both writes and checks its own work, it doesn't work well. When you review your own writing, you naturally miss your own habits. An odd phrase can still read as perfectly natural from the writer's own point of view.

This wasn't a matter of ability — it was a matter of structure. When the role that executes and the role that checks live in the same place, the check itself loses much of its meaning.

"Execution" Wasn't a Single Thing Either

Following the idea of separation of powers, we first split execution, audit, and approval apart. That much we covered in an earlier chapter.

But once we split things apart, we noticed something else: what we'd been lumping together as "execution" was actually a collection of several jobs, each with a different nature.

Deciding what to research and writing it up both fall under "execution," but they call for different standards. Writing the text and polishing its wording look at different things too. Setting policy and running day-to-day operations are separate jobs as well. And technical design work has its own standard again.

If one role carries all of this at once, the same problem comes back: it's structurally hard to question a policy you decided yourself. We needed to split roles inside execution too.

What Happened When We Split Each Branch

So we broke down the contents of each of the three branches — execution, audit, and approval — by function.

On the execution branch, we ended up with: a role that sets policy, a role that runs day-to-day operations, a role that handles technical design, a role that does research, a role that writes, a role that polishes wording, and a role that sorts and routes requests. On the audit branch, we placed a role that checks the finished work from the outside. The approval branch stood apart, as the function that gives the final go-ahead.

When we counted them up, it came to nine. We weren't aiming for the number nine from the start. To be precise, we split off each spot where "leaving this to the same role feels risky" as we went, and nine is where we landed.

Even Alone, It Becomes an Organization

Splitting into nine roles added overhead. Compared to when one point of contact handled everything, there's more back-and-forth for checks now.

Even so, we keep this structure because splitting the roles breaks the straight-line pattern of "the same person who decides also checks and also approves." Somewhere along the way, a different role always has to look at the work.

This holds even when every role is filled by AI. It's similar to what happens when one person starts a company alone: they might handle accounting, sales, and the day-to-day work all themselves, but they still keep the ledger and the approval stamp separate. What makes something an organization isn't headcount — it's partly how the roles are divided.

From here on, we'll look at each of the nine roles placed on the execution, audit, and approval branches, one at a time.