AEL Docs
Follow updates
Menu
Follow updates
Browse the documentation

Preview documentation for AEL Beta 0.0.1 — launching soon

Containers

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

Status

Planned for AEL Beta 0.0.1. AEL is not available yet.

Planned for Beta 0.0.1

Planned for Beta 0.0.1: static Linux executables and minimal container images for x86-64 and ARM64. Images will be built from the two Linux targets; see Planned targets.

How you will ask for an image, as a build option or a command of its own, will be announced at launch.

What goes into an image

  • Your program. A static Linux executable of your program, built from compiled AEL. Programs will 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.
  • Nothing else. No AEL toolchain and no compiler. Nothing in the image will be compiled, installed or downloaded when it starts.
  • Only what you use. Only what you use will ship: an HTTP-only app will carry no gRPC or WebSocket code.

Images will 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 will record exactly what went into it, so you can check what an image contains.

Starting and readiness

  • Nothing at startup. No source will be parsed, no package installed and no model weights downloaded when the container starts.
  • Ready will mean ready locally. A program will report 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 will be reported separately, because a program may be ready while a provider is offline.
  • Fail promptly. A missing required setting, credential, system prompt or file will stop the program promptly with a clear error, never with a false report that it is ready.
  • No tokens for health. Readiness and health checks will never call a model.
  • A console agent will need no network listener: it will be ready when it can accept input. An HTTP agent will be ready when its routes are bound and it is listening.

This page states no startup time. Startup figures will appear only alongside published measurements and the conditions they were measured under.

Running in a container

  • Main process. The program will run as the container's main process. It will pass stop signals on, finish or cancel its work within a bounded deadline, then exit. A one-shot program will keep its exit status.
  • Least privilege. Images will run as a user other than root, with a read-only root file system.
  • Writable mounts. File logs and any state you keep will go to writable mounts you declare. A file log that needs a mount that is missing will stop the program before it reports ready.
  • Logs. Structured logs will go to standard error by default, so standard output will carry 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 will come from files or environment variables when the container runs, and will never be written into the image. System prompts will come from a file, the environment or configuration, or the agent will run on its input alone; see System prompts.
  • TLS. Certificate verification will work without downloading anything at startup.
  • Restarts. A restarted program will keep the budgets of the work it resumes, and will never replay a side effect whose outcome is unknown.

Honest limits

  • Not a sandbox. A minimal image will not be a sandbox for running untrusted code.
  • Hard limits will need a boundary. Per-agent CPU and memory limits will state whether each limit is hard-enforced or accounted. A hard limit for one agent will need 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 will belong to the model service, not to the image.