<h1>Why I Built Another LLM Agent Framework (And Why You Might Actually Care)</h1>
Yeah, I know. Another LLM agent framework. The last thing the world needs, right?
But hear me out—I built <a href="https://crates.io/crates/helios-engine" target="_blank" rel="noopener nofollow">helios-engine</a> because every existing framework I tried made me want to throw my laptop out the window. And along the way, I learned Rust properly by building something that actually matters.
<h2>The Problem: Every Framework Was Broken in Its Own Special Way</h2>
I tried them all. LangChain, LlamaIndex, AutoGPT, CrewAI—you name it, I fought with it. Here’s what I kept running into:
<h3>Vendor Lock-In Everywhere</h3>
Most frameworks are married to OpenAI. Want to use Claude? Gemini? Some open-source model you’re hosting yourself? Good luck navigating their half-baked adapter patterns. And if you want to switch providers mid-project? Better start refactoring.
<h3>“Local Support” That Doesn’t Actually Work</h3>
Frameworks claim they support local models. What they mean is “we have a broken integration with Ollama that throws cryptic errors half the time.” Running a GGUF model directly? Offline inference? Forget about it.
<h3>Syntax That Fights You</h3>
Either you’re drowning in boilerplate and configuration files, or you’re using some “magical” DSL that breaks the moment you need to do something the framework designers didn’t anticipate. Both suck.
<h3>No Real Multi-Agent Support</h3>
Everyone talks about “agents,” but most frameworks give you one agent that can kinda-sorta call tools. Building an actual system where multiple agents collaborate? You’re on your own.
<h3>The Python Tax</h3>
Most of these frameworks are Python. Which is fine… until you want performance, type safety, or to deploy something that doesn’t need a 500MB Docker image just to run.
<h2>So I Built helios-engine</h2>
I had two goals:
<ol>
<li>Fix all the shit that annoyed me about existing frameworks</li>
<li>Actually learn Rust instead of just reading the book and building toy projects</li>
</ol>
<h3>What Makes It Different</h3>
No Vendor Lock-In
<pre><code class="language-rust">// OpenAI
let client = LLMClient::new(LLMProviderType::OpenAI(config)).await?;

// Any OpenAI-compatible API (Groq, Together, local inference servers)
let client = LLMClient::new(LLMProviderType::Custom(config)).await?;

// True local GGUF models (no server required)
let client = LLMClient::new(LLMProviderType::Local(config)).await?;
</code></pre>
Same interface. Zero refactoring to switch providers. The client doesn’t care where the tokens come from.
Local Models That Actually Work
The local mode uses llama.cpp under the hood. First run downloads the model from HuggingFace. After that, it’s fully offline. No servers, no containers, no Python interpreter. Just Rust and the model file.
<pre><code class="language-rust">let local_config = LocalConfig {
 huggingface_repo: &quot;unsloth/Qwen3-0.6B-GGUF&quot;.to_string(),
 model_file: &quot;Qwen3-0.6B-Q4_K_M.gguf&quot;.to_string(),
 temperature: 0.7,
 max_tokens: 2048,
};
</code></pre>
Forest of Agents
Multiple agents that can actually collaborate. Each agent has its own personality, tools, and context. They can delegate tasks to each other, share information, and work together on complex problems.
<pre><code class="language-rust">let researcher = AgentBuilder::new()
 .name(&quot;Researcher&quot;)
 .goal(&quot;Find accurate information&quot;)
 .tools(vec![search_tool, web_scraper_tool])
 .build()?;

let writer = AgentBuilder::new()
 .name(&quot;Writer&quot;)
 .goal(&quot;Create engaging content&quot;)
 .tools(vec![markdown_tool])
 .build()?;
</code></pre>
Clean Syntax
No magic. No configuration hell. Just Rust code that does what it looks like it does.
<pre><code class="language-rust">let agent = AgentBuilder::new()
 .name(&quot;Assistant&quot;)
 .goal(&quot;Help the user&quot;)
 .instruction(&quot;You are helpful and concise&quot;)
 .tool(calculator)
 .tool(web_search)
 .build()?;

agent.run(&quot;What&#x27;s 147 * 923?&quot;).await?;
</code></pre>
Tool Belt
Tools are just async functions. Register them, and agents can use them. That’s it.
<pre><code class="language-rust">async fn get_weather(location: String) -&gt; Result&lt;String&gt; {
 // Your implementation
}

let tool = Tool::new(
 &quot;get_weather&quot;,
 &quot;Gets current weather for a location&quot;,
 get_weather
);

agent.register_tool(tool);
</code></pre>
Built-in RAG
Vector stores (in-memory or Qdrant), embeddings, retrieval—all integrated. No separate libraries to wrangle.
Streaming
Real token-by-token streaming for both remote and local models. Watch the thinking process unfold in real-time.
<h2>What I Learned Building This</h2>
Building helios-engine forced me to actually understand Rust’s ownership model, async runtime, trait system, and error handling—not just read about them.
<h3>Async Rust Is Beautiful (Once You Get It)</h3>
Fighting with lifetimes in async contexts was painful at first. But once I understood how <code>Send</code> and <code>Sync</code> work with futures, everything clicked. The Tokio runtime is fast.
<h3>The Type System Saves You</h3>
Python’s flexibility sounds nice until you’re debugging why your agent system breaks at runtime. Rust’s compiler is harsh, but it catches problems before they become production incidents.
<pre><code class="language-rust">// This won&#x27;t compile if LLMProviderType doesn&#x27;t implement Clone
let client = LLMClient::new(provider.clone()).await?;
</code></pre>
That “won’t compile” is your best friend.
<h3>Error Handling Done Right</h3>
No more Python exceptions that bubble up three layers and get swallowed. Everything is <code>Result&lt;T, E&gt;</code>. Errors are values. Handle them or propagate them—the compiler enforces it.
<pre><code class="language-rust">pub type Result&lt;T&gt; = std::result::Result&lt;T, HeliosError&gt;;

#[derive(Debug, thiserror::Error)]
pub enum HeliosError {
 #[error(&quot;LLM API error: {0}&quot;)]
 LLMError(String),
 
 #[error(&quot;Configuration error: {0}&quot;)]
 ConfigError(String),
 
 #[error(&quot;Tool execution failed: {0}&quot;)]
 ToolError(String),
}
</code></pre>
<h3>Performance Matters</h3>
Rust’s zero-cost abstractions aren’t marketing. The difference in response time between a Python framework and helios-engine is noticeable, especially for local models.
<h3>Feature Flags Are Powerful</h3>
<pre><code class="language-toml">[dependencies]
helios-engine = { version = &quot;0.3&quot;, features = [&quot;local&quot;, &quot;rag&quot;] }
</code></pre>
Compile only what you need. Keep your binary small.
<h2>Should You Use It?</h2>
If you’re building LLM-powered applications and you’re tired of:
<ul>
<li>Being locked into one provider</li>
<li>Python’s performance and deployment overhead</li>
<li>Complex frameworks that do too much or too little</li>
<li>“Local support” that doesn’t actually work offline</li>
<li>Agent systems that can’t handle multiple agents</li>
</ul>
Then yeah, give it a shot.
If you’re also learning Rust and want a real project that exercises the language’s features in a practical context, helios-engine is a good codebase to study or contribute to.
<h2>Links</h2>
<ul>
<li>Crate: <a href="https://crates.io/crates/helios-engine" target="_blank" rel="noopener nofollow">crates.io/crates/helios-engine</a></li>
<li>Docs: <a href="https://docs.rs/helios-engine" target="_blank" rel="noopener nofollow">docs.rs/helios-engine</a></li>
<li>Source: <a href="https://github.com/Ammar-Alnagar/Helios-Engine" target="_blank" rel="noopener nofollow">github.com/Ammar-Alnagar/Helios-Engine</a></li>
</ul>
<hr>
Built with Rust. No bullshit. Just agents that work.

Deleted user

A developer shares their experience building helios-engine, a Rust-based LLM agent framework designed to address common pain points in existing solutions. The framework offers provider-agnostic LLM integration (OpenAI, local GGUF models, custom APIs), true offline inference using llama.cpp, multi-agent collaboration capabilities, built-in RAG support, and streaming. The author emphasizes learning Rust's ownership model, async runtime, and type system while solving practical problems like vendor lock-in, poor local model support, and Python's performance overhead. The framework uses clean syntax with minimal boilerplate and compiles only needed features through feature flags.

Helios-engine, I Built Another LLM Agent Framework (And Why You Might Actually Care)