Teams of agents — AEL documentation

Hierarchical and multi-agent patterns will be built into AEL, the Agent Engineering Language: supervisor, pipeline, fan-out and join, router, peers, quorum, handoff and typed delegation. Every pattern will keep typed inputs and outputs, one shared budget and explicit ownership of the work.

Status

Planned for AEL Beta 0.0.1. AEL is not available yet.

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.	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 will never assume that answers from models are independent of each other: you will decide what counts as agreement.

A pipeline

Here three nodes will run one after another, each connected by a typed edge:

Preview syntax — may change before launch

# 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 will be able to take a node's place through its typed inputs and outputs. How an agent lists its child agents will be confirmed when the syntax is final.

Agents inside agents

A child agent will be used through its public, typed inputs and outputs. Its parent will not be able to reach into its private nodes.
Ownership will form a tree: every agent instance will have exactly one owner.
Supervision will say who restarts or cancels whom. It will be declared separately, and will not be able to form a cycle.
Communication will follow the edges, which may cross the tree.
Placement will say where each agent runs, and grant nothing by itself.

Cancelling a parent will cancel the work it owns, wherever that work runs. A child's success will not be able to bring a cancelled parent back.

Delegation

When one agent delegates to another, it will pass a typed request and a bounded part of its context:

The child will keep its own system prompt, tools, state and memory.
It will not receive the caller's instructions, secrets or permissions, unless they are passed to it explicitly as data.
Its permissions will be 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 will be reserved from the parent's operation: token, time, CPU, memory and concurrency budgets will apply across every child agent.
The depth of delegation, the number of children and the number of open requests will all be bounded. A cycle, such as A asking B, which asks A again, will be detected or capped.
Only a result that has passed its checks will go back into the caller's context.

Delegation or handoff

With delegation, the caller will stay in charge. The child will work on the request and reply.
With a handoff, the conversation itself will move to another agent. The move will be recorded durably before it takes effect, the receiving agent will have to accept it by a deadline, and the first agent will stop working on it.

Placement

Code will call a typed service, and the deployment will decide whether it runs in the same process, on another machine, over HTTPS or over gRPC. The same team will be able to run in one program during development and across several machines when deployed, with no change to the agents. Placement will be a choice you make in the deployment.

Remote agents over A2A

Agents will discover remote agents and delegate long-running work to them over A2A:

A remote agent will be authorized on its own terms. Its published description will be checked, but never trusted as a grant.
Its progress will be tracked through clear states: submitted, accepted, working, waiting for input, completed, failed and cancelled.
The request will carry a typed input, a bounded context and the original deadline, and no unrelated prompts, secrets or permissions.
A remote agent will not be able to enlarge the local budget or permissions. Delegation depth and cycle limits will hold across remote calls too.
A cancellation request will not be proof that remote work has stopped; an uncertain outcome will be reported as uncertain.

Accepting remote work will not be the same as finishing it: a delegation will complete only when the remote agent reports a result.