AINL and Rust crates

How Rust fits into the AINL ecosystem, where to find crates, and a safe way to wire them into your own binaries — without hard-coding version numbers that will go stale. Authoritative source: github.com/sbhooley/ainativelang and the publish index at crates.io/users/sbhooley.

1. Why Rust is in the story

The reference developer loop for writing and validating workflows is the Python package and ainl CLI: .ainl source compiles to portable IR, then runs in the Python runtime with adapters. Separately, production stacks (including ArmaraOS-class hosts) also use native Rust components for graph memory, context assembly, policy contracts, and other host concerns. Upstream release notes discuss convergence between Python runtime semantics and Rust crates in those stacks — use the monorepo docs as the final word for your version.

2. Where the Rust packages live

Browse by author: crates.io/users/sbhooley — lists published crates (names, download counts, and last release). Always copy dependency names and versions from this page or from each crate’s own page rather than from a static tutorial.
Read integration docs in the repo: adapter contracts, graph memory, and host integration paths are under docs/ in the GitHub project. If you are embedding a Rust service next to a Python runner, start from those documents and the test suite, not from guesswork in Cargo.toml.

3. Recommended split of responsibilities

AINL program logic — keep in .ainl files, iterate with ainl check / ainl run.
Rust binary or library — use to embed execution hosts, call into shared infrastructure, or link crates that provide memory/context/policy capabilities your deployment requires.
MCP / HTTP — if you only need another process to call AINL, the MCP server and ainl serve path may be simpler than writing a new Rust embedding first.

4. Step-by-step: add a Rust dependency safely

Open crates.io/users/sbhooley and decide which published crate matches your need (read each crate’s README on crates.io and its repo link).
In your Rust workspace, add the dependency with the version shown on crates.io.
Run cargo check and fix API mismatches using the crate’s own docs; upstream renames do happen between minor releases.
If you are cloning the monorepo to work across Python + Rust, follow CONTRIBUTING.md and docs/INSTALL.md for the supported bootstrap (Python venv, optional Rust workspace).

# Discover published crates (names and versions change over time)
# Replace MY_CRATE with a name from your crates.io browse:
cargo search MY_CRATE --limit 5

# In Cargo.toml, pin versions to what crates.io shows for that crate, e.g.:
# [dependencies]
# some-ainl-crate = "x.y.z"

5. Finding the right crate for your problem

Crates in this ecosystem are tagged with different roles (e.g. graph-native memory, context window assembly, policy contracts, failure learning). Do notassume a single crate name from a blog post: open the user page, read descriptions, and follow the "Repository" and "Documentation" links on each crate. If two crates look similar, the README in the monorepo usually explains the boundary.

6. When you still need the Python runtime

For day-to-day workflow authoring, testing adapters, and generating traces, the Python CLI remains the most documented path. Use Rust for native embedding when you have a clear requirement (latency, host integration, or shipping a static binary) that the MCP or HTTP server cannot satisfy.

→ Build AI agents with AINL (Python / CLI / MCP)

Crate names and versions change; crates.io/users/sbhooley and each crate page are the source of truth.