Split the work
One agent with every tool and every instruction gets slower and less careful as it grows. Splitting it gives each agent its own context, tools and model. Glove has two shapes for this: a subagent, which the parent calls like a tool and waits for, and mesh, where peers send each other messages.
A subagent is a tool
The release assistant should not grade its own release notes. A reviewer with a fresh context, read-only tools and a cheaper model does it better:
// release.ts, continued: Glove, Displaymanager and createAdapter are imported in step 1.
import type { GloveFoldArgs } from "glove-core";
// Defined once, given to both agents: least privilege by construction.
const listMergedChanges: GloveFoldArgs<{ since: string }> = { /* the tool from step 1 */ };
agent.defineSubAgent({
name: "reviewer",
description: "Checks draft release notes against what actually merged. Read-only.",
async factory({ parentStore }) {
const store = await parentStore.createSubAgentStore!("reviewer");
return new Glove({
store,
model: createAdapter({ provider: "anthropic", model: "claude-haiku-4-5" }),
displayManager: new Displaymanager(),
systemPrompt:
"You review release notes. Every line must match a merged pull request. " +
"Reply with the problems you found, or 'OK'.",
compaction_config: { compaction_instructions: "Summarise the review." },
})
.fold(listMergedChanges)
.build();
},
});Defining a subagent registers glove_invoke_subagent on the parent, with the list of subagents in its description. The model decides when to call it (a user typing @reviewer nudges it) and passes a task. The factory builds the child, the child runs to completion, and its final answer comes back as the tool result. The parent's subscribers see the child's events between subagent_invoked and subagent_completed, so a UI can show the review happening. Pass true as createSubAgentStore's second argument, createSubAgentStore("reviewer", true), and the child keeps its history across calls.
Common subagents worth splitting out:
- Memory readers. One per retrieval task, each with only the memory tools it needs; the main agent stays small.
- Explorers. Search a codebase or the web with a big context, return a short answer.
- Reviewers and critics. Fresh eyes, read-only tools.
- Discovery.
glove-mcp's server discovery is a subagent; so is a classifier-backed triage step.
Peers: mesh
When two agents run independently (the release assistant and an on-call agent, say) neither should block on the other. mountMesh gives each agent glove_mesh_send_message, _broadcast, _list_agents and _acknowledge. A message lands in the recipient's inbox and reaches it on its next turn, exactly like any other resolved inbox item.
import { mountMesh } from "glove-mesh";
import { InMemoryMeshAdapter, MeshNetwork } from "glove-mesh/in-memory";
const network = new MeshNetwork(); // in-process; bring your own transport for real deployments
await mountMesh(release, {
adapter: new InMemoryMeshAdapter(network, "release"),
identity: { id: "release", name: "Release assistant", description: "Drafts and ships releases." },
});
await mountMesh(oncall, {
adapter: new InMemoryMeshAdapter(network, "oncall"),
identity: { id: "oncall", name: "On-call", description: "Watches production health." },
});The MeshAdapter is the transport: implement it over Redis, NATS or your database to run agents in different processes. Continuum supervises agents as subprocesses, cold per wake-up or warm, and pairs with mesh for talking. Mesh has no authentication of its own; sender ids are whatever the transport says they are.
Which one?
| You want… | Use |
|---|---|
| To delegate a task and use the answer in this turn | A subagent |
| To tell another agent something, or ask without waiting | Mesh |
| Agents that run as separate, supervised processes | Continuum (+ mesh) |
| A fast agent that hands slow work to siblings and hears back, questions included | Foundry delegates, in step 7 |
| A durable agent per customer to start another's run, or a schedule | Foundry: spawn, calls and shared work, in step 7 |
Already built for you
| Primitive | What you get | Instead of building |
|---|---|---|
| Subagentsglove-core | glove_invoke_subagent routes work to an isolated child with its own tools and store; events bracket the child's run.glove.defineSubAgent({ name, description, factory }) | a router that calls other agents by hand |
| Delegatesglove-foundry | A fast agent hands work to sibling agents and keeps talking; results and the workers' questions come back to its conversation.defineAgent({ delegates: [{ agent: "coder", description }] }) | a job queue and callback plumbing between a chat agent and its workers |
| Meshglove-mesh | Direct, broadcast and acknowledged messages between agents, delivered through their inboxes.mountMesh(glove, { adapter, identity }) | a message bus between agents |
| Continuumglove-continuum-signal | Agents supervised as subprocesses, cold per wake-up or warm and notified inline.agent("name").triggered() · new ContinuumRunner({ agentsDir }) | process supervision for long-lived agents |
Next
That is the whole harness: loop, tools, surface, context, state, workspace and a team. So far it is one agent for one team, running in one process. In step 7 it becomes a system: one definition, an instance per team, conversations, a weekly schedule, a Slack channel and an approval before anything is published.