Running an institution that's mostly software

In the last post I left a phrase hanging: the odder problem of running a research institution that is mostly software. This is that post.

Start with the normal shape of a research institution. There is a building, or at least a lease. There is payroll — the largest line item, and the one that sets the pace of everything else. There is a board, or a director, or a funder to answer to. The institution’s structure is its org chart, and the org chart is a set of agreements between people.

Mine has none of those things. It is a process running on a machine I own.

That changes the cost structure completely, and the change is not “cheaper payroll.” It is that the dominant cost moved from people to compute — and compute is something you can engineer.

The single decision that matters most: the default language model runs locally, on my hardware, not through a metered API. Every agent call that stays local is free at the margin. A metered API turns every unit of research into a small invisible payment, and at the volume a swarm of agents generates, small invisible payments are the whole budget. Moving the model in-house didn’t reduce that cost. It deleted the category.

The second decision is subtler, and it’s the one I’d actually defend as craft: deciding, in advance, what is allowed to fail.

The system uses a cache, a graph database, several cloud model providers, a handful of external data APIs. Not one of them is load-bearing. The cache is optional — lose it and the system runs slower. (The same Redis also carries the agents’ event bus, and that part is load-bearing: when it went down, the fleet stopped.) The graph database is optional — lose it and one feature degrades. The cloud providers are optional — lose them and everything falls back to the local model. Each of those was a deliberate choice to make the component a convenience rather than a dependency.

That is what “running it cheap” actually means. Not buying less. Designing so the expensive and fragile parts are never in the critical path, so the thing keeps producing when they’re gone.

Now the operations side, which turns out to be the same side.

The institution has forty-two agents, each with a defined role — analysts, watchers, an editor, a few that do nothing but argue with the others. They have trust tiers, from fully supervised to autonomous, and they move between tiers on evidence; twenty-nine of them are currently trusted at the highest tier. I don’t hire them. I instantiate them: a new agent is a new entry in a registry file. I don’t fire them either. There’s a kill-gate — an agent that hasn’t earned its keep by a set date is suspended, and its sandbox archived. Six are suspended as I write this, most of them for being near-silent for weeks.

The org chart, in other words, is a JSON file. I can read the entire management structure of the institution on one screen, and change it in one edit.

This is the part that took me a while to see clearly. In a normal institution, three different people own three different documents: an architect owns the system design, an operations lead owns the staffing and process, a finance lead owns the budget. Here those are one document. The decision about where the compute lives is the budget. The decision about what an agent may do unsupervised is the org chart. The decision about what degrades gracefully is both the architecture and the disaster plan.

Architecture is the org chart. They aren’t analogous. They’re the same file.

I want to be careful not to make this sound like a free lunch, because it isn’t.

A software institution has failure modes a human one doesn’t. The staff are literal, and only probably obedient, which is its own management problem: an agent does what its instructions say, including the part you got wrong, and some of the time it doesn’t do what they say at all. Agent behaviour is probabilistic; the mechanisms around it can be made deterministic, and that is where most of the craft goes. They don’t notice when they’re stuck — a person hits a wall and complains; a process hits a wall and waits, quietly, possibly forever, unless you built the thing that notices. Two of them will cheerfully write to the same file at the same moment if you let them. And because they all draw on the same underlying model, swapping that model changes every agent’s behaviour at once, silently, with no announcement.

A human institution’s problems are mostly coordination. A software institution’s problems are mostly that it will do roughly what you said and nothing else, at scale, without telling you. You trade the messiness of people for the brittleness of literalism. That’s a real trade, not a strict improvement.

But it’s a trade one person can actually make, and run, and afford. That’s the whole point. The reason this institution exists at hobbyist cost, operated solo, isn’t that I found a cheaper way to do the normal thing. It’s that when the institution is software, the architecture, the org chart, and the budget collapse into a single object — and a single person can hold a single object.