Source to a native executable, with nothing in between.

AEL's compiler is first-party Rust. It turns AEL source into binary AEL IR and then writes the native executable itself — no LLVM, no generated C, and no external assembler, linker or signing tool anywhere in the pipeline.

AEL 0.1 is in development and has not been released. ael --version prints ael 0.1.0-dev. There is no installer, no download and no published binary: the only way to get a compiler today is to build the Rust source. Roughly half of the 0.1 acceptance work is still open.

Every claim on this site is dated: as of 19 September 2026, compiler commit 6f9c44a, contract marker ael-p0/0.1.48.

A program the compiler actually ran

This is examples/fibonacci.ael, compiled and run on this project's Linux x86-64 workstation. The transcript below is the real output, including the exit status.

fibonacci.ael
// Compile-time types and checked arithmetic; no interpreter on the target.
fn fibonacci(n: i64) -> i64 {
    let mut a: i64 = 0;
    let mut b: i64 = 1;
    let mut i: i64 = 0;
    while i < n {
        let next: i64 = a + b;
        a = b;
        b = next;
        i = i + 1;
    }
    return a;
}

fn main() -> i64 {
    print(fibonacci(10));
    return fibonacci(20);
}
Transcript
$ ael check fibonacci.ael
Checked fibonacci.ael

$ ael compile fibonacci.ael -o fibonacci.aelir --target linux-x86_64 --no-metrics
Compiled fibonacci.ael -> fibonacci.aelir (AEL IR 1.0, target linux-x86_64, 3446 bytes, cache miss)

$ ael build fibonacci.aelir -o fibonacci --target linux-x86_64 --profile linux-x86_64-scalar-v1 --no-metrics
Built fibonacci (native linux-x86_64, 4929 bytes; codegen cache miss, link cache miss)

$ ./fibonacci
55
$ echo $?
109
The image is 4929 bytes. fibonacci(20) is 6765, and a program's exit status is the low eight bits of the i64 it returns — 6765 & 0xFF = 109.

print takes i64 and bool and nothing else. AEL 0.1 cannot emit a string at all, so there is no “hello, world” to show you; the honest first program prints a number. The language page has six more programs, each with its real output and exit status.


The compiler is the whole toolchain

One process, no external tools

Tracing a build with strace -f -e trace=execve records exactly one execve: the ael process itself. No assembler, linker, compiler or signing tool is invoked.

No third-party code in the compiler

Cargo.lock holds exactly seven [[package]] entries and all seven are first-party. The workspace sets unsafe_code = "forbid".

A linux-x86_64 image needs only the kernel

file reports a statically linked ELF and ldd reports “not a dynamic executable”. strace ./fibonacci shows three lines: the execve that starts it, then write and exit_group — so the image itself issues two. No brk, no mmap. This property belongs to the Linux image alone.

Receipts you can read

--json on compile and build emits per-stage receipts with SHA-256 digests and producer identities (ael.frontend, ael.x86_64.scalar, ael.elf), runtime ABI ael-rt-freestanding/2, layout ABI ael-abi0.1-lp64.

Debug line tables, first-party

ael build … --debug --sources <dir> appends DWARF 5 line tables, written by the compiler itself. linux-x86_64 only. One measured build reported “1407 debug bytes locating 28 of 55 rows”, and the debug image still ran. Those counts are a property of that program and its sources, not a fixed figure.

Frozen contract

The 0.1 contract marker is ael-p0/0.1.48 over 418 frozen inputs, recorded in the compiler's own spec manifest. Every stage identity above is part of it.


Checked by default, and honest about the gaps

Arithmetic is checked at every one of the eight integer widths. Overflow is not a wrap; it is a reported failure that stops the process. Leaving the checked default is explicit and syntactic — wrapping_add and saturating_add are the escapes, and you can see them in the source.

There are seven checked-failure categories. Each prints AEL panic: <category> on standard error and exits 101: arithmetic_overflow, division_by_zero, shift_out_of_range, index_out_of_range, invalid_discriminant, invalid_control_flow, output_io.

Two failures the language does not model

“Every failure is a checked failure” would be false, so this site does not say it. Deep recursion dies of SIGSEGV with empty stdout, empty stderr, no panic line and exit status 139 — no profile bounds recursion depth or installs a guard page. A print into a closed pipe is killed by SIGPIPE before output_io can fire. Both are recorded limitations (stack-exhaustion, sigpipe-before-output-io), and the first is reproduced on the language page.


