Quick Update: Introducing Architect-Zero in the Evolving Agents Toolkit
Hi everyone,
Thanks for all your feedback on the Evolving Agents Toolkit! Here's a quick update on an exciting new addition: Architect-Zero, a meta-agent built to autonomously create multi-agent solutions.
Architect-Zero includes several significant improvements:
Embedded Evolution Strategies: Replacing basic self-improvement prompts with advanced, targeted evolution methods built directly into the tools.
Pure ReAct SystemAgent: Now fully capable of reasoning and adapting its strategies autonomously without relying on fixed logic.
Agent Bus: A new system for agents to discover and communicate efficiently, allowing seamless coordination across distributed setups.
Currently, Architect-Zero is showing promise in practical scenarios, such as financial invoice analysis and healthcare assessment systems, autonomously designing teams of agents capable of managing complex tasks.
Please note that the toolkit is actively under development. The ultimate aim is to achieve robust production capabilities, but more improvements—especially to the Agent Bus—are needed before reaching that stage.
Following up on the feedback and refactoring mentioned previously, I've focused on solidifying the architecture based on the agent-centric philosophy. The key components and their interactions are now detailed here: https://github.com/matiasmolinas/evolving-agents/blob/main/d...
In short:
SystemAgent (ReAct): Orchestrates using specialized tools, not hardcoded logic.
ArchitectZero: Designs solutions, outputting a structured JSON design.
SmartLibrary: Manages component persistence and semantic search (using ChromaDB).
SmartAgentBus: Handles capability-based discovery and routing between agents/tools (basic implementation working).
Workflow Lifecycle: Clear Design -> Generate -> Process -> Execute flow managed by the SystemAgent.
Dual Bus Architecture: Based on @ismaelfaro's suggestion, I'm planning to split the SmartAgentBus implementation into a dedicated system bus (for metadata, discovery, system-level messages) and a data bus (for agent-to-agent payload communication). This feels like a cleaner way to manage the different communication needs.
Smart Context/Memory: Addressing concerns raised by @QuantGeekDev and others about context pollution and determinism, I'll be exploring concepts for smart memory and smart context. The goal is to develop mechanisms that help agents pass only the most relevant context during interactions over the agent bus, potentially using prioritization or summarization.
I also evaluated how MCP might fit in. Components like the SmartLibrary or SmartAgentBus could conceptually act as MCP servers, while agents like SystemAgent or ArchitectZero could be MCP clients. However, I ran into a fundamental question: If agents themselves can also act as tools (like in the OpenAI Agents SDK), does requiring potentially numerous MCP servers (one per agent/tool instance) scale well? Or is a different abstraction needed for direct agent/tool comms?
Given this, my immediate focus will be on refining the core communication patterns (dual bus, smart context) before deciding on the best way to integrate MCP specifically for agent-to-agent communication.
This is all evolving (pun intended!), and I'm actively working on the dual bus and smart context POCs now. You can see the current architecture details in the ARCHITECTURE.md link above. Keen to hear your thoughts on this direction!
Okay, there’s a new update: Evolving Agent Toolkits is now oriented toward providing the tools needed to implement AI-first strategies. Please check the updated project and let me know your thoughts. https://github.com/matiasmolinas/evolving-agents/blob/main/R...
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 started as a naive ‘please improve yourself’ prompt approach, but now I’m embedding multiple evolution strategies directly into each tool, allowing more sophisticated adaptation and versioning.
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”
We’ve moved that logic into specialized tools (e.g., SearchComponentTool, EvolveComponentTool) so it can evolve independently and become more sophisticated over time.
It’s more an aspirational vision than a claim of immediate readiness; the goal is eventually to support real-world, robust use cases but it’s still an early-stage project.
Hi everyone, just a quick update: we've now integrated full support for the OpenAI Agents SDK with our Smart Library, aligning perfectly with our core philosophy of reuse, evolve, and create—fully orchestrated by the System Agent and unified with robust firmware and guardrails. While the Agent Bus is still in its preliminary stages, this enhancement marks a significant step forward in ensuring seamless interoperability and smarter evolution strategies across frameworks. Your feedback has been invaluable, and I'm eager to hear your thoughts on this latest development as we continue to iterate and improve the system.
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.
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!
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 ?
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
We’re developing an ‘Agent Bus’ to enable distributed multi-agent orchestration, so agents can run across different environments in a more scalable, shared manner.
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!
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!
Quick Update: Introducing Architect-Zero in the Evolving Agents Toolkit
Hi everyone,
Thanks for all your feedback on the Evolving Agents Toolkit! Here's a quick update on an exciting new addition: Architect-Zero, a meta-agent built to autonomously create multi-agent solutions.
Architect-Zero includes several significant improvements:
Embedded Evolution Strategies: Replacing basic self-improvement prompts with advanced, targeted evolution methods built directly into the tools.
Pure ReAct SystemAgent: Now fully capable of reasoning and adapting its strategies autonomously without relying on fixed logic.
Agent Bus: A new system for agents to discover and communicate efficiently, allowing seamless coordination across distributed setups.
Currently, Architect-Zero is showing promise in practical scenarios, such as financial invoice analysis and healthcare assessment systems, autonomously designing teams of agents capable of managing complex tasks.
Please note that the toolkit is actively under development. The ultimate aim is to achieve robust production capabilities, but more improvements—especially to the Agent Bus—are needed before reaching that stage.
Explore the latest updates and examples:
GitHub Repository: https://github.com/matiasmolinas/evolving-agents
Run new examples: python evolving_agents/financial_example.py python evolving_agents/medical_example.py
Your ongoing feedback is very important. Feel free to share your thoughts on Architect-Zero and these recent updates!
Hey HN, quick update on the Evolving Agents toolkit (https://github.com/matiasmolinas/evolving-agents). Thanks again for all the great feedback on the original thread!
Following up on the feedback and refactoring mentioned previously, I've focused on solidifying the architecture based on the agent-centric philosophy. The key components and their interactions are now detailed here: https://github.com/matiasmolinas/evolving-agents/blob/main/d...
In short:
SystemAgent (ReAct): Orchestrates using specialized tools, not hardcoded logic.
ArchitectZero: Designs solutions, outputting a structured JSON design.
SmartLibrary: Manages component persistence and semantic search (using ChromaDB).
SmartAgentBus: Handles capability-based discovery and routing between agents/tools (basic implementation working).
Workflow Lifecycle: Clear Design -> Generate -> Process -> Execute flow managed by the SystemAgent.
The recent discussions on ACP (https://github.com/orgs/i-am-bee/discussions/284) have been super insightful and are guiding the next steps:
Dual Bus Architecture: Based on @ismaelfaro's suggestion, I'm planning to split the SmartAgentBus implementation into a dedicated system bus (for metadata, discovery, system-level messages) and a data bus (for agent-to-agent payload communication). This feels like a cleaner way to manage the different communication needs.
Smart Context/Memory: Addressing concerns raised by @QuantGeekDev and others about context pollution and determinism, I'll be exploring concepts for smart memory and smart context. The goal is to develop mechanisms that help agents pass only the most relevant context during interactions over the agent bus, potentially using prioritization or summarization.
I also evaluated how MCP might fit in. Components like the SmartLibrary or SmartAgentBus could conceptually act as MCP servers, while agents like SystemAgent or ArchitectZero could be MCP clients. However, I ran into a fundamental question: If agents themselves can also act as tools (like in the OpenAI Agents SDK), does requiring potentially numerous MCP servers (one per agent/tool instance) scale well? Or is a different abstraction needed for direct agent/tool comms?
Given this, my immediate focus will be on refining the core communication patterns (dual bus, smart context) before deciding on the best way to integrate MCP specifically for agent-to-agent communication.
This is all evolving (pun intended!), and I'm actively working on the dual bus and smart context POCs now. You can see the current architecture details in the ARCHITECTURE.md link above. Keen to hear your thoughts on this direction!
Okay, there’s a new update: Evolving Agent Toolkits is now oriented toward providing the tools needed to implement AI-first strategies. Please check the updated project and let me know your thoughts. https://github.com/matiasmolinas/evolving-agents/blob/main/R...
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-...
[dead]
It started as a naive ‘please improve yourself’ prompt approach, but now I’m embedding multiple evolution strategies directly into each tool, allowing more sophisticated adaptation and versioning.
> 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)
YAML makes it easy to version and visualize agent interactions, but I am open to more compact or alternative notations if it becomes unwieldy
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?
Integrating a vector DB is on the roadmap for advanced embedding lookups and improved semantic search; current storage is just a placeholder.
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.
We’ve moved that logic into specialized tools (e.g., SearchComponentTool, EvolveComponentTool) so it can evolve independently and become more sophisticated over time.
It’s more an aspirational vision than a claim of immediate readiness; the goal is eventually to support real-world, robust use cases but it’s still an early-stage project.
Hi everyone, just a quick update: we've now integrated full support for the OpenAI Agents SDK with our Smart Library, aligning perfectly with our core philosophy of reuse, evolve, and create—fully orchestrated by the System Agent and unified with robust firmware and guardrails. While the Agent Bus is still in its preliminary stages, this enhancement marks a significant step forward in ensuring seamless interoperability and smarter evolution strategies across frameworks. Your feedback has been invaluable, and I'm eager to hear your thoughts on this latest development as we continue to iterate and improve the system.
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.
[dead]
No, we plan to implement governance firmware, versioning, and test checkpoints to prevent runaways and maintain safety/compliance.
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.
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!
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.
These are in progress—we replaced the AI-generated image with more architectural diagrams and will add benchmarks as the project matures
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
We’re developing an ‘Agent Bus’ to enable distributed multi-agent orchestration, so agents can run across different environments in a more scalable, shared manner.
I love the approach
Would you like to join forces? Reach out to me: https://engageusers.ai/ecosystem.pdf
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!
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!
[dead]