Communication between agents

Every edge is a two-way channel

An edge carries a value from one component to another, and carries the reply back over the same edge. Both directions are typed, and the check refuses a type that does not match in either direction before anything is sent.

You declare the edge in its own file and connect it in the agent that uses it. From those declarations AEL generates the communication on every path a workflow uses:

You write no client or server code for any of them, and no code that turns their values into messages.

Modes, delivery and callbacks on both sides

An edge's mode, delivery and callbacks keep their meaning on both sides of the channel:

• Event: the sending side learns only whether the value was accepted, and nothing comes back.
• Request and reply: the sending side gets one result or one typed error for its request, within the edge's finite deadline. A late or duplicate reply completes nothing a second time.
• Callback: the reply comes back over the channel to the handler you name in the edge's file.
• Stream: a bounded sequence travels under backpressure, and ends with an explicit end, error or cancellation.
• Delivery: at most once or at least once, the order, the queue capacity and the idempotency key are declared once, on the edge, and hold on both sides.

Workflows describes each mode and the delivery settings.

One edge, wherever it runs

The same edge runs in one process, between processes or over the network, as your deployment places it, with no change to your source. One delivery contract holds in all three: the types, the mode, the deadline and the delivery rules stay the same, and only the transport changes.

Placement belongs to the deployment, not to the edge, as it does for the services your code calls: code calls a typed service, and the deployment decides whether it runs in the same process, on another machine, over HTTPS or over gRPC (see Tools and MCP). Declaring an edge opens no port by itself.

Over the network

Over the network, an edge uses AEL's built-in gRPC-compatible transport with TLS.

• Built in. You add no package for it. The transport joins your program only when an edge placed on the network is reachable, so a program whose edges all stay off the network carries no network transport for them.
• TLS. Every connection an edge makes over the network uses TLS.
• The caller stays trusted. The tenant and the caller's identity travel with each call, apart from the values your code sends, so nothing in a value can change them.
• No secrets travel. A call carries no credentials of the sending side: the receiving side uses its own.
• Your own gRPC services. A gRPC service that you design yourself, for outside clients, uses the server/grpc package, as Services and APIs shows. The built-in transport carries your edges.

Services built elsewhere call in

Services built elsewhere call your agents over gRPC, because each network edge publishes its interface in gRPC's standard interface-definition format. A service that another team builds, outside your project, uses that interface to call your agent through the edge, with the edge's types, mode and deadline.

Isolated components

You mark an agent, node or subagent as isolated: it always runs in a sandbox in its own process, outside the shared communication layer, reachable only through the edges you declare and holding only the resources it declares itself. Isolation needs the isolation facilities of Linux and runs only on the Linux target the documentation names for it: on macOS, on Windows, on microcontroller boards, on other Linux targets and on any host without those facilities, an isolated component is refused, never run without isolation.

For communication, this means:

• Only the edges you declare to an isolated component reach it. No other component can call it or send it a value.
• An isolated component makes no model or tool call itself: it reaches one through a declared edge to a node that is not isolated.

Isolated components describes the isolated modifier.

Subagents and the agent that spawned them

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. The link between a subagent and the agent that spawned it is generated like every channel: the subagent's typed parameters go one way, its typed result comes back, and nothing of the link stays open once the subagent ends. Subagents describes spawning.

Honest limits

• Microcontroller boards carry no network transport for edges, so on them an edge is never placed on the network.
• When a network connection drops after a value was sent, the outcome is reported as uncertain, and the value is never sent again blindly.
• Support for native gRPC clients does not imply support for gRPC from web browsers.
• This page states no latency, throughput or message-size figures; measure your own program on your own platform.

Related

• Workflows: starting points, edge modes, delivery, callbacks and triggers.
• Teams of agents: supervisors, delegation, placement and remote agents over A2A.
• Subagents: agents spawned at run time for one task.
• Isolated components: components that run in a sandbox, reachable only through their edges.
• Bindings and storage: the memory, skills, knowledge, storage and databases a component declares.
• Services and APIs: HTTP, gRPC, WebSocket and MCP services of your own design.