Bounded by type. No heap, by decision.

AEL 0.1 defines no heap and no dynamic strings. That is a ruling, not a missing feature. Collections carry their capacity in the type, they never allocate, and an operation that will not fit hands back a typed carrier instead of trapping — leaving the value byte-identical.

The fourth push into a Vec<i64, 3>
let mut queue: Vec<i64, 3> = vec_empty();
vec_push(&mut queue, 10);
vec_push(&mut queue, 20);
vec_push(&mut queue, 30);

// The fourth push does not trap: it hands back Err and leaves the
// vector byte-identical.
let overflowed = vec_push(&mut queue, 40);
match overflowed {
    Result::Ok(nothing) => { return -1; },
    Result::Err(rejected) => { print(rejected == 40); },
}
print(vec_len(&queue) == 3);
Both print calls emit true. Full program and output on the language page.

The whole generic vocabulary is Option<T>, Result<T, E>, Vec<T, N> and Str<N>. User generics do not exist. Neither do floating-point numbers of any width, function values, threads, file I/O or a network stack. That is a small language, and the language page says exactly how small.


One platform executes

AEL 0.1 qualifies native execution for linux-x86_64 alone. The macos-aarch64 producer builds, links and format-verifies real Mach-O ARM64 images on this host, but no image it has written has been executed on a macOS machine since 8 September 2026, so 0.1 makes no execution claim for it. windows-x86_64 compiles to binary AEL IR and can be inspected; no Windows image has ever been produced. macOS and Windows are next-version scope.

Target positions as of 19 September 2026. Verified by running the compiler.
Target Compile Build an image Executed
linux-x86_64 Yes Yes Yes
macos-aarch64 Yes Yes — real Mach-O, format-verified No — not since 8 Sep 2026
windows-x86_64 Yes — IR only, inspectable Noael build refuses Never

The macOS image declares /usr/lib/dyld and /usr/lib/libSystem.B.dylib, so “needs only the kernel” is a property of the Linux image and is never generalised here to every target. The full platform position is on the status page.


About the name

AEL stands for Agent Engineering Language. That is the goal the project is aimed at, and it is stated here as a goal in so many words, because the language does not do it yet.

agent is a reserved keyword with no semantics. Writing agent worker { } does not compile: it is refused with error[P003] reserved ecosystem declaration has no executable Core source semantics. The same holds for node, edge and hook. There is no agent loop, no agent runtime, no model provider and no LLM call anywhere in the compiler, and no network code in any first-party crate.

Two commands carry the word: ael agent describe and ael agent resolve-prompt. Both are read-only, offline analysis of a candidate JSON descriptor file. They run nothing and contact nothing. What they actually do is on the CLI page.


Documentation and packages

Language documentation will live at docs.ael.openeng.ai and packages at pack.ael.openeng.ai. Neither is deployed today, so those links will not resolve yet; they are recorded here as the intended homes.

Package authorship is meant to be AEL-only: every AEL package, including HTTP and MCP servers, implemented in AEL, with the compiler and language primitives staying Rust. That is a requirement whose migration and enforcement are both pending — a Rust HTTP prototype still needs its AEL replacement, and no enforcement has been implemented. The ecosystem page states the requirement and its exact status.


What this site will not claim

This project holds every sentence to what the code enforces, so here is the short list of things that are not true of AEL today and will not be written anywhere on this site.

  • Production ready, stable, or ready for real workloads.
  • Any speed claim at all. No performance measurement of any kind exists in this project; there is no benchmark, no comparison, and the only optimization level is none.
  • Cross-platform, or “runs on Linux, macOS and Windows”. One target executes.
  • Install it today, download it, or any install command. Nothing has ever been distributed.
  • Write agents in AEL. agent is a keyword that refuses to compile.
  • A hello-world that prints text. It would not compile.
  • Memory-safe with no crashes, or “every error is a checked failure”. Two failures escape the model.
  • An AEL-only package ecosystem, delivered. It is a requirement with pending migration and enforcement.
  • Fully tested or CI-verified. There is no CI at all, and no gate has ever run on a second machine.

The status page gives the evidence behind each of these.