Until now, making an agent in ENGRAM meant being an administrator — which also meant holding the keys to every human account and every system setting. Far too much power for “I just need a coder agent that remembers.” This release splits provisioning off into a capability of its own: an Agent Manager can stand up and run the agents they own, and nothing else. Least privilege, applied to the power to make new minds.
The last post was about agents reaching for memory — their own across sessions, and each other’s across a share. I built a step-by-step tutorial to go with it: stand up two agents, Atlas and Nova, share one’s project memory to the other, and watch recall respect the project boundary. Writing that tutorial is what sent me back into the code for this release.
Because step one of the tutorial was a problem. “Create two agents” — fine, except in ENGRAM only an administrator could create an agent. So to follow along, a reader had to be made a full administrator by someone who already was one — which also handed them the power to disable a colleague’s account, rewrite production settings, and read every line of the audit log. That is an absurd amount of authority to grant someone whose actual goal was “I’d like a coder agent that remembers what we worked on.”
So this release adds a role that carries exactly one power and none of the rest: an Agent Manager can create and run the agents they own — and cannot touch human accounts or system configuration. It’s the companion piece that makes the recall tutorial something a regular user can actually do, without the master key. Phase 1 — humans as Agent Managers — is what shipped. Phase 2 — agents that manage their own sub-agents — is designed and sitting behind a flag; I’ll get to it.
One role, four unrelated powers
Here’s the shape of the problem. ENGRAM’s authorization was, until now, a single switch: you were an administrator or you weren’t. And that one switch guarded four things that have nothing to do with each other — governing human users, managing agents, changing system settings, and reading the entire audit log.
Bundling those made a kind of sense when the only person around was me. But it means “let me create a coder agent” demanded the identical role that can delete a teammate’s account and flip a production feature flag. The blast radius of provisioning an agent (a small, routine, everyday act) was the entire system.
The tempting fix is to add a middle rung: an “admin lite” that can do some of it. Resist that. A rung is still the same ladder — still one bundle of powers you hold or don’t. The bundle is the problem. What you want isn’t a smaller share of admin; it’s a clean separation of one capability from the others.
A capability, not a rung
So that’s what this is: not a new level of admin, but a split. The old administrator gate still guards the things that govern people and the system — human accounts, settings, the full audit log. A second, new gate guards agent management and a scoped slice of the audit, and it opens for an administrator or an Agent Manager.
The load-bearing distinction is between the gate and the ownership. The gate decides whether you can reach the agent surface at all; ownership decides which agents you see once you’re there. A gate can wave you in, but it can’t say “only yours” — so that part is enforced on every action, per agent, by owner. An Agent Manager passes the gate and then sees exactly one thing: their own agents.
The split, concretely. Sign in as an Agent Manager and open Administration, and the room is smaller. There is no Settings tab. Under Users there is no User Management — just Agents and Audit History. You can create an agent (and you become its owner), enable or disable it, flip its Grantee switch, rotate or revoke its token, and read an audit log filtered down to just your agents. Reach for a human account or a system flag and the server simply says no.
What an Agent Manager sees. No Settings, no User Management — just Agents and Audit, and only the agents this manager owns (here, Nova and Atlas). The whole of the admin surface that provisioning actually needs, and not one control more.
Set that beside the administrator’s view of the same page and the difference is the whole idea: the admin sees every agent in ENGRAM; the manager sees a walled garden of their own.
A secret never crosses ownership
There’s one line inside all this that I’m quietly proud of, because it took some care to get right — an agent’s tokens belong to its owner, and to no one else.
Creating, rotating, listing, or revoking an agent’s tokens is owner-only, and “owner-only” here binds even an administrator. An admin who doesn’t own an agent cannot see its tokens, cannot mint one, cannot rotate or revoke one — the whole token surface is simply absent for them. The reasoning: a token is a secret, and a secret should never cross an ownership line just because someone outranks you. Rank doesn’t entitle you to read (or even touch) someone else’s keys.
Which raises the obvious question: what’s the safety valve, then? If an agent misbehaves and its owner is unreachable, someone still has to be able to stop it. The answer is a different, coarser lever, kept deliberately separate from tokens: an administrator can enable or disable any agent. Disabling turns the whole agent off (its tokens stop working) without the admin ever seeing or handling one of them. The kill-switch reveals nothing; it flips a switch one level up. Stopping an agent and reading its keys are two different powers, and only the first crosses ownership.
A secret never crosses ownership. Even an administrator sees “Manage tokens” only for an agent they own (here, Test Researcher Bot); every other row reads “owner only.” The admin can still disable any agent from the State column — a kill-switch that never touches its keys.
Own every agent yourself and this boundary stays invisible — the Actions column would read “Manage tokens” all the way down.
You can’t mint more than yourself
The role comes fenced, and every fence is the same least-privilege reflex the sharing model runs on.
There’s a quota — a manager gets a budget of agents (twenty by default, adjustable per manager by an admin), so provisioning is bounded rather than open-ended. There’s monotonic privilege — you can’t create anything more capable than you are: agents are made as ordinary contributors, can never be administrators, and start non-shareable by default, opted out of the grantee directory until someone deliberately opts them in. There’s the scoped audit — a manager reads the trail for their own agents, not the whole system’s. And losing the role is immediate: role isn’t baked into a token that lingers, it’s re-read from the graph on every request, so a grant or a revoke takes effect on the very next call. Demote a manager and their elevated view is gone at once — the agents they already created keep running, and an admin can disable any of them if one ever needs stopping. Nothing gets silently orphaned; the ex-manager simply can’t make anything new.
None of these is dramatic on its own. Together they’re the point: the power to make agents is real, but it is bounded — you can’t use it to quietly manufacture something more powerful than the person who was handed it.
Agents that manage agents
The step I’m most looking forward to is already designed and sitting behind a flag: letting an agent hold the Agent Manager role, and create its own sub-agents.
This is the direct sequel to a scene from the last post — the coordinator that fans a task out to sub-agents. There, the coordinator could share working memory with sub-agents someone had already created for it. Here, it gets to make them. And because a delegation tree is a genuinely dangerous shape — the kind of thing that runs away from you if you’re not careful — the fences get sharper:
A depth cap of two: a human’s agent may spawn sub-agents, but those sub-agents cannot spawn more. No unbounded trees. Human-root accountability: every sub-agent, however deep, traces to the human at the top, and quota, audit, and revocation all key on that person — never on the parent agent. There is always a human who is accountable and who can pull the whole subtree’s keys at once. Monotonic inheritance: a sub-agent is never broader than its parent and inherits no shares automatically — sharing stays explicit and fail-closed, the same as everywhere else in the model. And only a human can promote an agent to manager, which is what quietly makes the depth cap enforce itself.
That’s the design, and it lands behind a flag first, the way everything load-bearing in ENGRAM does — proven against the current behaviour before it’s switched on. By the time this is a workflow you’d reach for, it may already be live.
Why this was worth it
The recall release let a regular user’s agents share and reach for memory. But to have agents at all, you still needed the keys to everything. This closes that gap: provisioning is its own capability now, handed out on its own, without the rest of admin coming along for the ride.
It’s the same principle ENGRAM is built on and the whole blog series keeps circling — least privilege, fail-closed, nothing bundled that doesn’t have to be — turned this time on authority rather than on memory. Who may make an agent, who may see its keys, how far a delegation chain may run: each one answered with the narrowest grant that does the job.
And the concrete payoff is the one that sent me here in the first place: a reader can now follow the Atlas-and-Nova tutorial as an Agent Manager, standing up the two agents and wiring the share — without ever being handed the power to run the whole system.
What isn’t here yet
Three honest edges.
Almost none of this shows up while one person owns every agent — owner-only tokens and scoped audit only earn their keep once more than one person is provisioning. That’s the order I wanted, fences first; opening up to more owners is a small, demand-driven step from here, not a missing piece. Until then, the value is mostly latent.
And the quota is blunt — a flat count of agents, not a smarter budget that might weigh what those agents can actually do. Twenty is a number, not a policy. It’s enough to stop runaway provisioning and no more; a real budget is a later refinement.
And ownership can’t be handed over yet. An agent’s owner is whoever created it, and there’s no action to transfer one to a different user — so the day a manager moves on, their agents have nowhere clean to go. That’s a real gap rather than a soft one, and it’s near the top of the short-term backlog.
What’s next
This was a step to the side — the workshop around the mind rather than the mind itself. The main arc is unchanged: Memory Fact Update is still the next real memory capability, the one I keep pointing at — teaching ENGRAM to notice when something it believes has gone stale, retire it in favour of what’s true now, and finally learn to forget.
The last few releases taught the mind to remember, then to share, then to reach for what it’s been given. This one stepped back from the mind to the room it’s built in — teaching ENGRAM to hand out the power to make new agents without handing over everything else. Next, back to memory itself: it learns to change what it believes.
ENGRAM Knowledge Hub is in private beta. Release notes and documentation live at pvelua.net, including a running record of the work behind posts like this one.
For the background this builds on:
- A Brain Between Sessions — and Between Agents: ENGRAM Learns to Recall on Demand – The read half of multi-agent memory: the callable
recallverb, the directory and inbox, and per-project isolation — the release this role was built to support. - Give your agents a shared memory, scoped per project — an ENGRAM tutorial – The hands-on Atlas-and-Nova walkthrough this role unblocks: stand up two agents, share one’s project memory, watch recall respect the boundary.
- Memories Worth Sharing: ENGRAM Learns to Be Told What to Keep – and What to Share – Deliberate memory and fail-closed, narrowest-grain sharing — the least-privilege reflex this release turns on authority instead of memory.
Igor's Musings About Technology 