Glossary

Package names on this page are preview naming and may change before launch.

AEL and its parts

• AEL: the Agent Engineering Language, a programming language for building AI agents as reliable, native software.
• AEL Beta 0.0.1: the first public release of AEL, launching soon.
• AEL Cloud: a service hosted by OpenEng, coming with the beta at cloud.ael.openeng.ai, where you will build and run agents in the cloud with your own account.
• ael command: the one command-line tool of AEL (command names may change before launch).
• AEL toolchain: what the installers will install: the ael command and what it needs to build for the targets you choose.
• official package registry: pack.ael.openeng.ai, where only OpenEng will publish official packages, each version signed and never changed once published. It will open when the beta launches.

Building blocks

• agent: a named workflow with its own identity, configuration, starting points, completion and lifecycle, written in one .agent.ael file. Its decisions will be model-driven, through a system prompt, or deterministic.
• component: the collective word for an agent, node, edge, hook, configuration or other file role; each component will have 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 will be config.
• edge: a typed, directed connection from one node's output to another node's input, with its delivery and reply policy, in one .edge.ael file.
• 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.
• 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 will run in ordered or parallel groups, and a failed authorization will stop the work it guards.
• instance: a configured use of a component, such as the same node used twice with two different cameras.
• main: the program's entry point, main main(), 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.
• 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 will be the digest field.
• lock file: pack.lock, generated beside each manifest: the exact versions, origins and fingerprints a build uses. You will 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 will be written in AEL.
• package file: the single file that ael package will produce: 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 will win.
• 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 will have to be used.
• signed: carrying OpenEng's signature. Every official package version will be signed, and your tools will check the signature.

Building and running

• check, compile, build, run: the stages AEL will take a program through: checking the source, compiling it to compiled AEL, building a native executable or firmware image, and starting it. Every build will check 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 will start your program with nothing to compile, install or download at startup.
• device: a connected physical board or machine that ael flash and ael monitor will address.
• diagnostic: an error that points at your source; with --json, diagnostics will be machine-readable.
• firmware image: what a build will produce for a microcontroller board.
• microcontroller board: a small computer on one board, such as those listed under Microcontroller boards.
• native executable: what a build will produce 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 will fail at compile time, not on the device.
• reference map: what references what in a project, a folder or a file, with unused code and packages, shown by ael refmap.
• target: what a build will run on: an operating system and processor, or a microcontroller board.

Agents at run time

• budget: the shared limit of tokens, time, CPU, memory and concurrency that a run and all its child agents draw on.
• 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.
• system prompt: an agent's business policy for its model: inline, from a file, from the environment or from configuration. Without one, the agent will run 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.