The Pharmakon of a Billion Capsules
A Billion Capsules Without Losing Our Agency.
“Each increase in artificial agency should produce a corresponding increase in human agency.”
As early as 2023, AI agents shifted from a niche idea to a mainstream bet on the future of work. The idea that every person could have one or more agents handling mundane and repetitive work suggested that we are heading toward a world with billions of agents. As exciting as that prospect is, it also leaves me with a lingering concern. What happens to our own agency if the primary goal becomes eliminating human effort?
Every major leap in computing has been a pharmakon, and artificial agency is unlikely to be any different. The question I keep coming back to is not whether we should build AI agents, but how we can design them so they remain more of a remedy than a poison.
Human agency is our ability to set goals, make informed judgments, choose, refuse, and ultimately remain responsible for our actions. AI systems are beginning to exhibit forms of agency of their own: they can reason, plan, and act on our behalf. But those capabilities are precisely what I believe humans should continue to cultivate rather than surrender. Agents can help clarify goals, expose trade-offs, and support decision-making. Thoughtful design can increase human competence instead of quietly replacing it through silent automation.
So the question I want Murmur to answer is simple: how do we ensure that every increase in artificial agency also expands human agency?
Rather than jumping straight into technical solutions, I first wanted to crystallize the design principles behind Murmur. They are not intended as a universal solution, but as a technical ideal that guides the system’s evolution. The principles below shaped the initial infrastructure layer for deploying agents. It’s what I call the capsule runtime environment emphasizing containment and openness. These principles will continue to guide the Murmur ecosystem as I envision it for as long as they remain useful.
Principles
Containment
- Everything is declared. No hidden behavior, no magic. If the system makes a decision, there is a setting for it, written where anyone can read it.
- Off by default. Nothing turns on, and nothing reaches outside itself, unless you say so. A fresh system starts blank.
- Limits are structural, not prompts. Safety is enforced by the system no matter what the model tries — not by asking a person to approve each step. Set the boundary once; don’t sit and supervise inside it.
- One declaration is the whole contract. The same file is the policy, the record of what ran, and the team’s agreement. There is no second, hidden policy.
- Same input, same behavior — now and later. Pin versions, don’t float them. A thing built today runs identically next year.
- The control layer never asks the model. Reasoning and control are separate. Limits can’t be talked past, because they don’t live where the talking happens.
- A person can always stop it. Anything running has a halt the operator can pull, and the machine can’t override it.
Openness
- Opinionated about form, never about answers. Fix the shape of the work; leave how to solve it open. Don’t ship one blessed way of doing things.
- No privileged defaults. What ships with the system competes on quality with anything a user brings — loaded the same way, no shortcut for the house brand.
- Trust the simplest correct primitive. Prefer plain files and direct tools over layers that hide what is happening.
- Knowledge is the durable part; the model is replaceable. Tools, skills, and specs are portable, travel between people, and add up over time. Swapping the model changes one line.
- Keep capability local where you can. Data and compute stay near the person; nothing has to route through one central operator.
- Open and forkable. Infrastructure people depend on must be something they can inspect and improve, not something that changes under them.
- Don’t force one path in. More than one language, more than one way to build a tool — so the system never shrinks to whoever fits its favorite.
- Put each property where it earns its keep. Predictability, isolation, and portability are worth their cost the moment more than one person depends on the result — and pure overhead before that. Know which you are building.
So here is the real test. Before adding anything to make the machine more capable, we are asking one question:
Does this leave the person with more control, more understanding, or more skill, or less?
Build the first. Refuse the second, however powerful it is.
- @ewdegraaff