VulcanAI - Building Modular AI Agents with C#

Progress has been coming along well with VulcanAI, with ObsidianDB becoming more functional and HyperVectorDB being functionally complete, which brings me a few steps closer to my ambitions I talk about in the overarcing project page.

Now is a good time to stop and seriously think about the architecture of the the VulcanAI project, and how to proceed towards its design goals. In the README, I talk about it being modular and providing a Lego-like experience to building AI applications, but right now it is actually rather monolithic and a lot of behavior is hardcoded. If I am going to meet the goals I set out, I need to reconsider how the project is organized and how the functional logic is implemented.

Modular Architecture and Package Organization

In the ideal future, VulcanAI is an ecosystem of packages. You add the VulcanAI package that includes the Core namespace and some other common classes and interfaces, but then you add some combination of additional packages that bring the functionality you need while adding minimal dependencies that you don’t. The Discord interface should be its own package, for example. So should the Discord interface. I have grand plans for classes to support MPC, databases like SQL, IRC, web scraping, social media like Reddit and Twitter, automation tools like MQTT, etc. Since these would each bring new dependencies and almost no application will need all of them, they should all be split up into their own packages, enstilling a robustly modular, Lego-like approach.

For instance, the Discord interface should be a standalone package, as should other communication protocols like IRC and MQTT. Future plans include support for various data sources including SQL databases, web scraping capabilities, and social media integrations for platforms like Reddit and Twitter.

While maintaining everything in a single package during active development is more practical, the architecture must still enforce strong isolation between components. This approach will facilitate future separation into individual packages while maintaining clean, maintainable code.

Intelligent Agent Architecture and Scripting Capabilities

The current implementation’s centerpiece is the Agent class, which currently functions as a basic chatbot. While it successfully decouples from specific implementations through interfaces, its hardcoded logic loop needs to be reimagined.

A more flexible approach would involve:

1. Creating an IAgent interface as the foundation
2. Refactoring the current Agent into a ChatbotAgent implementation
3. Developing additional specialized agent types

Potential specialized agents could include:

• AnalysisAgent: Processes knowledge sources against templates to generate structured reports
• ScriptedAgent: Exposes the agent API to a scripting engine, enabling dynamic behavior modification

The integration of scripting capabilities represents a significant step toward creating self-improving AI agents. By supporting dynamic behavior modification through Lua or similar lightweight scripting languages, we can enable:

• Runtime agent reconfiguration
• Autonomous functionality expansion
• Self-modification capabilities
• Low-code agent development

Adding dynamic scripting is an important step towards my goal of an AI agent that can improve itself over time, add new functionality autonomously, etc. Anything that avoids having to kill the process, recompile, and restart helps towards that, and low-code functionality is a way to do that. At least, minimal C# code. If an agent could be defined entirely in JSON or XML and that definition reloaded without stopping the main executable, it would provide smoother development of agents while also empowering realtime AI generation of agents and even self-modification for agents.