AEL Docs
Follow updates
Menu
Follow updates
Browse the documentation

AEL 1.0.0

Containers

A program written in AEL, the Agent Engineering Language, runs in a container as a native program, with nothing else to start first. Minimal container images for x86-64 and ARM64 start with nothing to compile, install or download at startup.

What AEL 1.0.0 builds

AEL 1.0.0 builds static Linux executables and minimal container images for x86-64 and ARM64. Images are built from the two Linux targets; see Supported targets.

What goes into an image

  • Your program. A static Linux executable of your program, built from compiled AEL. Programs build into standalone native binaries, including static Linux binaries.
  • The files it needs. Prompts and assets kept as files, the trust roots for verifying TLS certificates, and any other data your program reads, each included on purpose.
  • The runtimes you provide. Functions in other languages are built and run with your own toolchains, pinned by version, so the image of a program that holds any carries the runtime each one needs, at the version it pins.
  • Nothing else. No AEL toolchain and no compiler. Nothing in the image is compiled, installed or downloaded when it starts.
  • Only what you use. Only what you use ships: an HTTP-only app carries no WebSocket code, and no gRPC code unless an edge is placed on the network.

Images come in two forms: one that holds nothing but your program and the files it needs, with no shell and no package manager, and one built on a small Linux distribution, for programs that need what the distribution provides. Each build records exactly what went into it, so you can check what an image contains.

Starting and readiness

  • Nothing at startup. No source is parsed, no package installed and no model weights downloaded when the container starts.
  • Ready means ready locally. A program reports that it is ready once its own configuration, prompts and files are validated and it can accept a request. Whether a model provider or another service can be reached is reported separately, because a program may be ready while a provider is offline.
  • Fail promptly. A missing required setting, credential, system prompt or file stops the program promptly with a clear error, never with a false report that it is ready.
  • No tokens for health. Readiness and health checks never call a model.
  • A console agent needs no network listener: it is ready when it can accept input. An HTTP agent is ready when its routes are bound and it is listening.

This page states no startup time.

Running in a container

  • Main process. The program runs as the container's main process. It passes stop signals on, finishes or cancels its work within a bounded deadline, then exits. A one-shot program keeps its exit status.
  • Least privilege. Images run as a user other than root, with a read-only root file system.
  • Writable mounts. File logs and any state you keep go to writable mounts you declare. A file log that needs a mount that is missing stops the program before it reports ready.
  • Logs. Structured logs go to standard error by default, so standard output carries only the program's result, as on the console, and a one-shot program's answer can still be piped unchanged; see Logging and monitoring.
  • Configuration and secrets. Settings and secrets come from files or environment variables when the container runs, and are never written into the image. System prompts come from a file, the environment or configuration, or the agent runs on its input alone; see System prompts.
  • TLS. Certificate verification works without downloading anything at startup.
  • Restarts. A restarted program resumes only the runs whose agent declares a storage point. 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. A resumed run keeps the budgets of the work it resumes, and never replays a side effect whose outcome is unknown.

Honest limits

  • Not a sandbox. A minimal image is not a sandbox for running untrusted code. Isolation belongs to a component, not to the image. You mark an agent, node or subagent as isolated: it always runs in a sandbox in its own process. Isolation needs the isolation facilities of Linux and runs only on the Linux target the documentation names for it: on any host without those facilities, an isolated component is refused, never run without isolation. Isolated components gives the rules, and Sandbox mode and isolated components the sandbox for functions in other languages.
  • Hard limits need a boundary. Per-agent CPU and memory limits state whether each limit is hard-enforced or accounted. A hard limit for one agent needs that agent in its own process group; see Desktop and server.
  • Models take their own time. A program that is ready may still wait for a model's first answer. Model loading and response times belong to the model service, not to the image.