Your framework name suggests that you have an effective method of taking an existing agent that is "close" to meeting requirements by some similarity metric and evolving a new agent that will be better suited than the base agent is to meet the requirements.
If this is true, your post, your repo README file, and your BeeAI Community call presentation (which starts here: https://www.youtube.com/watch?v=5-xqQBv-ccY&t=1294s) ought to be proclaiming such a notable success. Yet, I've seen little to nothing about it in any of those places. Am I missing it?
How exactly does your agent evolution process work?
Well thousands of years from now when aliens visit earth investigating how all agents died. The cause will be all agents were buried alive when a giant YAML file fell on them. (Human would be the slaves preparing and carrying yaml files all day and deliver to agents)
Here is the March 2025 BeeAI Community Call ( https://www.youtube.com/watch?v=5-xqQBv-ccY ), where I presented the draft of the framework and shared some ideas on why it makes sense for me to provide this kind of framework and tools to AI agents.
Probably the same thing that makes this logic “sophisticated”. It’s AI generated prose with little meaning.
“The System Agent implements a sophisticated decision mechanism:
If similarity ≥ 0.8: Reuse an existing agent/tool
If 0.4 ≤ similarity < 0.8: Evolve an existing agent/tool
If similarity < 0.4: Create a new agent/tool”
I wanted to drop a quick note that I’ve updated the README substantially and am now referring to this project as a “toolkit” rather than a “framework” (since it builds on existing frameworks like BeeAI rather than trying to replace them). I’ve clarified the roadmap, the focus on agent governance, and how exactly the “evolution engine” works. I’ve also included details on the experimental “service bus” for agent communication and discovery (coming soon), and I’ve tried to tone down any references that implied “production-grade” readiness—this is very much a work in progress!
It's not continuously evolving outside the developer's control, right? Companies need to checkpoint dependencies for resilience. Can you define tests to ensure compliance of new versions?
I hope this causes a catastrophe somewhere. This might be the warning shot that humanity needs to wake up, before we hook up spiking neuromorphic hardware to run agents.
Someone will notice there's something to be gained by building abstractions around caching/memoization and that running workflows in distributed environments might be augmented by some form of precompilation and/or hydration.
Then others will boast that they can do everything with whatever flavour of vanilla they are familiar with.
Then someone will bring up Greenspun's tenth rule.
Anyways: We'll have pages and pages of HN threads to scroll through.
mh... it might be good, but having a generated image in your ReadMe is a red flag. Why not provide some more insightful graphic, like a flow chart that actually helps to explain the concept at a glance ?
I'm excited to share a significant update to the Evolving Agents Framework. Based on all your valuable feedback, I've completed a substantial refactoring that implements a true agent-centric architecture with embedded strategy logic.
What's New: Pure ReAct SystemAgent
The most significant change is that the SystemAgent is now a pure BeeAI ReActAgent that manages the entire ecosystem through reasoning rather than hardcoded logic. This means:
1. The SystemAgent makes decisions by reasoning about the best approach, not through predefined functions
2. Tools encapsulate their own strategies and decision-making processes
3. The architecture follows a "tools all the way down" approach, where each tool can be independently evolved
This addresses the concerns about the "please improve yourself" approach mentioned in earlier comments. Instead of merely prompting for improvements, each tool now contains embedded strategy logic that can evolve independently.
Evolution Strategies Now Implemented
The `EvolveComponentTool` now implements multiple evolution strategies:
- *Standard*: Balanced evolution preserving core functionality while adding new features
- *Conservative*: Minimal changes focused on compatibility
- *Aggressive*: Significant changes optimizing for new requirements
- *Domain Adaptation*: Specialized for adapting components to new domains
Each strategy contains its own parameters for preservation level, optimization focus, and adaptation method. This is much more sophisticated than the "please improve yourself" approach I initially had.
Similarity-Based Decision Logic
As mentioned by @superb_dev, our initial similarity-based decision logic was quite simple:
"If similarity ≥ 0.8: Reuse an existing agent/tool
If 0.4 ≤ similarity < 0.8: Evolve an existing agent/tool
If similarity < 0.4: Create a new agent/tool"
What's different now is that this logic is encapsulated in the `SearchComponentTool` itself, not hardcoded in the SystemAgent. This means the decision strategy can evolve independently as we discover better approaches, without requiring changes to the SystemAgent.
Agent Bus Instead of "Service Bus"
I've also renamed the "Service Bus" to "Agent Bus" to reinforce the agent-centric philosophy. Everything is an agent with capabilities, not a service. This provides a clearer mental model while still enabling capability-based routing.
The Agent Bus now has three specialized tools:
- `RegisterProviderTool`: For registering agent capabilities
- `RequestServiceTool`: For capability-based routing
- `DiscoverCapabilityTool`: For finding available capabilities
Working Demonstration
I've created a new example (`pure_react_system_agent.py`) that demonstrates all these concepts in action. It shows:
1. How the SystemAgent uses reasoning to choose appropriate tools
2. How tools contain their own decision-making strategies
3. How the entire system works together to create, evolve, and manage agents
The demo is now working correctly and fully implements the architecture described in the README.
Addressing Specific Feedback
@kjhughes asked about the evolution process: The evolution process is now much more robust, with multiple strategies and clear preservation/adaptation parameters. It's no longer just a simple prompt.
@bob1029 pointed out the "please improve yourself" issue: This has been addressed by moving strategy logic into the tools themselves, making the evolution process more sophisticated.
@superb_dev commented on the "sophisticated decision mechanism": While the basic thresholds remain, the implementation is now truly sophisticated because it's embedded in the tools and can evolve independently.
@esafak asked about control and testing: The new architecture makes it easier to checkpoint, test, and govern agent evolution. Each evolution step is clearly tracked with metadata.
@mentalgear suggested better graphics: I've replaced the generated image with proper architectural diagrams that clearly show the system's components and relationships.
Try It Yourself
The new code is now live in the repository. You can run the demonstration with:
python examples/pure_react_system_agent.py
This will show the tools' embedded strategies in action, including semantic search with recommendations, component creation with code generation, and evolution with various strategies.
I'm still working on more comprehensive documentation, benchmarks, and examples, but this update addresses many of the fundamental architectural concerns raised in the comments.
Thank you all for your feedback - it's been invaluable in guiding this refactoring!
Sadly we’ll have many agent Smiths but as in the movies, without some rudimentary Matrix (it’s possible to make some good democratic one), Neo and we will have no chance against them.
Agents can change our world and us, but we have limited or no capability to change the online world and their often private multimodal “brains”. We can represent them as familiar 3D environments and this way level the playing field.
Agents are like strict librarians who spit quotes but we cannot enter the library. It has too many stolen things and companies don’t want us to see that, they won’t make 3D game-like representations of those libraries
Update: Evolving Agents Framework Refactoring in Progress
Hey HN,
I wanted to share an important update on the Evolving Agents Framework. Based on all the valuable feedback I've received from this community, I've been working on a substantial refactoring of the codebase and architecture. The latest README update shows where we're headed, and I'm currently implementing these changes.
Agent-Centric Architecture
The most significant change is moving to a true agent-centric architecture. The SystemAgent is being redesigned as a proper BeeAI ReActAgent that uses specialized tools to manage the entire ecosystem. This is a big shift from the previous approach and addresses many of the architectural concerns raised in the comments.
In this architecture, *everything is an agent*. This provides a clearer mental model for humans while still enabling powerful service-oriented capabilities under the hood. Agents can have specialized capabilities and can request services from other agents through a unified communication system.
Specialized Tools Instead of Monolithic Components
Instead of having monolithic components, I'm breaking things down into more specialized tools:
1. Smart Library Tools:
- SearchComponentTool - For semantic search and discovery
- CreateComponentTool - For creating new agents and tools
- EvolveComponentTool - For evolving existing components
2. Service Bus Tools:
- RegisterProviderTool - For registering capabilities
- RequestServiceTool - For capability-based routing
- DiscoverCapabilityTool - For finding available capabilities
This design aligns with the "do one thing well" philosophy and makes the system much more modular and maintainable.
Evolution Engine Improvements
I've heard your concerns about the evolution mechanism being too simplistic. The refactored EvolveComponentTool will provide a more robust approach to agent evolution with:
- Better tracking of evolution history
- More sophisticated adaptation strategies
- Proper versioning and checkpointing
- Testable evolution outcomes
Service Bus for Agent Communication
The Service Bus implementation is being completely reworked to support the agent-centric architecture. Instead of thinking in terms of "services," we're designing around "agents with capabilities." This means:
- Agents register their capabilities with the Service Bus
- Other agents discover and communicate with them based on those capabilities
- The focus stays on agents (which humans understand) rather than abstract services
This approach makes the system more intuitive while still enabling powerful capability-based routing and discovery.
Code Implementation Timeline
I'm actively refactoring the codebase right now to implement these changes. You'll see significant commits in the next few days as I update:
1. SystemAgent implementation as a BeeAI ReActAgent
2. The specialized tools for SmartLibrary and ServiceBus
3. The workflow processing system
4. Documentation with proper architecture diagrams
Addressing Your Feedback
Many of you pointed out inconsistencies between the README and the actual code implementation. You were absolutely right, and that's exactly what this refactoring aims to fix. The code will soon reflect everything described in the README.
I appreciate your patience as I work through these changes. The recent README update and ServiceBus issue description reflect where we're headed, and the code will follow shortly.
Thank you for all your insights and questions - they've been instrumental in guiding this refactoring. Keep the feedback coming!
First things first: This is a solo project in a very early stage. Many parts are indeed either mocked or simplified for now just to see the bigger picture of how these evolving, self-building agents might work together. I’m currently developing a “system bus” to handle agent-to-agent communication in a more distributed, scalable way. Once that’s in place, I plan to circle back and strengthen all the fundamentals—agent evolution, storage (including vector DB), test coverage, governance checks, etc. My “production-grade” wording may have been too ambitious at this point, so consider it more of a vision statement than a claim of readiness.
A few clarifications based on the comments:
Agent Evolution
Right now, the evolution mechanism is, honestly, a naive “please improve yourself” prompt approach. I fully agree it’s rudimentary. The plan is to add more robust ways to retrain or adapt an agent’s underlying models (and store interim states) so that “evolution” actually reflects meaningful improvements rather than superficial prompt tweaks.
Why YAML?
I get the concerns—YAML can get bulky, and yes, there’s a joke about burying agents under a giant YAML file. I’m primarily using YAML for readability and version control; it’s simple to keep track of how agents communicate in a “single source of truth.” But nothing’s set in stone. If another structure or domain language works better, I’m open to exploring it.
Storage and Vector DB
Several folks suggested a vector database or similar. I actually do plan to integrate a vector DB for more efficient embedding lookups and advanced search. The current approach is just a placeholder while I validate the overall workflow.
“Production-Grade” and Benchmarks
Totally fair to question that term. I used it loosely to convey that I eventually want these agents to be robust enough for real-world scenarios, not just toy experiments. But I have a ways to go before calling it truly production-ready, and benchmarks will definitely be needed.
Governance
I’m taking governance seriously. Agents “autonomously” evolving can definitely raise eyebrows around compliance, safety, and unexpected behaviors. My approach is to provide a “firmware” layer of guardrails that define domain rules and boundaries. As it matures, I plan to integrate testing and compliance checks for each agent’s modifications, so it’s not just a runaway chain of self-modifications.
Service Bus & Distributed Systems
The upcoming feature is the “system bus,” which will support more robust service discovery and distributed task routing. That includes letting multiple agents run in different environments or infrastructure. Right now, everything is local and pretty simplistic.
Mocked Features
Some of you noticed placeholders or references to incomplete features. Absolutely. My approach is to wire up the architecture first—even with partial stubs—so I can see how everything fits together. Once I know the big pieces make sense, I’ll replace these mocks with actual implementations and refine them.
Graphics & Diagrams
I hear you: an actual flowchart or architecture diagram might be more useful than a generic AI-generated image. That’s on my to-do list, alongside better docs and examples. For now, I just wanted something to visually convey the concept in the README, but I’ll definitely add more meaningful visuals.
Collaboration
I appreciate the offers to join forces! I’d love to collaborate more closely once the fundamentals are stable. For now, if anyone wants to experiment, provide feedback, or open an issue/PR on GitHub, that’s fantastic.
Thanks again for all the feedback and for checking this out. I know it’s a bit rough around the edges, but the goal is to create a toolkit for truly autonomous, evolving, and self-governed AI systems—while staying within safe operational boundaries. I’m excited to keep iterating and improving, and I welcome any further thoughts or contributions!
Your framework name suggests that you have an effective method of taking an existing agent that is "close" to meeting requirements by some similarity metric and evolving a new agent that will be better suited than the base agent is to meet the requirements.
If this is true, your post, your repo README file, and your BeeAI Community call presentation (which starts here: https://www.youtube.com/watch?v=5-xqQBv-ccY&t=1294s) ought to be proclaiming such a notable success. Yet, I've seen little to nothing about it in any of those places. Am I missing it?
How exactly does your agent evolution process work?
It appears to be a "please improve yourself" style prompt that is ran through the LLM.
https://github.com/matiasmolinas/evolving-agents?tab=readme-...
> The second part demonstrates how agents communicate with each other through workflows defined in YAML
oh no
Well thousands of years from now when aliens visit earth investigating how all agents died. The cause will be all agents were buried alive when a giant YAML file fell on them. (Human would be the slaves preparing and carrying yaml files all day and deliver to agents)
Here is the March 2025 BeeAI Community Call ( https://www.youtube.com/watch?v=5-xqQBv-ccY ), where I presented the draft of the framework and shared some ideas on why it makes sense for me to provide this kind of framework and tools to AI agents.
Cool project! Thanks for sharing.
Intrigued by the storage-why not use a VDB?
Nice work on the framework, it looks really interesting, I can't wait to give it a go.
I have a question though - in the very first part of the readme:
"A production-grade framework for creating, managing, and evolving AI agents with intelligent agent-to-agent communication."
What makes this production-grade?
Probably the same thing that makes this logic “sophisticated”. It’s AI generated prose with little meaning.
Hey HN,
I wanted to drop a quick note that I’ve updated the README substantially and am now referring to this project as a “toolkit” rather than a “framework” (since it builds on existing frameworks like BeeAI rather than trying to replace them). I’ve clarified the roadmap, the focus on agent governance, and how exactly the “evolution engine” works. I’ve also included details on the experimental “service bus” for agent communication and discovery (coming soon), and I’ve tried to tone down any references that implied “production-grade” readiness—this is very much a work in progress!
If you’re curious, the updated README is in the main repo: https://github.com/matiasmolinas/evolving-agents
Thanks again for all the feedback and discussions so far—keep the questions and suggestions coming!
It's not continuously evolving outside the developer's control, right? Companies need to checkpoint dependencies for resilience. Can you define tests to ensure compliance of new versions?
As long as we don't ask it to make paperclips it should be fine.
I hope this causes a catastrophe somewhere. This might be the warning shot that humanity needs to wake up, before we hook up spiking neuromorphic hardware to run agents.
Feels like the JavaScript framework wars era all over again. Wondering what will be the prevailing paradigm.
No matter what paradigm will come out on top:
Someone will notice there's something to be gained by building abstractions around caching/memoization and that running workflows in distributed environments might be augmented by some form of precompilation and/or hydration.
Then others will boast that they can do everything with whatever flavour of vanilla they are familiar with.
Then someone will bring up Greenspun's tenth rule.
Anyways: We'll have pages and pages of HN threads to scroll through.
mh... it might be good, but having a generated image in your ReadMe is a red flag. Why not provide some more insightful graphic, like a flow chart that actually helps to explain the concept at a glance ?
Also: benchmarks.
Hey HN,
I'm excited to share a significant update to the Evolving Agents Framework. Based on all your valuable feedback, I've completed a substantial refactoring that implements a true agent-centric architecture with embedded strategy logic.
What's New: Pure ReAct SystemAgent
The most significant change is that the SystemAgent is now a pure BeeAI ReActAgent that manages the entire ecosystem through reasoning rather than hardcoded logic. This means:
1. The SystemAgent makes decisions by reasoning about the best approach, not through predefined functions 2. Tools encapsulate their own strategies and decision-making processes 3. The architecture follows a "tools all the way down" approach, where each tool can be independently evolved
This addresses the concerns about the "please improve yourself" approach mentioned in earlier comments. Instead of merely prompting for improvements, each tool now contains embedded strategy logic that can evolve independently.
Evolution Strategies Now Implemented
The `EvolveComponentTool` now implements multiple evolution strategies:
- *Standard*: Balanced evolution preserving core functionality while adding new features - *Conservative*: Minimal changes focused on compatibility - *Aggressive*: Significant changes optimizing for new requirements - *Domain Adaptation*: Specialized for adapting components to new domains
Each strategy contains its own parameters for preservation level, optimization focus, and adaptation method. This is much more sophisticated than the "please improve yourself" approach I initially had.
Similarity-Based Decision Logic
As mentioned by @superb_dev, our initial similarity-based decision logic was quite simple:
"If similarity ≥ 0.8: Reuse an existing agent/tool If 0.4 ≤ similarity < 0.8: Evolve an existing agent/tool If similarity < 0.4: Create a new agent/tool"
What's different now is that this logic is encapsulated in the `SearchComponentTool` itself, not hardcoded in the SystemAgent. This means the decision strategy can evolve independently as we discover better approaches, without requiring changes to the SystemAgent.
Agent Bus Instead of "Service Bus"
I've also renamed the "Service Bus" to "Agent Bus" to reinforce the agent-centric philosophy. Everything is an agent with capabilities, not a service. This provides a clearer mental model while still enabling capability-based routing.
The Agent Bus now has three specialized tools: - `RegisterProviderTool`: For registering agent capabilities - `RequestServiceTool`: For capability-based routing - `DiscoverCapabilityTool`: For finding available capabilities
Working Demonstration
I've created a new example (`pure_react_system_agent.py`) that demonstrates all these concepts in action. It shows:
1. How the SystemAgent uses reasoning to choose appropriate tools 2. How tools contain their own decision-making strategies 3. How the entire system works together to create, evolve, and manage agents
The demo is now working correctly and fully implements the architecture described in the README.
Addressing Specific Feedback
@kjhughes asked about the evolution process: The evolution process is now much more robust, with multiple strategies and clear preservation/adaptation parameters. It's no longer just a simple prompt.
@bob1029 pointed out the "please improve yourself" issue: This has been addressed by moving strategy logic into the tools themselves, making the evolution process more sophisticated.
@superb_dev commented on the "sophisticated decision mechanism": While the basic thresholds remain, the implementation is now truly sophisticated because it's embedded in the tools and can evolve independently.
@esafak asked about control and testing: The new architecture makes it easier to checkpoint, test, and govern agent evolution. Each evolution step is clearly tracked with metadata.
@mentalgear suggested better graphics: I've replaced the generated image with proper architectural diagrams that clearly show the system's components and relationships.
Try It Yourself
The new code is now live in the repository. You can run the demonstration with:
python examples/pure_react_system_agent.py
This will show the tools' embedded strategies in action, including semantic search with recommendations, component creation with code generation, and evolution with various strategies.
I'm still working on more comprehensive documentation, benchmarks, and examples, but this update addresses many of the fundamental architectural concerns raised in the comments.
Thank you all for your feedback - it's been invaluable in guiding this refactoring!
There should be an image of Agent Smith somewhere in the readme (j/k) :)
Sadly we’ll have many agent Smiths but as in the movies, without some rudimentary Matrix (it’s possible to make some good democratic one), Neo and we will have no chance against them.
Agents can change our world and us, but we have limited or no capability to change the online world and their often private multimodal “brains”. We can represent them as familiar 3D environments and this way level the playing field.
Agents are like strict librarians who spit quotes but we cannot enter the library. It has too many stolen things and companies don’t want us to see that, they won’t make 3D game-like representations of those libraries
And here I was, thinking I was clever for coming up with the agent smith image for an agent framework.
https://codeberg.org/jfkimmes/TinyAgentSmith
You’re not alone: https://synw.github.io/agent-smith/
Sure would beat the cringe ugly AI image currently in the readme.
Is this distributed and peer to peer? Because I don't want to pay the cost of 50 agents myself. And we truly need something that can't be centralized
I love the approach
Would you like to join forces? Reach out to me: https://engageusers.ai/ecosystem.pdf
Update: Evolving Agents Framework Refactoring in Progress
Hey HN,
I wanted to share an important update on the Evolving Agents Framework. Based on all the valuable feedback I've received from this community, I've been working on a substantial refactoring of the codebase and architecture. The latest README update shows where we're headed, and I'm currently implementing these changes.
Agent-Centric Architecture
The most significant change is moving to a true agent-centric architecture. The SystemAgent is being redesigned as a proper BeeAI ReActAgent that uses specialized tools to manage the entire ecosystem. This is a big shift from the previous approach and addresses many of the architectural concerns raised in the comments.
In this architecture, *everything is an agent*. This provides a clearer mental model for humans while still enabling powerful service-oriented capabilities under the hood. Agents can have specialized capabilities and can request services from other agents through a unified communication system.
Specialized Tools Instead of Monolithic Components
Instead of having monolithic components, I'm breaking things down into more specialized tools:
1. Smart Library Tools: - SearchComponentTool - For semantic search and discovery - CreateComponentTool - For creating new agents and tools - EvolveComponentTool - For evolving existing components
2. Service Bus Tools: - RegisterProviderTool - For registering capabilities - RequestServiceTool - For capability-based routing - DiscoverCapabilityTool - For finding available capabilities
This design aligns with the "do one thing well" philosophy and makes the system much more modular and maintainable.
Evolution Engine Improvements
I've heard your concerns about the evolution mechanism being too simplistic. The refactored EvolveComponentTool will provide a more robust approach to agent evolution with:
- Better tracking of evolution history - More sophisticated adaptation strategies - Proper versioning and checkpointing - Testable evolution outcomes
Service Bus for Agent Communication
The Service Bus implementation is being completely reworked to support the agent-centric architecture. Instead of thinking in terms of "services," we're designing around "agents with capabilities." This means:
- Agents register their capabilities with the Service Bus - Other agents discover and communicate with them based on those capabilities - The focus stays on agents (which humans understand) rather than abstract services
This approach makes the system more intuitive while still enabling powerful capability-based routing and discovery.
Code Implementation Timeline
I'm actively refactoring the codebase right now to implement these changes. You'll see significant commits in the next few days as I update:
1. SystemAgent implementation as a BeeAI ReActAgent 2. The specialized tools for SmartLibrary and ServiceBus 3. The workflow processing system 4. Documentation with proper architecture diagrams
Addressing Your Feedback
Many of you pointed out inconsistencies between the README and the actual code implementation. You were absolutely right, and that's exactly what this refactoring aims to fix. The code will soon reflect everything described in the README.
I appreciate your patience as I work through these changes. The recent README update and ServiceBus issue description reflect where we're headed, and the code will follow shortly.
Thank you for all your insights and questions - they've been instrumental in guiding this refactoring. Keep the feedback coming!
Hey all, thanks for the feedback and questions!
First things first: This is a solo project in a very early stage. Many parts are indeed either mocked or simplified for now just to see the bigger picture of how these evolving, self-building agents might work together. I’m currently developing a “system bus” to handle agent-to-agent communication in a more distributed, scalable way. Once that’s in place, I plan to circle back and strengthen all the fundamentals—agent evolution, storage (including vector DB), test coverage, governance checks, etc. My “production-grade” wording may have been too ambitious at this point, so consider it more of a vision statement than a claim of readiness.
A few clarifications based on the comments:
Agent Evolution Right now, the evolution mechanism is, honestly, a naive “please improve yourself” prompt approach. I fully agree it’s rudimentary. The plan is to add more robust ways to retrain or adapt an agent’s underlying models (and store interim states) so that “evolution” actually reflects meaningful improvements rather than superficial prompt tweaks.
Why YAML? I get the concerns—YAML can get bulky, and yes, there’s a joke about burying agents under a giant YAML file. I’m primarily using YAML for readability and version control; it’s simple to keep track of how agents communicate in a “single source of truth.” But nothing’s set in stone. If another structure or domain language works better, I’m open to exploring it.
Storage and Vector DB Several folks suggested a vector database or similar. I actually do plan to integrate a vector DB for more efficient embedding lookups and advanced search. The current approach is just a placeholder while I validate the overall workflow.
“Production-Grade” and Benchmarks Totally fair to question that term. I used it loosely to convey that I eventually want these agents to be robust enough for real-world scenarios, not just toy experiments. But I have a ways to go before calling it truly production-ready, and benchmarks will definitely be needed.
Governance I’m taking governance seriously. Agents “autonomously” evolving can definitely raise eyebrows around compliance, safety, and unexpected behaviors. My approach is to provide a “firmware” layer of guardrails that define domain rules and boundaries. As it matures, I plan to integrate testing and compliance checks for each agent’s modifications, so it’s not just a runaway chain of self-modifications.
Service Bus & Distributed Systems The upcoming feature is the “system bus,” which will support more robust service discovery and distributed task routing. That includes letting multiple agents run in different environments or infrastructure. Right now, everything is local and pretty simplistic.
Mocked Features Some of you noticed placeholders or references to incomplete features. Absolutely. My approach is to wire up the architecture first—even with partial stubs—so I can see how everything fits together. Once I know the big pieces make sense, I’ll replace these mocks with actual implementations and refine them.
Graphics & Diagrams I hear you: an actual flowchart or architecture diagram might be more useful than a generic AI-generated image. That’s on my to-do list, alongside better docs and examples. For now, I just wanted something to visually convey the concept in the README, but I’ll definitely add more meaningful visuals.
Collaboration I appreciate the offers to join forces! I’d love to collaborate more closely once the fundamentals are stable. For now, if anyone wants to experiment, provide feedback, or open an issue/PR on GitHub, that’s fantastic.
Thanks again for all the feedback and for checking this out. I know it’s a bit rough around the edges, but the goal is to create a toolkit for truly autonomous, evolving, and self-governed AI systems—while staying within safe operational boundaries. I’m excited to keep iterating and improving, and I welcome any further thoughts or contributions!