Loong: a Rust skeleton for policy-authorized AI agents, not yet a product

The problem Loong is aimed at: authorization before side effects

Most agent frameworks treat tool calls as a dispatch problem. The model emits a call, the runtime executes it, and safety is bolted on afterwards through sandboxes, allowlists, or a second model that reviews the request. Loong inverts the order. The README describes modeling outbound effects as Actions and authorizing them before execution, with policy authorization as the primary boundary and sandboxes or model review as defense in depth. That is a specific architectural commitment: the check lives in the execution path, not in a wrapper around it. The audience follows from that choice. This is for engineers building vertical agents where an unauthorized outbound effect (a message sent, a file written, a request made to an external service) is the failure that matters, and who are willing to pay for a policy layer in the hot path. It is written in Rust, and the README ties that to predictable runtime overhead on core execution paths, while noting that concrete performance claims require representative workload benchmarks. No such benchmarks are published in the material available, so treat the performance framing as intent rather than a measured result.

What the repository actually contains right now

The README opens with an important note: this repository is an independent-history rewrite of Loong and currently contains an architecture and contract skeleton, not a usable agent product. The Current Status section repeats it: the rewrite is at an early foundation stage and is not ready to install or use as a complete agent product yet. The stated policy is to describe capabilities as they become real rather than presenting planned work as finished, which is a reasonable posture for a project at this stage but also means the gap between the README's design vocabulary (Actions, policy authorization, the Actor runtime) and working code is the first thing to check. The repository layout visible in the README includes crates/actor with its own README describing a lifetime model for running, extending, stopping, and restarting components. It also references ARCHITECTURE.md for technical design and docs/open-questions.md for unresolved decisions. Those two files are where the real state of the project lives, because the README deliberately stays at the level of principles.

Two extension paths, one of which is still being designed

Loong intends to support two ways of extending the product. The first is compiling Rust integrations directly into the host, which suits deep or performance-sensitive work. The second is loading scripts and similar extensions at runtime for faster iteration without rebuilding the host application. The README states that the same security expectations apply to both, which is the interesting part: a runtime-loaded script is still subject to the same Action authorization boundary as compiled code, or the boundary is not worth much. But the README also says the exact runtime extension system is still being designed. So of the two paths, only the compiled one has a clear story today. If your plan depends on hot-loading plugins or user-supplied scripts, there is no contract to build against yet, and any work you do there is speculative. This is the kind of section that would normally be padded with roadmap language; the honest version is that one half of the extensibility pitch is a stated intention with no documented mechanism.

Getting it running: the three commands the README documents

There is no install path for Loong as a product, and the README says so. What it does document is the development workflow for the workspace. The current checks are cargo fmt --all -- --check, cargo check --workspace --all-targets, and cargo test --workspace. Run those from the repository root against the rewrite branch, which is the default branch. There is no documented configuration file, no environment variable list, and no CLI entry point in the supplied material, so anyone expecting a loong.toml with policy rules will not find one described here. The named artifacts are crates.io packages loac and loac-macros, with the release workflow documented in docs/development/releasing.md. If you want to depend on Loong rather than build it from source, that release guide and the published crate versions are the things to consult, and the recent release list (v0.1.2-alpha.2, v0.1.2-alpha.1, v0.1.0-alpha.2) shows the project is still in alpha prereleases.

The limitation that matters: a skeleton invites premature integration

The failure mode here is not a bug. It is adoption timing. A repository with a strong architectural argument, a homepage, a logo, and a two-language README reads as more finished than it is. The README's own warning is the corrective: architecture and contract skeleton, not a usable agent product. If you build a vertical agent on Loong today, you are building on interfaces that docs/open-questions.md explicitly lists as unresolved, and you will absorb the cost of every contract change during the rewrite. The second limitation is scope. Loong is a foundation, not a framework with batteries: there is no documented model provider integration, no tool registry, no memory subsystem, and no prompt or conversation layer in the material provided. The README's stance is that new product areas will be added as their responsibilities and safety boundaries become clear, which keeps the core understandable but means you supply most of an agent yourself. If you need something to ship this quarter, this is the wrong tool, and the README agrees.

Where Loong differs from LangChain-style orchestration

LangChain and its Rust-adjacent equivalents are orchestration libraries. Their center of gravity is composition: chains, tools, retrievers, and model adapters wired together, with safety handled by whatever guardrail callback or output parser you attach. Loong's center of gravity is the authorization boundary around outbound effects, expressed as Actions authorized before execution, with the Actor runtime providing the lifecycle for the components that produce those effects. The difference in approach is where the abstraction sits. In an orchestration framework, the unit you compose is a step in a pipeline, and policy is a hook. In Loong, the unit is an effect that must pass a policy decision before it happens, and composition is secondary. That makes Loong a poor fit for rapid prototyping of multi-step reasoning workflows, where you want adapters and prompt templates immediately. It makes it a more plausible fit for systems where the audit question is 'what was allowed to leave this process, and who said so'. The trade-off is real: a policy-first design adds a decision point to every outbound action, and the README does not yet document how that decision is cached, batched, or made cheap.

Maintenance, licence, and what to verify before depending on it

Loong is MIT licensed under LICENSE-MIT. MIT is permissive: you can use, modify, and redistribute it, including in closed products, provided the copyright notice and permission notice are retained. That is a plain statement of what the licence identifier means, not legal advice; if you are embedding it in a commercial product, have counsel read the actual file. On maintenance cost, the practical signals are the release cadence and the branch. The default branch is rewrite, and the most recent release is an alpha prerelease (v0.1.2-alpha.2), so pinning to a stable version is not currently an option. Upgrading across the alpha series means tracking ARCHITECTURE.md and docs/open-questions.md, because those are where contract changes will surface first. The three cargo checks above are the cheapest way to confirm a checkout builds on your toolchain before you invest further. Verify the Action authorization path exists in code rather than only in prose, verify what crates/actor actually implements against its README, and confirm loac and loac-macros resolve on crates.io at a version you can pin. Until those three hold, Loong is a design document with a Rust workspace attached.

Editorial conclusion

Adopt Loong only if you are evaluating agent authorization architecture in Rust and are willing to read ARCHITECTURE.md and docs/open-questions.md before writing anything against it. Do not adopt it as a runtime for a shipping assistant: the README states it is not ready to install or use as a complete agent product, and the runtime extension system is still being designed. Before committing, verify three things in the repository: whether the Action authorization path is wired into code or only documented, whether crates/actor exposes the lifecycle behavior the Actor runtime README claims, and whether loac and loac-macros are published on crates.io at a version you can actually pin.

Official sources

1. eastreams/loong on GitHub
2. License: MIT
3. Project website
4. README
5. Releases