ldclabs/anda: A Rust Framework Where Agents, Tools and Models Share One Runtime

The problem anda targets: agent logic scattered across application code

Most agent projects start as a script that calls a model, parses a tool call, runs a function, and loops. That works until the second agent arrives, or the second model provider, or a session that needs to survive a process restart. At that point the loop, the tool registry and the provider adapters are entangled, and swapping one model tier for another means editing call sites.

Anda's answer is to make those pieces registrable components. The README describes it as "a Rust framework for building composable AI agent runtimes" and states that the core engine lets developers register agents and tools, route model requests by capability labels, call local or remote functions, isolate context state, and add persistence or memory when an application needs it. The intended audience is stated plainly: application builders use anda_cli and anda_engine_server to run configured engines, while developers build custom agents and tools against the anda_core traits and extend anda_engine with runtime features.

The repository layout supports that split. anda_core holds traits, types and runtime contracts; anda_engine holds the agent runtime, orchestration, contexts, models and extensions; anda_engine_server is an HTTP server for serving one or more engines; anda_cli is the command-line interface for engine servers; anda_web3_client is described as a Web3 client for non-TEE environments. That last crate is the one signal that the project has a deployment model beyond a plain HTTP service, though the README does not explain it further.

CompletionRunner is the actual agent loop

The orchestration story centres on a component named CompletionRunner. According to the README, it handles iterative model turns, tool calls, agent calls, usage accounting, artifacts, steering messages, follow-up messages, cancellation, and compact continuation handoffs for long-running sessions.

That list is more informative than a feature bullet usually is, because it names the parts of an agent loop that are tedious to write and easy to get wrong. Usage accounting implies token or cost tracking is attached to the loop rather than bolted on by the caller. Artifacts suggest outputs are collected as first-class objects. Steering and follow-up messages imply a session can receive input while a run is in progress, which is a different design from a single request-response call. The compact continuation handoff is the mechanism for sessions that outgrow a context window: rather than failing, the run hands off a compacted continuation.

The README does not specify how compaction is triggered, what is preserved, or how handoff state is serialised. Those are the questions to answer from docs/architecture.md and the anda_engine source before you depend on long sessions in production.

Model routing by capability label, not by provider name

Anda routes completion requests through labelled model tiers. The README gives primary, pro, flash and lite as examples, with provider-specific adapters sitting behind a common request and output contract.

The design consequence is that agent code asks for a tier, not for a vendor. Swapping the model behind lite is an adapter and configuration change rather than a code change, and a single workflow can mix a strong tier for planning with a cheap tier for extraction without branching on provider. The cost is that the label set becomes an interface of its own: if primary means one model in staging and another in production, behaviour differences show up as agent behaviour differences, not as configuration errors. The README does not state whether tier definitions are validated at startup or whether a missing tier fails fast, so treat that as something to verify rather than assume.

BaseCtx, AgentCtx and the scoping rules

Each agent or tool runs inside a scoped execution context. The README names two types, BaseCtx and AgentCtx, and says they provide isolated state, cache, object storage, HTTP calls, signed calls, cancellation, and child contexts.

Grouping those capabilities on a context object is what keeps tools testable: a tool that needs HTTP goes through the context rather than opening its own client, and cancellation propagates through the same object. Child contexts mean a sub-agent or nested tool call gets its own scope instead of sharing mutable state with its parent.

The limitation is that the README does not describe the isolation boundary in detail. Whether state is isolated per run, per session or per agent instance is not stated, and neither is the lifetime of cache entries or the semantics of signed calls. If your design depends on strict separation between concurrent sessions, read the architecture document and the context implementations before you build on it.

Getting an engine running: crates, CLI and server

The README does not include an install or quickstart command block, so the entry points have to be inferred from the crate list and the stated usage. Application builders are directed to anda_cli and anda_engine_server to run and interact with configured engines. Developers are directed to implement the anda_core traits for custom agents and tools, and to extend anda_engine for runtime features.

The practical sequence is therefore: add the core and engine crates as dependencies, implement the agent and tool traits from anda_core, register those components with the engine, and expose the result through anda_engine_server, using anda_cli to interact with it. The README does not publish crate names on crates.io, feature flags, environment variable names, or a configuration file schema, so any of those you see in the source should be treated as the source of truth rather than as documented API.

The extension surface is broader than the core. Optional extensions are described as providing conversation storage, KIP-based memory tools, filesystem access, shell execution, fetch, notes, todos, and file-backed skills. Note that filesystem access, shell execution and fetch are capabilities an agent can be granted, which means the security posture of a deployment depends on how those extensions are wired, not only on the model.

