A first agent

The project

One command will create the project (command names may change before launch):

ael init support

Besides the three root files that ael init will create, the agent will need three files: a system prompt, a node and the agent itself.

support/
  main.ael                       # the program's entry point
  pack.ael                       # packages; none needed here
  metadata.ael                   # the project's name
  prompts/summarize.md           # the system prompt
  src/
    nodes/summarize.node.ael     # the node: one business step
    agents/support.agent.ael     # the agent: the workflow

Apart from the three root files, the folder names will be your choice.

The system prompt

The system prompt will be the agent's business policy, written for its model in plain language. Here it is kept in its own file, prompts/summarize.md:

You summarize customer support requests for the support team.
Write two or three sentences: what the customer wants, and anything urgent.
Use only facts that are in the request.

You will also be able to write a system prompt inline, or take it from the environment or from configuration. Without one, the agent will run on its input alone.

The node

A node will be one business step. This one will send the request to a model, with the system prompt, and return the model's summary:

# src/nodes/summarize.node.ael
node summarize(request: Str<4000>) -> Str<1000> {
    config {
        prompt: file("prompts/summarize.md");
        model: binding("primary_model");
        max_attempts: 2;
    }
    return write_summary(request);
}

fn write_summary(request: Str<4000>) -> Str<1000> {
    # A private helper: only this node can call it.
    # It sends the request to the model and returns the summary.
}

• Str<4000> will be text of at most 4,000 bytes. The node's input and output will be typed, and AEL will check them.
• prompt will name the system prompt file. A file(…) path will be relative to the project root, not to the node's own file, so this one names prompts/summarize.md beside main.ael.
• model will name a model binding, primary_model. You will point the binding at a model endpoint through configuration or at deployment: an OpenAI-compatible API, a local model server or a major cloud provider. The source will name only the binding.
• max_attempts: 2 will let the node try again if its first attempt fails, and every attempt will draw on the run's budget.
• write_summary is a private helper whose body is a placeholder for now; see Placeholder bodies.

Models and providers describes model calls and bindings, and Budgets, retries and validation output checks and retries.

The agent

The agent will be the workflow: which nodes it runs, where work starts, and what completes it.

# src/agents/support.agent.ael
agent support(request: Str<4000>) -> Str<1000> {
    config {
        nodes: [summarizer = summarize];
        starts: [summarizer];
        completion: summarizer.result;
    }
}

summarizer is this agent's instance of the node summarize. An agent with one node will need no edge. A larger workflow will add a node for each business step and an edge for each typed connection between two nodes.

The entry point

main will take no parameters. It will read the request from the console, run the agent, and print its summary:

# main.ael
main main() {
    let request: Str<4000> = read_request();
    let summary: Str<1000> = support(request);
    print(summary);
}

fn read_request() -> Str<4000> {
    # A private helper: it reads the support request from the console.
}

How a program reads its input from the console is one of the details that may change before launch.

Placeholder bodies

The two helpers on this page, write_summary and read_request, hold only a comment where their code will go. A body with only a comment is a placeholder, not finished code: every path through a function with a result will have to end in a return (Control flow), so as shown, these helpers would not pass the check. They are placeholders because the names of the library's operations, such as the call that sends a request to a model and the one that reads the console, are not final yet.

How a node's code will call the model that its config block binds with prompt and model will be shown when the library is final. Until then, Model client describes what that call will do. Other pages of this documentation use placeholder bodies in the same way.

Checking and running

Once the helpers have their bodies, you will check and run the agent from inside the support folder:

ael check
ael run

ael check will check the whole project before anything runs: the file names and roles, the path of the prompt file, the types that pass from main to the agent and its node, and the model binding's name. Its diagnostics will point at your source.

ael run will build the agent into a native program and start it. You will type a support request, and the agent will print its summary.

Where to go next

• Checking the summaries. A second node will be able to verify each summary, with an edge connecting the two nodes. Agents, nodes and edges shows such a verifying node, and Workflows describes workflows and edges in full.
• Serving an API. Adding the HTTP package and declaring routes will make the agent a REST API; removing them will take it back to console-only. Services and APIs shows the HTTP package at work.
• The whole layout. Project layout shows every kind of file a project can hold.

Complete example agent systems and deployment recipes will be published with the beta.