Browse the documentation

AEL 1.0.0

Workflows

A workflow in AEL, the Agent Engineering Language, is the set of nodes and edges an agent runs, from its starting points to its completion. You write it in the agent's file; the nodes and edges it uses each have their own file. Agents, nodes and edges introduces the three building blocks.

Starting points and completion

# agents/support.agent.ael
agent support(input: Request) -> Decision {
    config {
        nodes: [summarizer = summarize, verifier = verify];
        edges: [summary_to_verify(summarizer, verifier)];
        starts: [summarizer];
        completion: summary_to_verify.callback_result;
    }
}
  • starts lists one or more node instances or child agents where a run begins. AEL never infers a start from file order or from a node without incoming edges.
  • With several starts, the agent declares whether they run at the same time or one after another, and how their results decide the outcome: all must succeed, the first success wins, a quorum agrees, or your own function combines them. Starts that lose are cancelled.
  • completion names the result that ends the run and becomes the agent's output. A run ends exactly once.

Edge modes

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. Each edge declares its mode, which fixes what each side of the channel can expect:

ModeThe sending side receivesThe receiving sideThe edge declares
EventOnly whether the value was accepted. No reply is promised.Takes the value and sends nothing back.Queue size, what happens when it is full, and where delivery errors go.
Request and replyOne result or one typed error, for this request.Sends one result or one typed error back over the same edge.A finite deadline, and what happens to late or duplicate replies.
CallbackThe result, passed to a handler you name.Sends its result back over the edge, to that handler.The handler, and a bound on how far callbacks can chain.
StreamA bounded sequence with an explicit end, error or cancellation.Takes part in the bounded sequence under backpressure, until its end, an error or a cancellation.The element type, backpressure, freshness and order, and what a disconnect does.

Being accepted into a queue is not completion: a sending side that needs a result uses a request or a callback. Communication between agents describes the channel itself and where it runs.

Delivery

An edge also declares how its values are delivered, and the same rules hold on both sides of the channel, wherever the edge runs:

  • at most once or at least once, and in what order;
  • the capacity of its queue, and how long a value may wait;
  • an idempotency key, retries and their backoff;
  • what to do when an effect's outcome is uncertain.

No delivery setting guarantees that an effect outside your program happens only once: at-least-once delivery is made safe with idempotency keys, as described in Durable runs and approval.

Mappings stay simple

An edge's body maps the value it receives to the next node's input. The mapping is deterministic and bounded: it selects, moves, copies and converts fields. Model calls, tools, network access and other work belong in a named node, so the route of every value stays easy to follow.

The check refuses an edge whose types do not match, a missing required field, a wrong number of values and a destination that cannot do what the edge needs, before anything is sent.

Callbacks

A callback is the reply path of an edge: the reply comes back over the same two-way channel to a handler you name. The handler is a helper function in the edge's own file:

# edges/summary_to_verify.edge.ael
edge summary_to_verify(summary: Summary) -> VerifyInput {
    return VerifyInput(summary);
}

fn on_verified(result: Verification) -> Decision {
    # Reads the verifier's reply and returns the workflow's decision.
}

The agent above uses the callback's result as its completion. The handler's body is a placeholder, as A first agent explains.

Fan-out and feedback

  • Fan-out. To send one output to several nodes, use several edges, each with its own delivery state, or a node that fans out to a bounded number of branches.
  • Feedback. A workflow can loop back only through a mailbox, a delay or a change of state, with a finite limit on depth, iterations or time. A cycle that would wait on itself at once is refused when you check your code.

Timeouts and cancellation

Every request along an edge has a finite deadline. When a run is cancelled or times out, it starts no new child work, releases the values it had queued and cancels the work already running. A reply that arrives late, or twice, cannot complete anything a second time. Concurrency describes the model behind this.

Triggers

A run can start from an event, a poll or a schedule, as well as from a call. Event, polling and scheduled triggers have overlap, missed-run and time-zone policies, and survive restarts when their agent declares a storage point:

  • Events: subscriptions with filters, acknowledgements and deduplication keys.
  • Polling: an interval, a timeout, retries with backoff and a cursor, so a slow poll never builds up an unbounded backlog.
  • Schedules: intervals or calendar times in a named time zone, with a rule for daylight-saving changes; see Time.
  • Overlap: when a new run is due while the last one is still going, skip it, queue it, replace the old one, or run both up to a limit.
  • Missed runs: after a restart of an agent that declares a storage point, catch up on missed runs up to a limit, or combine them into one.

Each trigger creates bounded runs. When its agent declares a storage point, a trigger keeps its identity across a restart and never starts the same scheduled run twice.

A run is durable only when its agent declares a storage point, a storage package you select that keeps the run's state in a directory, in object storage or in an SQL database you run; without one, the run runs to completion and keeps nothing. Bindings describes the storage point.

Entry points

main starts the work: it calls an agent like a function. A console agent needs no server; add the HTTP package and declare routes to make it a REST API, or remove them to go back to console-only; see Services and APIs. An edge adds no server for you to write: the same edge runs in one process, between processes or over the network, as your deployment places it, and over the network it uses AEL's built-in gRPC-compatible transport with TLS, as Communication between agents describes.