Tool discovery: tools_groups and tools_select

One of the more specific mechanisms in the README is discovery-aware tool bundles. Static tools, dynamic providers and MCP servers can expose capability groups. An agent surveys related bundles with tools_groups, then expands a group with tools_select only when the schemas are needed.

This addresses a concrete problem: dumping every tool schema into the prompt on every turn costs tokens and degrades selection as the tool count grows. Two-stage discovery keeps the initial surface small and pays the schema cost only for the group the agent decides it needs. It also fits MCP servers naturally, since a server can advertise a group rather than forcing every tool into the first prompt.

The trade-off is an extra round trip and a new failure mode: an agent that picks the wrong group, or fails to call tools_select at all, will not see the tools it needed. The README does not describe how group membership is declared or how selection errors surface, so this is a mechanism to test directly with your own tool set before relying on it.

Where anda is the wrong choice

Anda is a framework, not a product. There is no hosted runtime, no managed memory service and no visual builder described in the README. If you want to configure an agent in a browser and deploy it without writing Rust, this is the wrong layer.

The language choice narrows the field further. Tools and agents are Rust traits, so a team whose integrations live in Python will either port them or run them behind a service boundary. The README does not describe a Python binding or a foreign-function bridge.

There is also a maturity signal worth reading carefully. The release history jumps from v0.8.0 in September 2025 to v0.12.0 in May 2026 to v0.15.0 in August 2026. Pre-1.0 version numbers with that cadence mean the trait and API surface can still move, and the README's own framing of anda_core as providing "stable traits" is a claim about intent rather than a compatibility guarantee. Pin versions and read the release notes between them.

Finally, the README is thin on operations. There is no discussion of concurrency limits, backpressure, observability, or how anda_engine_server handles multiple engines under load. Those gaps matter more than feature lists when you are deciding whether to run this in front of users.

Alternatives and the difference in approach

The nearest comparison inside the same ecosystem is KIP, the Knowledge Interaction Protocol that the README lists as a related project and that Anda's memory tools use. KIP is a protocol, not a runtime: it defines how knowledge is exchanged, while anda defines how agents, tools and models are composed and executed. If your problem is a shared memory format across systems, KIP is the relevant piece; if your problem is the execution loop, it is not.

The sibling products make a similar distinction. Anda Brain is described as a persistent memory and cognition product built on the framework, and Anda Bot as a personal AI assistant and application runtime built on it. Both are applications; anda is the layer beneath them. Choosing between them is a build-versus-adopt decision, not a feature comparison.

Against general agent frameworks in other languages, the difference is where extensibility lives. Anda puts it in Rust traits in anda_core, with a runner that owns turns, tool calls, usage accounting and cancellation. Frameworks that expose agent behaviour as configuration put extensibility in prompts and plugin manifests instead. The first approach gives you compile-time checking and predictable runtime behaviour at the cost of writing and rebuilding Rust; the second gives faster iteration at the cost of weaker guarantees about what a component can do.

Licence, maintenance and upgrade cost

The repository metadata supplied here lists Apache-2.0 as the licence. The README's own licence section says the opposite: it states that ldclabs/anda is licensed under the MIT License and points to LICENSE-MIT for the full text. Those two statements cannot both describe the same distribution, and the discrepancy is unresolved in the material available. Check the LICENSE-MIT file and the crate manifests before you rely on either.

The practical difference matters for redistribution and for patent language, but this is not legal advice; if you are embedding anda in a product, have someone qualified read the actual licence file.

Upgrade cost is driven by the pre-1.0 cadence. Three releases across roughly eleven months, with a four-version jump between May and August 2026, means you should expect trait signatures and configuration to change between minor versions. The mitigation is mechanical: pin exact versions in Cargo.toml, read the release notes for each version you skip, and keep your agent and tool implementations thin so that a trait change is a small diff. The README does not publish a deprecation policy or a support window, so treat any compatibility statement as unverified until you find it in the release notes.

Editorial conclusion

Adopt anda if you are building a Rust service and want the agent loop, tool registration and model routing to live behind your own traits rather than inside a vendor SDK. Do not adopt it if you need a hosted control plane, a visual builder, or a Python ecosystem of prebuilt integrations, because none of that is described here. Before committing, read docs/architecture.md, confirm which crate exposes the traits you intend to implement, and check the LICENSE-MIT file against the Apache-2.0 metadata that this repository listing reports.

Official sources

1. ldclabs/anda on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases