The core of every agent framework is the same ReAct loop. It's commodity code. What actually matters is everything around that loop — how you manage context windows, how you pipeline tool execution, how you handle durability and replay. These are hard problems with real design trade-offs, and yet every framework bundles them into one monolith where you buy all of it or none of it.
neuron is the layer below frameworks. It defines trait boundaries — `Provider`, `Tool`, `ContextStrategy` — and ships working implementations of each as independent crates. You get four context compaction strategies without pulling a single provider. You get the Anthropic provider without the tool registry. You get MCP support without the agent loop. The analogy is `serde` and `serde_json`: one crate defines the traits, the others implement them, and you compose what you need.
v0.3 is 12 crates. Three providers (Anthropic, OpenAI, Ollama), composable tool middleware with a `#[neuron_tool]` proc macro, four context compaction strategies, an agent loop with cancellation and parallel tool execution, full MCP support across both stdio and Streamable HTTP, sessions, guardrails with sandboxing and permission policies, and a dedicated OpenTelemetry crate following the GenAI semantic conventions. Rust 2024 edition, native async traits.
Adding a provider is adding a crate. The existing provider crates serve as templates — implement the `Provider` trait from `neuron-types`, wire up streaming, and you have a first-class citizen in the ecosystem. The same goes for context strategies, tool middleware, and session backends. More provider and integration crates are on the roadmap, but the architecture is specifically designed so that you or your agent can add them without waiting on me.
That last point is deliberate. The repo ships with `CLAUDE.md`, `llms.txt`, and architecture docs written to be machine-readable. An LLM agent can pull the codebase, understand the trait boundaries, and start building against them. If you're using Claude Code or similar tools to scaffold new integrations, neuron is optimized for that workflow.
Looking for feedback on the crate boundaries and API surface. The docs site walks through the reasoning behind specific trade-offs — why axum-style middleware instead of tower, why `DurableContext` wraps side effects rather than observing them, why the flat `Message` struct instead of variant-per-role.
neuron is the layer below frameworks. It defines trait boundaries — `Provider`, `Tool`, `ContextStrategy` — and ships working implementations of each as independent crates. You get four context compaction strategies without pulling a single provider. You get the Anthropic provider without the tool registry. You get MCP support without the agent loop. The analogy is `serde` and `serde_json`: one crate defines the traits, the others implement them, and you compose what you need.
v0.3 is 12 crates. Three providers (Anthropic, OpenAI, Ollama), composable tool middleware with a `#[neuron_tool]` proc macro, four context compaction strategies, an agent loop with cancellation and parallel tool execution, full MCP support across both stdio and Streamable HTTP, sessions, guardrails with sandboxing and permission policies, and a dedicated OpenTelemetry crate following the GenAI semantic conventions. Rust 2024 edition, native async traits.
Adding a provider is adding a crate. The existing provider crates serve as templates — implement the `Provider` trait from `neuron-types`, wire up streaming, and you have a first-class citizen in the ecosystem. The same goes for context strategies, tool middleware, and session backends. More provider and integration crates are on the roadmap, but the architecture is specifically designed so that you or your agent can add them without waiting on me.
That last point is deliberate. The repo ships with `CLAUDE.md`, `llms.txt`, and architecture docs written to be machine-readable. An LLM agent can pull the codebase, understand the trait boundaries, and start building against them. If you're using Claude Code or similar tools to scaffold new integrations, neuron is optimized for that workflow.
Looking for feedback on the crate boundaries and API surface. The docs site walks through the reasoning behind specific trade-offs — why axum-style middleware instead of tower, why `DurableContext` wraps side effects rather than observing them, why the flat `Message` struct instead of variant-per-role.
Repo: https://github.com/SecBear/neuron Crates: https://crates.io/crates/neuron