Package catalog

The official registry describes how official packages are published and checked.

What every official package shares

• Written in AEL. Every package ships as compiled, verified AEL, with no bundled native code and no install scripts.
• You run the outside systems. When a package talks to an outside system, such as a database, a model server, a robot or a quantum computer, it uses that system's own interface, and you run that system.
• 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.
• Added like any other package. ael pack add server/http adds one; see Using packages.

Servers and APIs

server/http, server/grpc, server/websocket, server/mcp

• A console agent needs no server: add server/http and declare routes to make it a REST API, or remove them to go back to console-only. Routes live in .routes.ael files, a file role that server/http adds, and main mounts them.
• Optional HTTP, gRPC, WebSocket and socket servers send each reply to the authenticated caller that asked for it.
• An optional package exposes your agents as MCP tools. Calling MCP tools needs no package, because a built-in MCP client discovers and calls them; see Tools and MCP.
• Each server is a separate package: adding server/http never brings the gRPC, WebSocket or MCP server packages.

server/grpc is for the gRPC services you design yourself, for outside clients. The edges between your own components need no package: 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 AEL'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. Communication between agents describes the built-in transport.

Services and APIs shows one agent served over each of them.

Model providers

You choose local or cloud models: local model servers, optional packages for major cloud providers, and clients for inference endpoints you run yourself. The model client that is part of AEL itself is described under Model client, and model bindings and policies under Models and providers.

Caching and messaging

Optional packages connect agents to streams, caches and message brokers. You run the cache or broker; the package speaks its protocol.

Storage and databases

storage/file, database/sql

Optional storage packages keep data in files on a local or mounted path or in object storage, and connect to SQL databases you run; each can be an agent's storage point.

• Files. storage/file keeps data in a directory on the local machine or on a mounted path.
• Object storage. Packages of the object-storage family keep data in a bucket of an object-storage service.
• SQL databases. database/sql is the typed SQL contract: prepared statements with placeholders for their values, typed rows, transactions and typed errors. Database packages implement it for an SQL database server you run, and each can be a database binding and, with its transactions, a storage point.
• Nothing provisioned. You run the database and provide the bucket: no package bundles or provisions one.

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. AEL itself contains no database: the memory, knowledge and durable state of your runs live in the storage, database and vector-store packages you select. A database binding runs only the statements you write: a query a model proposes is data, and it runs only when a validator you write admits it.

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. Bindings and storage describes the bindings.

Vector stores

vector/store

Optional vector-store packages index and search your knowledge for retrieval, in a database you run.

• vector/store is the vector-store contract: collections with a declared dimension and distance measure, upserts and deletions by chunk with the version of its source, nearest-neighbour queries with metadata filters and a number of results, and commits that become visible to queries all at once.
• Its adapter in AEL 1.0.0 runs over an SQL database you run.
• A vector store indexes the embeddings that your embedding provider produces, through a model call; it computes none itself.

An agent reaches a vector store through its knowledge binding; Retrieval over your documents shows retrieval from end to end.

Skills

skills/<publisher>/<name>

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.

• Skill packages take names of the form skills/<publisher>/<name>.
• A skill is pinned by its version and the fingerprint of its instructions.

Skills describes how you write, package and load one.

Running your existing programs as tools

execution/process, execution/shell, execution/terminal, execution/remote, execution/python, execution/javascript, execution/jvm, execution/dotnet

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. The programs are yours: the package that starts them is written in AEL, and it never installs a runtime for you. Calling your existing programs shows how, and Files and processes is the reference.

Robotics

robotics/transforms, robotics/sensors, robotics/simulation, robotics/kinematics, robotics/dynamics, robotics/planning, robotics/control, robotics/estimation, robotics/mapping, robotics/calibration, robotics/middleware/ros2

• Optional robotics packages provide typed units, coordinate frames, timestamps and sensor and actuator schemas.
• Robot agents connect over ROS 2 and DDS, including the DDS-XRCE standard for constrained hardware.
• Optional packages cover kinematics, dynamics, trajectories, optimal control, localization, mapping, navigation and vision.
• Optional device packages, written in AEL, drive common robotics components: motor drivers, servos, inertial sensors, encoders and range sensors.

Robotics describes each package.

Scientific computing

math/array, math/linalg, math/optimization, math/signal, math/integration, math/autodiff, math/random, math/sparse

Optional packages provide numerical arrays, complex numbers and linear algebra, and optimization, signal processing, integration and automatic differentiation. Scientific computing describes each package.

Quantum computing

quantum/circuit, quantum/gates/standard, quantum/sim/statevector, quantum/sim/density-matrix, quantum/sim/stabilizer, quantum/sim/tensor-network, quantum/compile/openqasm, quantum/compile/qir, quantum/algorithms/…, quantum/control/pulse

• Quantum circuits are typed, with standard and custom gates.
• Quantum simulators (statevector, density-matrix, stabilizer and tensor-network) state their cost and precision limits.
• 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.

Quantum computing describes each package.

Your own connectors

You write your own connectors for services, models, knowledge sources, transports and log sinks, in AEL. To share one between projects, build it into a package of your own: see Creating a package and Private packages.

For what these families make possible, see Use cases.