A Team of Its Own: ENGRAM Agents Learn to Grow and Orchestrate a Team

Last time, ENGRAM handed a person the power to make agents — fenced. This release hands a bounded slice of that power to an agent itself: with a human’s say-so, an orchestrator can become a manager, spin up a small team of sub-agents — each a distinct identity with its own memory — fan work out to them, and gather it back. Not a control plane bolted on top; the team thinks together through the same memory it already had. A team of its own, bounded at every edge.

I ended the Agent Manager post on a promise. Its last movement (“agents that manage agents”)described a capability that was designed and sitting behind a flag, and closed with a hedge: by the time this is a workflow you’d reach for, it may already be live. It’s live now, on PROD, and there’s a tutorial — Atlas grows a team — that walks the whole thing end to end.

It also closes a loop from two posts before that. The recall post sketched a coordinator that fans a task out to sub-agents and pools their memory — but back then, someone else had already made those sub-agents; the coordinator only shared with them. Now the coordinator makes them itself, and runs them. That scenario, finally realized.

The post has two halves, and the title names them: an agent can now grow a team — provision sub-agents of its own — and orchestrate it, fanning work out and gathering it back entirely through the memory the series already built. And, as ever, the whole thing arrives fenced.

Two things both called “sub-agent”

Start with a distinction that’s easy to wave past and turns out to decide the entire design. There are two things the word “sub-agent” can mean, and they are not the same.

One is a Claude Code subagent — the in-process worker you spawn with the Task tool. It’s ephemeral: it lives for the turn, does its piece, and vanishes. Crucially, it inherits its parent’s ENGRAM connection — the single token the session was configured with. So every subagent you spawn this way reads and writes memory as one identity: yours.

The other is an ENGRAM sub-agent — a real, persistent identity in the delegation tree. It has its own token, its own place in the tree (its depth, and the human at the root it answers to), and (the part that matters) its own memory scope. What it remembers is its memory, not the orchestrator’s.

Here is why the difference is load-bearing. If you fan work out to a squad of in-process subagents, they all write memory as the same identity — which isn’t a team remembering, it’s one agent talking to itself in different voices. You can’t afterwards ask “who found what,” because there’s only ever one who. To get a team whose memory is legible per member — where Scout’s finding is Scout’s and Warden’s is Warden’s — each worker has to be a distinct ENGRAM identity, carrying its own token.

That is the hinge for everything below: give every worker a real identity, then let them coordinate through memory. It also means the tree’s ownership nests — the human owns the orchestrator, the orchestrator owns its workers — something you can read straight off the roster.

A team of real identities. Atlas, promoted to Agent Manager, with the three sub-agents it created — Scout, Forge, and Warden — nested beneath it, each its own persistent ENGRAM user. Ownership shows on the roster: the admin owns Atlas (Manage tokens is live), while Scout, Forge, and Warden read owner only — they belong to Atlas, not the human admin.

The two verbs that let an agent build a team

With that settled, the orchestrator needs a way to actually make those identities. And the first cut of that ability had a gap I didn’t notice until I sat down to write the tutorial.

Creating an agent was a plain REST API call — an endpoint, outside the tool surface an agent has in front of it during a session. Which meant an orchestrator agent couldn’t build its own team from inside its own run; it would have had to reach past the tools in its hand to a raw endpoint. A team you can’t assemble with the tools you’re holding isn’t really yours to grow.

So this release adds two verbs to the agent’s tool surface. create_sub_agent — the orchestrator makes a sub-agent it owns, handed a role (researcher, coder, reviewer). And issue_sub_agent_pat — mint that worker’s access token, returned exactly once, to hand to the process that will run it. With those two, the whole “grow a team” gesture happens in-session: Atlas creates Scout, Forge, and Warden and mints each a token without ever leaving its run. They arrive as a capability group of their own (Sub-agent Delegation) taking ENGRAM’s tool surface to twenty-seven.

The reassuring part is what these verbs don’t carry: any new authority. They’re thin shims over the same machinery the Admin UI already uses, and every guardrail lives underneath them, enforced server-side — owner-scoping, the subtree quota, the depth cap, and the operator flag itself. An agent on a deployment where the flag is off doesn’t find a loophole; it gets a polite refusal. The power to build a team arrives already fenced.

Orchestration through memory

Now the team exists. Watch it work — and watch that it works through nothing but memory.

The tutorial’s cast: Atlas, the orchestrator, with three specialists it created — Scout the researcher, Forge the coder, Warden the reviewer. Atlas fans a task out to them. Each worker, running as its own process under its own identity, does its piece and then does two things with the result: it remembers the finding (recorded under itself, so the memory is genuinely its own) and it shares that memory back to Atlas. Atlas then recalls, and the team’s findings come back, each tagged via:shared, each traceable to the worker that produced it. And Atlas drives that whole sequence itself (creating the workers, minting their keys, setting them to their tasks, and gathering what they return) with no human scripting the hand-offs in between.

