Smarter Coding Agents for Rust with Symposium
In a Nutshell
Symposium is a dependency-aware plugin system that automatically discovers and installs skills, hooks, and MCP servers from Rust crates to give AI coding agents the specialized guidance needed for idiomatic code. The core insight is that agents can't self-discover crate-specific best practices, so Symposium bridges this gap by having crates recommend plugins that activate based on what's actually in your dependency graph. This approach persists beyond model improvements because users will always need ways to inject their own preferences and organizational policies that no generic model can know.
These notes were generated by AI and may contain inaccuracies.
Orhan Rastolper, Rust advocate at JetBrains and lead maintainer of Retwe, introduces this live stream as part of a series with the Rust Foundation exploring the intersection of Rust and AI. The stream focuses on both using Rust to build AI systems and using AI to build better software.
The guests are Nico Matsakis and Jack Hui, discussing Rust AI coding agents and the Symposium project. Nico is one of the lead designers of the Rust programming language, co-lead of the language design team, and creator of Symposium. Jack works extensively on Rust's type system and project governance, and is also a Symposium maintainer.
Nico clarifies that he stepped back from co-leading the language team a little while ago but until very recently was co-lead of the language team.
Nico's Journey
Nico started experimenting with AI coding agents a couple years back when AI was becoming controversial. He wanted to understand what the fuss was about. He quickly realized this was going to be a really powerful tool for helping people learn. Despite complications and flaws like "mansplaining as a service," AI can figure out where the user is at, what they understand and don't understand, and offer a matched experience.
Nico sees this as a huge opportunity for Rust because the learning curve has always been the hardest part - teaching a new way of doing programming that is annoying at first. He feels this aligns with why he got into Rust in the first place: empowering people to build new stuff and do things they couldn't do before.
Jack's Journey
Jack came to the AI coding agent scene later than Nico. For a long time, he was trying to figure out the best way to work without using any agents or AI. Nico got him excited about it through their regular lunch conversations where Nico would talk about cool things he was thinking about and working on.
Jack's biggest interest is that AI is clearly not going away. He finds it inspiring to use the modeling of all the best AI characters he knows to guide agents in doing the best they can for you and guide them in ways you already know how to do things correctly.
Nico wrote a blog post about how he learned to stop worrying and love the LLM. The post was written fairly early when he realized this could be such a powerful tool.
Nico's key insight is that LLMs turn expectations of computers on their head. We're used to computers being really fast, really precise, always doing the same thing. LLMs are really bad at all the things computers are usually good at - they're slow, inefficient, can't do math reliably. But they can do things we thought were out of balance for a computer altogether: make summaries, make assessments, make judgments, adapt to new circumstances.
His intuition is that what's good for people is going to be good for LLMs too. Just like Rust's type system helps him think more clearly and find flaws in his thinking, he expects the same to be true for LLMs.
The Limitation of Compiler Diagnostics
Rust is known for its detailed compiler diagnostics that help users understand errors. However, knowing the right way to fix problems is often not straightforward - errors can be fixed in different ways and methods.
Jack explains that compiler diagnostics are generally a very local type analysis. For example, you might get a lifetime bound error, and the compiler will tell you the lifetime doesn't outlive something. This may help with a local solution, but it's also possible you're thinking about the problem the wrong way. Compiler diagnostics won't help you figure out the right pattern to write your code in.
Where LLMs Add Value
LLMs can look at your code and tell you that this bit here doesn't work with that bit over there, and suggest changes that would make it work. No book could tell you that because everyone's code is unique.
Nico mentions that Rust has a --info flag that gives longer explanations of error codes. When adding this feature, he and Sophia Turner talked about wanting a --explain mode that would adapt explanations to use your code as examples. It was unclear how to do this generically, but LLMs could do a great job at it.
The "It Depends" Problem
Over years of teaching Rust, Nico realized that what makes Rust significantly harder is that the answer to almost every question is "it depends." When someone asks how to do something they're used to in Java, the answer involves choices: ARC vs RC, visitor pattern via match/enum vs trait. This makes sense because Rust exposes more details for tuning code, but makes it harder to learn.
Compilers struggle with this because they don't know what the user knows or what's important to them. It's hard to balance between dumping too much information and being too minimal. The team has tended toward being taciturn because people are sensitive to too much information.
Early Attempts
Symposium was a name Nico came up with and applied to four different projects in succession until finding the one that worked best. One early project was called AskFerris, created when chatbots were still novel. It was a VS Code plugin where Ferris would hang out in your code. The idea was basically RAG before RAGs existed - compiling best practice Rust guidelines and asking the model to categorize problems into categories and supply better guidance.
That approach stopped being relevant because models got better so much faster that it stopped being an issue.
Current Focus
The current focus is giving agents the right best practices automatically. The challenge is figuring out when agents need those best practices. Skills give some of this but it's still up to the agent to decide when to turn them on. Symposium was started even before skills, with the idea that giving agents best practices requires baseline functionality.
The Core Problem
The initial problem was "all of the problems." Nico was using Claude Code (much simpler then) and found it so much easier to spin off a task that you really want some way to make a lightweight work tree.
Extensibility as Key Goal
The biggest thing that hasn't changed as Symposium evolved is extensibility. Nico was frustrated with how tools are built as all-in-one vertical integration - from the front end to context injection to caching strategies. He doesn't think these needs should be coupled, and believes better tools would result from letting people inject and customize to their situation.
MCP and ACP Context
Symposium was born out of looking at MCP (which lets you add new capabilities in a very specific way) and finding it pretty cool but limited. Skills have improvements over MCP but aren't that different from Nico's point of view.
The ACP (Agent Client Protocol) approach was the most recent predecessor of Symposium. It was about composable agents - wrapping agents in middleware or proxies that can take control over the experience. The goal was to eventually make Symposium do the right thing for things agents expose.
Protocol Independence
Symposium today doesn't depend on ACP. They've thought about allowing ACP components but that's not currently implemented.
Technically, Symposium doesn't depend on any protocols. When you install it, it does a few things if your agent supports them - it installs hooks for ensuring skills get updated. If your agent doesn't support hooks, you can manually invoke Symposium to sync things. If your agent doesn't support skills, Symposium doesn't copy them over.
Symposium supports MCP servers, though project-specific MCP server support is limited. They're working on support for the agent plugins protocol which allows project-specific MCP servers.
Meeting Agents Where They Are
The approach is meeting you where you are with what you have. The ACP approach required agents to be opted in, so without ACP support you had no Symposium functionality. The current approach works regardless of what protocols your agent supports.
Creatorware Plugins
Symposium looks through your Cargo.toml at dependencies and offers to install things that would improve the experience of coding against that dependency. This gives any Rust crate author the ability to improve their user's experience directly, without requiring Claude or other agents to decide to offer it.
The goal is to eventually allow writing plugins that combine multiple approaches: skills that tell agents what to do under certain conditions, hooks for post-facto checks like running cargo clippy, and MCP servers for when agents need information.
Symposium is evolving beyond crate-specific tools toward a dependency-aware approach that works across multiple languages including Python and NPM projects. The core concept is that dependencies themselves should automatically suggest the most relevant plugins and guidance. When using a crate like Serde, that crate knows best how to guide its usage, so the system enables crates to recommend plugins that improve the development experience.
The system automatically discovers useful information through the dependency graph. Rather than requiring manual plugin installation, Symposium suggests plugins that a crate recommends. This addresses the problem where developers might add a dependency like formality-core without receiving the specialized skills that would dramatically improve agent performance. The key insight is that dependency awareness provides an automated way to surface information that agents should know about.
While focused on dependencies as a clear signal, the system is designed to be extensible. Plugin managers can implement different discovery criteria, enabling extension to other languages. At Amazon, discussions are exploring using organizational context like org charts to provide tailored guidance based on project types and team structures. The environment itself can serve as a form of dependency that influences what guidance gets applied.
While agents could theoretically extract context from documentation or codebases, several practical barriers prevent this. Workspace-specific files like agents.md only load within that workspace and don't transfer to dependent plugins. No current agent automatically examines dependencies to find recommended plugins or documentation. Symposium's uniqueness lies in its ability to bridge this gap by automatically connecting dependencies to their associated guidance.
Agents require different information formats than humans need. Early development focused on providing example code from crate source, but modern agents handle API navigation well once they know where to find the source. The critical gap is that agents must be explicitly directed to source locations—otherwise they may locate incorrect versions and become confused. Agents also benefit from tighter, compressed formats and different example styles than human documentation typically provides.
Skills serve as a mechanism to provide agents with structured access to useful documentation without requiring them to search or grep through content. This saves tokens and prevents repeated effort. The goal is to surface relevant documentation proactively rather than forcing agents to discover it independently.
Symposium supports three plugin types: skills (guidance documents placed in specific locations), hooks (callbacks requiring agent configuration), and MCP servers (requiring installation and configuration). When a plugin from a dependency is activated, Symposium handles environment setup and configuration so the agent can immediately use the provided capabilities. Removing dependencies triggers automatic cleanup of associated plugins.
Rust Token Killer (RTK) functions as a global plugin that automatically reduces token usage by cleaning tool outputs. For Claude Code, it registers as a hook that routes supported tool outputs through RTK for compression. While not currently enabled, the integration will allow automatic token savings without manual configuration. The goal is that installing Symposium immediately provides efficiency improvements.
The recommendations repository serves two purposes: enabling global plugins that aren't tied to specific dependencies (like RTK), and allowing community contributions for crates that don't ship their own skills. Similar to TypeScript's @types packages, third parties can submit plugins for crates where the original maintainers haven't provided guidance. The maintainers currently review submissions to ensure they are reasonable and non-malicious.
Installation uses cargo install symposium, providing the cargo agents command. Running cargo agents init enables integrations and installs hooks that check for additional skills or plugins based on dependencies. Symposium creates a .claude directory with skills like "best practice" and "find crate source" automatically added to .gitignore.
The "find crate source" skill provides a simple but useful capability: running cargo agents crate info for a dependency returns the exact source location for the version being used. The "Rust best practice" skill includes guidance to run cargo fmt after edits, addressing the common issue of agents not formatting code automatically.
Amir Formality is a project formalizing the Rust type system mathematically. Formality Core enables writing type system notation that resembles mathematical notation through Rust macros. Without specialized guidance, agents produce working but non-idiomatic code—introducing unnecessary .clone() calls that the macro system handles automatically. The specialized skill dramatically improves code quality by teaching agents the idiomatic patterns specific to Formality's macro system.
Running cargo agents sync detects when dependencies have recommended skills and prompts for installation. Once approved for one project, the skill automatically applies to other packages without repeated prompts. This ensures consistent agent behavior across projects using the same dependencies.
If a dependency was added through an agent rather than directly via cargo add in the terminal, the agent receives a hint indicating that plugins are available. The system attempts to notify users about relevant plugins they might want to install, though the wording requires tuning. There have been cases where the agent successfully mentioned that a plugin should be funded for cargo agency, while other times it ignored the hint entirely.
A .agents directory gets created when working with codex. The goal is to bridge compatibility gaps so that when authoring a crate, plugins (skills, MCP servers, or hooks) work regardless of which agent the user employs. The approach is to provide plugins in the most general way possible, allowing the system to adapt them. Existing standards are leveraged wherever possible.
For hooks specifically, which lack a universal standard, symposium hooks can be written and then adapted to work across different agents. This creates an additional standard, but the hope is that the community will eventually converge on a unified approach for how hooks should function.
When symposium was enabled and created the project, cargo fmt was run. The question was raised whether this should be implemented using hooks or skills, and whether hooks would increase token costs. Currently, a skill is used that instructs the agent to run cargo fmt after generating Rust code. Hooks were considered as an alternative, where after a round cargo format --check would run.
Hooks run on the local computer after the model has executed, making them not part of the model loop. While hooks can add context for the model, they do not increase token costs themselves. Skills appear to work well for this use case, particularly for mainstream Rust operations like cargo fmt. The previous symposium ACP included a proxy that would detect modified Rust files and automatically run cargo fmt.
Skills present a supply chain attack surface. The current approach is comparable to BuildRS, though this is acknowledged as not ideal. There's existing nervousness about cargo add triggering cargo check in IDEs, which runs arbitrary code. Currently, confirmation is requested before installation, which is recognized as an incomplete solution.
Work is underway with the Rust Foundation through the Rust Innovation Lab. The foundation performs proactive scans of new crates.io packages looking for malicious or Trojan horse code. Integration is planned to detect whether packages contain skills and whether those skills might exfiltrate data. Additional security mechanisms are being discussed on Zulip. The position is that security boundaries are ultimately the responsibility of harnesses rather than symposium itself. Codex's default sandboxing is viewed positively, and more development in that direction is desired.
A new symposium user with a simple application created a skills directory and initialized symposium through a command, adding codex as the coding agent. The skill was fetched from a remote source but also made available locally, containing general guidelines. The question was whether this constituted complete setup.
The current behavior loads skills from agent/skills directories. Skills were observed to install correctly, with best practice and find create source visible. However, this approach is not the intended usage pattern. The skills directory is designed for libraries to provide skills for their users, not for individual workspace skills.
For skills meant for use within a workspace, the recommendation is to place them directly in .agent/skills rather than having symposium install them. This follows the conventional approach. Symposium then copies from .agent/skills into tool-specific locations like .cloud/skills when needed. The ideal placement for a skill like a ratatouille skill would be within the ratatouille crate itself for automatic discovery, though this capability is not yet implemented.
The sync command runs automatically by default for agents that support hooks. Users must still enable the features they want, but enabled features trigger automatic syncing. Automatic sync can be disabled via configuration, and manual syncing remains an option. The status command displays current project status, with Z icons indicating available plugins not relevant to the current workspace, and checkmarks showing installed plugins. Registry sources are displayed, such as centralized recommendations versus workspace member plugins.
The cargo agent use command allows installation of plugins that aren't loaded from dependencies. This is useful for plugins in organizational workspaces that might not be enabled by default, such as security policy compliance plugins. The command makes the plugin available as if loaded from a dependency. An example use case is an opinionated set of Rust rules called RTK ("Rust that is Just Right"), which could be installed explicitly via symposium use rather than being included by default.
When dependencies are added mid-session, skills get added appropriately. However, even when symposium is configured to sync newly enabled skills, the agent may not load those skills during the current session. Testing indicates agents are generally responsive to this, though immediate availability is not guaranteed and some agents may not support it.
The Rust best practice skill is built into symposium's recommendations section and is currently minimal. Plans exist to update recommendations as the language evolves, suggesting use of new features. Work is underway on an async best practice plugin that uses custom predicates to activate only when writing async Rust code. This would include advice such as avoiding blocking code in async contexts.
The current approach is described as "first do no harm," being selective about additions. A recognized issue is that adding excessive skills can either provide no benefit or degrade performance. Better evaluation methodologies are being developed to verify each addition provides value.
As models improve, the relevance of specific skills may change. Initially, advising about new features, crates, and best practices is valuable because models lack this knowledge. However, six months to a year later, newer models may already possess this information, making the skill potentially wasteful of context. This model drift problem will require additional features to address over time.
No comprehensive evaluation framework currently exists for benchmarking skills. The Rust best practice skill is minimal because it demonstrably provides meaningful benefit. Evaluation work is ongoing, with recognition that this applies to hooks and MCP servers as well as skills.
For specific skills like the mere formality idiomatic example from the demo, evaluations were written using an evals.json file convention. This contains tasks and judge questions using an LLM-as-judge approach. The methodology involves having an LLM complete a prompt, then having another LLM assess whether the skill's intended behavior was followed. One evaluation showed approximately 66% improvement from the skill.
Beyond skills, determining whether agent-generated Rust code is good remains challenging. One approach discussed involves identifying key situations where symposium or skills would help, then demonstrating measurable improvement. Examples include detecting blocking code in async contexts, inappropriate use of Arc, or other non-idiomatic patterns.
Larger-scale benchmarking beyond narrow skill evaluations has been discussed but not yet implemented. Related work includes the battery packs project, which involves networking services where agents might select arbitrary dependencies that aren't necessarily idiomatic Rust.
The symposium model extends beyond Rust to any language ecosystem. The core concept involves having project dependencies (code, environment, or opinions) automatically available without necessarily being automatically installed, while making installation straightforward when desired. Infrastructure exists to run symposium in Python projects by examining Python dependencies, or in NPM projects. Plugin managers for these ecosystems haven't been written yet but are planned.
The predicate system enables complex conditional plugin activation. Plugins can activate based on combinations of dependencies rather than single crates. For example, a plugin could activate when using both PyO3 and another specific crate, providing integrated advice for that combination. This capability extends beyond skills to hooks and MCP servers, allowing plugins to enable and configure the right tools for specific use cases.
Complete certainty about code quality is impossible, whether generated by agents or written by humans. However, Rust adoption is expanding to broader audiences because agents make it more accessible. Some users read generated code carefully while others do not. The guardrails and structure provided by symposium contribute to better results in these scenarios, though various gotchas remain.
There are ways that AI coding agents can go wrong with Rust. The speaker expresses concern about exploding Rust usage where people might get the wrong impression or be misled by agents that don't perform well. Without deep system knowledge, it's hard to tell if an agent is doing a good job. Symposium is important because the Rust organization needs a tool to improve people's experience directly when they use coding agents.
Symposium will not become obsolete even when agents get better. While agents might eventually standardize checking dependencies and avoid outdated crates through automatic model updates, there will still be things users want that aren't specific to any model. Users have specific opinions about file formatting and project setup that agents won't know. Symposium enables users to tell agents what they want in an automated, easy-to-use way. An infinitely good model will never know what you want, and Symposium makes it possible to convey these preferences.
The three core value propositions of Symposium that persist even as agents improve are:
- Better out-of-the-box experience, which may become less important over time
- Customization, particularly important in enterprise contexts where companies maintain internal repositories of skills
- Interoperability, where Symposium pushes for better conventions that all models follow
If all agents eventually interoperate well with well-known conventions, the Symposium project could retire, but the goal is to influence behavior and make agents better.
The chat discussion notes that a few years ago people discussed fine-tuning models to make them better at writing Rust. The speaker believes it's much easier to start with a powerful generalized model and tweak it with tailored skills. Skills and Symposium might become outdated, but the thesis of the system will probably not become outdated.
A potential future feature could be "cargo agents tune" that asks agents questions without any skills to determine what they know, then picks appropriate skills based on identified gaps. The speaker mentions remembering DOTS and autoconf configuration. There's also discussion about judging how smart agents are after implementation.
Skills may become a normal thing for open source maintainers to add to projects. However, the average crate will not require specialized skills. Instead, information present in other forms will be extracted and exposed. Models have improved, reducing the need for specialized skills in most cases.
There will be a subset of crates that push users into idiomatic or different styles and will require skills. Dial 9 is an interesting example - it's a profiler for async applications that provides agentic skills. The skills help agents understand data formats and come up with sensible answers to questions about performance issues like why something is pausing or why P99 latency is high.
Skills might not be named skills in the future. Many crates have indepth documentation, and telling agents that documentation exists and what's important can be just as useful as a skill. The key balance is between giving agents everything upfront versus having them find what they need. Symposium is important now because agents won't automatically look for crate source or documentation by default.
Crate authors should offer the ability to write lints and package automatic tooling to extend Clippy or Cargo for better error messages or to identify common foot guns, especially around async. This influences agent behavior as they will run these lints. There's unexplored potential in combining programmatic lints that may have false warnings with agents to narrow them down.
With agents, better proofs of correctness or bug checking may become feasible. The community has sometimes held back from exposing more complexity because it was more important to get up and going quickly. With agents handling complexity, higher quality bars become possible. Core libraries might start proving they don't have certain kinds of bugs. A new word might be needed since code proven correct is no longer truly unsafe.
Symposium's next goals include:
- Benchmarking and evals to know Symposium is actually helping
- Extending Symposium to other languages beyond Rust
- Creating content for popular crates where skills or hooks would be useful
- Addressing edge cases found through increased user adoption
- Adding security features like more preemptive scanning
- Developing a richer set of best practices
Battery packs are crates that provide lists of recommended dependencies rather than being directly used. For example, cargo BP add CLI gives recommendations for CLI building dependencies. The embedded crate has converted awesome-embedded suggestions. Battery packs help new Rust users navigate crates.io and ensure agents pick good dependencies. They also enable pushing new recommendations quickly since agents are a moving average of code seen over recent years. Battery packs can distribute skills that aren't specific to any particular crate but represent best practices across multiple crates.
The session concludes with thanks to participants and encouragement for viewers to try Symposium. The final message emphasizes being excellent to each other and profiling code.
Keep JetBrains in your library
Save the videos and channels worth coming back to, and find them again in one place.
