AutoAgents

to scale to thousands of agents. And open-source for agents is still not where it should be. Right now, I cannot easily reuse agents built by domain experts the same way I reuse open-source software. These issues bothered me, and I realized that if agents are ever going to be democratized, they need to be open and easy to use. Just like Docker solved system dependencies, we need something similar for agents. That is why I started building an agent framework in Rust. It is modular and follows the principle of true agency: an agent is an entity with tools, memory, and an executor. In AutoAgents, users can independently create and modify tools, executors, and memory. With AutoAgents, I saw that powerful agents could be built without compromising on performance or memory the way many other frameworks do. But the other problems still remained: re-sharing agents, sandboxing, and scaling to thousands of agents. So I created Odyssey — a bundle-first agent runtime written in Rust on top of AutoAgents, the Rust agent framework. It lets you define an agent once, package it as a portable artifact, and run it through the same execution model across local development, embedded SDK usage, shared runtime servers, and terminal workflows. Both AutoAgents and Odyssey are fully open source and built in Rust, and I am planning to build an Odyssey Agent Hub soon, with additional features like WASM tools, custom memory layers, and more. My vision is to democratize agents so they are available to everyone — securely and performantly. Being open is not enough; agents also need to be secure. The project is still in alpha, but it is in a working state. AutoAgents Repo -> https://github.com/liquidos-ai/AutoAgents Odyssey Repo -> https://github.com/liquidos-ai/Odyssey I would really appreciate feedback — especially from anyone who has dealt with similar problems. Your feedback help me shape the product. Thanks for your time in advance!

u wrap any provider with composable layers: ```rust let llm = PipelineBuilder::new(llama_cpp_provider) .add_layer(CacheLayer::new(CacheConfig { chat_key_mode: ChatCacheKeyMode::UserPromptOnly, ttl: Some(Duration::from_secs(900)), max_size: Some(512), ..Default::default() })) .add_layer( Guardrails::builder() .input_guard(RegexPiiRedactionGuard::default()) .input_guard(PromptInjectionGuard::default()) .enforcement_policy(EnforcementPolicy::Block) .build() .layer(), ) .build(); ``` That's it. The llm variable implements LLMProvider — you pass it to any agent and the layers are structurally enforced. Can't bypass them, can't forget them. The broader framework: AutoAgents is a full agent framework — memory, tool use, multi-agent orchestration, the works. The pipeline feature works with any provider: llama.cpp (local), Ollama, OpenAI, Anthropic, etc. Same .add_layer() API regardless of backend. Written in Rust. No GC pauses. Memory-safe. The framework has ~400 stars and is being used in production for edge AI deployments. A note on maturity: The guardrails and pipeline layers are still early — the guard implementations are basic, observability isn't there yet, and we're iterating on the API surface. But the underlying architecture is solid and stable. The middleware pattern, the trait-based guard system, and the provider-agnostic pipeline contract aren't going to change. We're building on a foundation we're confident in, and shipping the layers incrementally. Early feedback shapes what gets built next. I'd genuinely like feedback on: The layer ordering question — should we enforce a recommended order or keep it flexible? What guardrail implementations would you actually use in production? Is the Tower-middleware mental model the right framing, or is there a better analogy? Full example with local Qwen3-VL-8B: https://github.com/liquidos-ai/AutoAgents/tree/main/examples... Thanks

rks are bad. They got this ecosystem started and the DX is genuinely great. We're saying that at production scale, the runtime cost of convenience becomes a real line item — and teams deserve to see those numbers before they commit. A small peek into the memory usage: Rust frameworks: ~1 GB at 10 sessions Python frameworks: 5–9 GB at 10 sessions Scale that to 500 concurrent users on AWS and you're looking at $390/mo vs $3,121/mo. Same task. Same model. Same output. The benchmark is released on GitHub so you can explore every metric yourself — latency distributions, P95/P99 tails, CPU, memory. AutoAgents Repo: https://github.com/liquidos-ai/AutoAgents Benchmark Repo: https://github.com/liquidos-ai/autoagents-bench I'd love your feedback on AutoAgents. We're determined to build the best agent framework with performance and safety-first design. Thanks

es sense. This demo is intentionally limited. It’s a preview of direction rather than a feature-complete product, and we’re sharing it early to learn before open-sourcing the full platform. We’d really appreciate thoughts on: Whether you’d consider using something like this, and for what use cases What would need to exist for real-world adoption Whether the framing makes sense, or if it should be positioned differently If you’re interested in agent orchestration, local-first AI tooling, Rust-based runtimes, or alternatives to cloud-centric LLM frameworks, we’d love to hear your perspective. Open-source agent framework (Rust): https://github.com/liquidos-ai/AutoAgents If this direction resonates, we’re also keeping a small waitlist at https://liquidos.ai to share updates as the platform evolves. Happy to answer questions and take critiques.

executor The goal is to enable real research workflows while maintaining strong performance and developer-friendly usability. The project doesn’t stop at building agents, either — we want to ensure you can run them efficiently on any accelerated hardware, from GPUs to edge devices. Would love feedback from the HN community!