Glossary

AEL and its parts

• AEL: the Agent Engineering Language, a programming language for building AI agents as reliable, native software.
• AEL 1.0.0: the first public release of AEL.
• ael command: the one command-line tool of AEL.
• AEL Gateway: the gateway through which prompt-driven agents run on small devices; each device keeps its safe local behaviour when offline. See Microcontroller boards.
• AEL toolchain: what the AEL 1.0.0 build for your platform sets up: the ael command and what it needs to build for the targets you choose.
• distribution: the toolchain you build with. AEL 1.0.0 is the full distribution; smaller distributions of the same version leave out components, such as support for other languages or for agents, and refuse a feature they leave out by naming it. See Distributions.
• official package registry: pack.ael.openeng.ai, where only OpenEng publishes official packages, each version signed and never changed once published.

Building blocks

• agent: a named workflow with its own identity, configuration, starting points, completion and lifecycle, written in one .agent.ael file. Its decisions are model-driven, through a system prompt, or deterministic.
• component: the collective word for an agent, subagent, node, edge, hook, configuration, skill or other file role; each component has its own file.
• configuration: typed, reusable settings with defaults, in one .config.ael file, locked into a snapshot for each run. In code the keyword is config.
• edge: a typed, two-way connection from one component to another, such as from one node's output to another node's input, with its delivery and reply policy, in one .edge.ael file. 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.
• extension file: a file beside a component that adds private helper functions to it, named <name>.<role>.extended.ael, then <name>.<role>.extended.2.ael and up.
• function in another language: a private function whose body is written in another language and whose signature is typed in AEL, built and run with your own toolchain, pinned by version; also called a foreign function. It is declared in a language file or inline, as fn python and the like. See Functions in other languages.
• global function: a shared function in a .global.ael file, visible in its own folder and every folder below it.
• helper function: a function declared with fn in a component's file, private to that component and its extension files.
• hook: a typed function attached before or after a component, function or statement, for authorization, auditing or cleanup. Hooks run in ordered or parallel groups, and a failed authorization stops the work it guards.
• instance: a configured use of a component, such as the same node used twice with two different cameras.
• isolated component: an agent, node or subagent marked 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. See Isolated components.
• language file: a file named <name>.<lang>.ael, such as profile.python.ael, whose primary is one function in the language its tag names.
• main: the program's entry point, main <name>(), where <name> is the application's name in metadata.ael, in the project's root main.ael.
• node: one business step of a workflow: deterministic logic, or a model call with its tools, in one .node.ael file.
• reusable function: a shared function in a .reuse.ael file, usable in a file that imports it by path in its header.
• routes: the HTTP routes of a .routes.ael file, a file role that the server/http package adds, mounted by main.
• skill: a versioned, reusable bundle of instructions, typed tools and functions, in one .skill.ael file, that an agent or subagent loads through the skills it declares. See Skills.
• subagent: a short-lived agent, in one .subagent.ael file, that an agent spawns at run time: it does one task, returns a typed result to the agent that spawned it and ends, leaving nothing running. See Subagents.
• workflow: the nodes and edges an agent runs, from its starting points to its completion.

Projects and packages

• export: a public component of a package, such as get of server/http.
• fingerprint: the SHA-256 value that pins a package file. In the manifest it is the digest field.
• lock file: pack.lock, generated beside each manifest: the exact versions, origins and fingerprints a build uses. You never edit it by hand.
• manifest: pack.ael: the packages a project, or one folder of it, uses.
• package: reusable compiled AEL that a project uses: an official package from the registry, or a private package that you build and host. Every package is written in AEL.
• package file: the single file that ael package produces: compiled AEL only, with no source, no scripts and no native code.
• package scope: the folder a pack.ael governs, with the folders below it. The nearest manifest that declares a package wins.
• project: a folder with main.ael, pack.ael and metadata.ael at its root.
• project metadata: metadata.ael: the project's name, description and settings.
• select: naming the exports a file uses, as in refer server/http select get;. Every selected export must be used.
• signed: carrying OpenEng's signature. Every official package version is signed, and your tools check the signature.

Building and running

• check, compile, build, run: the stages AEL takes a program through: checking the source, compiling it to compiled AEL, building a native executable or firmware image, and starting it. Every build checks the complete reference map first. From your side, How it works groups them as four steps: write, check, build and run, with compiling part of the build unless you split the build in two.
• container image: a minimal image that starts your program with nothing to compile, install or download at startup.
• device: a connected physical board or machine that ael flash and ael monitor address.
• diagnostic: an error that points at your source; with --json, diagnostics are machine-readable.
• firmware image: what a build produces for a microcontroller board.
• microcontroller board: a small computer on one board, such as those listed under Microcontroller boards.
• native executable: what a build produces for an operating system.
• profile: what a target can offer: Host for Linux, macOS, Windows, single-board computers and servers; Edge for larger microcontrollers, with an optional heap, storage, networking and TLS; Nano for bare-metal microcontrollers, with no heap and no operating system. A feature a target cannot support fails at compile time, not on the device, and runtimes come in sizes for each class of device. Coin-cell-class and other small boards carry smaller runtimes than Nano's, with a cooperative scheduler or one main loop, and no heap.
• reference map: what references what in a project, a folder or a file, with unused code and packages, shown by ael refmap.
• self-hosting: hosting your built application on servers you operate, with health checks for the storage, databases and models it declares, graceful shutdown and log rotation. See Self-hosting your application.
• target: what a build runs on: an operating system and processor, or a microcontroller board.

Agents at run time

• binding: an entry of a component's bindings { … } record. An agent, subagent or node declares the memory, skills, knowledge, storage and database it uses, each bound to a package you select, and the check refuses any use it did not declare. A binding is not a model binding. See Bindings and storage.
• budget: the shared limit of tokens, time, CPU, memory and concurrency that a run and all its child agents draw on.
• channel: what AEL generates for every edge, and between a subagent and the agent that spawned it: a typed, two-way connection that carries a value one way and its reply back, in one process, between processes or over the network.
• model binding: the named connection from an agent to a model endpoint, set by configuration or at deployment rather than in source.
• run: one execution of an agent for one input, with its own run ID, budget and pinned configuration.
• spawn: to start a subagent at run time, with spawn or try_spawn. A spawn returns a handle, Spawned<R>, that join or cancel uses up.
• storage point: the storage package an agent declares in its storage binding. 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.
• system prompt: an agent's business policy for its model: inline, from a file, from the environment or from configuration. Without one, the agent runs on its input alone.
• tenant: the trusted identity that every call, store, log and reply carries, set where a request enters and never by prompt content.
• tool: a typed operation an agent may call, with its own permission.
• trigger: an event, a poll or a schedule that starts work.