The biggest improvement to my multi-agent system was making the agents less important

For the last couple of weeks I've been reworking the architecture of a fairly extensive multi-agent system I use for real work. And the biggest conceptual shift has been surprisingly simple: I no longer want the agents to be the system. I want them to be replaceable workers inside the system. Originally, like many people, I thought mostly in terms of roles: Director → researcher → analyst → executor → reviewer That still has value, but once tasks become long-running and consequential, a much more important question appears: What survives when I replace the worker? If I swap Codex for another model, a cheaper model, a deterministic script, a specialist agent, or even a human, I don't want to lose: - the project state - the original objective - the rules and methods - the permissions - the evidence gathered so far - the definition of “done” - the history of what was already tried So the architecture I'm moving toward looks more like this: authoritative state → bounded task contract → capability routing → appropriate worker → structured result → deterministic checks where possible → independent semantic validation where needed → verified state update → next work The worker is temporary. The task, authority and evidence are durable. That led to several other changes. First: “done” is no longer something the worker gets to declare. If the task changed an external system, the system should read the resulting state back independently. If a file was supposed to be created, check the file. If a record was supposed to change, read the record. If code was supposed to be deployed, verify the deployed state. The model can say “I finished”. That is a claim, not evidence. Second: I'm separating reasoning autonomy from execution authority. A strong model can be allowed to explore, challenge assumptions and propose completely different strategies. That does not mean it should also decide what credentials it has, what rules apply, how much money it can spend, or whether it may bypass an approval. The smarter the agent gets, the more important it becomes that those boundaries live outside the agent. Third: I'm becoming much more aggressive about removing reasoning from work that no longer needs it. If a new problem requires strong reasoning, use it. But once the same pattern has been solved repeatedly and we understand why the solution works: experience → rule rule → test test → workflow The mature version of an agent system should probably contain a surprising amount of boring deterministic software. I don't want a frontier model re-deriving a known calculation, checking a JSON schema, reconciling IDs or deciding whether a file exists. Reasoning is for uncertainty. Fourth: model selection starts looking less like a product choice and more like resource allocation. Some work needs: no model at all → cheap bounded classification → normal reasoning → frontier reasoning → human judgment The question stops being “which model should run this workflow?” It becomes: “what is the cheapest level of intelligence that can reliably complete this particular step?” And finally, I've changed the metric I care about. Token cost matters. But the scarce resource in my system is my attention. So the metric I'm increasingly interested in is: verified useful output per unit of human attention and total cost. If an autonomous system creates 10x more output but I have to inspect all of it, resolve stale state, confirm every action and repair every exception, I haven't really gained 10x leverage. I've just become the quality-control department for a very fast junior team. I'm not a software engineer — I came at this as a former CEO and economist — so maybe that's why I increasingly see agent architecture as an organizational-design problem. The system needs something analogous to: management, employees, company rules, decision rights, internal controls, audit, organizational memory, and escalation paths. The LLM is incredibly important. But I'm increasingly convinced that the long-term value isn't the LLM. It's the organization around it. Curious if others building long-running systems are converging on the same thing. What part of your architecture used to be “an agent problem” and eventually became normal software?