OEL (previously AEL) 1.0.0
Features
OEL (Open Engineering Language, previously AEL) 1.0.0 includes a typed, compiled language for agents, with one command-line tool to create, check, format, build, run and debug projects.
01
Language
- Programs build into self-contained native executables, with type, memory and permission checks built in and nothing else to install for desktop and server programs written in OEL alone.
- OEL is a statically typed, compiled language built for agent engineering, so type, ownership and permission mistakes are caught before anything runs.
- Programs compile straight to self-contained native executables, with no interpreter or virtual machine to run and no second language to install unless you write functions in one.
- Agents, subagents, nodes (business steps), edges (typed two-way connections), configuration, hooks and skills are first-class building blocks, each in its own named file, so a project's structure reads at a glance.
Show all 12Show fewer
- Your application can hold private functions written in other languages, with typed OEL signatures, built and run with your own toolchains, pinned by version.
- Sharing follows clear rules: helpers stay private to their owner, shared functions are visible by folder, and reusable functions are imported explicitly.
- Typed, reusable configuration is locked into a snapshot for each run, so settings cannot change underneath a running agent.
- Hooks attach authorization, auditing or cleanup before or after any component, function or statement, run in ordered or parallel groups, and fail closed when authorization fails.
- Compile-time effect and capability checks let code do only what it has been allowed to do.
- You mark an agent, node or subagent as 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.
- Memory use is predictable: fixed-capacity collections, an explicit result when something is full, and no mandatory heap on small devices.
- Arithmetic and indexing have defined results: an overflow or an out-of-range access is reported, never silently ignored.
02
Agents and workflows
- You write an agent's business policy as a system prompt (inline, from a file, from the environment or from configuration), or run it on its input alone with no system prompt.
- One workflow mixes model-driven and deterministic decisions, and routes sensor readings or events without paying for a model call.
- Agents take typed inputs and return typed outputs, with your own input builders and output checks and a choice of raw or typed results.
- Retries, output repair, timeouts and cancellation draw on one shared budget, so nested retries cannot multiply cost.
Show all 12Show fewer
- Hierarchical and multi-agent patterns are built in: supervisor, pipeline, fan-out and join, router, peers, quorum, handoff and typed delegation.
- An agent spawns subagents at run time: short-lived agents that each do one task, return a typed result to the agent that spawned them and end, leaving nothing running.
- A subagent draws on the budget, deadline and cancellation of the agent that spawned it, and holds only the permissions and resources that agent grants it, or, when it is isolated, only the resources it declares itself.
- Token, time, CPU, memory and concurrency budgets apply across every child agent.
- Runs pause, wait for human approval and reconcile side effects safely, and a run whose agent declares a storage point resumes and survives restarts.
- 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.
- State and long-term memory are scoped per tenant, agent, session or subject, with retention and deletion rules.
- 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.
03
Models and knowledge
- A built-in client for OpenAI-compatible APIs, including realtime sessions, comes with the language, with explicit or default parameters and no server or SDK to add.
- Model policies cover exactly one call, a bounded loop, routing, ordered fallback, parallel fan-out and an independent verifier model.
- You choose local or cloud models: local model servers, optional packages for major cloud providers, and clients for inference endpoints you run yourself.
- A built-in MCP client discovers and calls MCP tools, and an optional package exposes your agents as MCP tools.
Show all 9Show fewer
- A skill is a versioned, reusable bundle of instructions, typed tools and functions that an agent or subagent loads through the skills it declares; its tools run only where the agent's permissions allow, and it adds nothing the agent did not declare.
- Agents discover remote agents and delegate long-running work to them over A2A.
- Retrieval (RAG) covers the whole lifecycle (ingest, chunk, embed, index, update and delete, then retrieve with ranking and provenance), and you can bring your own knowledge connectors.
- Agents take and produce text, structured data, images, audio, files and video frames, and process live camera or sensor streams with bounded buffers and backpressure.
- Prompts are treated as releasable business logic, with evaluations, recorded-model regression tests, drift checks, and promotion with one-step rollback, while active runs stay pinned to their version.
04
Services and connections
- A console agent needs no server: add the HTTP package and declare routes to make it a REST API, or remove them to go back to console-only.
- Optional HTTP, gRPC, WebSocket and socket servers send each reply to the authenticated caller that asked for it.
- Event, polling and scheduled triggers have overlap, missed-run and time-zone policies, and survive restarts when their agent declares a storage point.
- Code calls a typed service, and the deployment decides whether it runs in the same process, on another machine, over HTTPS or over gRPC.
Show all 12Show fewer
- Every edge is a typed, two-way channel: OEL generates the communication between nodes, agents and subagents from your edge declarations, with no client or server code for you to write.
- The same edge runs in one process, between processes or over the network, as your deployment places it, with no change to your source, and over the network it uses OEL's built-in gRPC-compatible transport with TLS.
- Services built elsewhere call your agents over gRPC, because each network edge publishes its interface in gRPC's standard interface-definition format.
- Connections are resilient, with idempotency-aware retries, backpressure, circuit breakers and health checks.
- Optional packages connect agents to streams, caches and message brokers.
- You call your existing Python, JavaScript, Java or .NET programs, shell commands and operating-system operations as typed tools, with runtimes you provide, locally or on a remote worker.
- You write your own connectors for services, models, knowledge sources, transports and log sinks.
- 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, and a GET-only API no POST handlers.
05
Tooling
- One command creates a ready-to-build project.
- One command-line tool checks, formats, compiles, builds and runs your code, with diagnostics that point at your source.
- A reference map shows what references what, and lists unused code and packages, for a whole project, a folder or one file.
- The command line finds references, renames safely and generates API documentation.
Show all 8Show fewer
- You debug at source level in standard native debuggers.
- The OEL 1.0.0 build for Linux, macOS or Windows comes with target management and a health check, and desktop and server programs written in OEL alone need nothing else installed.
- Changes to the language or project format come with explicit, reviewable migrations.
- You record control and orchestration runs and replay them to find the first point where behavior diverged.
06
Platforms and deployment
- You build for Linux, macOS, Windows, containers and microcontroller boards from one language.
- Programs run on servers, containers and devices, with nothing to compile or download at startup.
- Programs build into standalone native binaries, including static Linux binaries.
- Minimal container images start with nothing to compile, install or download at startup.
Show all 11Show fewer
- A multi-core, nonblocking runtime needs no thread per user, and programs that don't need worker threads don't get them.
- Agents are multi-tenant from the start: a trusted tenant identity flows through every call, store, log and reply, with fair scheduling and predictable behavior under overload.
- Per-agent CPU and memory limits state whether each limit is hard-enforced or accounted.
- Time and token usage is reported by default on every channel (command line, HTTP, gRPC, WebSocket and sockets), and you can turn off each field without disabling the limits behind it.
- Structured logs go to the console, a file, or custom or remote sinks, with redaction, rotation and retention.
- You host your built application on servers you operate, with health checks for the storage, databases and models it declares, graceful shutdown and log rotation.
- OEL 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.
- One language reaches from servers down to microcontrollers, and a feature a target cannot support fails at compile time, not on the device.
- The smallest profile needs no heap and no operating system.
- Concurrency on microcontrollers is safe, with bounded mailboxes, timers, cooperative scheduling, supervision and restarts.
- Hardware access covers GPIO, clocks, UART, interrupts and defined panic behavior.
Show all 9Show fewer
- Runtimes come in sizes for each class of device, from servers down to coin-cell-class microcontrollers, and a program that does not fit its device's class is refused when you build it.
- Firmware images come with RAM, flash and stack reports.
- You flash and monitor supported boards from the command line, using each board's standard flashing tools.
- Prompt-driven agents run on small devices through OEL Gateway, and each device keeps its safe local behavior when offline.
- An optional heap, storage, networking and TLS are available on small networked boards.
08
Robotics, science and quantum
Optional packages for robotics, scientific computing and quantum computing include ROS 2 support and quantum circuits that export to OpenQASM and QIR.
Robotics
- Optional robotics packages provide typed units, coordinate frames, timestamps and sensor and actuator schemas.
- The same code runs against virtual hardware, a simulator or a real robot.
- Robot agents connect over ROS 2 and DDS, including the DDS-XRCE standard for constrained hardware.
- Safety stays deterministic: AI proposes, validators check freshness and limits, and the watchdog and emergency stop stay in charge.
Show all 7Show fewer
- Optional packages cover kinematics, dynamics, trajectories, optimal control, localization, mapping, navigation and vision.
- Optional device packages, written in OEL, drive common robotics components: motor drivers, servos, inertial sensors, encoders and range sensors.
- Hierarchical robot agents (for example eyes, face, body and a coordinator) come with ready-made recipes.
Scientific and quantum computing
- Optional packages provide numerical arrays, complex numbers and linear algebra.
- Optional packages provide optimization, signal processing, integration and automatic differentiation.
- Quantum circuits are typed, with standard and custom gates.
- Quantum simulators (statevector, density-matrix, stabilizer and tensor-network) state their cost and precision limits.
Show all 8Show fewer
- Circuits export to OpenQASM and QIR, with circuit lowering and routing.
- Quantum jobs run asynchronously on quantum hardware providers, with budgets, cancellation and tenant-scoped credentials.
- Optional packages cover quantum algorithms, error mitigation and correction, quantum machine learning and quantum chemistry.
- Hybrid agent workflows let an agent propose a circuit, validate it, simulate it, optionally run it on hardware and check the result.
- The OEL toolchain is self-contained: one install takes your OEL code all the way to a native program.
- The OEL 1.0.0 release is signed and reproducible, with a software bill of materials.
- Each build records exactly what went into it, so you can check what a program contains.
Follow OEL
Follow the OEL updates feed in any feed reader: it announces every OEL release and news about OEL.