Teams of agents
Hierarchical and multi-agent patterns are built into AEL, the Agent Engineering Language: supervisor, pipeline, fan-out and join, router, peers, quorum, handoff and typed delegation. Every pattern keeps typed inputs and outputs, one shared budget and explicit ownership of the work.
The patterns
| Pattern | What it does | What you declare |
|---|---|---|
| Supervisor | An agent owns child agents and restarts or cancels them when they fail. | The restart policy and its limits. |
| Pipeline | Each agent's output is the next one's input. | The order, through typed edges. |
| Fan-out and join | Work is split across several children and their results are combined. With subagents, an agent spawns its children at run time, one per piece of work. | The number of branches, and the join rule: all, any or quorum. |
| Router | A node picks which child handles each input, with your rules or a model. | The choices and how one is picked. |
| Peers | Agents exchange messages without a single owner in the middle. | Who owns each request, and when the exchange ends. |
| Quorum | Several agents answer, and a result needs enough of them to agree. | The votes required, a timeout and what disagreement does. |
| Handoff | The active conversation moves from one agent to another. | The receiving agent and the deadline for accepting. |
| Typed delegation | An agent asks another for a typed result, as it would call a tool, and stays in charge. | The request type, the result type and the limits. |
A quorum never assumes that answers from models are independent of each other: you decide what counts as agreement.
A pipeline
Here three nodes run one after another, each connected by a typed edge:
# agents/change.agent.ael
agent change(request: ChangeRequest) -> ChangeResult {
config {
nodes: [planner = plan, coder = implement, reviewer = review];
edges: [plan_to_code(planner, coder), code_to_review(coder, reviewer)];
starts: [planner];
completion: reviewer.result;
}
}
Each node may be model-driven or deterministic, and a child agent can take a node's place through its typed inputs and outputs.
Agents inside agents
- A child agent is used through its public, typed inputs and outputs. Its parent cannot reach into its private nodes.
- Child agents are static: the agents an agent lists in
agents:are fixed when you build. Subagents are the dynamic kind. An agent spawns subagents at run time: short-lived agents that each do one task, return a typed result to the agent that spawned them and end, leaving nothing running. A subagent is never listed inagents:; see Subagents. - Ownership forms a tree: every agent instance has exactly one owner.
- Supervision says who restarts or cancels whom. It is declared separately, and cannot form a cycle.
- Communication follows the edges, which may cross the tree. Every edge is a typed, two-way channel: AEL generates the communication between nodes, agents and subagents from your edge declarations, with no client or server code for you to write; see Communication between agents.
- Placement says where each agent runs, and grants nothing by itself.
Cancelling a parent cancels the work it owns, wherever that work runs. A child's success cannot bring a cancelled parent back.
Delegation
When one agent delegates to another, it passes a typed request and a bounded part of its context:
- The child keeps its own system prompt, tools, state and memory.
- It does not receive the caller's instructions, secrets or permissions, unless they are passed to it explicitly as data.
- Its permissions are the overlap of what the parent holds, what the child's policy allows and what the request needs: never more than the parent's.
- Its budget is reserved from the parent's operation: token, time, CPU, memory and concurrency budgets apply across every child agent.
- The depth of delegation, the number of children and the number of open requests are all bounded. A cycle, such as A asking B, which asks A again, is detected or capped.
- Only a result that has passed its checks goes back into the caller's context.
Delegation or handoff
- With delegation, the caller stays in charge. The child works on the request and replies.
- With a handoff, the conversation itself moves to another agent. The move is recorded before it takes effect, the receiving agent has to accept it by a deadline, and the first agent stops working on it. A run is durable only when its agent declares a storage point; see Bindings.
Placement
Code calls a typed service, and the deployment decides whether it runs in the same process, on another machine, over HTTPS or over gRPC. The same team can run in one program while you develop it and across several machines when deployed, with no change to the agents. Placement is a choice you make in the deployment. The same edge runs in one process, between processes or over the network, as your deployment places it, with no change to your source; Communication between agents describes how.
Remote agents over A2A
Agents discover remote agents and delegate long-running work to them over A2A:
- A remote agent is authorized on its own terms. Its published description is checked, but never trusted as a grant.
- Its progress is tracked through clear states: submitted, accepted, working, waiting for input, completed, failed and cancelled.
- The request carries a typed input, a bounded context and the original deadline, and no unrelated prompts, secrets or permissions.
- A remote agent cannot enlarge the local budget or permissions. Delegation depth and cycle limits hold across remote calls too.
- A cancellation request is not proof that remote work has stopped; an uncertain outcome is reported as uncertain.
Accepting remote work is not the same as finishing it: a delegation completes only when the remote agent reports a result.