The thing worth sitting with: there is no orchestration layer here. No message bus, no task queue, no control plane. Fan-out and fan-in are just the memory primitives the last few releases already built — remember, share, recall. The coordination is the memory. An orchestrator directs a team by writing and reading the same associative store everything else in ENGRAM writes and reads.

And the project isolation from the recall post carries straight over — now across a whole team. Split the squad by project: Scout and Forge work checkout-service, Warden works billing-service, and each shares its finding bound to its own project. When Atlas recalls while declaring the checkout project, it gets Scout’s and Forge’s work — and not Warden’s. Declare billing instead, and only Warden’s review comes back; the checkout pair is gone. One orchestrator, one memory surface, cleanly partitioned by the very same identity-gate that walled off a single borrowed memory two posts ago — now walling off a whole team’s reporting, project by project.

A tree that can’t run away

A delegation tree is a dangerous shape — the kind of structure that, left unfenced, grows arms and multiplies. So the fences the Agent Manager post described in the abstract are now real, tested end to end, and worth seeing up close.

A depth cap — two by default, and an admin can raise it. A sub-agent can, in turn, have sub-agents of its own — but by default the tree stops two levels down, a ceiling an administrator can lift if a real need appears. The number, though, isn’t the interesting part. What keeps the tree from running away is that it can only deepen through a human: creating sub-agents needs the Agent Manager role, a fresh sub-agent is a plain contributor, and an agent can’t promote its own workers — only a human can hand out that role. So an agent builds its team, but it can’t quietly grow the tree beneath itself; every level down waits on a person’s promotion, right up until the cap stops it outright. Every widening of “can build a team” passes through someone accountable.

One accountable human at the top. However deep the tree, every sub-agent’s root is the human who owns it. Quota is counted across the whole subtree against that human; the audit log of the whole subtree is theirs to read; and the disable that stops the team keys on them. There is always exactly one person who can account for a tree and pull its keys at once.

A pause you can take back. Disabling an orchestrator now suspends its whole subtree rather than destroying anything: every worker’s access stops at once, its tokens refused — but nothing is revoked for good. Re-enable, and the team resumes on the same credentials. An earlier cut hard-revoked on disable, which would have made “pause the team while I reassign the work” a one-way door; the fix makes stopping and restarting a whole team safe. Removing an account is still permanent — off is reversible; gone is not.

Why this was worth it

The arc in one line: people got a fenced power to make agents; now an agent gets a bounded slice of that same power, so a coordinator can grow and run a team — and the team coordinates through the very memory substrate the whole series has been building. The delegation tree the last post promised is live, and nothing about it is unfenced.

It’s the same reflex once more — least privilege, fail-closed, a human in the loop for every grant of create-authority — turned this time on delegation itself. Depth-capped so it can’t deepen without a person; quota’d against one accountable human; reversibly suspendable, so stopping a team isn’t destroying it. The power to build a team is real, and bounded at every edge.

What isn’t here yet

Two honest edges, and the first ties straight back to the last post.

See the whole tree, manage only your own branch. A human at the top of a tree can now see its entire subtree — the Agents table nests the whole thing, and the audit log covers all of it. But they can still only manage — promote, handle tokens for — the agents they directly own. So promoting a depth-1 sub-agent into a manager of its own still takes an administrator, even though the human root carries accountability for the whole tree. Visibility has caught up with the tree; management authority hasn’t. It folds into the same ownership-change work I flagged last time.

Ownership still can’t be handed over. The carry-forward from last post, and it bites harder here: it’s not one orphaned agent now, it’s a whole subtree with nowhere to go if the human at its root moves on.

What’s next

The main arc hasn’t moved: Memory Fact Update (belief revision, contradiction, and finally forgetting) is still the next real step for the memory itself. This was the second companion piece, paired with a tutorial, while the mind’s own next capability waits its turn.

The last stretch of this series taught the mind to remember, to share, and to reach for what it’s given; then it stepped out of the mind into the workshop and let people make agents; now an agent can grow and run a team of its own — a small, fenced organisation that thinks together through shared memory. Next, back to the mind 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:

1. Standing Up Your Own Agents: ENGRAM Adds an Agent Manager Role – Provisioning agents as a capability split off from full admin — where this post’s “agents that manage agents” was first promised.
2. Atlas grows a team — orchestrating sub-agents with shared memory – The hands-on walkthrough behind this post: promote an orchestrator, have it spin up a team, fan work out across projects, and recall the team’s findings per project.
3. Give your agents a shared memory, scoped per project — an ENGRAM tutorial – The two-peer sharing tutorial this one builds on; the source of the per-project isolation gate.
4. A Brain Between Sessions — and Between Agents: ENGRAM Learns to Recall on Demand – The callable recall verb and the coordinator-and-sub-agents use case this release finally makes real.